Interactive Troubleshooter

Published: Sep 28, 2026

Hyper-V VM Black Screen After Start: Integration Services

Time: 15 mins Level: Beginner

By StepDiag Engineering Team

Reviewed by Ibraheem Taofeeq Opeyemi

Systematically resolve Hyper-V virtual machine black screen display hangs during boot. This comprehensive decision tree addresses corrupted Hyper-V Integration Services, synthetic video driver initialization faults, Enhanced Session Mode (RDP/VMBus) negotiation failures, and Gen 2 UEFI Secure Boot payload conflicts.

Full Diagnostic Tree & Step-by-Step Overview

What specific display behavior or state does the Hyper-V Virtual Machine Connection window exhibit?

The VM turns on (CPU/RAM actively allocated), but the screen stays solid black without a blinking cursor or OS logo.
The VM displays the Windows/Linux boot logo, but screens immediately go black when transitioning to the login screen.
The VM screen remains black only when Enhanced Session Mode is activated or when connecting via vmconnect.exe.
Generation 2 UEFI VM displays a blank black screen or hangs on 'Booting from Dynamic Disk / SCSI' indefinitely.

Which Integration Component or VMBus transport state is currently observed on the host for this VM?

Integration Services report 'No Contact' or 'Protocol Mismatch' in Hyper-V Manager.
Dynamic Memory allocation is saturated or VM CPU is stuck at 100% thread usage during early boot kernel initialization.
The VM guest OS is Linux (Ubuntu, RHEL, Debian) running stock kernel modules without hyperv-daemons.
Hyper-V host was recently upgraded or updated, causing a VMBus synthetic device driver registry mismatch.

Hyper-V Integration Services Protocol Mismatch / Service Disablement

Solution:

Root Cause: VMBus Synthetic Channel Desynchronization

Hyper-V Virtual Machine Connection (vmconnect.exe) renders the guest console interface using the Hyper-V Video synthetic display device, which communicates over the VMBus protocol. When guest-side Integration Services services (such as vmicvss, vmicguestinterface, or vmicheartbeat) fail to initialize or match the host IC protocol version, the synthetic display pipeline fails to establish a framebuffer swapchain, resulting in a solid black screen.

# Diagnostic Verification:

1. Open PowerShell as Administrator on the Hyper-V host.
2. Query the active Integration Services status for the affected virtual machine:

powershell
   Get-VMIntegrationService -VMName "TargetVM"

3. Check if core services (specifically Guest Service Interface and Heartbeat) display PrimaryStatusDescription : No Contact or Enabled : False.

# Step-by-Step Fix:

1. Enable All Integration Components via Host PowerShell:

powershell
   Enable-VMIntegrationService -VMName "TargetVM" -Name "Guest Service Interface", "Heartbeat", "Key-Value Pair Exchange", "Shutdown", "Time Synchronization", "VSS"

2. Disable and Re-enable Synthetic Video Adapter via VM Settings:

Turn off the VM completely:

powershell
     Stop-VM -VMName "TargetVM" -TurnOff

Force the VM to recalculate video buffer memory allocated to the basic display adapter:

powershell
     Set-VMVideoAdapter -VMName "TargetVM" -HorizontalResolution 1920 -VerticalResolution 1080 -MaximumMemoryMegabytes 64

3. Inject Integration Drivers into Offline VHDX (if guest OS is corrupted):

Mount the guest OS VHDX on the host using Disk Management or PowerShell (Mount-VHD).

Use DISM to verify hyperv-integration drivers exist in %SystemRoot%\System32\drivers\vmbus.sys.

# Prevention & Long-Term Monitoring:

Ensure guest Windows operating systems receive regular Windows Cumulative Updates, which include updated Microsoft-Hyper-V-Guest-Integration-Drivers.

Dynamic Memory Pressure & Early Kernel Resource Deadlock

Solution:

Root Cause: Dynamic Memory Starvation During Display Driver Initialization

When a virtual machine boots with Dynamic Memory enabled and a Startup RAM setting that is too low (e.g., 512 MB or 1024 MB for modern Windows Server/Windows 11 guests), the OS kernel allocates memory for early boot drivers. During display driver initialization, the kernel attempts to map video memory frames. If available host memory is restricted, the kernel thread deadlocks while waiting for RAM expansion, leaving the display rendering pipeline initialized to a black screen.

