Fix STATUS_FILE_DELETED 0xC0000123 — Stop the file handle ghost

You've seen this error. Let's fix it now.

That 0xC0000123 error — STATUS_FILE_DELETED — is one of those Windows errors that feels like a ghost. A program says it can't access a file, but the file shows up in Explorer just fine. What's actually happening here is that Windows has a stale file handle. The file existed when the program started using it, but was deleted by something else before the operation finished. The OS knows the file is gone, but the handle is still dangling. You'll see this most often during Windows Update (especially the 22H2 or 23H2 feature updates), when uninstalling certain antivirus tools, or when running disk cleanup while another app has a file open.

The fix — reboot first, target the handle second

Reboot your machine. Not a shutdown with Fast Startup enabled. Do a full restart. In Windows 10/11, hold Shift and click Restart to force a full restart. Fast Startup hibernates some kernel state — that can keep dangling handles alive. A fresh boot clears all file handles.
If the error returns after reboot: Open an admin Command Prompt and run sfc /scannow followed by DISM /Online /Cleanup-Image /RestoreHealth. This checks for corrupted system files that might hold bad references. The reason step 2 works is that DISM can fix the component store where file metadata lives, removing dead entries.
Still failing? Identify the handle owner. Download Handle from Sysinternals (a tiny tool, no install needed). Run handle64.exe -a -p [program_name] targeting the process that throws the error. Look for open handles with status "Deleted" or "PendingDelete". Close those handles using handle64.exe -c [handle_hex]. Nine times out of ten, this is a third-party driver or a service like TrustedInstaller.exe that locked a temp file during an update.
If it's a Windows Update error specifically: Stop the Windows Update service, delete the SoftwareDistribution folder, and restart the service. Commands below:

net stop wuauserv
net stop bits
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
net start wuauserv
net start bits

This works because Windows Update had a handle to a file that update files were decompressing into, but the file was deleted mid-stream (often by a cleanup task or another update component). Wiping the folder forces a fresh download of update manifests without the stale handle.

Why this error happens — the kernel reality

Windows tracks open files with handles — lightweight pointers into the kernel's object manager. When you delete a file, the filesystem marks it as "Delete Pending" but doesn't actually remove the data until every handle to it is closed. If something holds a handle, the file object stays alive in memory. Any new operation that tries to reopen that file by path gets STATUS_FILE_DELETED because the path itself is gone. The handle itself is still valid for the original process, but no new access can be granted. This is by design — it prevents race conditions where one thread deletes a file while another is writing to it.

Most users hit this during Windows Update because the update system creates temp files, then deletes and recreates them rapidly. If a driver or security product intercepts those operations out of order, you get the ghost handle.

Less common variants of the same issue

1. Antivirus real-time scanning interference

Some AV products (looking at you, older McAfee and Norton builds) hold handles to files they're scanning. If Windows tries to delete the file during a scan, the AV's handle stays open and the file goes to "Delete Pending" limbo. The fix: disable real-time scanning temporarily, run the update or cleanup, then re-enable. You can check which process owns the handle with Handle from Sysinternals — filter by the file path.

2. Volume Shadow Copy issues

If you get 0xC0000123 when trying to back up or create a restore point, a shadow copy might hold a reference. Run vssadmin list shadows in an admin prompt. If you see old shadow copies referencing the file, delete them with vssadmin delete shadows /for=[drive]: /oldest. This frees the handle without a reboot.

3. Corrupted symbolic link or junction

A symlink pointing to a deleted target can produce this error when traversed. Check with dir /al in the parent directory. If you see a link with a broken target, delete the link with del (for file links) or rmdir (for directory junctions).

4. In-use pagefile or hibernation file

If you're trying to shrink or delete the pagefile (pagefile.sys) while it's in use, you might get 0xC0000123. The fix: disable pagefile entirely via System Properties > Advanced > Performance > Advanced > Virtual Memory, reboot, make your change, then re-enable pagefile.

Prevention — stop it before it starts

Don't run disk cleanup while updates are downloading. The temp files that Windows Update uses are fragile during installation. Let updates finish fully before running CleanMgr or Storage Sense.
Keep your drivers and AV up to date. Outdated filter drivers (like old antivirus minifilters) are the most common cause of stale handles. Windows 11 23H2 specifically tightened handle validation — old drivers that leaked handles now produce this error rather than silently failing.
Use proper shutdown, not hard power-offs. A sudden power loss can leave handles in an orphaned state that only a chkdsk can clear. Always shut down through the Start menu.
If you're a developer writing tools: Always close handles with CloseHandle() in a __finally block. Never assume the OS will clean up for you. Use NtDeleteFile() with FILE_DISPOSITION_DELETE only when no other thread could be holding the handle.

The bottom line: 0xC0000123 is Windows telling you someone else is holding a dead man's handle. A reboot clears it 90% of the time. For the other 10%, you need to find the culprit with a handle viewer. Don't waste time reinstalling Windows — this error is almost always a software race condition, not hardware failure.