| Previous | Next |
| STATUS_INVALID_MESSAGE | STATUS_RECURSIVE_DISPATCH |
STATUS_REQUEST_CANCELED
The ALPC request was canceled during its message lifecycle
Cancellation can originate from the local caller, port teardown, thread termination, or protocol shutdown. The status records that the wait or request path ended as canceled, but it does not guarantee that the peer never observed the message. Delivery and cancellation can cross in flight.
The caller should separate transport cancellation from application rollback. If the request changes state on the server, use an application request ID and a query or compensation operation to determine the outcome. Blindly replaying non-idempotent work can duplicate side effects.
What to inspect
- Record who initiated cancellation and whether the send, dequeue, and server dispatch events had already occurred.
- Keep cancellation tokens and ALPC message IDs distinct; one application operation may span more than one native message.
- Check whether teardown canceled all waiters consistently or left orphaned replies.
- Use bounded waits and explicit reconnect logic rather than abandoning native request objects silently.
References
- Microsoft Open Specifications: NTSTATUS values
- System Informer PHNT: native ALPC definitions
- Microsoft Windows SDK metadata: ntstatus.h
- ReactOS source: LPC implementation
Looking for a different code? Search another status or error code.