| Previous | Next |
| ERROR_DBG_TERMINATE_PROCESS | ERROR_DBG_PRINTEXCEPTION_C |
ERROR_DBG_CONTROL_C
What ERROR_DBG_CONTROL_C means
The debugger received a Ctrl+C control event from the debugged console process. In practical terms, this status belongs to console debugging and control events: a console interrupt is delivered through the debugger before the application control handler processes it.
Typical causes
- A user pressed Ctrl+C in the console
- Automation sent a console control signal to stop work
- The debugger is configured to break on control events
How to investigate
- Identify whether the event was first-chance and whether the application has a console handler
- Check the debugger setting for breaking on Ctrl+C
- Verify whether continuing the event lets the application perform graceful cancellation
Developer guidance
The event is not equivalent to process termination. The debugger can inspect it, pass it to the application, or suppress it according to the intended console semantics.
Operational interpretation
When ERROR_DBG_CONTROL_C 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 console debugging and control events boundary; broad machine-wide remediation before that boundary is identified can hide the original evidence.
Example scenario
An incident begins when a user pressed Ctrl+C in the console. A responder investigating this result should not begin with a generic reboot that destroys the original context. A better first step is to identify whether the event was first-chance and whether the application has a console handler. 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 this Win32 error 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 console debugging and control events 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.