STATUS_FILE_FORCED_CLOSED 0XC00000B6: File closed by another process

Quick answer: Reboot. If that's not an option, use Process Explorer or Resource Monitor to find the process holding the file handle, kill it, then retry your operation.

I ran into this one last week at a dental office. Their billing software kept throwing 0XC00000B6 when trying to save patient records. Turns out the antivirus scan was opening the file, crashing halfway through, leaving the handle dangling. The file looked closed but wasn't. This error pops up when a program opens a file, then crashes or gets killed before releasing the handle. Windows marks the file as closed by the process, but other applications can't access it until the handle is cleaned up. It's not a disk error—it's a process management hiccup.

What triggers this?

• Antivirus scanning a file while you're editing it
• A background backup tool (like Veeam or Windows Backup) accessing a database file
• A Windows update running file operations in the background
• An application crash during file save—had a client whose QuickBooks did this three times in a week
• Network file shares where another user's session holds the file open

How to fix it: Step by step

1. Reboot the machine. I know it's boring, but it clears all dangling handles. If you're on a server, do it during maintenance window. 90% of the time this is all you need.
2. If you can't reboot, open Resource Monitor (type resmon in Start). Go to the CPU tab, expand the Associated Handles search box. Type part of the filename that's causing the error. It'll show you exactly which process is still holding it.
3. Kill that process—right-click in Resource Monitor, select End Process. If it's a system process like svchost.exe, don't kill it blindly. Restart the service instead. For example, if it's the Windows Update service, run net stop wuauserv from an admin command prompt, then net start wuauserv.
4. Run the file operation again. If the error is gone, you're done. If not, you've got a deeper issue—probably a driver or filesystem filter driver problem.

Alternative fixes if the main one fails

Check for antivirus interference

I've seen this most often with McAfee and Symantec. They scan files on open and if their scanner crashes, the handle stays locked. Temporarily disable real-time scanning and test. If that fixes it, add an exclusion for the specific file path or folder in your AV settings.

Use Handle64 from Sysinternals

Download Handle64. Run from admin command prompt: handle64 -a -p [processname]. It'll list all open handles for that process. Look for the file path in question. If you see it, the handle is still active.

Force close the handle (advanced)

In Handle64, you can close a handle remotely, but it's risky—can crash the owning process. Use handle64 -c [handleID] -y -p [PID]. Only do this if you know exactly what you're doing. I did it once to recover a SQL database backup and ended up having to restart the SQL service anyway.

Disable third-party shell extensions

Some file context menu handlers (like Dropbox or Google Drive shell extension) can hold file handles longer than expected. Use ShellExView to disable non-Microsoft extensions and reboot.

How to prevent it

• Update your software. Outdated drivers and buggy apps are the #1 cause. Keep Windows and all third-party tools current.
• Don't open the same file in multiple programs. I know it's tempting to have Excel and Notepad++ both open the same CSV—don't. One will always win the handle.
• Use proper file sharing. If you're on a network, set file locks properly in your application. For databases, use a real DBMS (SQL Server, PostgreSQL) instead of file-based ones like Access or FoxPro.
• Monitor handle counts. On a server, set up a perfmon alert for Handle Count. If it spikes above 50,000, something's leaking. That's how I caught a custom CRM that was opening files without closing them—they had a classic handle leak.

Had a client whose entire print queue died because of this error on a shared network folder. Each printer driver was holding a temp file handle from a failed print job. A simple reboot fixed it, but the real fix was updating the printer driver to a version that didn't leak handles.

Bottom line: 0XC00000B6 is almost never a disk problem. It's a process problem. Track down which process is holding the file, kill it, and move on. If it keeps happening, find the root cause—bad software, old drivers, or a misconfigured antivirus. You'll save yourself hours of head-scratching.