| Previous | Next |
| ERROR_DLL_MIGHT_BE_INCOMPATIBLE | ERROR_DBG_REPLY_LATER |
ERROR_DBG_EXCEPTION_NOT_HANDLED
What ERROR_DBG_EXCEPTION_NOT_HANDLED means
A debugger received an exception notification but did not report the exception as handled. In practical terms, this status belongs to native debugging and exception dispatch: a debugger event loop returns a continue status that allows normal exception processing to resume.
Typical causes
- The debugger deliberately passed a first-chance exception back to the debuggee
- A debugger extension or automation layer used the wrong continuation code
- The exception was expected by the runtime but not recognized by the attached debugger
How to investigate
- Record the exception code, address, first-chance flag, thread identifier, and continuation status
- Check which component called ContinueDebugEvent and which status it supplied
- Reproduce without debugger extensions to separate debugger policy from application failure
Developer guidance
Treat this value as part of the debugger protocol, not automatically as the root application error. Preserve the original exception record because it explains what the debuggee actually raised.
Operational interpretation
When ERROR_DBG_EXCEPTION_NOT_HANDLED appears, first determine whether the operation actually failed, completed with an informational condition, or transferred work to another component. For ERROR_DBG_EXCEPTION_NOT_HANDLED, record the API name, returned value, affected process or object, and the immediately preceding event. For this code, the most useful boundary is the native debugging and exception dispatch boundary; broad machine-wide remediation before that boundary is identified can hide the original evidence.
Example scenario
An incident begins when the debugger deliberately passed a first-chance exception back to the debuggee. A responder investigating ERROR_DBG_EXCEPTION_NOT_HANDLED should not begin with a generic reboot that destroys the original context. A better first step is to record the exception code, address, first-chance flag, thread identifier, and continuation status. That evidence connects ERROR_DBG_EXCEPTION_NOT_HANDLED to its producing operation and reveals whether this particular result is repeatable, expected, or merely secondary.
Logging and telemetry
Telemetry for ERROR_DBG_EXCEPTION_NOT_HANDLED 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 ERROR_DBG_EXCEPTION_NOT_HANDLED correlation identifier stable across callbacks so the status can be joined to the request that initiated this exact operation.
Recovery and validation
For ERROR_DBG_EXCEPTION_NOT_HANDLED, apply recovery only after the responsible state has demonstrably changed. After changing that state, repeat one controlled ERROR_DBG_EXCEPTION_NOT_HANDLED scenario and verify both the returned status and the resulting system state. For ERROR_DBG_EXCEPTION_NOT_HANDLED, absence of another log line is not sufficient: confirm that the intended native debugging and exception dispatch 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.