# Diagnostic Verification:

1. Open Hyper-V Manager and select the target virtual machine.
2. Review the Memory Demand and Memory Status fields at the bottom pane.
3. Observe if Memory Status reports Warning or Critical while the VM is stuck on the black screen.

# Step-by-Step Fix:

1. Power Off Virtual Machine:

powershell
   Stop-VM -VMName "TargetVM" -Force

2. Adjust Memory Allocation Settings:

Open VM Settings > Hardware > Memory.

Increase Startup RAM to a minimum of 4096 MB for Windows 10/11/Server 2022.

Increase Minimum RAM to at least 2048 MB.

Set Maximum RAM to an adequate upper boundary (e.g., 16384 MB).

3. Adjust NUMA and CPU Core Allocations:

Ensure virtual processor allocation does not exceed physical host NUMA node bounds:

powershell
     Set-VMProcessor -VMName "TargetVM" -Count 4

4. Restart Virtual Machine:

powershell
   Start-VM -VMName "TargetVM"

# Prevention & Long-Term Monitoring:

Avoid setting Startup RAM lower than 2048 MB on modern x64 guest operating systems using Dynamic Memory.

Linux Guest Kernel DRM / Hyper-V Synthetic Framebuffer Driver Conflict

Solution:

Root Cause: Direct Rendering Manager (DRM) Mode-Setting Collision with hyperv_fb

Linux distributions (such as Ubuntu, RHEL, or Fedora) utilize kernel mode setting (KMS) for graphic rendering. During boot, the Linux kernel transitions from the early VESA/EFI framebuffer to the Hyper-V synthetic frame buffer driver (hyperv_fb or hyperv_drm). If the guest kernel lacks updated hyperv-daemons or encounters a resolution handshake failure with Hyper-V's synthetic display hardware, output drops to black immediately after GRUB.

# Diagnostic Verification:

1. Boot Linux VM and press Esc or Shift during early startup to open the GRUB boot menu.
2. Press e on the default kernel entry to edit boot arguments.
3. Check for kernel parameters like quiet splash.

# Step-by-Step Fix:

1. Edit Boot Parameters in GRUB:

Append the following parameter to the line starting with linux:

text
     nomodeset video=hyperv_fb:1920x1080

Press Ctrl + X or F10 to boot with these temporary settings.

2. Install Linux Integration Services (LIS) Daemons inside Guest OS:

Once booted into the terminal shell, update and install hyperv tools:

Ubuntu/Debian:

bash
       sudo apt-get update
       sudo apt-get install -y linux-image-extra-virtual linux-tools-virtual linux-cloud-tools-virtual linux-cloud-tools-generic

RHEL/CentOS/Rocky Linux:

bash
       sudo yum install -y hyperv-daemons

3. Update GRUB Defaults Permanently:

Edit /etc/default/grub using a text editor (sudo nano /etc/default/grub).

Update GRUB_CMDLINE_LINUX_DEFAULT to include video=hyperv_fb:1920x1080.

Update GRUB configuration:

bash
     sudo update-grub

# Prevention & Long-Term Monitoring:

Keep Linux kernel versions updated and ensure hyperv-daemons service is enabled (sudo systemctl enable hyperv-daemons).

Host Feature Upgrade / Orphaned Hyper-V Display Adapter Driver

Solution:

Root Cause: Orphaned Synthetic Display Registry Binding

Following a Windows Server or Windows 11 host Feature Update, the host-side Hyper-V synthetic display device class (Hyper-V Video) GUID bindings can desynchronize from guest OS device nodes. The guest OS attempts to send drawing commands to an unmapped VMBus channel instance, leaving the VM console black while the underlying OS continues running headlessly.

# Diagnostic Verification:

1. Verify if the VM is responding to network ping requests despite the console showing a black screen.
2. Attempt RDP directly to the guest VM's IP address (mstsc.exe /v:<VM_IP>).
3. If RDP works normally but Hyper-V Manager console remains black, the host synthetic video pipeline is desynchronized.

# Step-by-Step Fix:

1. Remove and Re-add Virtual Display Adapter via PowerShell:

Shut down the virtual machine.

Run Command Prompt / PowerShell as Administrator on host:

powershell
     Set-VMVideoAdapter -VMName "TargetVM" -ResetToDefaults

2. Re-register Hyper-V Host Worker Process DLLs:

