| Previous | Next |
| ERROR_SWAPERROR | ERROR_INVALID_MESSAGE |
ERROR_STACK_OVERFLOW
recursion too deep; the stack overflowed.
ERROR_STACK_OVERFLOW means that a thread exhausted the committed space available for its call stack. In this case, the decisive context is unbounded or unexpectedly deep recursion, together with the deepest repeating call-stack pattern and the input that produced it.
Where the result appears
- unbounded or unexpectedly deep recursion.
- large automatic arrays or structures allocated on the stack.
- mutual recursion in parsers, visitors, serializers, or tree walkers.
- callbacks or hooks that re-enter the same code path without a guard.
Typical causes
- input depth is not bounded before recursive processing.
- a termination condition is missing or based on corrupted state.
- stack usage per frame became excessive after a code or compiler change.
- the thread was created with a stack reserve too small for the legitimate workload.
Evidence to collect
- the deepest repeating call-stack pattern and the input that produced it.
- thread stack reserve/commit settings and architecture.
- sizes of local variables, compiler options, and recent changes to frame layout.
- whether the failure is deterministic at a particular nesting depth.
For this condition, begin the investigation with the deepest repeating call-stack pattern and the input that produced it. Correlate it with thread stack reserve/commit settings and architecture and check whether input depth is not bounded before recursive processing. Capture the original this result immediately after the failing call so later cleanup does not replace the thread-local error value.
Handling and recovery
Fix the algorithm or frame size before considering a larger stack. Convert recursive traversal to an explicit work stack where untrusted input can control depth, and enforce documented limits. A larger reserve can be appropriate only after measuring legitimate worst-case depth and its effect on process address space.
Any retry policy for this Win32 error should be tied to evidence that a termination condition is missing or based on corrupted state has changed. Before another attempt, verify sizes of local variables, compiler options, and recent changes to frame layout. If the thread was created with a stack reserve too small for the legitimate workload still applies, stop the retry sequence and preserve the first diagnostic event.
Common misinterpretation
Catching the resulting exception and continuing on the same exhausted stack is unsafe. Recovery normally requires unwinding to a protected boundary or terminating the affected operation.
Guidance for developers
When surfacing this result through another layer, retain its Win32 domain, numeric value, and the operation described by large automatic arrays or structures allocated on the stack. A useful telemetry record also includes whether the failure is deterministic at a particular nesting depth. For a-related handling, decisions must use the numeric value and documented API contract rather than localized wording.
A focused test should reproduce the condition in which stack usage per frame became excessive after a code or compiler change, assert this result, and confirm that the program releases resources associated with mutual recursion in parsers, visitors, serializers, or tree walkers. The recovery test should also verify that the deepest repeating call-stack pattern and the input that produced it is refreshed before the operation resumes.
References
Looking for a different code? Search another status or error code.