Fix 0x801F001A: Volume Already Mounted in Windows

The Simple Fix (30 seconds): Dismount and Remount the Volume

Let's start with the easiest thing. Nine times out of ten, this error is caused by a stale mount point. Open Disk Management (right-click Start > Disk Management). Find the volume that's throwing the error. Right-click it and select Change Drive Letter and Paths. Remove the drive letter or mount point, then add it back. Wait 10 seconds, then retry your operation. This clears the kernel's mount cache for that volume. Works on Windows 10, 11, Server 2012 through 2022.

The Moderate Fix (5 minutes): Use diskpart to Clean the Mount

If the simple fix didn't work, Disk Management might be lying to you. The volume could be hidden or locked. Open Command Prompt as Administrator and run:

diskpart
list volume
select volume X (replace X with the volume number)
remove
assign letter=Y (replace Y with an unused letter)
exit

This forces Windows to release the mount. I've seen this fail only when the volume is in use by another process. If it says the volume is locked, close File Explorer, any backup software, and antivirus scans. Then try again. This is also the fix if you're seeing the error on a mounted VHD or ISO — diskpart handles those better than the GUI.

Common Trigger: Storage Migration or Drive Letter Changes

This error pops up a lot after you move a drive between systems or change its letter in Disk Management without dismounting first. The registry gets a stale entry. Don't bother with chkdsk here — the disk is fine, it's just Windows being stubborn about the mount point.

The Advanced Fix (15+ minutes): Registry Cleanup

Alright, diskpart didn't work either. Now we're deep in the weeds. The registry still thinks the volume is mounted somewhere. I've had this happen on servers after SAN storage reconnects or VSS snapshots go sideways.

Open Regedit as Administrator. Navigate to:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Class\{71a27cdd-812a-11d0-bec7-08002be2092f}

This is the class GUID for volume mount points. Look for subkeys named 0000, 0001, etc. Each one has a Driver and Port value. Expand 0001 (or whichever has the most entries) and check MountPoints and Properties. Delete any entries that reference the mount point for your problem volume. Make a backup of this key first — right-click > Export. I've seen this go wrong if you delete the wrong one, and you'll need to restore it.

Next, check:

HKEY_LOCAL_MACHINE\SYSTEM\MountedDevices

This is where Windows stores drive letter assignments. Find the entry for your problem drive letter (like \DosDevices\Z:). Delete it. Reboot. After reboot, assign the drive letter in Disk Management. This is nuclear — don't do it unless the other steps failed. But it's the only way to clear deeply cached mount state.

Note: If you're on Windows Server with CSV (Cluster Shared Volumes), don't touch the registry. Instead, use Failover Cluster Manager to dismount the volume from the cluster — it's a different beast.

When to Give Up and Reboot

Look, sometimes Windows just needs a full restart. If you tried all three steps and the error persists, reboot. I've wasted hours chasing registry ghosts only to have a reboot fix it. Do that before trying anything else in the advanced section.

Last Resort: Reset the Volume Mount Database

If rebooting didn't work, and you're on a non-server system, you can reset the entire volume mount database. Open an elevated Command Prompt and run:

diskpart
clean

Yes, this wipes the partition table. You'll lose all data on that volume. Don't do it unless it's a scratch disk. But if the error is on a volume you don't care about, this clears everything and lets you start fresh. For production data, call your backup vendor.