How to Fix VirtualBox VT-x Is Not Available (Conflict with Hyper-V)

You go to start a VM in VirtualBox, and instead of a boot screen you get a wall of red text:

VT-x is not available (VERR_VMX_NO_VMX)

Sometimes it’s phrased a little differently — “Raw-mode is unavailable courtesy of Hyper-V” or “VT-x is not available. Result Code: E_FAIL (0x80004005)” — but the cause is the same. VirtualBox asked the CPU for hardware virtualization and came up empty.

There are really only two reasons that happens. Either VT-x is switched off in your BIOS/UEFI, or something in Windows has already claimed the virtualization extensions and won’t share. On Windows 10 and 11, that “something” is almost always a hypervisor you didn’t realize was running — Hyper-V, WSL2, Windows Sandbox, or the Memory Integrity feature that ships on by default on a lot of new machines.

This guide walks the causes in order, from the BIOS toggle most people forget to the bcdedit command that settles it for good. Work down the list and you’ll land on the one that’s biting you.

Why VT-x can only belong to one hypervisor#

VT-x (Intel) and AMD-V/SVM (AMD) are CPU features that let software run virtual machines at near-native speed. The catch: the processor only hands those extensions to one hypervisor at a time. Whoever grabs them at boot owns them.

For years that owner was always VirtualBox, VMware Workstation, or whatever desktop VM tool you installed. Then Microsoft started shipping its own hypervisor — Hyper-V — and wiring more and more Windows features on top of it. WSL2 runs on it. Windows Sandbox runs on it. So does Memory Integrity, the Core Isolation security feature. Docker Desktop’s default backend leans on it through WSL2.

When any one of those is active, the Windows hypervisor starts at boot and takes VT-x first. By the time VirtualBox launches, the extensions are spoken for, and you get VERR_VMX_NO_VMX.

flowchart TD
A["PC powers on"] --> B{"VT-x enabled<br/>in BIOS/UEFI?"}
B -->|No| C["VERR_VMX_NO_VMX<br/>nothing to claim"]
B -->|Yes| D{"Windows hypervisor<br/>set to start?"}
D -->|Yes: Hyper-V, WSL2,<br/>Memory Integrity| E["Hyper-V claims VT-x"]
D -->|No| F["VT-x free for VirtualBox"]
E --> G["VirtualBox: VT-x not available"]
F --> H["VirtualBox runs native"]

Cause 1: VT-x is disabled in the BIOS/UEFI#

Start here if nothing virtualization-related works, or if this is a fresh build or a machine that’s never run a VM. Plenty of consumer boards still ship with hardware virtualization turned off.

Reboot and enter firmware setup — usually Del, F2, F10, or Esc during the splash screen, depending on the vendor. Look for the setting under a CPU, Advanced, or Security menu. The name varies:

Set it to Enabled, save, and exit. A normal restart isn’t always enough for the change to register — if it still looks off, fully power down and back up once.

If Task Manager already shows virtualization as Enabled, don’t waste time poking around the firmware. The extensions exist; something in Windows is holding them.

Cause 2: Hyper-V is enabled#

Hyper-V is the most common culprit on machines that do real VM work. It might be on because you enabled it deliberately, or because installing Docker Desktop, the Windows Subsystem for Linux, or a Visual Studio workload switched it on for you.

Turn it off through Windows Optional Features. Press Win + R, run optionalfeatures, and clear the Hyper-V checkbox — both Hyper-V Platform and Hyper-V Management Tools. Click OK and let it reboot.

Prefer the command line? From an elevated PowerShell prompt:

Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All

Or with DISM, which works the same from an admin Command Prompt:

dism.exe /Online /Disable-Feature:Microsoft-Hyper-V-All

Reboot when it asks. Then check Task Manager again — if virtualization still reads Enabled but VirtualBox throws the error, Hyper-V is gone but another feature is keeping the hypervisor alive. That’s almost always Memory Integrity or Virtual Machine Platform, which is the next two sections.

Cause 3: Memory Integrity (Core Isolation) is holding the hypervisor#

This one trips up a lot of people because it has nothing to do with the Hyper-V checkbox. Memory Integrity — part of Core Isolation in Windows Security — uses virtualization-based security (VBS), and VBS needs the hypervisor running. Turn Hyper-V off all you like; if Memory Integrity is on, the hypervisor starts anyway and VT-x stays locked.

It’s enabled by default on many Windows 11 machines, and Windows updates have a habit of switching it back on. So if VirtualBox worked last week and broke after patching, check here first.

To turn it off:

1. Open Windows Security → Device security → Core isolation details.
2. Switch Memory integrity to Off.
3. Reboot.