Open Command Prompt as Administrator on host:

cmd
     net stop vmms
     regsvr32 /s %systemroot%\system32\vmsvc.dll
     net start vmms

3. Reset VMConnect Connection Cache:

Delete local connection preference files under %APPDATA%\Microsoft\Windows\Hyper-V\Client\1.0\ on the host workstation.

# Prevention & Long-Term Monitoring:

Always restart the vmms service (Hyper-V Virtual Machine Management) after installing host cumulative updates.

What display or driver transition occurs right before the screen turns black?

The screen turns black immediately when the Windows display driver loads (`BasicDisplay.sys` to `HyperVideo.sys`).
The screen turns black because RemoteFX or discrete Discrete Device Assignment (DDA) / vGPU is misconfigured.
The screen turns black due to a corrupted graphics driver or third-party display driver installed inside the guest.
The screen turns black due to BitLocker TPM / PIN unlock prompt failing to render on the virtual display.

Synthetic Display Driver Initialization Crash (HyperVideo.sys / BasicDisplay.sys)

Solution:

Root Cause: Windows Kernel Mode Driver Framework (KMDF) Display Initialization Crash

During boot, Windows transitions from Microsoft Basic Display Driver (BasicDisplay.sys) to the Microsoft Hyper-V Video driver (HyperVideo.sys). If the guest OS registry contains corrupted resolution parameters or if KMDF encounters a page fault when allocating framebuffers, the display thread crashes silently without BugCheck rendering, freezing the output on a black screen.

# Diagnostic Verification:

1. Boot the VM in Safe Mode:

Force shut down the VM 3 times during boot to trigger Windows Automatic Repair.

Select Troubleshoot > Advanced options > Startup Settings > Restart.

Press 4 or F4 to enable Safe Mode.

2. If Safe Mode boots successfully with basic display output, HyperVideo.sys or custom resolution configurations are faulty.

# Step-by-Step Fix:

1. Reset Graphics Resolution Settings via Safe Mode Registry Edit:

Press Win + R, type regedit, press Enter inside Safe Mode.

Navigate to:

HKLM\SYSTEM\CurrentControlSet\Control\GraphicsDrivers\Configuration

Right-click and delete subkeys under Configuration and Connectivity to force Windows to rebuild monitor topology.

2. Reinstall Hyper-V Synthetic Video Driver:

Open Device Manager inside Safe Mode (devmgmt.msc).

Expand Display adapters > Right-click Microsoft Hyper-V Video > Select Uninstall device.

Check Attempt to remove the driver for this device if prompted.

3. Reboot into Normal Mode:

Windows will automatically discover the synthetic hardware and re-bind a clean driver instance upon reboot.

# Prevention & Long-Term Monitoring:

Avoid installing third-party physical GPU display drivers (NVIDIA/AMD desktop packages) inside standard Hyper-V VMs unless using DDA.

Legacy RemoteFX / Deprecated vGPU Allocation Failure

Solution:

Root Cause: Deprecated RemoteFX vGPU / Invalid GPU Partitioning Allocation

Microsoft officially deprecated and removed RemoteFX 3D Video Adapter functionality from Hyper-V due to security vulnerabilities. If an older virtual machine configured with a RemoteFX 3D adapter or invalid GPU Partitioning (GPU-P) instance starts, the Hyper-V worker process (vmwp.exe) fails to initialize video output, resulting in a black screen when the guest OS loads GPU drivers.

# Diagnostic Verification:

1. Open PowerShell as Administrator on host.
2. Inspect VM hardware adapters:

powershell
   Get-VMRemoteFx3dVideoAdapter -VMName "TargetVM"

3. Check Event Viewer on host: Applications and Services Logs > Microsoft > Windows > Hyper-V-VMMS > Admin for Event ID 32510 or RemoteFX errors.

# Step-by-Step Fix:

1. Remove Legacy RemoteFX Adapter via PowerShell:

powershell
   Remove-VMRemoteFx3dVideoAdapter -VMName "TargetVM"

2. Reconfigure GPU-Partitioning (GPU-P) correctly (if physical GPU pass-through is required):

Copy physical GPU host drivers from host C:\Windows\System32\DriverStore\FileRepository\ into the guest OS System32\HostDriverStore directory.

Assign GPU partition object using PowerShell:

