VHD 0XC03A0017 Fix: Child-Parent Size Mismatch

Cause 1: Parent VHD was replaced or resized

This is the one I see in production more than anything else. Someone replaces the parent .vhd or .vhdx file with a different one that has the same name but different size. Windows sees the size mismatch and refuses to touch the chain. You get 0xC03A0017 when trying to attach the child disk.

The fix is straightforward: point the child back to the original parent. You'll need the original file. If you don't have it, you're rebuilding from a backup. Don't bother trying to force-attach the child — it won't work because the internal block offsets are baked into the child's footer.

How to check the parent's size

Open PowerShell as admin and run:

Get-VHD -Path "C:\VMs\Parent.vhdx" | Select-Object FileSize, Size
Get-VHD -Path "C:\VMs\Child.vhdx" | Select-Object ParentPath, FileSize

Compare the Size of the parent with the ParentPath of the child. If the parent was replaced, the FileSize will differ from what the child expects. The child stores the parent's size in its header — that's what the error checks.

If you have the original parent, just copy it back and overwrite the wrong one. Then try attaching the child again.

If you don't have the original, you can try to reset the parent size in the child's header using a hex editor, but honestly, that's fragile. I've seen it work maybe half the time. Better to restore from backup.

Cause 2: Parent path is wrong or the file was moved

Second most common trigger: someone moves the parent .vhd(x) to a different folder or renames it. The child still points to the old path. The error message might say size mismatch, but the underlying issue is that Windows found a different file at that location — with a different size.

You can verify the child's parent path with:

Get-VHD -Path "C:\VMs\Child.vhdx" | Format-List ParentPath

If that path doesn't exist or points to the wrong file, fix it using:

Set-VHD -Path "C:\VMs\Child.vhdx" -ParentPath "D:\Original\Parent.vhdx"

Note: This only works if the child's current parent is still accessible and valid. If not, you'll get an error. In that case, you can use the -Force flag, but be careful — it bypasses safety checks. Only do this if you're absolutely sure the new parent is the correct one.

Also check file permissions. If the service account running Hyper-V or the VM doesn't have read access to the parent's folder, you'll get odd errors. Grant read to NT VIRTUAL MACHINE\<VM GUID> or use the Hyper-V Manager's Edit Disk wizard to reconnect.

Cause 3: The chain was corrupted by an unclean shutdown

Less common, but it happens. A power loss or forced reboot while the differencing disk was being written to can corrupt the chain. The size values in the child's header get scrambled. This is rarer than the first two, but I've seen it on older Windows Server 2012 R2 hosts with flaky power supplies.

First, check the child disk's integrity:

chkdsk /f /r C:\VMs\Child.vhdx

That's for a fixed VHD. For dynamic or differencing, you need to mount it or use Optimize-VHD. But honestly, if the header is corrupted, chkdsk won't fix it. The real fix is to recreate the child disk from the parent.

If the parent is fine, you can create a new differencing disk that points to it:

New-VHD -Path "C:\VMs\ChildNew.vhdx" -ParentPath "D:\Original\Parent.vhdx" -Differencing

Then mount the old child to copy data off if possible. Often the corruption is only in the header, and the data blocks are still intact. Try attaching with -ReadOnly to avoid further damage:

Mount-VHD -Path "C:\VMs\Child.vhdx" -ReadOnly -NoErrorAction

If it mounts, copy the files you need to the new disk. If it doesn't mount, you're looking at data recovery tools. That's beyond this article.

Warning: Never run Resize-VHD on any disk in a differencing chain. You'll almost certainly break the child. Resize the parent first, then merge the children.

Quick-Reference Summary

That's the sum of it. Nine times out of ten, it's the parent disk. Get that right, and the error disappears.