Fixing VMware Workstation Virtual Machines That Won’t Start: Hyper-V and Device Guard Incompatibility

1. What causes the error?

For security features such as Device Guard, Credential Guard and Memory Integrity, Windows relies on Virtualization Based Security (VBS). To work, VBS loads the Hyper-V hypervisor when Windows boots — even if you never installed Hyper-V yourself.

While the Hyper-V hypervisor is running, Windows owns direct access to the processor’s virtualization features (Intel VT-x or AMD-V), and older versions of VMware Workstation (before 15.5.5) cannot run virtual machines. Newer versions of VMware also show this message if the host is older than Windows 10 version 2004.

• VMware Workstation older than 15.5.5: not compatible with Hyper-V and VBS; virtual machines will not run as long as these features are on.
• VMware Workstation 15.5.5 and later: can run alongside Hyper-V on Windows 10 version 2004 and later, but virtual machines are slower in this mode and some features are limited.

2. Before you start: check your system

To confirm the cause, press Win + R, type msinfo32 and press Enter. On the System Summary page, look for these two items:

• Virtualization-based security: if its value is Running, VBS is enabled and is the main cause of the problem.
• A hypervisor has been detected: if you see this line, the Windows hypervisor (Hyper-V) was loaded at boot.

Also make sure processor virtualization (Intel VT-x or AMD-V / SVM) is enabled in the BIOS/UEFI settings; you can check it on the Performance tab of Task Manager, under CPU, next to “Virtualization”.

3. The main fix: disable VBS in Group Policy

This is the method that solves the problem on most systems. The Group Policy Editor is only available in the Pro, Enterprise and Education editions of Windows (for Windows Home, see section 5).

1. Press Win + R, type gpedit.msc and press Enter to open the Local Group Policy Editor.
2. In the left pane, go to Local Computer Policy → Computer Configuration → Administrative Templates → System → Device Guard.
3. Double-click Turn On Virtualization Based Security.
4. Select Disabled and click OK.
5. Restart the computer once.

The full path of this setting:

Local Computer Policy
 └─ Computer Configuration
     └─ Administrative Templates
         └─ System
             └─ Device Guard
                 └─ Turn On Virtualization Based Security  =  Disabled

After the restart, open VMware Workstation; in most cases the virtual machine now powers on without errors and the guest OS installation continues.

4. If the problem persists: turn off Hyper-V

Sometimes the Hyper-V hypervisor still runs at boot even after VBS has been disabled — for example when Hyper-V itself, Windows Sandbox or WSL2 is installed. In that case, open Command Prompt as Administrator and run:

bcdedit /set hypervisorlaunchtype off

Then restart. If you want to remove the related features completely, go to Control Panel → Programs and Features → Turn Windows features on or off and untick Hyper-V, Virtual Machine Platform, Windows Hypervisor Platform and Windows Sandbox. You can do the same with PowerShell (as Administrator):

Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-All
Disable-WindowsOptionalFeature -Online -FeatureName VirtualMachinePlatform
Disable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform

If you later need Hyper-V, WSL2 or Docker Desktop again, re-enable the hypervisor with the following command and a restart:

bcdedit /set hypervisorlaunchtype auto

5. Turning off Memory Integrity and the registry method (Windows Home)

On Windows 10 and 11, Memory Integrity (Hypervisor-protected Code Integrity) also keeps VBS switched on. To turn it off, open Windows Security, go to Device security → Core isolation details, switch Memory integrity off and restart.

On Windows Home, which has no Group Policy Editor, you can apply the setting from section 3 through the registry. Open Command Prompt as Administrator and run these commands (create a restore point before editing the registry):

reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard" /v EnableVirtualizationBasedSecurity /t REG_DWORD /d 0 /f
reg add "HKLM\SYSTEM\CurrentControlSet\Control\DeviceGuard\Scenarios\HypervisorEnforcedCodeIntegrity" /v Enabled /t REG_DWORD /d 0 /f

After restarting, check again with msinfo32 that Virtualization-based security shows Not enabled.

Security note: VBS, Credential Guard and Memory Integrity are designed to protect Windows against malware. On corporate computers where these settings are enforced by domain policy, talk to your network administrator before changing anything; your changes may be reverted at the next policy sync.

6. Alternative: update VMware Workstation

If you need Hyper-V, WSL2 or Docker Desktop and don’t want to turn VBS off, upgrade VMware Workstation to 15.5.5 or later (ideally the latest 17.x release). On Windows 10 version 2004 and later these versions use the Windows Hypervisor Platform API and can run alongside Hyper-V. For this to work, the Windows Hypervisor Platform feature must be enabled in Windows Features. Keep in mind that virtual machines run more slowly in this mode than without Hyper-V.

Reminder: since 2024 VMware Workstation Pro has been free for all users (personal and commercial), and you can download the latest version from Broadcom’s official website.

7. Conclusion

The error “Your host does not meet minimum requirements to run VMware Workstation with Hyper-V or Device/Credential Guard enabled” means that the Windows hypervisor — because of Hyper-V or virtualization-based security features — took control of the processor before VMware could. The simplest fix is to disable Turn On Virtualization Based Security in Group Policy and restart once. If the problem persists, turn Hyper-V off with bcdedit and disable Memory Integrity; and if you do need Hyper-V, update VMware Workstation to the latest version.

Video tutorial for this method: https://www.youtube.com/watch?v=bmwyN6oiUU8