If the toggle is greyed out or flips back on after a restart, a Group Policy or registry setting is enforcing it. You can clear the registry value from an elevated prompt:

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 0 /f

Cause 4: Virtual Machine Platform, WSL2, Sandbox, and Credential Guard#

Even with Hyper-V and Memory Integrity off, a few other features quietly keep the hypervisor loaded. Each one runs on the same VBS plumbing:

• Virtual Machine Platform — the optional feature WSL2 depends on. WSL2 itself is the usual reason this is enabled.
• Windows Subsystem for Linux — pulls in Virtual Machine Platform and the hypervisor.
• Windows Sandbox — the disposable desktop feature; runs on Hyper-V isolation.
• Windows Hypervisor Platform — the API layer that lets third-party tools sit on top of the Windows hypervisor.
• Credential Guard — VBS-based credential protection, common on domain-joined and enterprise machines.

Open optionalfeatures again and clear the ones you don’t need. To remove Virtual Machine Platform and WSL from PowerShell:

Disable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-Linux

Here’s a summary of every blocker and how to clear it:

Cause 5: Force the hypervisor off with bcdedit#

Sometimes you turn off every feature you can find and the hypervisor still starts. The boot configuration has a master switch — hypervisorlaunchtype — that decides whether Windows loads its hypervisor at all. When features leave it set to Auto, the hypervisor comes up on boot. Set it to Off and it stays down regardless of what’s installed.

From an elevated Command Prompt or PowerShell:

bcdedit /set hypervisorlaunchtype off

Then reboot. After it comes back, start your VM. VirtualBox should now own VT-x and run at full speed.

To check the current value before or after:

bcdedit /enum {current}

Look for the hypervisorlaunchtype line. Off means VirtualBox gets VT-x; Auto means the Windows hypervisor takes it.

When you’d rather keep Hyper-V running#

You don’t always have to choose. VirtualBox 6.1 added the ability to run on top of the Windows Hypervisor Platform, and 7.x kept it. When the Windows hypervisor is active, VirtualBox detects it and runs your VMs as a guest of Hyper-V instead of refusing to start.

The upside: WSL2, Docker Desktop, and Memory Integrity keep working, and you don’t have to touch bcdedit. The downside: performance drops, sometimes a lot, because VirtualBox is no longer talking to the CPU directly. You may also see a small green turtle icon in the VM window — that’s VirtualBox’s way of telling you it’s running in the slower, paravirtualized mode.

So the decision comes down to what you actually need:

• You live in Docker/WSL2 and only run a VirtualBox VM occasionally — leave the hypervisor on and accept the slower VirtualBox. Make sure VirtualBox is 6.1 or newer.
• VirtualBox is your main tool and you want native speed — free VT-x by turning the Windows hypervisor off, and bring it back when you need WSL2 or Docker.

There’s no setting that gives both stacks full hardware speed at once. The CPU only has one set of extensions to give.

The fast path when you’re in a hurry#

When VirtualBox throws VERR_VMX_NO_VMX and you just want it working, this is the order that finds it quickest:

1. Task Manager → Performance → CPU. Is Virtualization Enabled? If not, fix it in the BIOS (Cause 1) and stop here.
2. If it’s enabled, turn off Memory Integrity under Core Isolation and reboot. This alone fixes a surprising number of cases.
3. Disable Hyper-V via optionalfeatures and reboot.
4. Disable Virtual Machine Platform and WSL if you don’t need them.
5. Still stuck? Run bcdedit /set hypervisorlaunchtype off and reboot.
6. Need Docker/WSL2 back later? bcdedit /set hypervisorlaunchtype auto, re-enable the features, reboot.

If you work across several VM tools on the same box, it’s worth reading up on how Hyper-V and other hypervisors share — or fight over — the CPU so the next conflict doesn’t catch you out. And if a Windows update keeps re-enabling Memory Integrity, keep these virtualization troubleshooting guides handy, because that pattern tends to repeat.

Wrapping up#

VT-x is not available (VERR_VMX_NO_VMX) looks scary but it’s a simple ownership problem: the CPU’s virtualization extensions are either switched off in firmware or already claimed by the Windows hypervisor. Confirm VT-x is on in the BIOS, then walk the Windows features that ride on the hypervisor — Hyper-V, Memory Integrity, Virtual Machine Platform, WSL2 — and either turn them off or, on VirtualBox 6.1 and later, accept the slower shared mode.

Decide which stack matters more on this machine. If it’s VirtualBox, free VT-x with bcdedit /set hypervisorlaunchtype off and reboot. If it’s Docker or WSL2, leave the hypervisor on and let VirtualBox run as a guest. Either way, you now know exactly which switch controls it and how to flip it back.