Virtualization Applications Are Not Working: What Do You Do?

When you install a virtualization application on a Windows machine on which Hyper-V or related services are installed, errors can often occur. Errors that happen when you run VMs on non-Hyper-V virtualization applications cause significant problems. This blog post explains what causes these errors, how to fix them, and how to run other virtualization applications on a computer with Hyper-V.

NAKIVO for Hyper-V Backup

NAKIVO for Hyper-V Backup

Agentless, application-aware backups for Hyper-V. Anti-ransomware protection, instant VM boot from backup, other virtual/physical platform support and more.

Background and Working Principle

After you install VMware Workstation, VMware Player, or Oracle VirtualBox on a Windows machine, you might get errors when starting a VM in these virtualization applications. The errors occur even if Hyper-V VMs are not running at that time. You can install VMware Workstation and VirtualBox, and run VMware VMs and VirtualBox VMs on the same computer, but not simultaneously. What causes this problem with Hyper-V? Let’s take a closer look.

VMware Workstation, VMware Player, and VirtualBox are type 2 hypervisors, while Hyper-V is a type 1 hypervisor. A type 2 hypervisor is installed on the operating system that is running on hardware. A type 1 hypervisor is installed on top of hardware. All hypervisors require processor virtualization extensions, which are instruction sets for hardware virtualization – Intel VT-x or AMD-V. Hyper-V takes control of virtualization extensions when Windows boots. These virtualization extensions are not available for VMware Workstation and VirtualBox when Windows loads. Only one software component can use Intel VT-x or AMD-V at a time.

How Hyper-V and Windows applications work on a computer

This incompatibility is caused by Hyper-V because virtualization extensions are not exposed to type 2 hypervisors installed on a Windows machine where the Hyper-V role is enabled.

VMware Workstation errors:

VMware Workstation and Hyper-V are not compatible. Remove the Hyper-V role from the system before running VMware Workstation.

VMware Workstation and Device/Credential Guard are not compatible. VMware Workstation can be run after disabling Device/Credential guard.

VirtualBox errors:


VT-x is not available (VER_VMX_NO_VMX). E_FAIL (0x80004005).

A VirtualBox VM works too slowly and uses the paravirtualisation (emulation) mode.

The most interesting situation is when a user doesn’t install Hyper-V and still encounters one of the errors mentioned earlier when using VMware Workstation or VirtualBox. The error occurs when automatic Windows updates are enabled. With the updates (Windows 10 v1607 and the appropriate Windows Server versions starting from Windows Server 2016), some new Hyper-V-related features are installed and enabled automatically without Windows user consent. These features are Device Guard and Credential Guard. Windows updates known vulnerabilities but can add issues and destroy a working configuration. That’s why many users don’t like automatic updates.

Device Guard is a group of security features in Windows. The idea of implementing this feature is to harden the execution of malicious code. Device Guard is available in Windows 10, Windows Server 2019, and Windows Server 2019. The main requirements are: UEFI running in native mode and Secure Boot enabled.

Credential Guard is a feature to minimize the impact of attacks if malicious code is already running by isolating system and user secrets to make more difficult to compromising.

Virtual Secure Mode (VSM) is a feature to leverage processor virtualization extensions that secures data in an isolated region of memory. HVCI is Hypervisor-protected code integrity. LSA is Local Security Authority.

Virtualization Based Security (VBS) is a class of technologies that uses virtualization extensions, including VSM, to provide security in Windows. The Hyper-V role is required to make these features work (Hyper-V management tools are not needed).

The hypervisor (Hyper-V) loads first, and then the operating system (Windows) loads. Hyper-V provides an abstraction layer between hardware and the operating system. A VSM allows the tagging of specific critical processes and memory used by them as they belong to a separate independent operating system controlled by Hyper-V. The principle is similar to the isolation of two VMs running on a Hyper-V host when each VM can use only the hardware resources provisioned to it.

Note: If you need a type 1 hypervisor from VMware, use VMware ESXi and VMware vSphere environment. Learn more in these blog posts: Hyper-V vs VMware, VMware Workstation vs VMware Player, and How to install ESXi on Hyper-V.

Let’s explore how to resolve the incompatibility issue of Hyper-V and other virtualization applications in detail.

Method 1: Uninstall Hyper-V in the GUI

Check system information about Windows configuration by running the following command in CMD:


A System Information window opens. On the following screenshot, you see that Hyper-V is enabled (a hypervisor has been detected), and Device Guard Virtualization-based security is running. Now you can remove these features.

Viewing system information in Windows

You should be aware that the following Hyper-V related features will not be available after you remove Hyper-V:

  • Hyper-V
  • Credential Guard and Device Guard
  • Virtual Machine Platform
  • Windows Sandbox
  • WSL2.

Remove the Hyper-V feature in the graphical user interface (GUI) by using Control Panel, Add Roles, and Features wizard.

In Windows 10, open Control Panel, click Programs and Features, then click Turn Windows features on or off.

The Windows Features window opens.

Deselect the Hyper-V checkbox, and hit OK.

To finish removing Hyper-V, restart the computer.

Removing Hyper-V in Windows 10 to allow other virtualization applications to work properly

The steps for removing Hyper-V on Windows 10 and Windows Server 2016 are similar.

In Windows Server 2016, open Server Manager and click Manage > Remove Roles and Features. In the Remove Roles and Features Wizard, go to the Server Roles step, and deselect Hyper-V. Hit Next at each step to continue. Restart is required to finish removing the Hyper-V role.

Removing Hyper-V in the Remove Roles and Features wizard

Method 2: Use PowerShell to Disable the Hyper-V Feature

You can do a similar action by using the command-line interface rather than the GUI.

Log in to PowerShell as Administrator, and run the command to disable the Hyper-V feature:

Disable-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V-Hypervisor

Restart your host machine:

shutdown -r -t 0

Method 3: Disable Hyper-V by Using BCDedit

The idea behind this method is to edit boot configuration data and disable booting of Hyper-V without uninstalling the Hyper-V role.

Log in to PowerShell as Administrator, or run the command from an elevated command prompt to disable Hyper-V:

bcdedit /set hypervisorlaunchtype off

If you need to re-enable Hyper-V and set the default value back, run this command:

bcdedit /set hypervisorlaunchtype auto

For more control and convenience, disable fast boot in Windows 10. Open Windows Registry Editor, and go to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Power 

Set the HiberbootEnabled parameter to 0

If you need to use Hyper-V VMs sometimes, create two entries for a Windows boot loader: one to boot Windows with Hyper-V and another to boot Windows without Hyper-V. Then, select the needed option before you boot Windows. This approach prevents you from running commands in PowerShell manually each time when you need to enable or disable Hyper-V.

bcdedit /copy “{current}” /d “No Hyper-V”

“The entry was successfully copied to {xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}.”

Copy and paste your value instead of xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.

bcdedit /set “{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}” hypervisorlaunchtype off

Editing boot configuration in Windows

Restart the computer.

Once your computer has restarted, you should see two options in Windows Boot Manager.

Two boot options in Windows Boot Manager

If you want to remove the No Hyper-V boot entry, use the /delete option for bcdedit.

Get a list of the current boot entries:

bcdedit /v

A list of all entries with their identifiers is displayed in the output. Copy the ID of the entry which you want to remove, and run the following command:

bcdedit /delete “{xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx}”

Method 4: Uninstall the Hyper-V Role in PowerShell with dism.exe

The idea behind this method is to use the Deployment Image Servicing and Management tool in the command-line interface to uninstall Hyper-V.

Log in to CMD or PowerShell as Administrator. Run the following command to uninstall Hyper-V:

dism.exe /Online /Disable-Feature:Microsoft-Hyper-V

If you want to install Hyper-V again, use this command:

dism.exe /Online /Enable-Feature:Microsoft-Hyper-V /All

How to uninstall Hyper-V in the command line interface

Method 5: Turn off virtualization Based Security in Windows

This method is used to disable Device Guard and Credential Guard, which are Hyper-V-related features.

Open the Group Policy Editor for a local machine. The group Policy Editor is available in Windows 10 Pro, Enterprise, and Education. In the command prompt, run gpedit.msc

Go to Local Computer Policy > Computer Configuration > Administrative Templates > System > Device Guard

Double-click Turn On Virtualization Based Security. By default, the status of this setting is Not configured.

Turn Off Virtualization Based Security that uses Hyper-V

In the window that opens, select Disabled and hit OK to save settings, and close the window.

Close the Group Policy Editor and restart your computer to make changes take effect

Edit Registry as an alternative

In Windows 10 Home, where the Group Policy Editor is not present, you can disable Virtualization Based Security in Windows Registry.

Create a backup of the Windows registry before changing registry settings to avoid errors and issues.

Open Registry Editor. Run regedit in the command line that should be opened as Administrator.

Go to HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > DeviceGuard

Create the EnableVirtualizationBasedSecurity entry if this entry is missing. To create a new entry, right-click an empty place in the DeviceGuard directory, and in the context menu, click New > DWORD (32-bit) Value. Enter the EnableVirtualizationBasedSecurity name for this registry entry. By default, data set for this entry should be 0 (see the following screenshot). You can double-click the EnableVirtualizationBasedSecurity and set 0 manually.

Editing registry to disable Virtualization Based Security in Windows

Go to HKEY_LOCAL_MACHINE > SYSTEM > CurrentControlSet > Control > Lsa

Create a new registry entry in the Lsa directory. Right-click an empty space in the right pane of the Registry Editor window. In the context menu, click New > DWORD (32-bit) Value.

Enter the LsaCfgFlags name for this value. This value must be set to 0.

How to disable LSA in Windows Registry

Close the Registry Editor, and restart your computer.

You can run the following commands in PowerShell (as Administrator) to disable Device Guard and Credential Guard on the next Windows boot.

Mont a UEFI system partition to the drive X: (select an unused volume):

mountvol X: /s

Copy the C:\Windows\System32\SecConfig.efi to X:\EFI\Microsoft\Boot\SecConfig.efi with an option to overwrite the file if the file exists. This file is a boot image for Windows security configuration tool.

copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y

Create a new option in the boot menu with the ID {0cb3b571-2f2e-4343-a879-d86a476d7215} and the DebugTool name:

bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d “DebugTool” /application osloader

Set the boot option you created to boot at the previous step to \EFI\Microsoft\Boot\SecConfig.efi:

bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path “\EFI\Microsoft\Boot\SecConfig.efi”

Set Windows Boot Manager to make the new entry the default one for the next reboot. After that, reboot your Windows should go back to normal boot.

bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}

Set the bootloader to pass the options DISABLE-LSA-ISO,DISABLE-VBS to the SecConfig.efi file when the bootloader launches the file.

bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS

Set the partition for the booted drive to the X: drive:

bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:

Unmount the X: drive from the system:

mountvol X: /d

Method 6: Update VMware Workstation

If you have Windows 10 version 2004 (20H1) build 19041 or newer on your physical computer, you can upgrade VMware Workstation to VMware Workstation 15.5.6 or newer and run VMware VMs on your Windows machine without disabling/uninstalling Hyper-V and Virtualization Based Security (VBS) features, including Device Guard and Credential Guard.

Due to many complaints from customers, Microsoft and VMware decided to develop a joint project that adopts Microsoft Windows Hypervisor Platform (WHP) APIs to allow type 2 hypervisors, such as VMware Workstation, to run on a host where Hyper-V is enabled. These APIs allow applications to manage CPU resources, read/write registry values, terminate CPU operation, and generate interruptions.

VMware Workstation before version 15.5.5 uses a Virtual Machine Monitor (VMM) that has direct access to a CPU and virtualization instruction sets (Intel VT-x or AMD-V). A VMM operates in a privileged mode. If Virtualization Based Security features are enabled on a Windows host, then an additional hypervisor layer (Hyper-V) is added between hardware and Windows. Hyper-V has direct access to CPU features used for hardware virtualization, and VMM has no access to CPU virtualization features.

VMware made changes in the architecture of VMware Workstation 15.5.6 to allow their product to use Microsoft WHP APIs and fix the compatibility issue. VMM can now run at the user level (not in the privileged mode) using the WHP APIs and run VMs without direct access to CPU virtualization extensions. This mode is called User Level Monitor (ULM) or a Host VBS mode. If you uninstall Hyper-V-related features from your Windows host, VMware Workstation detects it automatically, and VMM is switched to direct access of CPU virtualization extensions (running in the privileged mode).

Windows Hypervisor Platform (WHP) must be installed on a physical Windows machine where Hyper-V is enabled to allow VMware Workstation to run VMware VMs on this machine. Install the Windows Hypervisor Platform feature in Control Panel by clicking Turn Windows features on or off.

Thus, you can update Windows 10 and VMware Workstation on your physical machine to versions that support running Hyper-V-related features and VMware Workstation VMs on the same machine.

Limitations of the Host VBS mode:

  • Windows Hypervisor Platform is not supported on Windows Server 2016 and other Windows Server versions and editions. As a result, VMware Workstation cannot run VMs in the host VBS mode on physical machines running Windows Server.
  • Nested Virtualization is not supported. You cannot run nested VMs (VMs inside VMware Workstation VMs).
  • VMware VMs can run slower.
  • X86 performance monitoring counters (PMC) are not supported.
  • User-mode protection keys (PKU) capability is not available.
  • Restricted transactional memory (RTM) and hardware lock elision (HLE) capabilities are not available.

VirtualBox and Hyper-V

VirtualBox can co-exist with Hyper-V, Device Guard, and Credential Guard starting from VirtualBox 6.0. VirtualBox 6 can work with Hyper-V APIs similarly to VMware Workstation on Windows 10 v1803 x64.

These features must be enabled on a host Windows machine to allow VirtualBox to work with Hyper-V APIs:

  • Hyper-V
  • Windows Hypervisor Platform

If the Hyper-V feature is enabled, but the Windows Hypervisor Platform feature is disabled, in System > Acceleration in VM configuration summary, you can see that the Paravirtualisation mode is on. If you try to start a VM, VirtualBox reminds you that you should enable Windows Hypervisor Platform and displays the error message.

The error message:
WHvCapabilityCodeHypervisorPresent is FALSE! Make sure you have enabled the ‘Windows Hypervisor Platform’ feature.


VT-x is not available (VERR_VMX_NO_VMX).

If the required Hyper-V-related features in Windows are enabled, the following information is displayed for the VM in the System section:

Acceleration: VT-x/AMD-v, Nested Paging, Paravirtualization Hyper-V

Hyper-V and VirtualBox are installed on the same Windows host

The VM should start successfully. A green turtle icon is displayed in the bottom panel of the VirtualBox window. This icon indicates that a VM is running in the Hyper-V paravirtualization mode instead of the native mode that is usually used by VirtualBox when interacting directly with CPU virtualization extensions. The performance of VirtualBox VMs degrades on machines on which Hyper-V and related features are enabled. You can disable or remove Hyper-V as explained earlier to run VMs on VirtualBox in the native mode using CPU virtualization extensions directly.

Read also the VirtualBox vs Hyper-V comparison and the VirtualBox vs VMware comparison.


New Windows features such as Virtualization Based Security (Device Guard and Credential Guard), Windows Sandbox, WSL that use the Hyper-V engine cause a lot of problems to users, administrators, and software developers using other hypervisors such as VMware Workstation, VirtualBox, QEMU, and Google Android Emulator on Windows machines. There are two approaches to resolve these incompatibility issues: Disable/uninstall Hyper-V or use new versions of virtualization applications that support work with Hyper-V APIs, such as Windows Hypervisor Platform API provided by Microsoft.

Running VMs on VirtualBox, VMware Workstation, and other hypervisors on machines with Hyper-V by using APIs can degrade the performance of non-Hyper-V VMs. Data backup is crucial for the cases when virtualization applications fail. If you still haven’t chosen the best Hyper-V backup solution for your environment, consider NAKIVO Backup & Replication. The solution offers robust backup, ransomware protection, disaster recovery and more. Download the Free Edition to see the solution in action.

1 Year of Free Data Protection: NAKIVO Backup & Replication

1 Year of Free Data Protection: NAKIVO Backup & Replication

Deploy in 2 minutes and protect virtual, cloud, physical and SaaS data. Backup, replication, instant recovery options.

People also read