Fix ERROR_TOO_MANY_THREADS (0X00000235) Fast

1. A Single Process Is Hogging Threads (Most Common)

Every process in Windows has a default thread limit of 2048 threads. But some apps — especially custom software, database engines, or old Java apps — can eat through that fast. I've seen this on SQL Server instances with poorly configured connection pools, and on badly-written monitoring tools that spawn a thread for every file they check.

The fix is immediate:

1. Open Task Manager (Ctrl+Shift+Esc).
2. Go to the Details tab.
3. Right-click the column headers and select Select Columns.
4. Check Threads.
5. Sort by the Threads column. Look for any process with more than 1500 threads.
6. If you see one, right-click it and End Process. That's it.

Don't bother checking the Performance tab — it shows total system threads, not per-process. The Details tab is where you find the culprit.

If the process is critical (like SQL Server), don't kill it. Instead, restart the service: net stop MSSQL$INSTANCENAME then net start MSSQL$INSTANCENAME. Replace the instance name with yours.

If you can't kill or restart it, use Process Explorer from Sysinternals. It shows thread counts in real-time and lets you kill individual threads inside a process — but that's a last resort.

2. The System-Wide Thread Limit Is Too Low

Windows has a global thread limit per session. By default, it's 20,000 threads for desktops and 32,768 for servers. If you're running apps that legitimately need many threads (think automation frameworks, load testing tools, or container hosts), you'll hit this limit.

Here's how to check if you're there:

wmic path Win32_SystemThreads get ThreadCount

If the number is over 18,000 on a desktop or 30,000 on a server, you're close to the wall.

To raise it, you need a registry tweak:

• Open regedit as admin.
• Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Executive
• Create a DWORD (32-bit) named AdditionalCriticalWorkerThreads.
• Set it to a decimal value like 20 (this adds 20 threads per CPU core to the system pool).
• Reboot.

Don't go crazy — setting it to 200 can cause instability. I stick to 10–40 max unless you know exactly what you're doing.

Windows Server 2019 and 2022 also have a separate limit in the kernel. If you're on Server, check:

reg query HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Memory Management /v PagedPoolSize

If it's set to 0 (default), the paged pool can run out. That triggers thread creation failures even below the thread limit. Set it to a value like 0xFFFFFFFF for unlimited — but only on 64-bit systems with 8GB+ RAM.

3. Handle Leak in a Service or Driver

Threads count as handles. If a driver or service leaks handles, the process hits its handle limit (default 16,384 per process) before it hits the thread limit. The result? Same error code.

To check for this:

tasklist /fi "handles gt 10000"

If anything shows up with over 12,000 handles, that's your leak. Common culprits:

• Antivirus drivers (looking at you, McAfee and Symantec legacy versions)
• Custom WMI providers that don't release handles
• Old .NET apps with thread pool starvation

To fix a handle leak, you'll need to update the driver or app. But for immediate relief, you can increase the handle limit per process:

• Same reg key as above: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Executive
• Create a DWORD named AdditionalHandleQuota.
• Set it to a decimal value like 16384 (doubles the default).
• Reboot.

This is a stopgap — don't rely on it. Find and fix the real leak.

Quick Reference Summary