| Previous | Next |
| STATUS_BAD_SERVICE_ENTRYPOINT | STATUS_IP_ADDRESS_CONFLICT1 |
STATUS_LPC_REPLY_LOST
Diagnose the reply half of the LPC transaction
STATUS_LPC_REPLY_LOST narrows the failure to a request/reply lifecycle: the published NTSTATUS definition says the server received the message, so this is not equivalent to a connection failure or a request that never left the client. The missing evidence is what happened between server receipt and reply delivery.
Microsoft's historical !lpc debugger extension exposes LPC ports, message IDs, queued messages, threads waiting for replies, server ports, and rundown queues. Modern Windows emulates LPC in ALPC, and ETW documents separate ALPC send, receive, wait-for-reply, stop-waiting, and close-port events. Those distinctions provide a practical trace model even though this status retains the LPC name. ReactOS also provides an NT-compatible implementation example where a Session Manager client uses NtRequestWaitReplyPort to send an LPC message and wait synchronously for the server reply.
Capture the message ID, client and server process/thread IDs, port identity, server termination or rundown, cancellation, and wait state. Do not retry blindly if the request may have side effects: the server-side operation could have executed before the reply disappeared. First determine whether the protocol is idempotent or has a transaction/request identifier that lets the caller detect duplicate execution.
What to inspect
- Correlate send, receive, wait-for-reply, and server rundown events by message identity.
- Check whether the server thread exited or the port closed after receipt.
- Establish idempotency before replaying a request whose reply was lost.
References
- Microsoft Open Specifications: NTSTATUS values
- Microsoft debugger: !lpc
- Microsoft ETW: ALPC events
- Microsoft WPT: ALPC event types
- ReactOS smlib: NtRequestWaitReplyPort example
Looking for a different code? Search another status or error code.