How to Fix Hypervisor Error Windows 11

A HYPERVISOR_ERROR blue screen in Windows 11 means the Windows hypervisor encountered a fatal error. Microsoft assigns this bug check the value 0x00020001, but the stop code by itself does not identify the faulty driver, firmware setting, memory module, or virtualization component.

That makes diagnosis more important than simply disabling Hyper-V. Windows can use the hypervisor for Hyper-V, WSL 2, Windows Sandbox, Virtual Machine Platform, and virtualization-based security. Even a PC that never runs a traditional virtual machine may therefore have the hypervisor active.

I would troubleshoot this BSOD according to when it occurs: after enabling virtualization, while starting a virtual machine, after a BIOS or driver change, or alongside other random crashes.

First, Identify the Pattern

Before changing Windows features, answer these questions:

• Does the BSOD happen only when starting a virtual machine?
• Did it begin after enabling Hyper-V, WSL 2, Windows Sandbox, or Memory Integrity?
• Did you recently install or update VMware Workstation, VirtualBox, an Android emulator, or similar software?
• Did you update the BIOS, chipset driver, or Windows?
• Did you enable XMP, EXPO, CPU overclocking, or undervolting?
• Did you recently install RAM?
• Are you also getting unrelated blue-screen codes, freezes, or random restarts?

The answers determine which branch of troubleshooting deserves priority.

Pattern	Start here
Error appeared once and has not returned	Restart and monitor
Crashes only when a VM starts	Virtualization configuration and VM software
Started after enabling Hyper-V/WSL/Sandbox	Hypervisor configuration and Windows features
Started after BIOS, RAM, XMP, or CPU changes	Firmware and hardware stability
Multiple different BSODs occur	RAM, drivers, firmware, hardware
Started after a driver update	Driver update/rollback and dump analysis
Happens repeatedly with no clear trigger	Event Viewer and crash dump analysis

Confirm That Hardware Virtualization Is Enabled

Press Ctrl + Shift + Esc to open Task Manager, select Performance > CPU, and find Virtualization.

For Hyper-V and other hardware-assisted virtualization workloads, it should normally show:

Virtualization: Enabled

When it is disabled, enter the PC’s BIOS or UEFI and look for a setting such as:

• Intel Virtualization Technology
• Intel VT-x
• AMD-V
• SVM Mode
• Virtualization Technology

The wording varies by motherboard and computer manufacturer.

Do not change unrelated BIOS settings while looking for virtualization. If you need help reaching the firmware interface, see How to Open BIOS in Windows 11.

Check Whether the Windows Hypervisor Is Actually Running

Press Windows + R, enter:

msinfo32

and press Enter.

Near the bottom of System Summary, Windows may display:

A hypervisor has been detected. Features required for Hyper-V will not be displayed.

That message is not an error. It tells you the Windows hypervisor has loaded.

This is useful when you are trying to determine whether the problem is an active hypervisor configuration or a failure before virtualization starts.

Check the Hypervisor Boot Configuration

Open Windows Terminal or Command Prompt as administrator and run:

bcdedit /enum

Look for hypervisorlaunchtype.

If you use Hyper-V, WSL 2, Windows Sandbox, or another feature that requires the Windows hypervisor, it will normally need to launch automatically.

To set that behavior:

bcdedit /set hypervisorlaunchtype auto

Restart Windows after changing it.

Do not set hypervisorlaunchtype to off merely because the BSOD contains the word hypervisor. Turning the hypervisor off can disable features you actually need and can hide the symptom without identifying the underlying problem.

When the Error Started After Enabling a Virtualization Feature

Press Windows + R, type:

optionalfeatures

and press Enter.

Review the virtualization-related features installed on the PC, which may include:

• Hyper-V
• Virtual Machine Platform
• Windows Hypervisor Platform
• Windows Sandbox
• Windows Subsystem for Linux

Think about what changed immediately before the crashes started.

