4

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?

Improve this question
4

1 Answer 1

Reset to default
3

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.

Improve this answer
5
  • +1 because you've become one of my favorites on Serverfault. You seem to always have something good to add to the discussion. Thank you.
    – Ryan Ries
    Oct 4, 2012 at 1:14
  • @RyanRies Still no complete answer? :( Guess I'm gonna have to try burning some MS support time on this. "Hey, we're getting recurring crashes with Server 2012 on [some system I made up], also what does this field mean?" If I get an answer worth posting, I'll add it to my answer here and ping you.
    – HopelessN00b
    Oct 9, 2012 at 15:16
  • No complete answer, but this is the best I've gotten so far. It turns out that this makes a pretty good conversation with my geekier friends, as I've gotten several of them on the hunt to solve the mystery as well. :)
    – Ryan Ries
    Oct 9, 2012 at 15:18
  • Oh and I've heard that "free system" is opposed to the checked or debug build... or something.
    – Ryan Ries
    Oct 9, 2012 at 15:20
  • I believe the "debug" build died a LONG time ago (before NT shipped?), leaving only "free" and "checked". And "checked" got axed recently, too: github.com/MicrosoftDocs/windows-driver-docs/commit/…
    – SamB
    Mar 29, 2021 at 23:30

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .