Fix Hyper-V Error: Virtual Machine could not be Started Because the Hypervisor is not Running

6.5K

This article explains how to troubleshoot and fix issues that may prevent virtual machines from starting on a Windows host with the Hyper-V role installed.

About Virtual Machine could not be Started Because the Hypervisor is not Running

For example, the following error may occur when you try to run a virtual machine from the Hyper-V Manager console:

An error occurred while attempting to start the selected virtual machine(s).
VMname failed to start.
Virtual machine VMName could not be started because the hypervisor is not running.

What does this error indicate?

Virtual machine could not be started because the hypervisor is not running error indicates that either the Windows host is not running Hyper-V services, or the firmware settings have been changed so that the underlying hardware no longer supports virtualization.

Check if VBS Is Keeping the Windows Hypervisor Active

On Windows 11, especially on newer installations, Virtualization-Based Security (VBS) and related security features such as Memory Integrity (HVCI) and Credential Guard can use the Windows hypervisor. As a result, the Windows hypervisor can be running even when you are not actively using Hyper-V VMs.

This is crucial on Windows 11 systems that also run third-party virtualization software (such as VMware Workstation/VirtualBox). Microsoft notes that third-party virtualization apps may fail to start VMs or may fall back to a slower virtualization mode when the Hyper-V hypervisor/Hyper-V-based security features are active.

In order to check the current VBS state, use the command below:

