A Windows 11 guest that sits on a black screen in VirtualBox — no firmware logo, no "Press any key to boot" prompt, no Setup — is most likely hitting a known VirtualBox defect that strikes when the machine runs through the Windows hypervisor (Hyper-V) and has two or more vCPUs. You do not need a new ISO or a rebuilt VM: one extra-data setting makes it boot again without touching your Hyper-V setup.
The quick fix
Power the VM off completely (a saved state will not do), then run this in a terminal, substituting your VM's name:
VBoxManage setextradata "My Windows 11 VM" "VBoxInternal/EM/ExitOptimizationEnabled" 0
The command disables an execution-engine optimization that misbehaves on the Hyper-V code path; it changes nothing else about the VM. On the next start, the UEFI firmware should finish initializing and show the usual boot prompt. If a later VirtualBox release fixes the underlying bug, you can remove the override by rerunning the same command without the final 0.
Why the display never comes up
With multiple virtual CPUs, UEFI firmware must wake and synchronize the secondary processors very early in boot — before it initializes any graphics. On the Hyper-V execution path, that coordination currently deadlocks inside VirtualBox's built-in firmware, so the machine stalls while it is still several steps away from setting a video mode. This explains the two symptoms people find most baffling:
- No output at all. The firmware never reaches the stage where it would draw a logo or a boot prompt, so there is literally nothing to see.
- Screenshots fail. Running
VBoxManage controlvm "<VM name>" screenshotpng screen.pngreports an unsupported resolution of0x0, because the guest never announced a display mode to VirtualBox.
How to confirm this is your case
Open the VM's log (VBox.log) and look near the top for these lines:
HM: HMR3Init: Attempting fall back to NEM: VT-x is not available
NEM: NEMR3Init: Snail execution mode is active!
The first line means VirtualBox could not take control of the CPU's hardware virtualization because something else already owns it — on a Windows host, virtually always Hyper-V. The second confirms the guest executes indirectly through the Windows hypervisor. Farther down, the EFI log stops abruptly after loading a handful of early firmware drivers (names such as Tcg2Dxe.efi or PciHostBridgeDxe.efi) and logs nothing more: that silence is the hang itself. If all three signs match, the workaround above is the right fix.
What "Snail mode" costs you
The black screen is only the visible symptom. A CPU's virtualization instructions (Intel VT-x or AMD-V) can be owned by exactly one hypervisor at a time. Once Hyper-V is active — which happens automatically with WSL 2, Docker Desktop's default backend, Windows Sandbox, or Core Isolation — VirtualBox must route every guest instruction stream through the Windows hypervisor and back. Each event where the guest touches disk, network, timers, or the screen takes a longer round trip:
Hyper-V off: guest <-> VirtualBox
Hyper-V on: guest <-> Windows hypervisor <-> Windows kernel <-> VirtualBox
VirtualBox's own nickname for this situation, "Snail execution mode," is apt: things work, but slowly.
Choosing between Hyper-V and VirtualBox
You cannot have both at full strength, so pick deliberately:
- Keep Hyper-V and accept the slowdown. Apply the workaround and continue using WSL 2 alongside VirtualBox. This is fine for occasional testing and installations, painful for long builds or heavy workloads.
- Give VT-x back to VirtualBox. In an elevated PowerShell, run
bcdedit /set hypervisorlaunchtype offand reboot. WSL 2, Docker Desktop's WSL backend, Windows Sandbox, and Hyper-V VMs stop working until you revert withbcdedit /set hypervisorlaunchtype auto. - Switch hypervisors. VMware Workstation Pro copes much better when Hyper-V is present and stays reasonably fast. The trade-off: WSL 2, Docker, or Hyper-V will not run inside its guests.
Preventing a repeat
- Glance at the first lines of
VBox.logwhenever you create a new VM; knowing immediately whether you are in NEM mode saves hours of confusion later. - Keep VirtualBox updated. The defect is tracked in the project's public issue tracker, and a future build may make the workaround unnecessary.
- Treat Hyper-V as a switch: turn it off for demanding VirtualBox sessions, and back on (
auto) when you need WSL 2.
Frequently Asked Questions
Is the workaround safe, and how do I undo it?
Yes — it toggles a single VirtualBox execution-engine flag for that one VM and affects nothing else on the host. To remove it later, rerun the same setextradata command without the final value.
Why is there no error message, just blackness?
The failure happens inside the firmware, before any video mode exists. Even the firmware logo requires an initialized display, so a deadlock this early leaves nothing on screen — and screenshots report a 0×0 resolution.
Does this also happen without Hyper-V?
The hang is specific to the indirect execution path (NEM) that Hyper-V forces. With Hyper-V off, VirtualBox drives the CPU's virtualization features directly, and multi-vCPU UEFI guests boot normally.
Will disabling Hyper-V break WSL 2 permanently?
No. WSL 2 depends on the Windows hypervisor, so it pauses while Hyper-V is off, but switching hypervisorlaunchtype back to auto and rebooting restores it intact, distributions included.
My VM boots now but is still slow — is that normal?
Unfortunately yes. The workaround repairs the boot hang, not the performance penalty of routing execution through the Windows hypervisor. Only disabling Hyper-V, or moving to a hypervisor that tolerates it better, recovers near-native speed.