Repair a Native VHDX boot entry that points to a missing or moved VHDX

Windows Boot Manager can start Windows directly from a local Native Boot VHDX. If the VHDX file is renamed, moved, deleted, blocked, stored on an unavailable parent volume, or referenced by the wrong BCD path, selecting that entry fails even though other Windows entries may still boot.

For Windows 10 and later Native Boot, Microsoft requires VHDX rather than the older VHD format. The host/parent volume must remain a supported basic local volume with enough free space for the VHDX and external page file. This is a specialist deployment feature, not the same as starting a Hyper-V virtual machine.

Searchable Windows error codes and exact messages

Use when a known Native Boot menu entry has device and osdevice values beginning with vhd= and the referenced local .vhdx is missing, moved, renamed, blocked by Mark of the Web, or inaccessible because its parent volume changed.

Do not use for Hyper-V VM configuration files, differencing disks whose parent chain is broken, Azure VMs, VHDX files stored on an unsupported network path, or ordinary partition-based Windows. Do not create a new empty VHDX in place of a missing one; that destroys the diagnostic distinction and will not restore its contents.

The original drive letter may remain unknown because WinRE letters change. The loader GUID, BCD store, actual VHDX filename/path, parent physical volume, VHDX integrity, and free-space requirement may not remain unknown.

• Another bootable Windows entry or current recovery media
• Readable BCD store and backup
• Verified copy of the intended VHDX
• Enough parent-volume free space for a dynamic VHDX to expand to its configured maximum plus paging needs
• Administrative Command Prompt; Windows PowerShell from a working Windows installation for Mark-of-the-Web removal when applicable

Boot another working Windows entry or external recovery media. Do not select, create, compact, expand, merge, or detach virtual disks until the actual file and entry are inventoried. Use detected letters; examples use P: for the parent volume.

1. Enumerate BCD verbosely:

   bcdedit /enum all /v
   

   If using an offline store:

   bcdedit /store S:\EFI\Microsoft\Boot\BCD /enum all /v
   

2. Identify the Native Boot loader GUID. Record description, device, osdevice, path, systemroot, detecthal, and inherit.

3. Back up the exact store:

   bcdedit /export P:\BCD-backup-<date>.bcd
   

   Or copy the offline BCD file to a separate backup path.

4. Map parent volumes with DiskPart and assign a temporary unused letter only to the proven volume.

5. Test the exact path from the BCD record:

   dir /a "P:\VHDs\<Windows-file>.vhdx"
   

6. Search likely local parent volumes only when the file was moved:

   dir P:\*.vhdx /s /b
   

7. Inspect the VHDX read-only:

   diskpart
   select vdisk file="P:\VHDs\<Windows-file>.vhdx"
   detail vdisk
   attach vdisk readonly
   list disk
   list volume
   detach vdisk
   exit
   

   Stop if DiskPart reports corruption, a missing differencing parent, or I/O errors.

8. Check parent free space. A dynamic VHDX may need room to grow to its maximum size and Windows creates its page file outside the VHDX for Native Boot.

9. If the file was downloaded or copied from an Internet-zone source and updates from November 2022 or later are installed, check for Mark of the Web from a working Windows PowerShell session:

   Get-Item -LiteralPath 'P:\VHDs\<Windows-file>.vhdx' -Stream Zone.Identifier -ErrorAction SilentlyContinue
   

Choose one branch; do not combine them blindly.

Branch A — File was renamed or moved

1. Safest: restore the verified VHDX to its original BCD path and name.

2. If the new location is intentional, copy the loader entry first so the original remains available:

   bcdedit /copy {<Native-VHDX-loader-GUID>} /d "Windows VHDX — corrected path"
   

3. Record the new GUID returned. Set both device and osdevice to the same verified VHDX. Using [locate] avoids relying on WinRE’s temporary letter when the local layout is unambiguous:

   bcdedit /set {<new-GUID>} device vhd=[locate]\VHDs\<Windows-file>.vhdx
   bcdedit /set {<new-GUID>} osdevice vhd=[locate]\VHDs\<Windows-file>.vhdx
   bcdedit /set {<new-GUID>} detecthal yes
   

4. Re-enumerate the new entry and compare every field with the original.

Branch B — Mark of the Web blocks an otherwise valid local VHDX

1. From a trusted working Windows installation, verify the file came from a trusted controlled source and validate its hash.

2. Remove only the Zone.Identifier stream:

   Unblock-File -LiteralPath 'P:\VHDs\<Windows-file>.vhdx'
   

3. Do not unblock an unknown image merely to make it boot.

Branch C — Parent volume is unavailable or full

1. Restore the parent disk/volume connection or its prior stable mount identity.
2. Free space by moving unrelated, backed-up files—not by deleting or compacting the only VHDX.
3. Do not move the VHDX again unless BCD is deliberately updated and the move is verified.

Branch D — VHDX itself is damaged or absent

1. Restore the verified VHDX from backup to the expected path.
2. If no backup exists, treat this as data recovery. A new VHDX is a new installation, not a repair.

• Original path restored and entry boots: path/parent availability was causal.
• Copied entry with corrected path boots: preserve the original temporarily, then remove it only after verification and a fresh BCD backup.
• Read-only attach fails: VHDX or parent chain/storage is damaged; stop BCD edits.
• VHDX attaches but Windows shows a named internal boot error: the outer path works; diagnose the Windows installation inside the VHDX separately.

Do not create an empty VHDX with the missing name, set only device but not osdevice, use a guessed WinRE drive letter in permanent BCD, compact/merge the only copy, remove Mark of the Web from an untrusted image, or delete the old loader before the new one boots.

Select the original loader from the boot menu. Delete only the newly copied test entry if it is proven wrong:

bcdedit /delete {<new-GUID>}

If the original store was damaged, restore the exported BCD from external recovery. Return the VHDX to its original path if it was moved during testing.

Verify the corrected entry twice, then verify another boot entry still works. Confirm the VHDX path, parent free space, BCD device/osdevice, Windows edition/build inside the VHDX, and absence of new disk or file-system errors. Make a new BCD backup after final cleanup.

Confidence is about 80% when the BCD path is proven wrong or unavailable, the exact VHDX attaches read-only without errors, correcting only the path/availability changes the result, and two boots succeed. Stop for a broken differencing chain, damaged VHDX, unsupported parent volume, insufficient expansion space, ambiguous BCD store, or an image of unknown trust.