Ticket #20034 (closed defect: fixed)

Opened 2 years ago

Last modified 4 weeks ago

CMPXCHG16B is not provided to Windows Server 2019 guests

Reported by: fth0 Owned by:
Component: other Version: VirtualBox 6.1.16
Keywords: CMPXCHG16B Cc:
Guest type: Windows Host type: Windows


The hack in ConsoleImpl2.cpp?rev=86506#L936 obviously cannot work for "Windows 2019 (64-bit)" as "Guest OS Version". The Windows Server 2019 installer runs up to an INT3, leading to a Guru Meditation (see forum topic  VMs crash when VM OS Version set to Window 2019 for a VBox.log file if necessary).

Change History

comment:1 Changed 2 years ago by fth0

In the case of the forum user, the host CPU is missing the Unrestricted Guest CPU feature. In consequence, VirtualBox doesn't provide the CX16 CPU feature to the guest OS. When the Guest OS Version is configured as "Windows 2016 (64-bit)", the CX16 CPU feature is provided to the guest OS because of the hack, and the crash doesn't happen.

Disclaimer: The term hack is copied from the VirtualBox source code referenced in the description. ;)

comment:2 Changed 17 months ago by klaus

Thanks for the reminder today... we clearly missed both the forum posts and this ticket.

In the latest 6.1 Testbuilds this should be fixed (for good, because the reasons why we had to handle it in a hacky way have been eliminated quite a while ago). The same builds also have a fix for the forgotten adaption of the Paravirt Provider default (HyperV) for Windows Server 2016 and 2019. Not quite as much "for good", but should still last a while.

Revision 145326 or later has the change.

comment:3 Changed 17 months ago by fth0

I confirm that this issue is fixed with VirtualBox 6.1.23r145326: For a Windows Server 2019 guest, the effective paravirtualization provider is now "HyperV", CX16 (CMPXCHG16B) is provided to the guest, and the Windows Server 2019 installation ISO boots successfully up to the installer, instead of executing INT3 leading to the Guru Meditation.

FWIW, during my tests, I once encountered a BSOD in the Windows memory management, but it wasn't reproducible and the VM didn't crash.

Thanks a lot for addressing this issue, which was recurring regularly in the VirtualBox forums.

comment:4 Changed 17 months ago by fth0

I confirm that this issue is fixed in VirtualBox 6.1.24.

comment:5 Changed 4 weeks ago by aeichner

  • Status changed from new to closed
  • Resolution set to fixed
Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use