Missing VHDX parent: what to save before recovery

Quick answer: When a VHDX/AVHDX reports a missing parent, your data is not necessarily lost. First, establish exactly what is missing from the chain and what remains available. Do all work on a backed-up copy of the files, and leave the originals and configuration unchanged.

What actually happened: parent and differencing disk

A differencing disk (typically a file with the .avhdx extension for Hyper-V checkpoints) does not contain a complete set of data. It stores only changes relative to its parent—another VHDX or AVHDX file in the chain. A checkpoint therefore depends on the entire chain: every link must be physically accessible and correctly linked to the others. When Hyper-V reports at virtual machine startup that a parent is missing or that the chain cannot be assembled, this indicates a broken link, not necessarily a loss of content.

According to Microsoft documentation, a broken chain can result from manually deleted files, a failed merge or a storage outage Hyper-V checkpoints and differencing disks. Identifying which scenario occurred is the first step: it distinguishes „the file has disappeared„ from „the file is still somewhere, but is not working as expected."

What we know and what the check does not prove

Before attempting any repair, understand the limits of what the diagnostics can tell you:

What diagnostics can establish:

• that a particular AVHDX references a particular parent path,
• whether the parent file physically exists at that path,
• the type and structure of the identified chain.

What the check does not prove:

• that the original parent has been irretrievably destroyed—the file may simply have been moved or renamed,
• that the missing file was the last surviving copy—other copies, old checkpoint files or backups may exist on the storage,
• that the data inside the surviving disks is consistent—this can only be assessed after the chain has been restored, using a specialist procedure that is beyond the scope of this article.

Put simply, a missing parent is a symptom, not a diagnosis. It certainly does not mean you can substitute a new, empty parent and carry on. At best, that would fix nothing; at worst, it could make the situation worse.

What to preserve before recovery—a complete inventory

Before attempting any repair, make a safe copy of everything related to the incident. Microsoft recommends backing up all related files before repairing a broken chain Hyper-V checkpoints and differencing disks. Your inventory should include:

1. All VHDX and AVHDX files belonging to the virtual machine, including files that currently appear to be „old" or unused. One of them may be the missing parent.
2. The virtual machine configuration—XML/VMCX and bin/VMRS files, meaning the complete virtual machine directory.
3. Records of missing paths—the exact Hyper-V error message, including the full parent path the system expected.
4. An existing backup of the machine, if available, including its creation date.
5. Logs and a timeline—when the error appeared and what happened to the storage that day, such as maintenance, file deletion, a restart or an outage.

Store the copies on separate, healthy storage, not on the disk where the incident occurred. If there are signs of physical media failure, refer the case to a data recovery laboratory first; repeatedly reading a failing disk can further damage the available data.

A practical step-by-step procedure (read-only)

This procedure is diagnostic. None of its steps modifies the originals. It assumes that you are working on a healthy working copy of a shut-down machine and are authorised to read the data. Simply copying the disks of a running machine may not produce a consistent set; an administrator should arrange its preservation. If you administer your own Hyper-V environment or are authorised to administer it, proceed as follows:

1. Prepare a working copy. Copy the AVHDX whose parent you are looking for to healthy storage, for example D:\Kopie\. Leave the original untouched.
2. Open PowerShell with the Hyper-V module and inspect the copy to display the disk metadata:

Get-VHD -Path 'D:\Kopie\disk.avhdx' | Select-Object Path,ParentPath,VhdType

3. Expected result when the metadata is readable: a table with three columns. Path identifies the file being examined, ParentPath gives the path to its parent, and VhdType shows the disk type (Differencing for a differencing disk). The ParentPath value shows the stored reference to the parent. If the command returns an error instead of the table, record it and do not try to bypass it by changing the header. This outcome provides evidence for specialist analysis; it does not prove that all data has been lost.
4. Compare ParentPath with the actual files. Does a file exist at that path? If not, search the storage, including recycle bins, temporary directories and previous locations, for the filename shown in ParentPath. A move or rename may explain why the path is unavailable. However, finding a file with the same name does not establish that its contents match or that it is the correct parent.
5. If the AVHDX parent also has a parent, repeat step 2 for that file until you reach the base VHDX. This gives you a complete map of the chain.
6. Record everything: missing paths, a list of all VHDX/AVHDX files found with their paths and sizes, the machine configuration and backup results. This list provides the basis for any further action.

Microsoft documents that Get-VHD returns a virtual hard disk object Get-VHD, and its checkpoint troubleshooting guide maps the chain by selecting Path, ParentPath and VhdType Hyper-V checkpoints and differencing disks. There is also a practical limitation to be aware of: a VHD on shared storage that is currently in use by a running virtual machine can only be read by the host using it Get-VHD. If the command fails on shared storage, this restriction may be the reason, rather than corruption.

A safe approach to deeper analysis: if you have access to backup software or a backup, assess its data separately. Check whether the same parent is missing from the backup or whether it contains an earlier version of the chain. Treat the backup as an independent source. An older parent with the same name may not match the surviving differencing disk; its suitability must be verified, and it cannot simply be substituted.

