EErrorHarbor
Error Library

Hypervisor Still Detected After Disabling Hyper-V

Disabling the Hyper-V role or feature does not prove the Microsoft hypervisor stopped launching. Treat installed features, configured security policy, running VBS services and boot launch state as separate evidence. Identify the actual dependency—and the application that truly requires the hypervisor absent—before disabling security or changing BCD.

Windows 11 · Windows 10Hyper-V · VBSLast reviewed Sep 27, 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 RunningInspect configured/running VBS security services and policy; do not guess which feature is responsible from the word Running alone.
VBS is not runningCheck optional virtualization workloads and boot state, while keeping “feature installed” separate from “hypervisor currently launched.”
This is a managed/work deviceCheck organizational policy before changing VBS, Credential Guard, Memory Integrity or BCD; local changes may weaken required controls or be reapplied.
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

Interpret: If VBS is Running while systeminfo detects a hypervisor, you have proved the host still uses virtualization-backed security—not which individual policy/service caused it. Record the configured/running VBS services before changing anything.

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, configured/running security services, optional virtualization workloads and whether the machine is policy-managed. Distinguish what is merely installed/configured from what is actually active.

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 — treat boot hypervisor state as the last configuration boundary

If VBS/security policy and optional virtualization workloads are accounted for but Windows still launches the hypervisor, inspect the boot configuration read-only first. The boot setting is not a generic cleanup switch: changing it can prevent multiple security/virtualization features from starting together.

bcdedit /enum {current}

Look for hypervisorlaunchtype. Microsoft documents Auto and Off values. Preserve the current BCD state and determine whether policy/security/workloads require the hypervisor before any write operation. On managed devices, use the organization's supported change path rather than overriding security policy locally.

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.Do not infer the exact responsible feature merely because msinfo32 says VBS is Running; inspect configured/running services and policy.Do not use hypervisorlaunchtype Off as a generic “remove Hyper-V completely” command; it is a boot-level state change with broader dependencies.Do not locally override organization-managed VBS/Credential Guard/Memory Integrity or boot policy without authorization.Do not treat an installed optional feature as proof it is the dependency keeping the hypervisor active.

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 errorconfigured and running VBS security services/policy, not only the overall VBS statewhether the PC is organization-managed and the relevant policy sourcewhich optional virtualization workloads are actually required versus merely installedbefore/after state from the same rebooted host if an approved change is made

References and related guides

VMware Nested Virtualization Not SupportedIf VMware ends with Module HV power on failed and the guest needs nested virtualization, diagnose that boundary →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 →

Virtualization failure map

Use the exact failure stage to avoid applying a Hyper-V or VMware fix to the wrong problem.

Nested virtualization / Module HVVMware cannot expose VT-x/EPT or AMD-V/RVI to a guest that needs nested virtualization. →A hypervisor has been detectedWindows reports that the Microsoft hypervisor is active; first decide whether that state is expected. →VMware unrecoverable error (vcpu-0)Workstation crashes; preserve the exact exception and vmware.log before changing host virtualization. →Operating System Not FoundThe VM powers on but firmware cannot find a bootable guest OS; start with disk and boot path. →Virtualization Troubleshooting HubCompare all five VMware / Hyper-V failure paths →

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…