powershell
     Add-VMGpuPartitionAdapter -VMName "TargetVM"
     Set-VMGpuPartitionAdapter -VMName "TargetVM" -MinPartitionVRAM 1 -MaxPartitionVRAM 100 -OptimalPartitionVRAM 100

3. Power On Virtual Machine:

powershell
   Start-VM -VMName "TargetVM"

# Prevention & Long-Term Monitoring:

Migrate legacy RemoteFX workloads to modern GPU Partitioning (GPU-P) or Discrete Device Assignment (DDA).

Corrupted Guest OS Graphics Subsystem / Third-Party Driver Collision

Solution:

Root Cause: Desktop Window Manager (DWM) Crash in Guest OS

A corrupted Desktop Window Manager (dwm.exe) executable or conflicting virtual display mirror drivers (e.g., installed by third-party remote access software like Citrix, LogMeIn, or TeamViewer) override default display pipeline hooks, causing DWM to crash in an infinite restart loop during user session startup.

# Diagnostic Verification:

1. Access the VM file system offline or via administrative network share (\\VM_IP\C$).
2. Inspect Windows Event Logs under C:\Windows\System32\winevt\Logs\Application.evtx.
3. Look for Event ID 1000 (Application Error) pointing to dwm.exe or lsass.exe.

# Step-by-Step Fix:

1. Boot into Safe Mode:

Interrupt boot 3 times to enter WinRE > Select Startup Settings > Safe Mode.

2. Remove Third-Party Display Drivers:

Open Command Prompt as Administrator inside Safe Mode.

List installed third-party drivers:

cmd
     dism /online /get-drivers /format:table

Remove offending display mirror driver:

cmd
     pnputil /delete-driver oemXX.inf /uninstall /force

3. Perform System File Inspection:

cmd
   sfc /scannow
   DISM /Online /Cleanup-Image /RestoreHealth

4. Reboot Machine.

# Prevention & Long-Term Monitoring:

Avoid installing kernel-level display mirror drivers on Hyper-V virtualized operating systems.

BitLocker / Key Protector Prompt Rendering Failure

Solution:

Root Cause: Early Boot Video Mode Mismatch During Virtual TPM Authentication

If BitLocker drive encryption is enabled inside a Generation 2 Hyper-V VM using Virtual TPM (vTPM), and the BitLocker policy is configured to require a Startup PIN or recovery key prompt, the early boot pre-authentication screen attempts to render at a resolution unsupported by the basic EFI display driver. The screen stays black, waiting for PIN input that is invisible to the user.

# Diagnostic Verification:

1. Open Hyper-V Manager > VM Settings > Security.
2. Confirm Enable Trusted Platform Module is checked.
3. Press keys on the black screen (e.g., press Esc or enter a known BitLocker PIN and hit Enter). If the VM suddenly proceeds to boot, the PIN prompt is rendering blindly.

# Step-by-Step Fix:

1. Force Standard Resolution in UEFI Boot Configuration:

Shut down VM.

Open PowerShell as Administrator on host:

powershell
     Set-VMVideoAdapter -VMName "TargetVM" -HorizontalResolution 1024 -VerticalResolution 768

2. Retrieve BitLocker Recovery Key from Entra ID / Active Directory:

Obtain the 48-digit recovery key from your administrative portal.

3. Type Recovery Key Blindly or via Serial Console:

If screen remains black, type the 48-digit key directly into the VMConnect window and press Enter.

4. Reconfigure BitLocker TPM-Only Protector inside Guest:

Once booted into Windows, open PowerShell (Admin) inside guest:

powershell
     Add-BitLockerKeyProtector -MountPoint "C:" -TpmProtector

# Prevention & Long-Term Monitoring:

Use TPM-only key protectors for automated server VMs to eliminate early boot interactive PIN prompts.

What occurs when switching between Basic Session and Enhanced Session Mode?

Basic Session works normally, but switching to Enhanced Session immediately results in a black window.
Enhanced Session connects, displays credentials prompt, then turns black after entering credentials.
Host-level Hyper-V Guest Access Service is disabled, preventing VMBus RDP socket creation.
Remote Desktop Services (TermService) inside the guest OS is disabled or crashing.

Enhanced Session Mode (RDP Over VMBus) Handshake Failure

Solution:

Root Cause: VMBus Transport Channel Disconnect During Enhanced Session Escalation

