Fix ERROR_EXCL_SEM_ALREADY_OWNED (0x00000065) – Exclusive Semaphore Owned by Another Process

1. Stale Lock Files from a Crashed Program

This is the one I see most often. A program crashes while holding an exclusive semaphore—basically a software lock that says “I’m using this resource, stay out.” Windows doesn’t always clean up those locks when a process dies unexpectedly. You end up with a lingering lock that blocks the same app from starting again, or any other app that needs that resource.

How to Find and Kill the Process

First, figure out which process owns the semaphore. Grab Process Explorer from Microsoft Sysinternals (free, no install needed). Run it as Administrator. Go to Find > Find Handle or DLL (Ctrl+F). In the search box, type the name of the resource causing the error—like a file path, a port number, or the program’s executable name. Process Explorer will show you which process holds the handle.

Had a client last month whose accounting software threw 0x00000065 every time they tried to access the shared database file. Turned out a background backup utility had crashed earlier and left a handle on that file. Killed the backup process with Process Explorer (right-click > Kill Process), and the error vanished.

If you can’t identify the resource, open Task Manager (Ctrl+Shift+Esc), go to the Details tab, and look for any instance of the program that’s failing. If you see multiple, kill all of them. If you see none, check for orphaned processes—look for processes with high handle counts or ones that have been running for days. Right-click and End task on anything suspicious.

Reboot to Clear Stale Locks

Rebooting is the nuclear option, but it works. When Windows shuts down cleanly, it releases all semaphores. So if you’re stuck and can’t find the culprit, restart the machine. That clears every lock. Not elegant, but effective.

2. Driver or Service Holding a Semaphore After Crash

Sometimes the process that owns the semaphore isn’t a user-mode app—it’s a driver or a Windows service. This is trickier because you can’t just kill a driver. Common culprits: printer drivers (especially HP and Canon), network filter drivers (like VPN clients), and anti-virus real-time scanners.

Check Event Viewer for Clues

Open Event Viewer (eventvwr.msc). Go to Windows Logs > System. Look for errors around the time the 0x00000065 error appeared. Filter by source Application Popup or Service Control Manager. If you see a service crash right before the semaphore error, that’s your lead.

Reinstall or Disable the Problem Driver

If the error happens when you plug in a USB device or start a specific piece of hardware, update or reinstall that driver. For printer spooler issues (common with this error), restart the Print Spooler service: open Services.msc, find Print Spooler, right-click > Restart. If that fixes it temporarily, uninstall and reinstall the printer driver.

I once debugged a system where a Canon printer driver left a semaphore locked after a failed print job. The user couldn’t print at all until we restarted the spooler. Turned out a corrupt driver file was the root cause. Replaced it with the latest version from Canon’s site, and the problem never came back.

3. Corrupted Application State or Race Condition

Less common, but it happens. The program itself has a bug—maybe it didn’t release the semaphore after a normal exit, or two threads in the same app are fighting over the same lock. This is more likely in older software or custom in-house applications.

Repair or Reinstall the Application

Go to Settings > Apps > Installed apps, find the application that’s throwing the error, click the three dots, and choose Modify. Windows will offer a repair option. Run it. If that doesn’t help, uninstall and reinstall the app. Make sure you get the latest version from the vendor.

Use Dr. Watson or Debug Diag to Capture the Crash

If you’re dealing with a custom app, you can enable crash dumps. Download Debug Diagnostic Tool from Microsoft. Configure a crash rule for the failing executable. When the error happens, the tool creates a dump file. Send that to the developer or analyze it yourself with WinDbg to see which thread owns the semaphore.

This is advanced, but I’ve used it to find a race condition in an old VB6 app. The app would spawn a worker thread, the thread grabbed a semaphore, and then the main thread crashed. The semaphore was never released. The fix was a code change, but until then, we added a startup routine to kill orphaned semaphores.

Quick-Reference Summary Table

That’s the playbook. Start with the first fix—nine times out of ten it’s a zombie process. If not, move to drivers or app corruption. And if all else fails, a reboot buys you time. Good luck.