VHD Chain Locked? Fix 0XC03A0016 Fast

First: What Actually Causes This

You're dealing with a differencing VHD—a child disk that relies on a parent. Windows throws 0XC03A0016 when it can't read that parent. Nine times out of ten, it's one of two things:

• The parent VHD file is locked by another process (often leftover from a crashed VM).
• The NTFS permissions on the parent file don't allow the current user (or the Hyper-V service) to read it.

I know this error is infuriating because it halts everything, and the error message gives you zero hint about which VHD in the chain is the problem. So let's start with the quickest win.

Fix #1: The 30-Second Unlock

This works when the parent VHD is simply stuck in a locked state—usually because a previous VM didn't shut down cleanly.

1. Close Hyper-V Manager and any VM that's currently running.
2. Open Task Manager (Ctrl+Shift+Esc). Look under the Details tab for any vmms.exe or vmwp.exe processes. If you see them, right-click and End Task.
3. Now locate the parent VHD file (the one without the delta—you'll know it's the parent because it's the original base disk).
4. Right-click the file, choose Properties, and tick the Read-only checkbox if it's checked. If it is, untick it and hit Apply.
5. Try attaching the child VHD again.

If that didn't fix it, the file might be genuinely locked by a background service. For a more aggressive unlock, run this in an elevated Command Prompt:

openfiles /query | findstr "VHD"

If you see any handles, you'll need to reboot. Yes, a reboot. It's annoying, but it clears all file locks from services that won't die gracefully.

Fix #2: The 5-Minute Permission Repair

This is the fix that solves the majority of cases. When you move VHD files between folders, drives, or machines, the ACLs (access control lists) often don't move with them—or they point to a user that no longer exists.

Here's the scenario: You copied a VHD from an old server that used a domain account. Your current machine has a local account. The ACLs still reference that old domain SID, so Windows denies access even if you're an admin.

1. Find the parent VHD file (not the child—this is critical).
2. Right-click it → Properties → Security tab.
3. Click Advanced.
4. At the top, next to Owner, click Change.
5. Type Administrators and click Check Names, then OK.
6. Tick Replace owner on subcontainers and objects—even if it's a single file, this forces the ACL reset.
7. Click OK to go back to the Security tab.
8. Click Edit, then Add.
9. Type Everyone and give it Full control (temporarily—you can tighten later).
10. Click OK, then try mounting the VHD again.

Using Everyone is a blunt instrument, but it tells you instantly if permissions were the culprit. If it works, then go back and remove Everyone and instead add the specific account that runs Hyper-V (usually NT VIRTUAL MACHINE\... or your own admin account).

Fix #3: The 15+ Minute Check (Advanced)

If you're still stuck, the problem is deeper. Either the VHD chain itself is corrupted or misconfigured, or there's a service-level issue.

3a. Verify the Parent Path is Correct

A differencing VHD stores the parent path internally. If you've moved files, that path might now point to a file that doesn't exist—and Windows doesn't always tell you that directly; it just throws 0XC03A0016.

Open an elevated Command Prompt and run:

diskpart
select vdisk file="C:\path\to\child.vhdx"
attach vdisk

If diskpart complains about the parent, you'll get a clearer message. If not, you can also use PowerShell to inspect the chain:

Get-VHD -Path "C:\path\to\child.vhdx" | Get-VHDParentDisk

That cmdlet will show you the parent path it expects. Compare that to the actual file location. If they don't match, you have two options: either move the parent to the expected path, or recreate the child VHD using the correct path. Recreating the child is safer—it takes minutes and avoids weird path quirks.

3b. Check for Physical Corruption

If the parent VHD is corrupted—say, a bad sector or a truncated file—you'll get access denied errors that trick you into thinking it's a permission issue. Run a check on the parent:

chkdsk /f

That checks the physical disk. For the VHD itself, try mounting it directly in Hyper-V as a standalone disk (don't attach the child). If it mounts, the parent is fine. If it doesn't, you might need to use the Inspect Disk option in Hyper-V Manager to repair it.

3c. Fix the Hyper-V Service Account

Rarely, the Hyper-V virtual machine management service (vmms.exe) loses its ability to access the file—often after a domain password change or a group policy update. Restart the service from an elevated command prompt:

net stop vmms
net start vmms

Then try attaching the child VHD again. If this fixes it, you'll want to check the service's logon account. Go to Services → Hyper-V Virtual Machine Management → Log On tab. Make sure it's set to Local System Account (the default). If someone changed it to a domain account, that's your culprit.

When to Give Up and Recreate

Honestly, if you've done all three fixes and still get 0XC03A0016, the parent VHD might be beyond repair. The fastest solution is to create a new parent VHD from a known-good backup and create a fresh differencing disk from it. You'll lose any data that wasn't merged into the parent, but sometimes that's the cost of chasing this error down a rabbit hole.

For future prevention, always store VHD files on NTFS (not exFAT or network shares that don't support locking well), and keep your parent VHDs in a dedicated folder where you know the ACLs won't get scrambled by sync tools like OneDrive or Dropbox.

This error tripped me up the first time too. The 30-second unlock fixes maybe a third of the cases. The permission repair fixes the rest. Don't jump to the advanced stuff unless you've confirmed the file isn't just locked.