For example, when the PC was stable until Windows Sandbox was enabled, temporarily removing that feature is a useful test. When you rely on WSL 2 every day, indiscriminately disabling Virtual Machine Platform is not a useful permanent solution.

Change one relevant feature at a time, restart, and test. That preserves the diagnostic value of each change.

When the BSOD Happens Only With VMware, VirtualBox, or Another VM App

A crash that appears only when launching virtualization software deserves a different approach from a PC that crashes while sitting idle.

First update the virtualization application to a version that officially supports your current Windows 11 configuration.

Then determine whether the application is designed to coexist with the Windows hypervisor on your current version. Hyper-V, Windows Hypervisor Platform, VBS, and Memory Integrity can change how third-party virtualization software accesses hardware virtualization.

Do not immediately disable Windows security features simply to make an old virtualization application run. Updating the VM application is usually the better first move.

If only one particular virtual machine triggers the crash while other VMs work, compare that VM’s configuration with a working one. The host virtualization stack becomes a stronger suspect when every VM causes the same failure.

Return CPU and RAM Settings to Stock

This is one of the highest-value checks when HYPERVISOR_ERROR appears after BIOS tuning or alongside other BSODs.

Temporarily disable:

• CPU overclocking
• CPU undervolting
• XMP
• EXPO
• DOCP
• manual RAM timings
• other performance-oriented firmware tuning

Then test Windows at default settings.

Virtualization can expose marginal CPU or memory instability that does not appear during ordinary browsing. A PC being “stable in games” is therefore not enough to rule out unstable memory or processor settings.

When returning to stock settings stops the crashes, reintroduce changes individually rather than restoring the entire tuned configuration at once.

Update the BIOS and Chipset Drivers Carefully

Firmware and platform drivers sit much closer to virtualization hardware than ordinary desktop applications do.

Open msinfo32 and note BIOS Version/Date. Then check the support page for the exact laptop, desktop, or motherboard model.

Prioritize:

• BIOS/UEFI firmware
• AMD or Intel chipset components
• platform/management drivers
• storage-controller drivers when applicable

Read the BIOS release notes before updating. A firmware update may contain CPU microcode, memory compatibility, security, or system-stability changes relevant to virtualization.

Never install firmware intended for a similar-looking but different motherboard or laptop model.

Test the RAM When Crashes Are Broader Than Hyper-V

Press Windows + R, type:

mdsched.exe

and press Enter.

Choose to restart and check for memory problems.

A clean Windows Memory Diagnostic result does not prove that RAM is perfect, but reported errors are significant and should be investigated before repeatedly modifying Hyper-V.

Move RAM and hardware stability higher on the list when HYPERVISOR_ERROR appears alongside:

• different BSOD stop codes;
• random application crashes;
• unexplained restarts;
• file corruption;
• freezing under load;
• problems that began after installing RAM;
• instability after enabling XMP or EXPO.

In that situation, treating every crash as a Hyper-V configuration issue can send the diagnosis in the wrong direction.

Repair Windows Components With DISM and SFC

When the hardware configuration is stable, check Windows system files.

Open Terminal or Command Prompt as administrator and run:

DISM /Online /Cleanup-Image /RestoreHealth

After DISM completes, run:

sfc /scannow

Restart Windows when both commands are finished.

DISM repairs the Windows component store that SFC can use when repairing protected system files. These commands are reasonable when Windows components are corrupted, but they should not be treated as proof that every hypervisor crash is caused by corrupt files.

When SFC itself fails, use the separate SFC /Scannow Not Working guide rather than repeatedly running the same command.

Check Memory Integrity Without Disabling It Automatically

Open:

Windows Security > Device security > Core isolation details

Check Memory integrity.

Memory Integrity uses virtualization-based security, so its relationship with the Windows hypervisor is relevant. An incompatible low-level driver can also create problems around this security stack.

Look for any incompatible-driver warning and deal with the driver first.

I would not recommend turning Memory Integrity off as a generic HYPERVISOR_ERROR fix. It is a security feature. Temporarily changing it may be useful in a controlled diagnostic test, but the better outcome is identifying and updating or removing the incompatible component.

