| Previous | Next |
| STATUS_THREADPOOL_HANDLE_EXCEPTION | STATUS_THREADPOOL_RELEASE_SEMAPHORE_ON_COMPLETION_FAILED |
STATUS_THREADPOOL_SET_EVENT_ON_COMPLETION_FAILED
The callback completed, but its deferred event signal failed
SetEventWhenCallbackReturns asks the thread pool to signal an event after the current callback finishes. The callback body can succeed while this finalization action fails because the event handle was closed, lacked the required access, or no longer referred to the intended event.
This matters when another thread uses the event as proof that callback cleanup is complete. The waiter can block indefinitely even though the worker returned. Event ownership must therefore extend beyond callback finalization, not merely beyond the call that schedules the deferred action.
What to inspect
- Record the callback instance, event handle, owning component, and the nested status reported by finalization.
- Keep the event open until the callback has returned and all deferred actions are known to have run.
- Do not recycle the handle through a pool or wrapper while the callback instance is active.
- Add an independent shutdown timeout so a missed signal cannot deadlock process teardown.
References
- Microsoft Open Specifications: NTSTATUS values
- Microsoft: SetEventWhenCallbackReturns
- Microsoft: threadpoolapiset.h functions
- Microsoft: pooled threads and callback environments
Looking for a different code? Search another status or error code.