Get-CimInstance -ClassName Win32_DeviceGuard `
-Namespace root\Microsoft\Windows\DeviceGuard |
Select-Object VirtualizationBasedSecurityStatus,
SecurityServicesConfigured,
SecurityServicesRunning

You can also check if a hypervisor is currently running:

(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

In case HypervisorPresent is True, it means that the Windows hypervisor is active. This does not by itself mean that the Hyper-V role is broken. VBS, HVCI, Credential Guard, or other Hyper-V-based Windows security features may be using the hypervisor.

On a Windows 11 client where the goal is to run a third-party hypervisor directly against the hardware, you need to identify which Windows virtualization and security features are enabled before disabling anything. Do not disable VBS, HVCI, Credential Guard, or other security protections on an enterprise-managed device without checking the organization’s security policy.

VirtualizationBasedSecurityStatus shows the current VBS state, while SecurityServicesConfigured and SecurityServicesRunning show which VBS security services are configured and active.

VBS, HVCI (Memory Integrity), Credential Guard, and other Hyper-V-based security features can keep the Windows hypervisor active even when Hyper-V VMs are not running.

Note that you should not disable VBS, HVCI, Credential Guard, or other security protections on an enterprise-managed device without checking the organization’s security policy.

Check the Hyper-V Role Core Services on Windows

Start by checking that the Hyper-V role and core hypervisor services are installed and running on your Windows host. For supported host OSs and Hyper-V installation requirements, see the Microsoft Hyper-V documentation.

Open an elevated PowerShell console and use the command corresponding to your OS. Note that these commands are not interchangeable: Get-WindowsFeature is used for Windows Server roles and features, while Get-WindowsOptionalFeature is used for Windows client optional features.

• Windows Server 2025/2022/2019/2016:
  

  Get-WindowsFeature -Name Hyper-V

• Windows 10 and 11:
  

  Get-WindowsOptionalFeature -Online -FeatureName Microsoft-Hyper-V

If the Hyper-V role is missing, it needs to be installed.

Then check the status of the two core Hyper-V services: Hyper-V Host Compute Service and Hyper-V Virtual Machine Management. Check the services state from the services.msc console or with the PowerShell command:

Get-Service vmcompute,vmms

You can also check if the Hyper-V hypervisor is currently loaded and available to the OS using the command below:

(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

If the command returns True, Windows detects that a hypervisor is present and loaded on the system. If it returns False, the hypervisor is not loaded, which may indicate that virtualization is disabled in firmware, Hyper-V is not configured to start automatically, or the Hyper-V role installation is corrupted.

If the services are stopped, start them manually using the command:

Start-Service vmcompute,vmms

However, in my case, the services did not start with the error:

Start-Service : Service ‘Hyper-V Host Compute Service (vmcompute)’ cannot be started due to the following error: Cannot start service vmcompute on computer ‘

Check for Nested Virtualization

In case the Hyper-V host is itself running as a VM, you need to verify if nested virtualization is enabled on the VM. This applies to Hyper-V VMs running on another Hyper-V host and to supported cloud/Azure Local cases.

Check whether virtualization extensions are exposed to the VM on a Hyper-V host by running the command below:

Get-VMProcessor -VMName "VMName" |
Select-Object VMName,ExposeVirtualizationExtensions

If ExposeVirtualizationExtensions is False, the VM cannot expose the required hardware virtualization extensions to a nested Hyper-V installation.

Note that the VM must be powered off before changing this setting. On the physical or first-level Hyper-V host, run the command:

Set-VMProcessor -VMName "VMName" -ExposeVirtualizationExtensions $true

Then start the VM and verify the Hyper-V requirements from inside the nested host:

systeminfo

The nested host should report the required virtualization capabilities instead of reporting that virtualization support is unavailable.

In case you are working with Azure VMs, you need to check if the selected VM size and security config support nested virtualization. For Azure Local, follow the supported nested virtualization requirements for the deployed Azure Local version.

Nested virtualization adds another layer to the troubleshooting path:

Physical/cloud host > L1 Hyper-V host VM > Nested Hyper-V hypervisor > L2 virtual machine

In case the L1 VM does not expose virtualization extensions, the L2 Hyper-V hypervisor cannot start correctly regardless of the guest OS’s BIOS/UEFI settings.

Check Hyper-V Event Logs

If the Hyper-V services are running but VMs still fail to start, you need to check the Hyper-V event logs for errors and warnings. In many cases, the logs contain detailed info about virtualization, firmware, boot configuration, or hypervisor startup problems. Here is the command:

Get-WinEvent `
-LogName Microsoft-Windows-Hyper-V-Hypervisor-Admin `
-MaxEvents 20 |
Select-Object TimeCreated,Id,LevelDisplayName,Message

This log contains events related to Hyper-V hypervisor startup and hardware virtualization requirements.

You should also review the Hyper-V Worker log for VM startup failures and config-related errors:

Get-WinEvent `
-LogName Microsoft-Windows-Hyper-V-Worker-Admin `
-MaxEvents 20 |
Select-Object TimeCreated,Id,LevelDisplayName,Message

Check Antivirus and EDR Interference

Note that security software can interfere with Hyper-V VM startup through file-system/kernel filter drivers. This is especially important on enterprise Hyper-V hosts where third-party antivirus/EDR products are installed.

In case the problem started after an EDR/antivirus deployment, policy change, agent update, or security update, you need to check the security product logs for blocked/quarantined Hyper-V processes, files, or drivers.

Microsoft specifically recommends configuring antivirus exclusions for Hyper-V hosts. Depending on the config, the exclusions may need to cover Hyper-V VM files and directories and Hyper-V processes (such as vmms.exe, vmwp.exe, and vmcompute.exe).

You need to check if the affected host has recently received an antivirus/EDR update or policy change. If possible, compare the behavior with a healthy Hyper-V host using the same Windows and Hyper-V config.

Do not permanently disable antivirus/EDR protection on a production host as a troubleshooting step. Instead, you need to follow the security vendor’s documented Hyper-V exclusions and change-control procedures. For Microsoft Defender, Windows Server already provides automatic Hyper-V exclusions in supported configs.

For a Hyper-V host, you should review exclusions for the locations used by the VMs, including the following:

• %ProgramData%\Microsoft\Windows\Hyper-V
• %Public%\Documents\Hyper-V\Virtual Hard Disks
• C:\ClusterStorage on Failover Cluster nodes
• Custom VM configuration and VHD/VHDX locations
• Hyper-V Replica storage locations, when applicable

Also, you need to check if the security product is inspecting/blocking Hyper-V processes such as:

• %SystemRoot%\System32\vmms.exe
• %SystemRoot%\System32\vmwp.exe
• %SystemRoot%\System32\vmcompute.exe

You need to apply the vendor’s recommended exclusions consistently across all nodes in case you are working with clustered hosts. Do not create broad exclusions for entire system drives/disable EDR protection globally just to test VM startup.

In case the Hyper-V services fail to start, correlate the service failure time with the EDR/antivirus event logs and Windows Event Viewer. A security event occurring at the same time as the vmms or vmcompute failure is a useful indicator that the security product should be investigated.

Hyper-V Failover Cluster Considerations

If the VM runs in a Hyper-V Failover Cluster, you need to check the Hyper-V and cluster state on the affected node rather than troubleshooting the host in isolation. Check the cluster nodes with the command:

Get-ClusterNode

Then you need to verify Hyper-V on the affected node. Use the following command:

Get-Service vmms,vmcompute
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent

If the issue appeared after a Group Policy or security-policy change, you need to refresh policies on the affected node:

gpupdate /force

If the VM starts successfully on another cluster node, you need to compare the Hyper-V, firmware, BCD, and policy config between the affected and healthy nodes.

System requirements for Hyper-V on Windows and Windows Server

There are several hardware and software requirements. These are needed for a Windows computer to run Hyper-V:

• Operating system: Windows Server or Windows 10/11 Enterprise, Pro, or Education editions (you cannot install Hyper-V on Windows Home);
• CPU: a 64-bit processor with Second Level Address Translation (SLAT) with support a number of key virtualization features: Hardware assisted virtualization (Intel VT or AMD-V), Hardware based Data Execution Prevention (DEP) (AMD NX or Intel XD), VM Monitor Mode Extensions (VT-x on Intel CPUs). Refer to the CPU manufacturer’s specification for specific CPU features;
• RAM: at least 4 GB of RAM
• Virtualization support turned on in the BIOS/UEFI.

Check if your CPU meets the Hyper-V requirements

Open a command prompt, and run the systeminfo command to check if your CPU meets the Hyper-V requirements. Scroll down to the Hyper-V Requirements section. The following items should be listed here:

• VM Monitor Mode Extensions: Yes
• Virtualization Enabled In Firmware: Yes
• Second Level Address Translation: Yes
• Data Execution Prevention Available: Yes

1. If all items are Yes, your hardware meets the Hyper-V requirements and virtualization is enabled in firmware.
2. If it says “A hypervisor has been detected. Features required for Hyper-V are not displayed“, this means that the role is already installed.
3. If Virtualization Enabled in Firmware is No, you must enable virtualization support in the BIOS/UEFI settings.

You can also use PowerShell to quickly check if hardware virtualization is enabled in firmware:

Get-CimInstance Win32_Processor |
Select-Object Name,VirtualizationFirmwareEnabled

If VirtualizationFirmwareEnabled returns True, hardware virtualization support is enabled in BIOS/UEFI. If the value is False, you need to enable virtualization support in the firmware settings before Hyper-V can start VMs.

You can also open System Information (msinfo32) and review the Hyper-V Requirements section.

Enable Virtualization in the Computer BIOS/UEFI Firmware

Even if your computer’s CPU supports hardware-assisted virtualization, the feature may not be enabled by default. Restart the machine and enter the BIOS/UEFI config menu. You need to ensure that the required virtualization features are enabled.

Enable firmware options in CPU configuration

Search for the CPU configuration section, then look for the following firmware options if available and enable them:

• Hardware-assisted virtualization can have a different name (depends on the vendor). For example, Intel Virtualization Technology (VT-X), AMD-V, Virtualization Extensions, or Vanderpool;

  

• Intel VT-d or AMD IOMMU;
• Hardware-enforced Data Execution Prevention (DEP): for Intel CPUs it’s the XD bit (eXecute Disable bit), and for AMD devices it’s the NX bit (No eXecute bit). For example, for HP servers, this option is called “No Execute Memory Protection”.
  

  

• SVM mode option (on AMD devices);

  

• Specific BIOS settings on HPE servers: ‘Intel(R) Virtualization Tech’ and ‘No Execute Memory Protection’.

Enable the required hardware virtualization options in the BIOS/UEFI firmware settings and save the changes. After changing virtualization settings, you need to perform a full shutdown and power cycle rather than only restarting Windows. Then power the system back on and boot Windows.

Check for Conflicts with Other Virtualization Software

Hyper-V can coexist with several Windows virtualization technologies, but third-party virtualization software may behave differently when the Hyper-V hypervisor is enabled. Common examples include VMware Workstation, VirtualBox, WSL 2, and Docker Desktop.

Do not automatically disable WSL 2, Virtual Machine Platform, or Docker Desktop when troubleshooting Hyper-V. Modern versions of VMware Workstation and VirtualBox can use Hyper-V-compatible Windows virtualization interfaces, and WSL 2 itself is based on the Hyper-V virtualization architecture. The correct action depends on which virtualization platform is intended to be authoritative on the host.

First, you need to check which Windows virtualization components are enabled:

Get-WindowsOptionalFeature -Online |
Where-Object FeatureName -match 'Hyper-V|VirtualMachinePlatform|Microsoft-Windows-Subsystem-Linux'

This shows whether Hyper-V, Virtual Machine Platform, and WSL components are enabled. WSL 2 uses the Windows virtualization stack, while Docker Desktop can use either WSL 2 or Hyper-V depending on its config.

If WSL is installed, you should check its current config:

wsl --status

If VMware Workstation/VirtualBox is also installed, check that you are using a version compatible with Hyper-V. Do not disable WSL 2/Virtual Machine Platform just because they are enabled, they do not normally prevent Hyper-V from running.

Tip. If Hyper-V itself is working but a third-party VM fails to start, you should investigate virtualization compatibility before changing BIOS settings/reinstalling Hyper-V.

Checking Secure Boot and DMA Protection

On modern UEFI-based systems, you need to check if Secure Boot and Kernel DMA Protection are configured as expected (especially when troubleshooting VBS, HVCI, or other virtualization-based security features).

To check Secure Boot, use the command:

Confirm-SecureBootUEFI

The command returns True when Secure Boot is enabled and False when it is disabled. Note that on systems that do not use UEFI, the command can return an error.

In order to check Kernel DMA Protection, use the following command:

Get-CimInstance -ClassName Win32_DeviceGuard |
Select-Object -ExpandProperty AvailableSecurityProperties

You can also check the current Kernel DMA Protection status in Windows Security → Device security → Core isolation details or System Information (msinfo32).

These settings are not normally required simply to start Hyper-V, but they can affect virtualization-based security features (such as VBS and HVCI). In case VBS/HVCI is involved in the problem, you need to verify the firmware and security config before changing/disabling these protections.

Add Hyper-V entry to Boot Configuration Data file

Then add a Hyper-V entry to the Boot Configuration Data file. Run the following command in the elevated cmd:

bcdedit /set hypervisorlaunchtype auto

After that, restart Windows for the change to take effect:

shutdown /r /t 0

It modifies the BCD file to specify that the Hyper-V hypervisor should launch automatically on system start (before the Windows OS boots).

To verify that Hyper-V is configured to start automatically, run:

bcdedit /enum | findstr /i hypervisorlaunchtype

The command should return hypervisorlaunchtype Auto. If the value is Off, Hyper-V will not start during system boot.

Repair or Reinstall Hyper-V as a Last Resort

Before reinstalling Hyper-V, you should check that virtualization support, hypervisor startup config, and Hyper-V services are functioning correctly. Use the command below:

systeminfo | findstr /i "Hyper-V"
(Get-CimInstance Win32_ComputerSystem).HypervisorPresent
Get-Service vmms,vmcompute
bcdedit /enum | findstr /i hypervisorlaunchtype

If any of these checks return unexpected results, you need to fix the reported issue before reinstalling Hyper-V.

In case the Hyper-V component installation is suspected to be damaged and the previous troubleshooting steps have not identified another cause, you should consider repairing/reinstalling the Hyper-V role. On production and clustered hosts, you need to treat role removal as a last resort and perform it only during an appropriate maintenance window.

On Windows 11 24H2 and 25H2, you can also enable Hyper-V from the Settings app. On supported builds, navigate to Settings → System → Advanced → Virtual Workspaces and use the available virtualization options in order to enable Hyper-V. This provides a modern GUI alternative to optionalfeatures.exe, DISM, and PowerShell-based feature management. Keep in mind that the exact availability of the Virtual Workspaces settings can depend on the Windows version, build, device config, and rollout status. You should continue using PowerShell, DISM, or management tools such as Microsoft Intune where appropriate.

1. Run the optionalfeatures command to open the Turn Windows features on or off dialog;
   

   

2. Go to the Hyper-V > Hyper-V Platform section and disable Hyper-V Hypervisor and Hyper-V Services features. Restart your computer and then re-enable these features.
   

   

On Windows 10 and Windows 11, you can disable and re-enable all Hyper-V components using PowerShell:

1. Disable the Hyper-V components:
   

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

2. Restart a computer:
   

   Restart-Computer

3. Enable the Hyper-V features:
   

   Enable-WindowsOptionalFeature `
   -Online `
   -FeatureName Microsoft-Hyper-V `
   -All `
   -NoRestart

4. Restart a machine:
   

   Restart-Computer

   

You can also enable the Hyper-V feature from an elevated Command Prompt using DISM:

DISM /Online /Enable-Feature /FeatureName:Microsoft-Hyper-V /All /NoRestart

For offline Windows images, you need to specify the mounted image instead of /Online:

DISM /Image:C:\Mount /Enable-Feature /FeatureName:Microsoft-Hyper-V /All

You should use DISM when enabling Hyper-V in a mounted Windows image/when PowerShell-based feature management is not available. DISM can also be incorporated into image-servicing and provisioning workflows in case of enterprise deployments.

On Windows Server, you can reinstall the Hyper-V role only as a last resort and during an approved maintenance window. Follow the steps below:

1. Remove the Hyper-V role and restart the server:

   Uninstall-WindowsFeature -Name Hyper-V -Restart

   The -Restart parameter reboots the server after the role is removed. Do not run the installation command until Windows has completed the reboot and the server is back online.
2. After the server has restarted, install Hyper-V again:

   Install-WindowsFeature -Name Hyper-V -IncludeManagementTools

3. Restart the server if prompted, then verify the Hyper-V services and hypervisor state:

   Get-Service vmms,vmcompute
   
   (Get-CimInstance Win32_ComputerSystem).HypervisorPresent

If the server is managed remotely, you can omit -IncludeManagementTools and install the required Hyper-V management tools on admin workstation instead.

If this doesn’t help, check the errors and warnings in the Event Viewer under Application and Services Logs > Microsoft > Windows > Hyper-V-Hypervisor.

For example, if the DEP options is disabled in BIOS, you will find Event ID 3112 from the Microsoft-Windows-Hyper-V-Worker source with the following description:

The virtual machine could not be started because the hypervisor is not running.

If you see Event ID 3112 from Microsoft-Windows-Hyper-V-Worker, you need to check the Hyper-V and firmware config. Microsoft documents this event for the The virtual machine could not be started because the hypervisor is not running error and identifies disabled Data Execution Prevention (DEP) in BIOS as one documented cause.

Wrapping Up

In most environments, this error is caused by one of the following config/hardware issues:

• Hardware virtualization is disabled in BIOS/UEFI
• Hyper-V is configured not to start automatically (hypervisorlaunchtype Off)
• Hyper-V services are stopped/corrupted
• The Hyper-V role installation is damaged
• Required CPU virtualization features are unavailable

By systematically checking Hyper-V services, event logs, firmware settings, virtualization requirements, and BCD config, you can identify the exact cause of the problem and restore normal VM startup without unnecessary Hyper-V reinstallation.