Enhanced Session Mode in Hyper-V operates by establishing a Remote Desktop Protocol (RDP) connection over the internal VMBus transport mechanism rather than the network adapter. If the guest operating system's Remote Desktop Configuration service or security policy rejects local VMBus RDP connections, the connection window drops display buffers, leaving a persistent black screen.

# Diagnostic Verification:

1. In the Hyper-V Manager VMConnect window, click View on the top menu bar.
2. Toggle Enhanced Session off (uncheck).
3. If checking Basic Session instantly reveals the guest desktop screen, Enhanced Session negotiation is failing.

# Step-by-Step Fix:

1. Re-enable Enhanced Session Transport on Host:

Open PowerShell as Administrator on the Hyper-V host:

powershell
     Set-HyperVConfiguration -EnhancedSessionModePolicy $true
     Set-VM -VMName "TargetVM" -EnhancedSessionTransportType HvSocket

2. Allow Remote Desktop Connections inside Guest OS Registry:

If able to access guest via Basic Session or PowerShell Direct:

powershell
     Set-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name "fDenyTSConnections" -Value 0
     Enable-NetFirewallRule -DisplayGroup "Remote Desktop"

3. Clear Saved VMConnect Connection Credentials:

Close all VMConnect windows.

Delete configuration file under %APPDATA%\Microsoft\Windows\Hyper-V\Client\1.0\vmconnect.config.

# Prevention & Long-Term Monitoring:

Ensure Group Policy objects (GPO) applied to virtual machines do not disable Remote Desktop Services.

User Profile Service Initialization Hang / Shell Render Timeout

Solution:

Root Cause: User Profile Service Locking During Virtual Smart Card / Single Sign-On Authentication

When logging in via Enhanced Session Mode, Windows attempts to map local client resources (printers, drives, clipboard) into the guest session over VMBus. If a mapped drive or network share inside the user profile hangs during session initialization, the Windows Shell (explorer.exe) fails to render, leaving the user with an active RDP session displaying a solid black background without desktop icons.

# Diagnostic Verification:

1. Connect via Enhanced Session and enter credentials.
2. Screen turns black.
3. Press Ctrl + Shift + Esc or Ctrl + Alt + End to test if Windows Security or Task Manager opens.
4. If Task Manager opens, explorer.exe failed to launch automatically.

# Step-by-Step Fix:

1. Launch Explorer Manually from Task Manager:

Click Run new task > Type explorer.exe > Press Enter.

2. Disable Local Resource Redirection in VMConnect Configuration:

When opening VMConnect, click Show Options on the Enhanced Session prompt.

Go to Local Resources tab.

Uncheck Printers, and under More, uncheck Drives.

Click Connect.

3. Fix Corrupted User Profile Registry Keys inside Guest:

Open regedit in guest > Navigate to:

HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList

Ensure no orphaned profile keys containing .bak extensions exist.

# Prevention & Long-Term Monitoring:

Avoid redirecting slow host storage drives across Enhanced Session connections.

Hyper-V Guest Access Service Unregistered on Host

Solution:

Root Cause: Stopped or Unregistered vmicguestinterface Service

The vmicguestinterface service (Hyper-V Guest Access Service) routes low-level communications between the host VMMS service and the guest operating system. If this service is stopped inside the guest OS or disabled on the host, Enhanced Session Mode cannot establish its socket listener.

# Diagnostic Verification:

1. Test PowerShell Direct connection from host to VM:

powershell
   Enter-PSSession -VMName "TargetVM"

2. If PowerShell Direct fails with The Windows Remote Management service cannot process the request, the Guest Access Service channel is down.

# Step-by-Step Fix:

1. Start Service inside Guest via Host PowerShell Direct or Basic Session:

Run command on host to query guest services:

powershell
     Invoke-Command -VMName "TargetVM" -ScriptBlock { Get-Service -Name "vmicguestinterface" }

Force start and configure service for automatic boot:

powershell
     Invoke-Command -VMName "TargetVM" -ScriptBlock {
         Set-Service -Name "vmicguestinterface" -StartupType Automatic
         Start-Service -Name "vmicguestinterface"
     }

2. Verify Host-Side Integration Settings:

powershell
   Enable-VMIntegrationService -VMName "TargetVM" -Name "Guest Service Interface"

# Prevention & Long-Term Monitoring:

