Home / server / Questions / 434648
Accepted
Ryan Ries
Asked: 2012-10-04 15:31:50 +0800 CST

Crash dump analysis

  • 772

I hope this isn't a stupid question, and if it is, then I want to at least get it over with so I don't feel so dumb in the future.

Here we are, loading up a Windows crash dump with Windbg. Here are the first few lines of the debugger output:

0: kd> .dumpdebug
----- 64 bit Kernel Summary Dump Analysis
DUMP_HEADER64:
MajorVersion 0000000f
MinorVersion 00001db1
...

The MinorVersion I mostly understand. It's hexadecimal and it translates to 7601 in decimal. Windows admins would already be able to tell from that that this must be either a Win7 x64 machine or a 2k8 R2 machine with SP1. But isn't 7601 the build number? It's supposed to be Major.Minor.Build/Revision... right?

Also I don't understand the MajorVersion. It should be 6. This version of Windows is 6. But isn't 0000000f in hexadecimal 15 in decimal?

The full version string of this version of Windows, when you launch the Command Prompt for instance, is 6.1.7601. If 7601 is the MinorVersion, then what is 1 and what is 6? And why does the crash dump say 0F?

windows

1 Answers

  1. Best Answer

    Partial answer:

    The MinorVersion does indeed refer to the build number, and if you're willing to abuse older machines/OSes, you can verify that across platforms by matching up the build number of (for example) some XP and 2003 boxes with the MinorVersion in the dump_header.

    You'd probably also notice (or at least I did) that the MajorVersion in those dump debug files is also 0000000f, despite the different kernel version. So, it obviously doesn't refer to the kernel version... or, not correctly at least. As to what it does refer to... well, definitely not a stupid question, though I don't have an answer for that. Yet.

    Update:

    Found something very irritating.

    On Windows 2000 and Windows NT 4, the MajorVersion in the dump debug file is free system. And the meaning of this field seems to be undocumented, though free system is what's shown in all the example dumps I've seen from Microsoft, such as in the NT Workstation Resource Kit, and even the KB on how to use dumpchk.exe that applies to 2008 and Windows 7 systems.

    Starting to look like it might be meaningless, or a bug? At least it's not 0xB16B00B5 or 0x0B00B135 this time.

    • 3