Windows 11 Preview 26016 install doesn't boot on 7.0.12

[Tronmch2]

This is more an FYI than a problem report... I was installing various Windows 11 preview releases to investigate whether they fixed a particular windows explorer integration crash... I was having great luck installing Windows 11 previews, until I tried the 26016 "canary" build...

The install hung solid with the Virtualbox logo after the "press any key to boot from CD or DVD" prompt... This was reproduced on Windows hosts and an Ubuntu 22.04.2 host...

I then installed 7.0.14, which apparently JUST came out... Because that is literally the first question I would have been asked: "What happens on the current release?" And it worked. While the changelog doesn't appear to have anything in it that SHOULD cause it to hang, one of the fixes apparently does solve the issue...

Just letting folks know...

[fth0]

While the changelog doesn't appear to have anything in it that SHOULD cause it to hang, one of the fixes apparently does solve the issue...

I think the change was too specialized to be mentioned in the Changelog, and Windows Previews aren't officially supported anyway. If you're interested in the details: Changeset 102630.

[PlinioDePaula]

Hi.
I was discussing very similar issue in the VB forum Windows Hosts pre-releases:
Canary builds 25987 25992 cannot start any VirtualBox, Feedback bug is open

Unfortunately it seems I'm having a different issue with Guest Windows 11 Preview 26016 as neither the hpet workaround nor updating to latest Vbox 7.0.14 solved my issue.

I've collected this Vbox.log excerpt that seems to point the root cause but couldn't find a way to fix it (aside from disabling HW VT-x acceleration and going into "turtle mode"):

Code: Select all

00:00:36.454367 GIM: HyperV: Guest OS reported ID 0x1040a0000271b
00:00:36.454367 GIM: HyperV: Open-source=false Vendor=0x1 OS=0x4 (Windows NT or derivative) Major=10 Minor=0 ServicePack=0 Build=10011
00:00:36.455300 GIM: HyperV: Queried extended hypercall capabilities 0x1 at 0x0000000003229000
00:00:36.455326 GIM: HyperV: Queried boot zeroed guest memory range (starting at 0x0000000000000000 spanning 2181657 pages) at 0x0000000003229000
00:00:36.459250 GIM: HyperV: Queried extended hypercall capabilities 0x1 at 0x0000000000008000
00:00:36.459347 GIM: HyperV: Enabled TSC page at 0x000000000000d000 - u64TscScale=0x1da12c900000000 u64TscKHz=0x151802 (1 382 402) Seq=1
00:00:36.459386 TM: Switching TSC mode from 'VirtTSCEmulated' to 'RealTSCOffset'
00:00:36.459488 GIM0: HyperV: Enabled APIC-assist page at 0x000000000000e000
00:00:36.459554 IEM: rdmsr(0x123) -> #GP(0)
00:00:36.459651 GIM: HyperV: Guest indicates a fatal condition! P0=0xa P1=0x7fffffff0000 P2=0xff P3=0x0 P4=0xfffff804122edfc5
00:00:36.459734 GIMHv: BugCheck a {7fffffff0000, ff, 0, fffff804122edfc5}
00:00:36.459735 IRQL_NOT_LESS_OR_EQUAL
00:00:36.459735 P1: 00007fffffff0000 - memory referenced
00:00:36.459736 P2: 00000000000000ff - IRQL
00:00:36.459736 P3: 0000000000000000 - bitfield
00:00:36.459736     b0: 0 - read operation
00:00:36.459736     b3: 0 - execute operation
00:00:36.459737 P4: fffff804122edfc5 - EIP/RIP
00:00:50.343743 Changing the VM state from 'RUNNING' to 'SUSPENDING'
00:00:50.364175 PDMR3Suspend: 20 342 784 ns run time
00:00:50.364196 Changing the VM state from 'SUSPENDING' to 'SUSPENDED'
00:00:50.364206 Console: Machine state changed to 'Paused'
00:00:54.481758 GUI: Request for close-action to power VM off.
00:00:54.482568 GUI: Powering VM off..

