Windows setup for winxp 64 bit checked build guest freezes

[Jason]

Hi, not sure what info you guys need me to post but I'm running win7 host system. I'm upgraded to the new 4.1.6 version I saw today but this was happening with my prior version too.

I'm trying to install a winxp 64bit checked build guest. Windows setup gets stuck really fast with a mostly black blue screen that just says Windows Setup at the top and "Setup is starting Windows" in the grey status line at the bottom. I've tried with Enable Nested Paging both on and off. (as I saw old posts suggesting this as a workaround)

I definitely get past this in a normal wix xp 64 bit build guest. (Haven't fully installed it but I get to the point where it asks for the product key).

[Jason]

vbox.log

[x64]

Have same issue with VirtualBox 4.2 on host Windows 7 SP1 x64, log and screenshot attached above. Please, fix this bug.

[Frank Mehnert]

Please attach a VBox.log file taken from a VM running on VirtualBox 4.2.4.

[x64]

Log from VirtualBox 4.2.4

[Matthijs Lavrijsen]

I'd like to resurrect this thread, as I just ran into this exact same issue - 6 years after it was reported! (using VirtualBox 5.2.97 from SVN r70507). Why was this thread closed, and does 'obsolete' refer to the ticket or the support status of XP x64?

I managed to work around the issue (well, several issues...) and get the OS and even service pack 2 to install. However this was not trivial, so I am posting reproduction steps here in case anyone else comes across this problem in the future.

First, I have to clarify something, because the previous posters apparently did not get this memo: YOU SHOULD ALWAYS HAVE A KERNEL DEBUGGER ATTACHED WHEN RUNNING A CHECKED KERNEL! This is literally why the checked kernel exists. It pedantically asserts on anything that is deemed even slightly wrong or unexpected. If you don't have a debugger attached, you can assume 'assert' in the previous sentence to simply mean 'crash'. (Checked kernels have gotten slightly more user friendly since Windows 7 and may not always kill the machine if no kernel debugger is present. But XP and Server 2003 are a bit more hardcore.)

Why am I saying this? Because the 'hang' that is occurring is simply a kernel assert manifesting with no debugger attached (which for all intents and purposes is the same thing - VirtualBox also reports nothing in the log). On the other hand, if you have a debugger attached, you can handle the assert and (usually) continue.

VM setup

PIIX3 chipset, I/O APIC enabled (required), 1-4 CPUs, 2+ GB RAM, PAE/NX, VT-x and nested paging enabled, paravirtualization left at default. For storage simply use a PIIX4 IDE controller with a VDI attached as primary master and obviously the installation CD. Finally, add a serial port as follows: port: COM1, port mode: host pipe, do not connect to an existing socket, path/address: \\.\ pipe\vbox_xp_x64_chk .

(My host machine: Windows 7 x64, Core i7 6700K, 32 GB RAM.)

Installation

- Make a shortcut to WinDbg with the following command line: windbg.exe -k com:pipe,port=\\.\pipe\vbox_xp_x64_chk,resets=0,reconnect and launch it. WinDbg is now pending in wait mode.

- Start the VM. The boot loader will automatically detect the serial port and launch the setup environment in kernel debug mode(!). If all went well, you will now finally be greeted with the assert message:

Windows Server 2003 Kernel Version 3790 MP (1 procs) Checked x64
Built by: 3790.srv03_sp1_rtm.050324-1447
Machine Name:
Kernel base = 0xfffff800`01000000 PsLoadedModuleList = 0xfffff800`013cdfd0
System Uptime: not available

*** Assertion failed: FALSE
***   Source File: d:\srvrtm\base\busdrv\acpi\driver\shared\loaddsdt.c, line 488

Break repeatedly, break Once, Ignore, terminate Process, or terminate Thread (boipt)?

Further investigation points to acpi.sys!GetFadtTablePointerEntry as the culprit. Now, I know just enough about ACPI to know that I never want to know anything about it, but fortunately coreboot knows about this one: ​"There's a faulty assert in acpi.sys that trips only on checked builds.". So, no VirtualBox bug here.

- Like the prompt says, you can now simply continue execution by entering 'i' for 'ignore'. As this is a spurious assert this is harmless. The same assert will repeat a few more times, depending on CPU count.

- Oops! Here's another one.

*** Assertion failed: NumberOfBytes != 0
***   Source File: d:\nt\base\ntos\mm\iosup.c, line 8861

This assert is actually from the kernel (nt!MmMapIoSpace) and fairly serious. At the very least it indicates a poorly programmed driver. Type kb to see which driver that might be! (spoiler alert: it's acpi.sys happily carrying on with the invalid data it just threw a fit about). Still no VirtualBox bug so far.

- The rest of the text mode part of setup should now work as normal, so that you will have a bootable hard disk with a minimal NT environment to start the GUI part of the installation. Here we have a slight issue: the GUI installer will not start in debug mode by default. The solution to this is to spam F8 at startup and to select debug mode from the startup options. Unfortunately, the installation CD will get in the way with its 'press any key to start from CD...' prompt, making this impossible. Solution: (1) as the text mode is about to reboot (it will show a notification with a countdown), eject the CD from the VM through the VirtualBox menu, (2) wait for the VM to reset and start hammering F8 furiously until you see the boot options menu, (3) re-insert the CD again while still at the boot menu because setup will fail catastrophically without it, and finally (4) select 'Debugging Mode' from the menu and press enter. You know how to deal with the first two asserts by now.

- This is the final assert I encountered during setup (as well as every regular boot afterwards), and the one that is in my opinion caused by a VirtualBox bug:

*** Assertion failed: Update: Driver did not load a microcode update
(CurrentUpdateRevision != 0)
***   Source File: d:\srvrtm\drivers\filters\update\update.c, line 1108

(source: update.sys)

Windows 7 checked has the exact same problem with a slightly wordier meessage:

*** Assertion failed: The system BIOS on this machine does not properly
support the processor.  The system BIOS did not load any microcode update.
A BIOS containing the latest microcode update is needed for system reliability.
(CurrentUpdateRevision != 0)
*** Source File: d:\nt\drivers\filters\update\update.c, line 1115

(source: mcupdate_GenuineIntel.dll)

What's happening here? Windows ships with CPU microcode update loaders for both Intel and AMD CPUs. These drivers can load a CPU microcode update onto a CPU in the case that the microcode version in the driver is newer than the one that was initially loaded by the BIOS (often the case on consumer systems, where BIOS updates are infrequent). The driver queries the version of the microcode signature that is currently loaded using the MSR IA32_BIOS_SIGN_ID (ref: Intel Software Developer’s Manual Vol 3, 9.11.7.1 - "Determining the Signature"). The problem is that VirtualBox returns 0 here, which means that no microcode was loaded by the BIOS at all, even though it's its responsibility to do so. Of course, since we are inside a VM, we can't actually update the microcode, at least not without help from the hypervisor, which we aren't going to get for good reason. What we can do is return a fake microcode update signature version that is greater or equal than the one the driver is carrying so that it won't attempt to update the microcode. And indeed, if we look at VMMAll/CPUMAllMsrs.cpp, it seems that someone already had this idea, but didn't feel like implementing it:

/** @callback_method_impl{FNCPUMRDMSR} */
static DECLCALLBACK(VBOXSTRICTRC) cpumMsrRd_Ia32BiosSignId(PVMCPU pVCpu, uint32_t idMsr, PCCPUMMSRRANGE pRange, uint64_t *puValue)
{
    RT_NOREF_PV(pVCpu); RT_NOREF_PV(idMsr); RT_NOREF_PV(pRange);
    /** @todo fake microcode update. */
    *puValue = pRange->uValue;
    return VINF_SUCCESS;
}

I changed this function to

/** @callback_method_impl{FNCPUMRDMSR} */
static DECLCALLBACK(VBOXSTRICTRC) cpumMsrRd_Ia32BiosSignId(PVMCPU pVCpu, uint32_t idMsr, PCCPUMMSRRANGE pRange, uint64_t *puValue)
{
    RT_NOREF_PV(pVCpu); RT_NOREF_PV(idMsr); RT_NOREF_PV(pRange);
    *puValue = 0xFFFFFFFF00000000ULL; // [edx:eax]
    return VINF_SUCCESS;
}

So that the signature version is always reported as UINT32_MAX. This fixes the assert. (On Intel CPUs, that is - it could be that AMD CPUs require a different approach or simply don't have this issue at all for some other reason.)

- Complete the rest of the installation as normal. I recommend installing Service Pack 2 immediately afterwards, because it has public debug symbols available on the MS symbol store server (unlike the SP1 files, which makes a checked installation of XP x64 SP1 worse than useless).