我希望这不是一个愚蠢的问题，如果是的话，我想至less要把它弄清楚，所以我不会在将来感到这么愚蠢。
在这里，我们正在用Windbg加载Windows崩溃转储。 以下是debugging器输出的前几行：
0: kd> .dumpdebug ----- 64 bit Kernel Summary Dump Analysis DUMP_HEADER64: MajorVersion 0000000f MinorVersion 00001db1 ... MinorVersion我大部分理解。 它是hex的，它翻译成十进制的7601。 Windowspipe理员已经可以从中得知，这必须是Win7 x64机器或带有SP1的2k8 R2机器。 但不是7601的内部编号？ 这应该是Major.Minor.Build/Revision …对不对？
另外我不了解MajorVersion。 应该是6.这个版本的Windows是6.但十进制hex15不是0000000f？
此版本Windows的完整版本string（例如启动命令提示符时）为6.1.7601。 如果7601是MinorVersion，那么什么是1，什么是6？ 为什么崩溃转储会说0F？
MinorVersion确实指的是内部版本号，如果你愿意滥用较旧的机器/操作系统，你可以通过匹配（例如）一些XP和2003盒子的版本号与MinorVersion dump_header 。
你可能还会注意到（或者至less我做过）那些转储debugging文件中的0000000f也是0000000f ，尽pipe内核版本不同。 所以，它显然不是指内核版本…或者，至less是不正确的。 至于它是指什么……好吧，绝对不是一个愚蠢的问题，虽然我没有答案。 然而。
发现一些非常刺激的东西。
在Windows 2000和Windows NT 4上，转储debugging文件中的MajorVersion是free system 。 这个字段的含义似乎没有记载，尽pipefree system是我从微软看到的所有例子转储（如NT工作站资源工具包）中显示的 ， 甚至是关于如何使用dumpchk.exe的KB适用于2008和Windows 7系统。
开始看起来可能是没有意义的，或者是一个bug？ 至less这次不是0xB16B00B5或0x0B00B135 。