| Previous | Next |
| STATUS_REQUEST_CANCELED | STATUS_LPC_RECEIVE_BUFFER_EXPECTED |
STATUS_RECURSIVE_DISPATCH
A callback or message dispatcher was entered recursively
Windows dispatch paths often assume that one callback instance owns a context until it returns. Reentering the same dispatcher from a callback, completion routine, hook, or synchronous request can violate that ownership and produce this status. The problem is control-flow recursion, not merely a deeply nested function call.
A common trigger is sending a synchronous request from code that must itself drain the reply or callback needed to finish that request. The durable fix is to queue deferred work, return to the outer dispatcher, and continue after the original context has been released.
What to inspect
- Capture the complete callback and native-call stack, including hooks and message pumps that can reenter application code.
- Mark dispatcher entry and exit with a per-thread depth counter during diagnosis.
- Move blocking or synchronous cross-component calls out of the callback path.
- Check whether exception or cancellation cleanup leaves the recursion guard set incorrectly.
References
- Microsoft Open Specifications: NTSTATUS values
- Microsoft Windows SDK metadata: ntstatus.h
- Microsoft: pooled threads and callback environments
- System Informer PHNT: native ALPC definitions
Looking for a different code? Search another status or error code.