Fix ERROR_CANT_RECOVER_WITH_HANDLE_OPEN (0x1AA2)

Windows throws this when you try to recover a file (usually via Volume Shadow Copy or NTFS repair) while another process still has it open. Close the handle first.

When does this error show up?

You'll see ERROR_CANT_RECOVER_WITH_HANDLE_OPEN (0x00001AA2) when you're trying to recover a file — typically from a Volume Shadow Copy (previous versions) or during an NTFS file repair with chkdsk /f. The exact trigger is: you run a recovery tool, it tries to grab exclusive access to the file, and the OS says "nope, someone else has it locked." Common scenario? You're restoring a document from a shadow copy while OneDrive or antivirus has it pinned open.

Root cause

The culprit here is almost always a handle leak — some process grabbed the file with read or write access and never let go. Could be a backup agent, a cloud sync client (Dropbox, OneDrive), or even a misbehaving antivirus. The NTFS volume can't roll the file back to a snapshot because the handle prevents exclusive write access. No mystery here: close the handle, fix the problem.

Fix it in 4 steps

Don't bother rebooting first — that's a brute-force approach that works but loses your recovery context. Instead, find and close the specific handle.

Step 1: Identify the file path

Get the exact file path from the error. If it's a chkdsk run, note the volume (e.g., C:). If it's a shadow copy recovery, check the file name in the error dialog.

Step 2: Find which process holds the handle

Use Process Explorer from Sysinternals. Download it, run as admin, hit Ctrl+F, type the file name or path. It'll show you the PID and process name holding the handle. For example: svchost.exe (PID 4567) or OneDrive.exe (PID 1234).

Alternate command-line method (faster if you're already in a shell):

handle64.exe -a -u "C:\path\to\file.txt"

That dumps the process name, PID, and handle ID. handle64.exe is also in the Sysinternals suite.

Step 3: Close the handle

In Process Explorer, right-click the handle entry and select Close Handle. Confirm the warning. That's it — the handle is gone.

From command line:

handle64.exe -c <handleID> -p <PID> -y

Example: handle64.exe -c 0x1234 -p 4567 -y. The -y suppresses the confirmation prompt.

Step 4: Retry the recovery

Run your recovery operation again — whether that's chkdsk /f, restoring from shadow copy, or whatever NTFS repair tool you were using. Should go through now.

What to check if it still fails

If the error persists after closing the handle, you've got a more stubborn issue.

Handle reopens immediately: Some processes (like antivirus real-time scanning) reopen the handle right after you close it. In that case, temporarily disable the service (e.g., stop OneDrive, disable your AV real-time protection) then repeat the steps.
Multiple handles: Run the handle search again — sometimes a file is locked by two different processes. Close all of them.
System handles: If the handle belongs to System (PID 4), you can't close it directly. Try a reboot, or use chkdsk /f on the next boot (schedule it with y at the prompt).
Shadow copy corruption: Rare but possible — if the volume itself has shadow copy inconsistencies, run vssadmin list shadows and delete stale shadows. Then recreate a fresh restore point.

Bottom line: 0x1AA2 is a lock issue, not a corruption issue. Handle it right, and you're done in under a minute.