ERROR_BUSY (0x000000AA): Fix the Resource In Use Error on Windows

What ERROR_BUSY 0x000000AA actually looks like

You're saving a file to a network share and Windows throws a dialog at you: ERROR_BUSY (0x000000AA) — The requested resource is in use. Or the printer just sits there, you try to delete the stuck job, and nothing happens. Or a USB drive won't eject because "a program is still using it." I've seen this pop up most often when a backup tool or antivirus scanner has a file open in the background while you try to move it. Last month a client's entire print queue died because a single user left a corrupted spool file on the print server. Nobody could print until I killed the spooler. That's the pattern with 0x000000AA — one process is holding a handle, and Windows won't let go.

Why ERROR_BUSY happens (the plain English version)

Windows does this on purpose. When a process opens a file, folder, printer, or device, it gets a handle. As long as that handle is open, the OS refuses to let another process modify, delete, or take exclusive control of the same resource. It returns ERROR_BUSY instead. That's a safety feature, not a bug.

The catch is that handles get left open for dumb reasons: a crashed app that never cleaned up, a service that's wedged, an antivirus filter driver scanning the file, or a network share where the remote machine thinks someone still has the file open. You can't just hit Retry forever — you need to find what's holding the handle and release it.

The fix — step by step

1. Identify what's holding the resource

   Grab Process Explorer from Microsoft Sysinternals (free). Run it as admin, then hit Ctrl+F and type the filename or the share path that's throwing ERROR_BUSY. It'll show you every process with an open handle on that resource.

   If you prefer the command line, use handle.exe from the same Sysinternals suite:

   handle.exe -a "C:\Path\To\Locked\File.txt"

   For a printer that's stuck, that path is typically the spool folder:

   handle.exe -a "C:\Windows\System32\spool\PRINTERS"

2. Close the offending process

   Once you know which PID is holding the handle, decide if you can safely kill it. If it's Explorer.exe holding your file, that's easy — restart Explorer. If it's a service like the Print Spooler or an antivirus scanning engine, stop that service first instead of killing the process.

   net stop spooler
   net start spooler

   For a corrupted print job, clear the spool folder while the spooler is stopped:

   del /Q /F C:\Windows\System32\spool\PRINTERS\*.*

3. Check for a dead network session

   On a file share, ERROR_BUSY often comes from a stale SMB session. A user closed their laptop lid three days ago and Windows still thinks the file is open. Check open files and sessions on the server:

   openfiles /query /fo table
   net session

   Kill the dead session with net session \\ComputerName /delete, or use openfiles /disconnect /id ID.

4. Rule out antivirus filter drivers

   Third-party AV is the #1 cause of phantom ERROR_BUSY on file servers in my experience. The scanner opens a file to inspect it, the app tries to write to it at the same moment, and the OS says busy. Temporarily disable real-time scanning on the folder and retry. If the error goes away, add an exclusion for that path.

5. Reboot — but only as a last resort

   If you can't figure out which process it is and it's blocking production, a reboot clears every handle. It's a hammer, and it hides the real cause, so write down what you were doing when it happened so you can track the pattern.

If it still fails after all that

• Check for handle leaks. Open Task Manager, add the "Handles" column, and watch a long-running service. If handles climb into the hundreds of thousands and never drop, that process is leaking and eventually triggers ERROR_BUSY across the board. Patch or restart it.
• Look at the System event log. Filter on source Ntfs, Disk, or SmbClient around the timestamp. A failing disk or a flaky SMB connection shows up here before it shows up as 0x000000AA.
• Test with a different account. If a mapped drive under one user throws ERROR_BUSY but the same share works under your admin account, it's a credential or cached-session problem. Run net use * /delete /y and remap.
• Update the filter driver. Backup software (Veeam, Backup Exec, Windows Server Backup) installs a filter driver that sits in the I/O path. Old versions of these are notorious for holding handles past their window. Update them.
• Check for a shadow copy in progress. Volume Shadow Copy holds transient locks on files during a snapshot. If you're getting ERROR_BUSY on a schedule — same time every night — that's your culprit. Reschedule the backup or the snapshot window.

ERROR_BUSY is Windows telling you the truth: something else has the resource. Don't fight it. Find the handle holder, close it properly, and move on.

One thing worth hammering home — if this happens on a server and you "fix" it by rebooting every week, you're not fixing anything. You're masking a handle leak or a misbehaving filter driver. Trace it once, find the process, and you'll never see 0x000000AA on that box again.