STATUS_RESOURCE_IN_USE (0xC0000708) – Quick Fix & Why It Works

Yeah, this one’s a pain

You try to open a file, start a service, or mount a drive, and Windows throws 0xC0000708 at you. The exact text is STATUS_RESOURCE_IN_USE – and it means exactly what it says: something else has already claimed that resource. I’ve seen this with shared documents, USB drives that stick after ejection, and even corrupted print spools. Let’s fix it.

First thing: find the lock

The real fix isn't a registry tweak or a system restore – it’s finding what’s holding the resource. You need Sysinternals Handle (free from Microsoft).

1. Download Handle and extract it to a folder like C:\Handle.
2. Open Command Prompt as Administrator. Not PowerShell, not a regular window – Admin.
3. Run this command, replacing your-file-name with the file or device name you’re stuck on:
   

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

4. Look for a line like pid: 1234 type: File. That’s your culprit. Note the PID number.

For example, if you’re trying to delete a stuck report.docx and Handle shows PID 5678 with a locked handle, you know 5678 is the process.

Kill it

Still in the Admin command prompt, run:

taskkill /F /PID 5678

Replace 5678 with the actual PID. The /F forces it closed. Then try your original action again – 9 times out of 10, the error is gone.

Why this works

STATUS_RESOURCE_IN_USE (0xC0000708) is a kernel-level signal from the Windows NT I/O subsystem. When a process opens a file or device, it gets a handle. If a second process tries to open that object with exclusive access, the kernel says “nope – already in use.” The error isn’t about corruption or permissions, it’s about access mode conflicts. Specifically, if the first process opened with FILE_FLAG_NO_BUFFERING (common with databases) or FILE_SHARE_READ (no write sharing), any other write attempt fails with this exact code.

Handle.exe uses low-level NT API calls (NtQuerySystemInformation) to peek into the kernel’s handle table – bypassing the user-mode abstraction that hides open handles from normal utilities. It’s the same tool Microsoft support uses internally.

Less common variations

• Service won’t start – You might see 0xC0000708 when starting a Windows service that depends on a named pipe or kernel object still held by a crashed instance. Use sc queryex <service-name> to find the PID, then taskkill /F /PID on that. Then restart the service.
• USB drive won’t eject – This happens when a background process (like Windows Search or a third-party backup tool) has an open handle to the drive. Run Handle on the drive letter: handle.exe E:. Kill the process that holds it, then you can safely remove the hardware.
• Print spooler errors – Sometimes a corrupt print job locks a printer driver resource. Restart the spooler (net stop spooler && net start spooler in Admin command prompt). If that doesn’t help, use handle.exe -a -u "spool\PRINTERS" to find what’s holding the queue.
• Registry hive loading – Trying to load a registry hive (like another user’s NTUSER.DAT) can trigger this if the hive was unloaded incorrectly. Reboot to flush all handles, then try again.

Preventing it from coming back

• Close apps properly – Don’t just yank USB drives or force-quit file editors. Let them release handles cleanly.
• Watch for backup software – Programs like Veeam, Acronis, or even Windows Backup can hold open file handles during snapshots. Schedule backups during off-hours.
• Use Sysinternals Autoruns – Some startup programs open resources aggressively. Disable anything that doesn’t need to start automatically.
• If it’s a recurring system file (like a database or log file), consider using Windows OpenTrace or adjusting the application’s sharing mode settings – though that’s usually a developer fix.

For most people, Handle + taskkill is the only tool you’ll need. I keep Handle.exe in my C:\Windows\System32 folder so it’s always on the path. Saves me five minutes every time this error pops up.