| Previous | Next |
| ERROR_DBG_EXCEPTION_NOT_HANDLED | ERROR_DBG_UNABLE_TO_PROVIDE_HANDLE |
ERROR_DBG_REPLY_LATER
What ERROR_DBG_REPLY_LATER means
A debugger has deferred its reply for the current debug event. In practical terms, this status belongs to asynchronous debugger control: the debugger postpones continuation while another operation, user decision, or inspection step is pending.
Typical causes
- The debugger is waiting for symbol loading or a user command
- A remote debugging transport has not completed the requested inspection
- The event is intentionally parked so another thread or process can be examined
How to investigate
- Identify the outstanding debug event and the thread that owns it
- Check whether the debugger UI, extension, or remote transport is waiting for input
- Verify that every deferred event has a bounded completion or cancellation path
Developer guidance
Do not convert a deferred reply into an immediate retry loop. The event remains owned by the debugger until it explicitly resumes or terminates the target.
Operational interpretation
When ERROR_DBG_REPLY_LATER appears, first determine whether the operation actually failed, completed with an informational condition, or transferred work to another component. Record the API name, returned value, affected process or object, and the immediately preceding event. For this code, the most useful boundary is the asynchronous debugger control boundary; broad machine-wide remediation before that boundary is identified can hide the original evidence.
Example scenario
An incident begins when the debugger is waiting for symbol loading or a user command. A responder investigating this result should not begin with a generic reboot that destroys the original context. A better first step is to identify the outstanding debug event and the thread that owns it. That evidence connects it to its producing operation and reveals whether this particular result is repeatable, expected, or merely secondary.
Logging and telemetry
Telemetry for it should preserve its numeric value, component version, process and thread identifiers, operation name, affected object or endpoint, elapsed time, and the first earlier failure in the same activity. Keep the result correlation identifier stable across callbacks so the status can be joined to the request that initiated this exact operation.
Recovery and validation
Apply recovery only after the responsible state has demonstrably changed. After changing that state, repeat one controlled this result scenario and verify both the returned status and the resulting system state. Absence of another log line is not sufficient: confirm that the intended asynchronous debugger control action completed, that no resource remains pending, and that later cleanup does not produce a different secondary error.
References
Looking for a different code? Search another status or error code.