0XC0000129

STATUS_TOO_MANY_THREADs 0XC0000129: The Real Fixes

Your process hit the thread limit. Almost always a runaway app or misconfigured service. Here's how to kill it fast.

1. Runaway Process — The Most Common Culprit

You'll see 0XC0000129 when an application or service spawns threads faster than it kills them. Think a buggy database driver, a memory-leaking web server, or a svchost.exe gone rogue. The thread count climbs until it hits the default per-process limit — 32,768 on 64-bit Windows, 2,048 on 32-bit.

I've seen this most often with IIS worker processes (w3wp.exe) that have a bad module loaded, or with SQL Server running a query that creates thousands of worker threads. But the fix is always the same.

How to find the guilty process

  1. Open Task Manager and go to the Details tab.
  2. Right-click any column header and select Select columns.
  3. Check Threads and Handles.
  4. Sort by the Threads column descending. Look for anything above 5,000 threads — that's your problem.

Alternatively, use PowerShell to get the top offenders in one go:

Get-Process | Sort-Object Threads -Descending | Select-Object -First 10 Name, Id, Threads

Once you've identified the process, kill it with taskkill /F /PID [PID]. If it's a service, stop the service via Services.msc or sc stop [service name].

Then restart the service or application cleanly. If the thread count shoots back up within minutes, you've got a leak that needs developer attention. But for a one-off crash, this is all you need.

2. I/O Completion Port Thread Pool Exhaustion

This one’s trickier. Windows uses I/O Completion Ports (IOCP) for high-performance async I/O. When an application opens too many I/O completion ports but never closes them, the thread pool backing those ports can hit a system-wide limit. The error code is the same: 0XC0000129.

This usually happens in custom server apps (Node.js, Python Twisted, or .NET async servers) that are poorly tuned. The default IOCP thread limit is 500 per process on Windows 10 and Server 2016+. But if your app tries to create more than that without recycling threads, bam — you're done.

The fix: Tune the thread pool

If you control the application code, adjust the IOCP thread pool size. In .NET, you can set it via ThreadPool.SetMinThreads(work, completionPort). In native C++, call SetThreadpoolThreadMaximum. But if it's third-party software, you're stuck with their defaults — patch or update the vendor.

For IIS in particular, try reducing the Queue Length and Max Worker Threads settings in the application pool advanced settings. Don't just crank them up — that masks the real problem and makes things worse under load.

You can also check the current IOCP thread count with Performance Monitor (perfmon). Add the Thread\% Processor Time and Process\Thread Count counters for the offending PID. A steady climb after each request confirms the leak.

3. Kernel-Mode Driver or Antivirus Hook Interfering

Less common, but when it hits, it's a nightmare. Some third-party drivers — especially antivirus software, backup agents, or VPN clients — hook into process creation and thread creation. If that hook is buggy or triggers an internal check that fires a new thread, you can get a recursion loop that quickly exhausts the thread limit.

I've personally debugged this with McAfee Endpoint Security and with a misconfigured Trend Micro OfficeScan driver. The symptom: your process shows thousands of threads in kernel stacks, and Process Explorer shows ntoskrnl.exe as the owning module for most of them.

How to verify and fix

  1. Open Process Explorer (not Task Manager for this).
  2. Double-click the problem process, go to the Threads tab.
  3. Look at the Start Address column. If you see drivers like MfeEpe.sys or tmevtmgr.sys, that's your suspect.
  4. Temporarily disable the antivirus or uninstall the third-party driver.
  5. Restart the process. If the error stops, you've found the culprit.

If you can't disable the antivirus (corporate policy), contact the vendor and ask for a fix. Sometimes updating to the latest signature or driver version resolves the hook recursion. Other times you need to exclude your application from real-time scanning.

Pro tip: Use fltmc instances to list active file system filter drivers. Then check the vendor's names. A clean system has maybe 5–8 filters. If you see 15+, that's a red flag.

Quick-Reference Summary Table

Cause Symptom Fix Time to resolve
Runaway application Thread count > 5000, steady climb Kill process, fix the app or update it 5 min (kill) / hours (fix)
IOCP thread pool exhaustion Async I/O heavy app, threads stuck on ntdll.dll Tune thread pool or reduce load on server 30 min (tune) / days (code change)
Driver or AV hook recursion Threads owned by kernel driver (.sys files) Disable AV or update driver 15 min to diagnose, vendor fix varies

Remember: 0XC0000129 is almost never a hardware issue. Don't waste time swapping RAM or disks. Focus on the software layer — threads are managed by the OS, and the OS is telling you that one process is out of control. Act accordingly.

Related Errors in Windows Errors
0XC00D10B4 Fix NS_E_WMPCORE_WMX_ENTRYREF_NO_REF (0XC00D10B4) in Windows Media Player 0XC00D272D NS_E_BACKUP_RESTORE_FAILURE (0XC00D272D): How I Fixed It 0X80280801 TPM SelfTestFull Not Run – Fix 0x80280801 Fast 0XC0000268 0xC0000268 STATUS_EVALUATION_EXPIRATION - Fix Windows Evaluation License Has Expired

Was this solution helpful?

EP
Erropedia Team
Tech Support Editors
The Erropedia editorial team researches and documents real-world tech errors from across Windows, Linux, macOS, networking, databases, cloud platforms, and more. Every solution is reviewed for accuracy and updated as software and systems evolve.