Fix ERROR_UNABLE_TO_REMOVE_REPLACED 0x00000497

This Windows error means a file can't be deleted during a replace operation — usually because another process holds a lock on it. Here's how to break that lock and why.

Hitting 0x00000497 mid-replace is incredibly frustrating — you're trying to swap an old file with a new one, and Windows just says "nope." The raw message translates to ERROR_UNABLE_TO_REMOVE_REPLACED, and it has a specific root cause: something else has a handle open on the target file, and the ReplaceFile API can't delete it because of that.

The Real Fix: Kill the Locking Process

You don't need to reboot or reinstall anything. The fix is finding and terminating whatever holds the file open. Here's the exact workflow I use, tested on Windows 10 22H2 and Windows 11 23H2.

Step 1: Identify the File Path

Whatever tool or script threw the error should give you the file path. If it didn't, check your application logs or run fltmc instances from an admin prompt — but honestly, you usually know which file you were replacing. Write the full path down.

Step 2: Use Handle.exe (Sysinternals)

handle.exe -a -u "C:\path\to\your\file.ext"

Download Handle from Microsoft's Sysinternals suite. Run that command from an elevated command prompt. It'll list every process holding a handle to that file. You'll see the PID, the process name, and the handle type (typically File or Section).

If you'd rather use a GUI, open Process Explorer (also Sysinternals), press Ctrl+F, type the filename — same result.

Step 3: Kill the Offending Process

Do not guess. Look at what's locking the file. Common culprits:

Explorer.exe — happens when a file preview or thumbnail is cached. Restart Explorer via Task Manager.
Your own application — if the file was opened with FILE_SHARE_READ but not FILE_SHARE_DELETE, the same app can't replace it. Close and retry.
Antivirus or backup software — these hold temporary locks during scans. Disable real-time protection temporarily (re-enable after).
Windows Search Indexer — SearchIndexer.exe. Stop the WSearch service, do your replace, then restart it.

Once you identify the PID, kill it:

taskkill /PID 1234 /F

Or right-click in Process Explorer and select Kill Process.

Step 4: Retry the Replace Operation

Now run your replacement again. It should succeed immediately because the lock is gone.

Why This Worked

The ReplaceFile Windows API (used by many applications for atomic file swaps) internally calls NtSetInformationFile to delete the old file after renaming the replacement into place. If any process has an open handle with DELETE access denied — or simply a non-shared handle — the delete fails and Windows returns 0x00000497. It's not a file permission issue (that would be 0x00000005). It's purely a locking problem.

The reason step 3 works is that killing the process releases all its kernel handles, including the one blocking the delete. Windows then can complete the ReplaceFile transaction. The API is designed to be atomic: either the entire swap happens, or nothing changes. So until you remove the lock, the old file stays and the new one sits in a temporary location.

Less Common Variations

Variation 1: Locked by a System Service (PID 4)

If Handle.exe shows PID: 4 (System process) locking the file, you can't kill that. The usual cause is a memory-mapped file. Use rammap.exe from Sysinternals to clear the system working set, or simply reboot. I've also seen this with volume shadow copies — run vssadmin delete shadows /all (admin prompt) to clear those.

Variation 2: ReplaceFile on a Network Share

Same 0x00000497 can pop up over SMB. The lock is on the server side. You need admin access to the remote machine and run Handle or openfiles /query there. Or ask the sharing user to close the file.

Variation 3: Delayed Lock Release

Some applications (looking at you, Adobe) release handles asynchronously. Even after the process appears closed, a file can stay locked for a few seconds. Use handle.exe again to confirm — if nothing shows, wait 10 seconds and retry.

Variation 4: Antivirus Scanning the Temp Replacement File

Rare, but I've seen Defender lock the temporary file that ReplaceFile creates. The error will point to a path like C:\Users\...\AppData\Local\Temp\...tmp. Disable real-time protection for 60 seconds, do the replace, then re-enable.

Prevention for Next Time

Three things reduce your odds of seeing 0x00000497 again:

Close files explicitly before overwriting. If you're writing the replacing code, call CloseHandle on the source file before calling ReplaceFile. Most apps already do this, but third-party scripts often forget.
Use MOVEFILE_WRITE_THROUGH instead. If you're using MoveFileEx with MOVEFILE_REPLACE_EXISTING instead of ReplaceFile, you won't hit this error — the API works differently and can overwrite the target even while it's open (though the open process may fail later). It's a tradeoff.
Schedule replacements during quiet hours. If you're replacing a file that's actively in use (like a DLL or configuration file), schedule it when no process has it open. Use Restart Manager API if your app can coordinate.

And if you're the one developing the tool that triggers this error — consider using ReplaceFile with a retry loop that waits on the lock, rather than failing immediately. The ERROR_UNABLE_TO_REMOVE_REPLACED code literally tells you the delete failed; adding a short sleep and retry can paper over transient locks without user intervention.