I found out a bit more from the product group. It seems some legacy operating systems, like Windows NT 4.0, bugcheck if they perform a CPUID and have more than three leafs returned. The checkbox is there to allow us to try and get them working. So I was on the right track after all. I still think this functionality does limit what functions of the processor can be detected and suggest you try and leave it off if you can.
It is important to note that the operating systems are not necessarily supported by Hyper-V.
For more information about how Microsoft defines what operating systems are supported on Hyper-V checkout the Windows Server Virtualization Blog at http://blogs.technet.com/virtualization
And in case you didn't know yet! Hyper-V RC1 was released to Windows Update last week!
BTW, this isn't the only problem that NT 4's CPUID code have, another is that it truncates the family code to 3 bit, forcing Intel to use family 15 for the Pentium 4 processor (family 7 was already occupied by the Itanium).
In fact, before NT 4.0 SP6a, there were other bugs:
* NT 4.0 before SP4 crashed if CMPXCHG8B is reported as available in CPUID and the processor vendor is not AMD or Intel.
The workaround was to mask the CMPXCHG8B CPUID feature flag out.
* NT 3.50 did not install if the family code as reported in CPUID is higher than 5:
NT 3.51 fixed this bug. The workaround was to modify files on the installation CD to get NT 3.5 to install.
These bugs left me wondering about the general quality of the NT 4.0 CPUID code. I am glad MS fixed all of these issues for Windows 2000.
I was going to disassemble NT 4's ntoskrnl, but Geoff Chappell already did it:
Thanks Yuhong. Your comments and links have been great. It's nice to learn from others.