Include vmicguestinterface in administrative service monitoring templates for all virtualized workloads.

Remote Desktop Services (TermService) Crash inside Guest

Solution:

Root Cause: TermService Dependencies Crash in Guest System32 DLLs

If the Remote Desktop Services service (TermService) in the guest operating system experiences a dependency failure (e.g., corrupted termsrv.dll or RPC service block), Enhanced Session Mode handshakes start, negotiate initial keys, and instantly crash, returning the console to black.

# Diagnostic Verification:

1. Connect to guest OS via Basic Session.
2. Open services.msc and inspect Remote Desktop Services.
3. Verify if status reads Stopped or if restarting the service throws error 1068 (The dependency service or group failed to start).

# Step-by-Step Fix:

1. Repair System Binaries in Guest OS:

Open PowerShell as Administrator inside guest:

powershell
     sfc /scannow

2. Reset Terminal Services Registry Keys to Default:

Ensure required service dependencies (RpcSs, TermDD) are running:

powershell
     Set-Service -Name "RpcSs" -StartupType Automatic
     Start-Service -Name "RpcSs"
     Set-Service -Name "TermService" -StartupType Automatic
     Start-Service -Name "TermService"

3. Restart Virtual Machine.

# Prevention & Long-Term Monitoring:

Monitor Event Viewer Application logs for Event ID 7023 or 7034 related to TermService crashes.

What UEFI / Secure Boot or SCSI controller error occurs on the Generation 2 VM?

UEFI Secure Boot blocks Linux / unsigned kernel payloads, hanging on a blank screen.
Virtual Hard Disk (VHDX) is attached to an improperly ordered SCSI Controller or missing boot entry.
BitLocker / TPM platform key validation drops video rendering during UEFI handover.
VHDX file is corrupted or experiencing underlying storage queue timeouts on physical disk.

Generation 2 UEFI Secure Boot Payload Rejection

Solution:

Root Cause: Microsoft Authenticode Certificate Template Mismatch

Generation 2 Hyper-V virtual machines default to using the Microsoft Windows Secure Boot template. When booting Linux distributions, custom OS images, or older bootloaders that are signed with the Microsoft Corporation UEFI CA certificate instead of the Windows core production key, the UEFI firmware fails to load the bootloader execution binary (shimx64.efi or grubx64.efi). The VM halts immediately, showing a blank black screen.

# Diagnostic Verification:

1. Open Hyper-V Manager > Right-click VM > Settings.
2. Navigate to Security.
3. Check if Enable Secure Boot is checked and inspect the Template drop-down menu.

# Step-by-Step Fix:

1. Change Secure Boot Template for Linux Guest OS:

Power off VM:

powershell
     Stop-VM -VMName "TargetVM" -TurnOff

Change template via PowerShell:

powershell
     Set-VMSecureBootConfiguration -VMName "TargetVM" -SecureBootTemplate "MicrosoftUEFICertificateAuthority"

2. Alternatively, Disable Secure Boot (For Unsigned Custom Kernels):

powershell
   Set-VMSecureBootConfiguration -VMName "TargetVM" -EnableSecureBoot $false

3. Power On Virtual Machine:

powershell
   Start-VM -VMName "TargetVM"

# Prevention & Long-Term Monitoring:

Always select the MicrosoftUEFICertificateAuthority template when creating new Gen 2 Linux virtual machines in Hyper-V.

Invalid UEFI Firmware Boot Order / SCSI Controller Assignment

Solution:

Root Cause: Unmapped EFI Boot Path or Missing SCSI Drive Binding

Generation 2 virtual machines boot exclusively via virtualized SCSI controllers and UEFI firmware. If the primary OS VHDX is moved to a secondary SCSI location (e.g., Controller 0, Location 1 instead of Location 0) or if the EFI System Partition (ESP) boot entry is cleared from NVRAM, UEFI fails to identify a bootable payload and halts with a blank black console screen.

# Diagnostic Verification:

1. Open Hyper-V Manager > VM Settings > Firmware.
2. Inspect the Boot Order list.
3. Check if File or Hard Drive entries are missing or marked with error warnings.

# Step-by-Step Fix:

1. Re-order UEFI Boot Entries in Hyper-V Settings:

Open VM Settings > Firmware.

Select the virtual hard disk entry (.vhdx) and click Move Up to place it at the top of the boot order.

