| Previous | Next |
| ERROR_LABEL_TOO_LONG | ERROR_SIGNAL_REFUSED |
ERROR_TOO_MANY_TCBS
What ERROR_TOO_MANY_TCBS means
The environment cannot create another thread control block. A thread control block is bookkeeping for a thread in older runtimes and compatibility subsystems. This result means thread creation reached a system, process, or subsystem-specific limit.
Common causes
- The application creates one thread per request without reusing workers
- Finished threads are not fully joined or released by a runtime
- Thread stacks exhaust address space before other memory appears low
- A compatibility subsystem enforces a lower fixed thread limit
How to investigate
- Track thread count, creation rate, and stack reservation over time
- Capture thread start addresses to group threads by subsystem
- Verify that completed workers actually terminate
- Repeat with a bounded pool and compare memory and handle growth
Developer guidance
Use a bounded thread pool, asynchronous I/O, or task scheduling. Thread creation failure must be handled as resource exhaustion, not followed by dereferencing an invalid thread handle.
Administrator and support guidance
Capture a dump or thread inventory before restarting. The distribution of start addresses often identifies the leaking component immediately.
How this code differs from related results
ERROR_MAX_THRDS_REACHED expresses a similar practical condition through another API family; preserve the exact code and call site because limits and remedies can differ.
Evidence worth collecting
For ERROR_TOO_MANY_TCBS, begin the trace at the operation where the application creates one thread per request without reusing workers. Preserve the exact API boundary, numeric result, process and thread identifiers, relevant object state, and the component version. The first verification point should be to track thread count, creation rate, and stack reservation over time. This evidence distinguishes the specific this result contract from a later secondary failure.
Recovery and verification
Recovery for it should address the observed condition rather than merely retrying the same call. After the change, reproduce the scenario in which the application creates one thread per request without reusing workers, then confirm that the intended operation completes and that cleanup returns all associated resources. Also verify that the next repeated operation follows the same successful path without increasing the resource class implicated by this result.
When to escalate
Escalate this result with a minimal reproduction focused on the failing synchronization boundary. Include the operating-system build, binary architecture, runtime or compatibility-layer version, the exact input values, and a timestamped trace showing the application creates one thread per request without reusing workers. For the result escalation record, note whether changing concurrency, object lifetime, target process, module set, or endpoint location alters the result.
References
Looking for a different code? Search another status or error code.