Stop ERROR_TOO_MANY_SEMAPHORES (0x64) on Windows 10/11

You hit the semaphore ceiling

I know seeing ERROR_TOO_MANY_SEMAPHORES (0x00000064) is frustrating — especially when it kills your app or even freezes the whole system. The good news? You can fix it in under a minute if you know where to look.

Jump straight to the fix

1. Kill the leaky process — Open Task Manager (Ctrl+Shift+Esc). Go to the Details tab. Sort by the Handles column (click it). Look for any process consuming 10,000+ handles — that's your culprit. Right-click and End task. Done.
2. If you can't see handles in Task Manager — Use Process Explorer (free from Microsoft). Launch it, click View > Select Columns, then check Handle Count. Sort by that column. Spot the monster process — likely a browser with 50+ tabs, a memory-hungry IDE, or a buggy driver. End it.
3. Still stuck? — Restart the machine. That resets the semaphore pool to zero. If the error comes back right after boot, you're looking at a driver or a service that starts automatically. Run sc query in Command Prompt (as admin) and check for anything unusual with a high handle count. Then disable it via sc stop [servicename].

Why this works

Windows has a finite pool of semaphore objects — about 65,000 on typical systems. Every lock, every mutex, every wait operation in multithreaded apps uses a semaphore. When one badly-written program opens handles and never closes them (a classic handle leak), that pool drains fast. The OS hits the wall at 0x00000064 and gives up.

By killing the process that's hoarding handles, you free every semaphore it held — instantly. The system can breathe again.

I've seen this most often with:

• Google Chrome after weeks of never closing tabs (yes, each tab can eat 5+ handles).
• Visual Studio when debugging large solutions — sometimes the debugger leaks handles like a sieve.
• Antivirus software — especially older versions of McAfee or Norton that forget to close process handles.
• Custom .NET apps that create Semaphore objects and never call Dispose().

Less common variations of the same issue

Not every case is a single process going wild. Sometimes it's the system that's misconfigured. Here's what I've run into over the years:

• Hyper-V or Docker Desktop — These create hundreds of semaphores for virtual machine synchronization. If you're running nested VMs or 15 containers, you can hit the limit. Close VMs/containers until the error stops.
• Third-party shell extensions — One user had a Dropbox overlay handler that leaked one semaphore per file operation. After 50,000 file operations, boom. Uninstall the shell extension via Settings > Apps > Installed apps.
• Windows kernel-mode drivers — Rare, but I've seen a bad GPU driver (older Nvidia versions) leak semaphores in its DirectX handling. Update your graphics driver to the latest from the manufacturer's site — not Windows Update.
• Citrix or RDP sessions — If you're on a terminal server, each user session consumes semaphores. When you're past 50 concurrent sessions on a single server, you might see this error. The fix is to increase the Desktop Heap limit via registry — but that's advanced surgery. Only do it if you're a sysadmin and know what you're doing.

Prevention: keep the leak from coming back

Once you've killed the immediate fire, take these steps so you don't see 0x00000064 again next week:

1. Monitor handle usage — Set up Task Manager's Handles column permanently. Open it once a week. If you see any process creeping past 5,000 handles, investigate.
2. Close apps you're not using — Browsers, especially, are the #1 offender. Use a tab suspender extension. Restart your browser daily if you're a heavy user.
3. Update everything — Outdated software leaks handles. Keep Windows Update current, and update your main apps (browser, IDE, antivirus) manually if needed.
4. Consider a scheduled reboot — If this is a shared server, a weekly restart at 3 AM can flush the semaphore pool and prevent cascading failures. Many enterprise admins do this for good reason.
5. Check for driver updates — Go to your motherboard or laptop manufacturer's support page for chipset and storage drivers. Generic Windows drivers are often the leaky ones.

That's it. The error is almost always a runaway handle count. Kill the process, and you're back in business. If it keeps happening, update your software — or just restart once a week. Your system will thank you.