| Previous | Next |
| STATUS_DATATYPE_MISALIGNMENT | STATUS_SINGLE_STEP |
STATUS_BREAKPOINT
A breakpoint instruction transferred control to exception handling
This exception is normally generated by an INT 3 instruction, DebugBreak, or a debugger-inserted breakpoint. It is expected during debugging, but in an unmonitored production process it can also indicate a deliberate diagnostic trap, a failed assertion path, leftover instrumentation, or execution of corrupted bytes that happen to decode as a breakpoint.
Windows gives a debugger first-chance access before frame-based handlers run. Continuing correctly depends on the architecture and saved context; Microsoft specifically notes that the instruction pointer may need adjustment when a breakpoint is handled manually. Do not simply suppress the event without identifying who planted or executed the breakpoint, because repeated traps can hide a control-flow problem.
What to inspect
- Disassemble the bytes at and immediately before the exception address.
- Determine whether a debugger, patcher, assertion macro, or application code inserted the trap.
- Inspect first-chance handling before evaluating the later process termination.
- Modify the instruction pointer only according to the architecture-specific contract.
References
- Microsoft Learn: Debugger Exception Handling
- Microsoft Learn: GetExceptionCode
- Microsoft Learn: Specific Exceptions
- Microsoft Learn: EXCEPTION_RECORD
Looking for a different code? Search another status or error code.