| Previous | Next |
| STATUS_DRIVERS_LEAKING_LOCKED_PAGES | STATUS_SYSTEM_POWERSTATE_TRANSITION |
STATUS_MESSAGE_RETRIEVED
The peer retrieved the ALPC message before cancellation completed
ALPC cancellation is inherently race-sensitive. A sender can request cancellation while the receiving endpoint is simultaneously dequeuing the same message. This informational result means ownership has already moved past the queue state that the cancellation path can undo; it does not prove that the peer finished processing or sent a reply.
Treat the original request as potentially visible to the peer. Reusing attached handles, sections, or application buffers as though delivery never occurred can create use-after-close or duplicate-operation bugs. A higher-level protocol should use request identifiers and explicit reply or disconnect handling to decide whether retrying is safe.
What to inspect
- Log the ALPC port, message ID, callback or request ID, cancellation timestamp, and the first observed receive or reply event.
- Determine whether the operation is idempotent before issuing a replacement request.
- Keep transferred handles and mapped-view lifetime valid until the protocol has resolved the race.
- Distinguish queue retrieval from successful application-level completion.
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.