If VirtualBox or VMware Workstation is running painfully slow, refusing to start a 64-bit guest, or throwing a VT-x error on Windows 11, Hyper-V is the usual reason. The Windows hypervisor grabs the CPU’s virtualization extensions at boot, and those extensions only go to one hypervisor at a time. Whatever you installed first doesn’t matter — if Hyper-V is active, it wins.
Disabling Hyper-V isn’t a single checkbox, which is where most guides fall short. The Hyper-V role is only one of several Windows features that keep the hypervisor running. Memory Integrity, WSL2, Windows Sandbox, and Credential Guard all sit on the same plumbing. Turn off Hyper-V and leave any of those on, and the hypervisor stays loaded.
This walkthrough disables them in the right order, ending with the bcdedit switch that guarantees the hypervisor stays down. It also covers how to put everything back when you need Docker or WSL2 again.
Confirm Hyper-V is the problem
Before disabling anything, confirm the CPU’s virtualization extensions exist and that something is holding them. Open Task Manager → Performance → CPU and read the Virtualization line.
- Enabled — the extensions are on, and a Windows hypervisor has them. This whole guide applies.
- Disabled — virtualization is off in firmware. That’s a different fix (turn on VT-x/AMD-V in the BIOS), and disabling Hyper-V won’t help.
You can also check whether the hypervisor is currently running:
Get-ComputerInfo -Property "HyperVisorPresent"True means the Windows hypervisor is loaded right now and is what’s blocking VirtualBox or VMware.
Step 1: Disable the Hyper-V role
Start with the obvious one. Press Win + R, run optionalfeatures, and clear the Hyper-V checkbox — both Hyper-V Platform and Hyper-V Management Tools. Click OK and reboot.
From an elevated PowerShell prompt instead:
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-AllOr with DISM from an admin Command Prompt:
DISM /Online /Disable-Feature /FeatureName:Microsoft-Hyper-V-AllReboot, then recheck Task Manager. If Virtualization still reads Enabled and VirtualBox or VMware still struggles, Hyper-V is gone but another feature is keeping the hypervisor alive. Keep going.
Step 2: Turn off Memory Integrity (Core Isolation)
This is the one most people miss, because it has nothing to do with the Hyper-V checkbox. Memory Integrity, part of Core Isolation, uses virtualization-based security (VBS) — and VBS needs the hypervisor running. It ships on by default on many Windows 11 machines.
To turn it off:
- Open Windows Security → Device security → Core isolation details.
- Switch Memory integrity to Off.
- Reboot.
If the toggle is greyed out or flips back on, a policy or registry value is enforcing it. Clear it from an elevated prompt:
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 0 /fStep 3: Clear the other hypervisor features
Even with Hyper-V and Memory Integrity off, a few features quietly keep the hypervisor loaded. Each runs on the same VBS foundation:
Features that keep the hypervisor running
| Virtual Machine Platform | The feature WSL2 depends on — usually why it's enabled |
|---|---|
| Windows Subsystem for Linux | Pulls in Virtual Machine Platform and the hypervisor |
| Windows Sandbox | Disposable desktop; runs on Hyper-V isolation |
| Windows Hypervisor Platform | API layer letting third-party tools sit on the Windows hypervisor |
| Credential Guard | VBS-based credential protection, common on enterprise/domain machines |
Open optionalfeatures again and clear the ones you don’t need. From PowerShell, to remove the WSL2 stack:
Disable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Windows-Subsystem-LinuxCredential Guard on enterprise machines is managed through Group Policy or the registry rather than Optional Features, so if your device enforces it you may need help from whoever manages the policy.
Features to clear before forcing the hypervisor off
- Hyper-V (Platform + Management Tools)
- Memory Integrity under Core Isolation
- Virtual Machine Platform
- Windows Subsystem for Linux (WSL2)
- Windows Sandbox
- Credential Guard, if your machine enforces it
Step 4: Force the hypervisor off with bcdedit
Sometimes you clear 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. While features leave it on Auto, the hypervisor comes up at boot. Set it to Off and it stays down regardless of what’s installed.
From an elevated Command Prompt or PowerShell:
bcdedit /set hypervisorlaunchtype offReboot. After Windows comes back, VirtualBox or VMware should own the virtualization extensions and run at full native speed.
To check the current value either way:
bcdedit /enum {current}Look for the hypervisorlaunchtype line. Off means VirtualBox/VMware get the extensions; Auto means the Windows hypervisor takes them.
When you’d rather not disable Hyper-V at all
You don’t always have to choose. VirtualBox 6.1+ and recent VMware Workstation builds can run on top of the Windows Hypervisor Platform. With the Windows hypervisor active, they detect it and run 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 never touch bcdedit. The downside: performance drops, sometimes a lot, because the VM software no longer talks to the CPU directly. VirtualBox even shows a small green turtle icon to flag the slower paravirtualized mode.
So weigh it by how you actually work:
- You live in Docker/WSL2 and only run a VirtualBox/VMware VM occasionally — leave Hyper-V on, keep your VM software current, and accept the slower guest mode.
- VirtualBox or VMware is your main tool and you want native speed — disable the Windows hypervisor with the steps above, and bring it back when you need WSL2 or Docker.
There’s no setting that gives both stacks full hardware speed at the same time. The CPU has one set of extensions to give.
Putting it all back
When you need Docker or WSL2 again, reverse the changes:
bcdedit /set hypervisorlaunchtype autofrom an elevated prompt.- Re-enable any features you removed (Hyper-V, Virtual Machine Platform, WSL).
- Turn Memory Integrity back on under Core Isolation if you want it.
- Reboot. The hypervisor reclaims the extensions and the Windows stack works again.
If you want the deeper background on the specific VirtualBox error this all causes, see VirtualBox VT-x is not available. And if your VirtualBox VM is just sluggish rather than broken, why a VirtualBox VM runs slow on Windows 11 covers the performance side.
Wrapping up
Disabling Hyper-V for VirtualBox or VMware is less about one checkbox and more about clearing everything that rides on the Windows hypervisor. Turn off the Hyper-V role, then Memory Integrity, then Virtual Machine Platform and WSL2, and finish with bcdedit /set hypervisorlaunchtype off so nothing quietly reloads it at boot.
Decide which stack matters more on this machine. If it’s VirtualBox or VMware, free the extensions and reboot. If it’s Docker or WSL2, leave Hyper-V on and let your VM software run in the slower shared mode. Either way, you now know which switches control it and how to flip them back. For more VM fixes, browse the virtualization guides.