Anyone, any guess how to fix it?!

[fth0]

The VBox.log excerpt indicates a BSOD in the Windows guest OS, so the next step would be to analyze the corresponding Windows minidump file in the Windows guest.

Note that you can add the virtual disk image of the Windows guest to another VM to access its file system.

[PlinioDePaula]

The VBox.log excerpt indicates a BSOD in the Windows guest OS, so the next step would be to analyze the corresponding Windows minidump file in the Windows guest.

Note that you can add the virtual disk image of the Windows guest to another VM to access its file system.

Hi @fth0.
I don't reach this point.

Like in the initial post, I'm still at the early Windows CD/ISO Install boot phase:

The install hung solid with the Virtualbox logo after the "press any key to boot from CD or DVD" prompt...

There's no [mini]dump at all except for the Vbox.log messages.

I've already tried a LOT of things but can't get this WIn11 Insider Canary 26016 Guest install to work under Vbox 7.0[.14]!

[fth0]

Then I see at least two possible directions to go:

1. You could provide a complete (zipped) VBox.log file in the hope that someone notices something unusual in it.

2. Depending on your Windows developer skills, you could do "remote" Windows debugging. The "remote" means from the host to the guest in this case, and the "Windows" is the Windows PE from the ISO file.

[PlinioDePaula]

Hey guys.
FINALLY good news!

Got Win11 Canary 26016 guest install working by DISABLING the VT-x Unrestrict Guest mode:

Code: Select all

VBoxManage modifyvm <Win11 VM> --vtxux off

7.8. VBoxManage modifyvm

--vtxux on|off: If hardware virtualization is enabled, for Intel VT-x only, this setting enables or disables the use of the unrestricted guest mode feature for executing your guest.

Seems that this option, at least with my CPU, is incompatible with newer Win11 Canary builds.

@fth0,
Maybe we should report this as new Virtualbox bug like the hpet one.

[fth0]

Congratulations!

Could you provide (zipped) VBox.log files from two runs of the VM, one with and one without Unrestricted Guest mode, both taken after closing the VM, so that the VirtualBox statistics get written to the log file?

[Tronmch2]

The weird part is that I suddenly stopped being able to boot my 26016 VM under VB 7.0.14... And then could not install (again) with the issue in the other thread I just created... Crash every time with no visible BSOD.

My default log WITHOUT
VBoxManage modifyvm <Win11 VM> --vtxux off

is in vbox-stalled.zip... Waiting on the install to finish before collecting the good log.

[Tronmch2]

And here is the one after setting that option...

[fth0]

00:00:15.411089 IEM: rdmsr(0x123) -> #GP(0)
00:00:15.411138 GIM: HyperV: Guest indicates a fatal condition! P0=0xa P1=0x7fffffff0000 P2=0xff P3=0x0 P4=0xfffff8037faedfc5
00:00:15.411172 GIMHv: BugCheck a {7fffffff0000, ff, 0, fffff8037faedfc5}
00:00:15.411173 IRQL_NOT_LESS_OR_EQUAL
00:00:15.411173 P1: 00007fffffff0000 - memory referenced
00:00:15.411173 P2: 00000000000000ff - IRQL
00:00:15.411173 P3: 0000000000000000 - bitfield
00:00:15.411173     b0: 0 - read operation
00:00:15.411174     b3: 0 - execute operation
00:00:15.411174 P4: fffff8037faedfc5 - EIP/RIP

The Windows guest OS tries to read MSR 0x123 (IA32_MCU_OPT_CTRL) without checking for its availability in CPUID.(EAX=07H,ECX=0).EDX[SRBDS_CTRL = 9], which VirtualBox does not provide to the guest. Therefore, I'll make an educated guess that the guest OS crash ~50 microseconds later relates to this bug in the guest OS.

PS: I don't know why disabling the Unrestricted Guest CPU feature makes a difference.