gbr
gbr

Reputation: 1302

Is WinDbg's vertarget command always accurate?

I wonder because running it on a client's minidump it reports a different Windows version than the client repeatedly told me she had, and the version I'm being reported happens to be exactly the same version I'm running WinDbg on.

So I wonder, can vertarget always be trusted (and clients not) or the information it relies on may be absent with some dump generation options and when it is it reports the version WinDbg is currently running on, or maybe just some default that happens to coincide with my OS version?

I'm using WinDbg 6.12.

Upvotes: 1

Views: 909

Answers (1)

Thomas Weller
Thomas Weller

Reputation: 59303

In all my cases so far, vertarget has been correct and the customer/client made a mistake - and vertarget is one of the commands I use for every dump, exactly for the purpose of checking if the dump contains what I need.

But perhaps, things can potentially go wrong here as well, so let's evaluate some options:

  1. vertarget also reports debug session time and system uptime. Do those also match your system? Reboot your system in order to get a low system uptime and check again. Is it still your PC's uptime?

  2. vertarget also reports the number of CPUs. Does that number match your number?

  3. Get a virtual machine which does not have your OS, e.g. one from Modern.IE (Microsoft). Copy WinDbg and the dump to the VM and check the output of vertarget again.

  4. WinDbg 6.12 is a bit old. Do newer versions (6.2.9200 / 6.3.9600 or even 10.0) provide the same information or was there a bug fixed already?

And even check some other information:

  1. Is it a dump of the correct application? Use | (pipe)

  2. Is it a dump of the version you are expecting? Use lm vm <exename>

  3. Does it have the flags which can be expected for the method used for taking the dump? Use .dumpdebug.

Other than that I observe (not representative) that many client OS version dumps (Windows 7, 8, 8.1) have all latest service packs installed, while administrators seem to follow the "never change a running system" approach for server OS (Windows Server 2012, R2). So it might just be a coincident.

Upvotes: 4

Related Questions