2. Rebuild EFI Boot Manager Entries via PowerShell:

powershell
   $vm = Get-VM -Name "TargetVM"
   $hdd = Get-VMHardDiskDrive -VMName "TargetVM" -ControllerType SCSI
   Set-VMFirmware -VM $vm -FirstBootDevice $hdd

3. Repair Corrupted EFI BCD Store inside VHDX (if bootloader is missing):

Mount VHDX on host using Disk Management.

Assign drive letters to the EFI System Partition (FAT32) and OS Partition (NTFS).

Open Command Prompt as Administrator on host and run:

cmd
     bcdboot X:\Windows /s S: /f UEFI

*(Where X: is the OS volume and S: is the EFI volume).*
4. Unmount VHDX and Start VM.

# Prevention & Long-Term Monitoring:

Do not detach or re-order SCSI controllers hosting the primary OS boot partition.

Virtual TPM Encryption State Desynchronization

Solution:

Root Cause: Isolated Key Storage (vTPM) Passphrase Decryption Timeout

Generation 2 VMs using Virtual TPM (vTPM) rely on the host's Host Guardian Service (HGS) or local Shielded VM Key Protector to decrypt the VM state file (.vmrs) and VHDX header keys upon startup. If host key isolation services fail to respond during boot, the virtual motherboard halts before launching the display driver, holding the screen on solid black.

# Diagnostic Verification:

1. Check Event Viewer on host: Applications and Services Logs > Microsoft > Windows > Hyper-V-Worker > Admin.
2. Search for Event ID 12010 or error messages stating: Failed to decrypt security structure or Key protector validation failed.

# Step-by-Step Fix:

1. Verify Host Key Attestation Status:

Run command on host:

powershell
     Get-KeyStorageProvider

2. Export and Re-bind vTPM Key Protector:

Open PowerShell as Administrator on host:

powershell
     Disable-VMTPM -VMName "TargetVM"
     Enable-VMTPM -VMName "TargetVM"

3. Restart Hyper-V Virtual Machine Management Service:

cmd
   net stop vmms && net start vmms

# Prevention & Long-Term Monitoring:

Maintain valid certificate lifecycles for Shielded VM Key Protectors and Host Guardian Services.

VHDX Storage Allocation Timeout & Physical Disk I/O Queue Bottleneck

Solution:

Root Cause: Disk I/O Queue Stalls and Sparse VHDX Expansion Deadlock

When a virtual machine uses Dynamically Expanding VHDX files stored on a slow or failing physical hard drive (or overloaded SAN/SMB share), the physical disk storage controller may encounter extreme I/O response latencies (>1000ms). When the VM OS requests dynamic disk expansion during boot, the Hyper-V storage stack waits for disk block allocation, freezing the VM console output on a black screen.

# Diagnostic Verification:

1. Open Task Manager or Resource Monitor (resmon.exe) on the Hyper-V host.
2. Navigate to the Disk tab and check Response Time and Queue Length for the volume containing the .vhdx file.
3. Check Event Viewer: System log for Event ID 129 (storport reset) or Event ID 153 (IO operation retried).

# Step-by-Step Fix:

1. Convert Dynamically Expanding VHDX to Fixed Size Disk:

Shut down VM:

powershell
     Stop-VM -VMName "TargetVM" -Force

Convert disk type using PowerShell:

powershell
     Convert-VHD -Path "C:\VMs\TargetVM\Virtual Hard Disks\disk.vhdx" -DestinationPath "D:\FastStorage\TargetVM\disk_fixed.vhdx" -VHDType Fixed

2. Re-attach New Fixed VHDX to VM Settings:

Swap disk paths under VM Settings > SCSI Controller.

3. Optimize Host Physical Disk Storage:

Move VM storage volumes to high-performance NVMe/SSD storage pools.

# Prevention & Long-Term Monitoring:

Use Fixed-Size VHDX files for production enterprise virtual machines to eliminate runtime disk expansion latency.

Related Diagnostic Guides

AI Transcription Hallucinating: Model and Noise Diagnostic

PXE Boot Failed: DHCP Option 66 / 67 Fix Guide

BMS Error on Power Station: Reset and Recovery Guide

eGPU Not Detected via USB4: Bandwidth and Driver

Matter Bridge Not Showing Devices to Alexa / Google: Fix Guide

Subscribe to StepDiag

Embed Guide on Your Website