ErrorHarbor
Error Library

Hypervisor Still Detected After Disabling Hyper-V

Disabling the Hyper-V role or Windows feature does not prove the Microsoft hypervisor has stopped starting. Windows virtualization-based security (VBS), Memory Integrity, Credential Guard, Virtual Machine Platform or another dependent feature can still require the hypervisor. Confirm what is running before disabling more security features.

Windows 11 · Windows 10Hyper-V · VBSLast reviewed Sep 26, 2026
🎯 This guide matches when:
You removed/disabled Hyper-V but systeminfo still says a hypervisor has been detected.System Information may still report Virtualization-based security as Running.You are trying to establish whether Windows is still launching its hypervisor for security or virtualization features.
Start with the state, not another disable command
VBS says RunningIdentify the security feature using virtualization before changing boot configuration.
VBS is not runningCheck remaining optional virtualization features and the boot hypervisor setting.
Your only goal is VMware compatibilityConfirm the VMware version and actual failure first; current Workstation versions can operate with Hyper-V/WHP in supported configurations.
🔎 Quick Check — confirm whether VBS is still running
msinfo32

In System Information, inspect Virtualization-based security. Then run:

systeminfo

Verify: If VBS is Running while systeminfo still reports a detected hypervisor, removing the Hyper-V role alone did not remove every Windows dependency on the hypervisor.

Why Hyper-V can be off while the hypervisor is still active

Hyper-V is not the only Windows feature that can use the Microsoft hypervisor. Microsoft documents virtualization-based security as using the Windows hypervisor to create an isolated environment, and Credential Guard can use VBS to protect secrets. Memory Integrity is also a VBS security feature.

This distinction prevents a common troubleshooting mistake: repeatedly uninstalling Hyper-V while a security feature is intentionally keeping the hypervisor active.

Verify: Record VBS status and which security/virtualization features your machine actually needs before changing them.

Fix path #2 — check the Windows features that can keep virtualization active

Review your enabled Windows features and workload requirements. Depending on the machine, features such as Virtual Machine Platform, Windows Hypervisor Platform, Windows Sandbox or WSL2-related virtualization may be intentional.

🟡 Security caution: Do not disable Memory Integrity or Credential Guard simply to remove the detected-hypervisor message. Those are security controls. Only change them when you have a documented compatibility requirement and understand the security trade-off.

Verify: After changing only a feature you intentionally no longer require, reboot and check msinfo32 and systeminfo again.

Fix path #3 — inspect the boot hypervisor setting only after feature checks

If VBS/security requirements and optional virtualization features are accounted for but Windows still launches the hypervisor, inspect the boot configuration instead of blindly overwriting it.

bcdedit /enum {current}

Look for hypervisorlaunchtype. Microsoft documents Auto and Off values for this setting. Changing BCD affects boot behavior, so preserve the current state first and only change it for a confirmed requirement.

Verify: After an intentional, documented change and reboot, rerun systeminfo and test the application that originally required the hypervisor to be absent.

Fix path #4 — if this is for VMware, test the actual VMware failure

Do not use the detected-hypervisor line as the only success criterion. Broadcom documents current Workstation behavior with Hyper-V/Windows Hypervisor Platform, so a detected Microsoft hypervisor does not automatically mean VMware must fail.

Verify: Launch the affected VM and judge the result by the original VMware error/performance problem. If VMware now works, there is no benefit in weakening Windows security only to make the informational line disappear.

What not to do

Do not disable every virtualization/security feature at once; you lose the evidence of which dependency mattered.Do not disable Memory Integrity or Credential Guard solely because systeminfo detects a hypervisor.Do not change BCD before recording the existing boot configuration.Do not assume all current VMware versions require direct ownership of hardware virtualization.

Still detected after the checks?

At this point, collect the state that can explain why the hypervisor remains active rather than applying more generic disable commands.

Capture before escalating:Windows edition/buildsysteminfo hypervisor linemsinfo32 VBS status and running/configured servicesenabled Windows virtualization featuresbcdedit /enum {current} hypervisorlaunchtypethe exact application/version that requires the hypervisor absentthe original application error

Official references

Microsoft: Virtualization-based securityHow VBS uses hardware virtualization and the Windows hypervisor →Microsoft: Credential GuardCredential Guard and VBS security context →Microsoft: BCDEdit /setDocumented hypervisorlaunchtype boot option →Broadcom: Workstation with Hyper-V/WHPCurrent VMware Workstation behavior when the Microsoft hypervisor is present →

Still stuck? Ask the community

Share the Windows build, VBS state, enabled virtualization features and the exact app/error that requires the Microsoft hypervisor to be absent.

Keep it safe: never post passwords, recovery keys, access tokens, private URLs or confidential logs.
Powered by GitHub DiscussionsSign in with GitHub to comment. Reading comments does not require sign-in.

Loading community discussion…