For a system where the setting itself refuses to enable, see Memory Integrity Can’t Be Turned On? How to Fix It.

Use Event Viewer to Look for a Pattern

Press Windows + X and open Event Viewer.

Go to:

Windows Logs > System

Concentrate on the minutes immediately before the blue screen.

Useful event sources can include:

• Hyper-V components
• WHEA-Logger
• Kernel-Power
• driver-related events
• storage or hardware errors

A Kernel-Power event after an unexpected restart often records the consequence of the crash rather than its cause.

WHEA errors deserve more attention when they recur near the BSOD because they can indicate a hardware or firmware stability problem.

Do not assume every red error in Event Viewer caused the crash. Windows can log several secondary errors while recovering from an unexpected shutdown.

Check Recent Low-Level Driver Changes

Open Device Manager and think about what was updated immediately before the first HYPERVISOR_ERROR.

Pay particular attention to:

• chipset/platform drivers;
• storage controllers;
• network adapters;
• graphics drivers;
• motherboard utilities and drivers;
• recently installed PCIe or USB hardware.

When the timing strongly points to one driver, update it from the hardware manufacturer’s official source. If the newest version caused the problem and Roll Back Driver is available under the device’s Properties > Driver tab, testing the previous stable version may be appropriate.

Avoid mass-updating every driver with a third-party driver updater. That creates several new variables at once.

Analyze the Crash Dump When the Error Keeps Returning

Repeated HYPERVISOR_ERROR crashes are the point where dump analysis becomes more valuable than adding another generic “fix.”

Microsoft documents bug check 0x00020001 as a fatal hypervisor error and recommends using the debugger’s !analyze extension to help determine the root cause.

Windows may store small crash dumps in:

C:\Windows\Minidump

Install Microsoft’s WinDbg, open the relevant dump, and run:

!analyze -v

Look for a pattern across multiple crashes rather than treating one driver name in one dump as definitive proof.

The dump may help narrow the investigation toward a driver, virtualization component, processor/hardware condition, or another kernel-level interaction. That is considerably more useful than the HYPERVISOR_ERROR label alone.

Microsoft’s reference for the stop code is available in its HYPERVISOR_ERROR bug-check documentation.

What to Do When Windows Will Not Stay Running Long Enough

When the BSOD loop makes normal troubleshooting difficult, use Windows Recovery Environment or Safe Mode to undo the most recent change.

The priority should be the change most closely connected to the first crash, such as:

• a newly installed driver;
• a virtualization application;
• a recent firmware configuration change;
• newly installed hardware;
• a Windows feature you just enabled.

Do not start by wiping Windows.

When the machine is stable in Safe Mode but repeatedly crashes during a normal boot, third-party drivers and startup software deserve closer inspection.

Should You Disable Hyper-V?

Only when doing so answers a useful diagnostic question or you genuinely do not need the Windows hypervisor-dependent workload.

Disabling Hyper-V can be a sensible temporary test when crashes began immediately after enabling the virtualization stack or when troubleshooting compatibility with specific VM software.

It is a poor generic fix when:

• you rely on WSL 2;
• you use Windows Sandbox;
• virtualization-based security is part of your configuration;
• crashes also occur without VM workloads;
• hardware instability is already suspected.

The goal is not simply to make the word “hypervisor” disappear from Windows. It is to identify why the hypervisor reached a fatal condition.

When I Would Suspect Hardware Instead of Windows

Hardware moves much higher on my list when the PC:

• produces several different BSOD codes;
• has recurring WHEA errors;
• crashes with virtualization features both enabled and disabled;
• became unstable after a RAM or CPU change;
• becomes stable after XMP/EXPO or overclocking is disabled;
• fails memory testing;
• freezes or restarts outside virtualization workloads.

At that point, repeatedly reinstalling Hyper-V or resetting Windows is unlikely to be the best use of time.