Hyper-V: The Hypervisor Is Not Running — Complete Fix Guide (2026)

Fix guide Hyper-V troubleshooting · 9 min read · Published May 2026

You hit Start on a VM and Hyper-V slams the door: “The virtual machine could not be started because the hypervisor is not running” or the older phrasing “Virtual machine could not be started because the hypervisor is not running”. And half the time Task Manager’s sitting right there showing Virtualization: Disabled, just to twist the knife. Looks like Windows ate itself. It didn’t. I’ve babysat Hyper-V on lab boxes and dev laptops for years now, and honestly? This thing fails for maybe five reasons, no more, and they tend to break in a pretty predictable order. So I just work them top to bottom. Fix the first gate that’s failing, reboot, try again. Beats clicking random checkboxes till one of them sticks, which is how most folks lose an afternoon to this.

What the error actually means

Here’s the bit that makes the error click. Hyper-V is a Type-1 hypervisor. Which is a fancy way of saying it isn’t a program Windows runs, it’s a thin layer that loads before Windows does, way down at boot, straight onto the CPU’s virtualization extensions. So when Windows says “the hypervisor is not running,” what it actually means is that layer never woke up this boot. And the reasons are short. The CPU extensions are switched off. Or nobody told Windows to launch the hypervisor at boot. Or something else grabbed those extensions first, a rival hypervisor, say, or Virtualization-Based Security wedged in a bad state. Notice what’s not on that list? Corruption. Most of the time nothing’s actually broken. The layer just didn’t load, and your VM can’t run on nothing.

Gate 1: enable virtualization in BIOS/UEFI

Start here. Always. This is the one I run into most, and it has a real soft spot for brand-new machines and any box that’s had its CMOS cleared. Reboot into firmware setup (mash Del, F2, F10 or F1 as it powers on, the key’s a vendor lottery) and flip the virtualization extension on. What it’s called depends on whose silicon you’ve got:

• Intel: turn on Intel Virtualization Technology (VT-x). And VT-d as well, if your firmware can be bothered to list it.
• AMD: you want SVM Mode (Secure Virtual Machine). It’s usually buried a menu or two deeper than feels reasonable.

Now the bit everyone skips: save, then do a full shutdown, not a restart. Plenty of firmware only commits the change on a cold boot. So a quick reboot leaves you glaring at the exact same error, swearing the toggle did nothing. Back in Windows, prove it took:

Not a PowerShell person? Open Task Manager → Performance → CPU and look at the bottom panel for Virtualization: Enabled. Same answer, a lot fewer keystrokes.

Gate 2: confirm the Hyper-V feature is installed

VT-x is on and you’re still stuck? Then I’d start suspecting the role itself. Maybe it never finished installing. Maybe some half-finished install left it sort of half-there, in that weird in-between state. Either way the hypervisor won’t load. I just reinstall it clean from an elevated PowerShell and let Windows untangle itself:

Enable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V -All
# reboot when prompted, then verify:
Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor

State wants to read Enabled. Now here’s the gotcha that snags people week after week: on Windows 11/10 Home, the Hyper-V role isn’t disabled, it just doesn’t ship. At all. You can click till your wrist hurts and it won’t appear. Pro, Education or Enterprise, that’s the price of entry. Although, if all you really want is WSL2 or Docker, you don’t actually need the whole role, enable VirtualMachinePlatform instead. That gets you the hypervisor without dragging in the full Hyper-V management stack, and it runs fine on Home.

Gate 3: set the hypervisor to launch at boot

This one’s my favourite, and I think it’s because the fix is a single line while the cause is so wonderfully petty. The feature can be installed perfectly and the hypervisor still won’t launch, because a separate boot-configuration flag gets the final say. And all kinds of things flip that flag off behind your back. A game’s anti-cheat that wants the extensions for itself. An older VMware. Half the “fix your VM” guides floating around out there. They switch it off, do whatever they came to do, and never bother flipping it back. Go look:

bcdedit /enum {current}
# look for: hypervisorlaunchtype   Auto
# if it says Off, turn it back on:
bcdedit /set hypervisorlaunchtype auto

Reboot. Boot flags only get read at boot, so nothing happens until you do. And honestly, if everything else looks clean and the error’s still there, I’d put my money on this line. It’s quietly behind a huge chunk of the “hypervisor is not running” cases I’ve seen, maybe more than any other single cause.

Gate 4: resolve VMware / VirtualBox / VBS conflicts

At the hardware level, only one thing gets to own the CPU virtualization extensions. One. So if something else has already grabbed them, Hyper-V is locked out cold, and you’ll get the error no matter how spotless gates 1 through 3 look. The usual culprits I go hunting for:

• VMware Workstation 15 or older just won’t share the CPU with Hyper-V. It’s an architectural standoff, not a checkbox you can talk it out of. Upgrade to Workstation 16+, which speaks the Windows Hypervisor Platform and coexists happily, or accept that you’ll have to disable Hyper-V to keep the ancient VMware around.
• VirtualBox below v6 pulls the exact same stunt. Update it and the whole problem evaporates, because modern VirtualBox rides the Hyper-V backend instead of brawling with it.
• Virtualization-Based Security (VBS), which is Core Isolation, Memory Integrity, Credential Guard and that crowd, leans on the hypervisor too. Most of the time they coexist without a fuss. But a VBS that’s only half-enabled, or wedged by some group policy somewhere, will quietly murder your VMs. This is the one that takes the longest to even suspect. If you don’t need it, turn off Core Isolation → Memory Integrity in Windows Security, reboot, and try again.

Before you start switching things off, know what you’re trading away. WSL2, Docker Desktop, the Windows Sandbox, Hyper-V, they all drink from the same well. They all need that hypervisor. Kill it to keep some old VMware happy and you’ve just taken those down with it, usually weeks later, long after you’ve forgotten this is why your containers stopped working. So I’ll say what I say to everyone, drag the conflicting software into this decade instead of crippling Hyper-V. That’s the route I’d take, anyway.

Gate 5: services and system-file repair

You almost never get here. But when all four earlier gates pass and a VM still won’t start, it’s usually one of two things: stopped management services, or a component store that’s taken some damage. Get the services up and patch the image:

Start-Service vmcompute
Start-Service vmms
Set-Service vmms -StartupType Automatic

# repair Windows component store if services refuse to start
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

And if even that won’t shift it, here’s the nuclear option: rip the role out and put it back. Run Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All, reboot, then enable it again. That rebuilds the WMI namespace and the hypervisor boot entry from scratch, which tends to flush out whatever mess the earlier steps couldn’t reach. I’ve personally never had to go further than this.

Verify the fix

One habit that’s saved me a lot of grief. After any change and the reboot that follows, confirm the hypervisor actually loaded before you start cursing Hyper-V all over again. One line settles it:

HypervisorPresent comes back True? Then the layer’s up and that original error is dead. If it’s still False after you’ve worked through all five gates, don’t spiral, just go back to the BIOS and look again. A firmware update will happily reset that virtualization toggle without a peep, so the thing you fixed on Tuesday can be quietly off again by Friday.

FAQ