On some systems, both physical and virtual, 64-bit Windows 8.1 as well as Server 2012 R2 consistently crashes with error code (bug check) 0xC4; 64-bit Windows 8 may run on these same systems without trouble. On physical systems, the BSOD is typically accompanied by the machine rebooting so fast that it is very difficult to read the error message at all. If the system keeps attempting to boot Windows 8.1, this results in a nice reboot loop.
In VirtualBox, users at least have a chance to read the error message before the VM terminates with a fatal error:
Not that the error message is in any way helpful. According to MSDN, bug check 0xc4 means DRIVER_VERIFIER_DETECTED_VIOLATION and the first argument of 0x91 is “reserved”. But wait, a driver verifier violation usually means buggy software, so how can that happen with a Windows 8.1 installation DVD? Windows 8.1 couldn’t be buggy, could it?
Short answer… yes, it could be. The long answer is a bit more complicated, but the Windows kernel debugger provides all the clues.
It doesn’t help that Microsoft helpfully disabled the F8 start-up key on Windows 8.1, as that makes debugging the installation disc itself just about impossible. Fortunately the F8 key survived in Windows Server 2012 R2, and the two systems are very, very similar.
Hitting F8 early enough in the start-up sequence (the first “loading files” progress bar) brings up the following menu:
The “Debugging Mode” selection allows WinDbg to attach to the system/VM. And soon enough, WinDbg hits a bug check… but wait—it’s not bug check 0xC4, it’s 0x5D or UNSUPPORTED_PROCESSOR. MSDN is again unhelpful. Sadly, Geoff Chappell has not yet updated his excellent bug check 0x5D documentation to cover this issue either.
But instead of perhaps BSODing with the 0x5D bug check, Windows hits a 0xC4 bug check if it is allowed to continue executing. According to WinDbg, that bug check is caused by incorrect stack switching. Whether that is really the case is difficult to tell. At any rate, WinDbg classifies it as a software bug (in Windows itself, since there’s nothing else installed yet).
The reason for the 0x5D bug check on 64-bit Windows 8.1/Server 2012 R2 is typically the lack of a CMPXCHG16B instruction. One might think that a company with the resources of Microsoft would adequately document the exact processor requirements for a server OS, but that does not appear to be the case. But fear not—for those willing to make the leap of faith that Windows 8.1 and Server 2012 R2 is the same thing, the documentation does exist: “To install a 64-bit OS on a 64-bit PC, your processor needs to support CMPXCHG16b, PrefetchW, and LAHF/SAHF”. And no, this is not exactly news.
The new Windows 8.1/Server 2012 R2 requirements only affect fairly old processors, most likely only CPUs produced in 2005 and earlier. There were a few Intel CPUs based on the Pentium 4 architecture which didn’t support LAHF/SAHF, but those are probably on the scrap heap where they always belonged.
However, the entire first generation of AMD Opteron and Athlon 64 processors is affected because those CPUs did not support the CMPXCHG16B instruction. Indeed the problem described here was easy to reproduce on a system equipped with an Athlon 64 3200+ CPU.
For those without historic hardware at hand, a VirtualBox VM will do, as long as the guest OS type is set to something other than Windows 8.1 or Server 2012 R2. VirtualBox will then not enable the CMPXCHG16B instruction and Windows 8.1 will crash as described above.
The exact cause is unclear but the problem may be caused by the 0x5D bug check occurring before the NT kernel is prepared to deal with bug checks. The OS is not fully initialized and hits the 0xC4 bug check. That will soon invoke nt!KiBugCheckDebugBreak and then nt!DbgBreakPointWithStatus.
The latter is basically just an INT3 instruction and then things go horribly wrong. The IDT is either not fully initialized or corrupted, and the system can’t handle exceptions. A triple fault ensues (the CPUs way of saying “I’m utterly lost and can’t go on anymore”), which on physical systems usually causes a reboot of the system. In virtualized environments it typically terminates the VM.
For physical systems which hit this error, there’s nothing that can be done other than upgrading the hardware or downgrading the OS. They’re just not supported by 64-bit Windows 8.1.
For VirtualBox VMs, the situation is a bit different. There do not appear to be any CPUs that would support hardware virtualization and not support CMPXCHG16B (although conclusively proving this is impossible). Because VirtualBox requires hardware virtualization for 64-bit VMs, it’s more or less certain that the CPU does support CMPXCHG16B, and it just needs to be enabled for the VM. For recent VirtualBox releases, simply setting the guest OS type to Windows 8.1 (64-bit) or Windows Server 2012 R2 will do the trick.
It’s clear that although 64-bit Windows 8.1/Server 2012 R2 enforces the presence of required CPU features, Microsoft never adequately tested the failure scenario. This causes the users of affected systems to needlessly suffer because they do not get any useful diagnostic information, and may not even be able to read the error message (such as it is) at all. While obscure, such bug is hardly something that would inspire confidence.