Hyper-V VHD Not Found: 3 Quick Fixes That Work

Cause #1: The VHD/VHDX file was moved or renamed

This is the most common reason. You moved the virtual hard disk to another folder, another drive, or renamed it. Hyper-V still points to the old path. The error shows up as 0x80070003 — “The system cannot find the path specified.”

I see this all the time when people reorganize their storage. They drag the VHDX file to a “Old VMs” folder or an external drive, then wonder why the VM won’t boot.

How to fix it

1. Open Hyper-V Manager. Right-click the VM and select Settings.
2. Go to SCSI Controller > Hard Drive. Look at the path listed under “Virtual hard disk.”
3. If the path is wrong, click Browse and point to the correct VHD/VHDX file.
4. Click OK, then start the VM.

If you renamed the file, you’ll need to either rename it back or update the path. Don’t rename files after you attach them to a VM — Hyper-V doesn’t track renames. It only stores the exact file path at attachment time.

Example: 
Old path: D:\VMs\WindowsServer\disk.vhdx
New path: E:\Archive\WindowsServer\disk.vhdx

Fix: Browse to the new location, or move the file back.

Cause #2: The VHD file is there, but Hyper-V can’t read it (permissions)

This one tricks people. The file sits in the correct folder, you can see it in Explorer, but the VM still throws the same error. What’s happening: the Hyper-V Host Compute Service account (NT VIRTUAL MACHINE\...) doesn’t have read access to the file or its parent folder.

I hit this after restoring from a backup. The backup preserved the file but wiped the NTFS permissions. Hyper-V runs under a virtual machine-specific security context, not your user account. So even if you can open the file, Hyper-V can’t.

How to fix it

1. Right-click the VHD/VHDX file in Explorer, go to Properties > Security.
2. Click Advanced, then Add.
3. Click Select a principal, type NT VIRTUAL MACHINE\ (note the backslash at the end). Then click Check Names — it should resolve to something like NT VIRTUAL MACHINE\Virtual Machines.
4. Give it Read & execute and Read permissions. Click OK all the way.
5. Do the same for the folder containing the VHD. Right-click the folder, go to Properties > Security, repeat steps 2–4.

The reason step 4 matters: if Hyper-V can’t list the folder, it can’t find the file. Even if the file’s permissions are correct, the parent folder must allow traversal.

Cause #3: The VHD path is broken due to a checkpoint chain issue

Hyper-V checkpoints (snapshots) create a chain of differencing disks. The parent VHD is read-only, and children store changes. If you delete a checkpoint file manually (don’t do this) or move the VM folder without Hyper-V, the chain breaks. The VM references an AVHDX file that no longer exists.

This happens more on Hyper-V Server 2019 and Windows 11 Pro. The error message is still the same, just cryptic. You might see “The virtual machine could not be started because the hypervisor is not running” but really it’s a missing checkpoint file.

How to fix it

1. Open Hyper-V Manager. Right-click the VM, choose Checkpoints > Delete Checkpoint Subtree. This merges all children into the parent VHD.
2. If the checkpoint is “bad” and won’t delete, use PowerShell:
   Get-VM -Name "YourVMName" | Get-VMSnapshot | Remove-VMSnapshot
3. After clearing checkpoints, check the VM settings (like Cause #1) to make sure the VHD path still points to the base VHDX.

If you need the checkpoint data, you can try to manually merge it with Merge-VHD in PowerShell. But honestly, if the chain is broken, you’re often better off restoring from a backup and re-creating checkpoints.

Quick reference summary

Start with Cause #1. That’s the fix 80% of the time. If not, go to permissions. The checkpoint issue is rarer but painful when it hits. And next time, don’t manually move VM files — use Hyper-V’s Move feature in the GUI or PowerShell. It handles paths and permissions for you.