What you must avoid

• Do not use Set-VHD -IgnoreIdMismatch or Merge-VHD at this stage. Both operations modify data and can make the situation worse without a full understanding of the chain. They are not part of this procedure.
• Do not delete any files. This includes files that appear to be orphaned. A supposedly „unnecessary" AVHDX may be the missing parent of another link in the chain.
• Do not create a new, empty parent. A differencing disk references the specific contents of its predecessor. A new, empty file with the same name cannot replace the original data, will not repair the link and may complicate recovery.
• Do not delete checkpoints or merge disks through Hyper-V Manager until you know what is actually broken.
• Do not attempt repairs on failing physical media or read it repeatedly „just to be sure."

Decision table: how to proceed

Finding	What it means	Safe next step
ParentPath points to an existing file, but the VM will not start	A different type of fault, such as an ID mismatch or a path in the configuration	Map the entire chain using Get-VHD, consult a specialist and change nothing
The parent file is missing, but an old backup exists	The backup is another source, not a guaranteed matching parent	Restore the backup separately and have a specialist compare both the links and the contents
The parent is missing, no backup exists and the media is healthy	The outcome is uncertain, but irreversible loss has not been confirmed	Preserve everything, search all storage for the filename and refer the case to a specialist
The physical media returns read errors	Suspected storage failure; a logical fault may also be present	Stop work, refer the media to a data recovery laboratory and stop reading it
All files have been found, but the error persists	The presence of the files does not guarantee that their links are correct	Have a specialist work on a copy; restore any backup separately
A renamed or moved file matching the parent has been found	A simple relocation is the likely cause	Record the finding and perform repairs only on a copy, after verifying the disk’s identity

Handover checklist

If you are handing the case over to a colleague, service provider or data recovery laboratory, include:

• The error message with the exact expected parent path (ParentPath)
• A list of all VHDX/AVHDX files: path, filename, size and modification date
• The Get-VHD output for every link in the mapped chain
• A copy of the virtual machine configuration (the entire directory)
• Backup details: what exists, its date and where it is stored
• An incident timeline: when the error appeared and what preceded it
• Confirmation that the originals were not modified and all work was performed on a copy

How to verify that diagnostics were completed successfully

Check the outcome of this stage as follows:

1. You have a record containing Path, ParentPath and VhdType for every AVHDX examined, and you know whether each parent physically exists.
2. The list of files on the storage is complete, and nothing has been deleted or moved in the meantime.
3. You have documented which copy you worked on and how the originals were preserved. An unchanged modification date alone does not prove bit-for-bit identity or the absence of all writes.
4. A readable backup of all files exists on separate storage.
5. The handover checklist is complete and includes the exact command used.

Only once these conditions are met does it make sense to proceed with recovery itself. That requires either specialist work on a copy or a backup restoration carried out separately from the production environment.

Frequently asked questions

Does a missing parent mean the data is lost?

Not necessarily. A missing parent indicates a broken chain structure, not proof that the contents are lost. The file may simply have been moved, renamed or captured in a backup. A specialist assesses recovery options based on the surviving data and verified alternative copies, rather than the error message alone.

Can I create a new parent with the same name?

No. A differencing disk is linked to its parent’s contents, not just its name. A new, empty VHDX cannot replace the original data and may also complicate a later recovery attempt. This is not part of a safe procedure.

Why work on a copy rather than the original?

Because diagnostics and any subsequent repair carry a risk of writes. Microsoft recommends backing up all files before repairing a broken chain, and working on a copy allows you to start again if necessary. Preserving the original enables further assessment, but does not guarantee successful recovery.

What should I do if the disk is physically failing?

Refer the media to a data recovery laboratory and stop reading it. The distinction between a logical chain fault and device failure is crucial: mapping with Get-VHD helps with a logical fault, while every additional read from failing media may damage the available data.

When is restoring from a backup appropriate?

When a verified backup of the required point in time exists, or when it can serve as an independent source for further assessment. Finding files alone does not prove that the chain is healthy, and an older parent may not match a newer differencing disk. Restore the backup separately from production to avoid overwriting the original files, and compare the result with the recorded chain map.

Need to preserve business data?

If the original media has failed or the only usable copy is missing, describe the situation using the data recovery enquiry form. Include the device, symptoms, what happened before the failure and which data you need. Do not submit passwords, keys or sensitive files through the form. We will agree on the scope of the assessment and any costs in advance, based on your specific case; the current price list distinguishes between media types and levels of complexity. See the data recovery overview for more information about the available options.

Sources and review date

The technical sources were checked on 7 October 2026.

• Microsoft: Hyper-V checkpoints and differencing disks
• Microsoft: Get-VHD

Where to find us

ITHOPE is a company based in Brno, Czechia: we do data recovery from disks, RAID and NAS, PC and laptop service and IT for business, all in our own lab at Viniční 3587/216, 615 00 Brno.

Phone +420 775 556 063 (24/7 line). You can bring the device in person, or send it by courier (Zásilkovna, PPL).