delphi – How to get rid of exception 80000003? – Stack Overflow
Posted by jpluimers on 2018/05/02
The [WayBack] delphi – How to get rid of exception 80000003? – Stack Overflow got me on the right track:
When I run my program (admittedly, it was built in debug mode), I get an error “External exception 80000003”.
According to Win32 Exception/Access Violation Errors it means
0x80000003 EXCEPTION_BREAKPOINT A breakpoint was encountered.
What happened was that during debugging a multi-threaded application doing quite a bit of Windows API stuff and CPU debugger Windows stuff by single-stepping through it.
Single-stepping involves the debugger putting a lot of temporary breakpoints similar to how other debuggers do this:
when stepping at the source level, the debugger uses temporary breakpoints to stop execution at the specified location
Source: [WayBack] ARM Information Center – ARM DS-5 Using the Debugger – Stepping through an application
On Intel platforms, temporary breakpoints are usually done using an INT 3 instruction as that encodes in the single-byte 0xCC opcode. which is very simple for the debugger to patch and remove: just keep a list of addresses and the original byte content.
Note that some debuggers even allow you to manually set temporary breakpoints that disappear after 1-time use; see [WayBack] Temporary Breakpoint – Now You See It, Now You Don’t – mohit.io:
Have you faced the problem of breakpoint clutter where breakpoints keep piling up only to hinder the debugging session? It is then that one realizes that there are some breakpoints that can be deleted and others disabled. A useful feature in a debugger is a temporary breakpoint that automagically gets deleted when hit thereby reducing the clutter of unnecessary breakpoints.
Somehow this doesn’t work well all the time in the Delphi debugger when using multi-threading, but not in a reproducible way: you get a 0x80000003 exception at irregular moments, but more often when you use more threads.
The solution:
- do not single step
- configure the IDE to save the desktop (as that contains your breakpoint settings)
- put regular breakpoints but configure them to be
- non-breaking
- log expressions you are interested in
- put them in a breakpoint group organised by areas you are interested in
- turn off/on breakpoint groups when certain breakpoints are hit
The above is far more painstaking than using single-stepping but suffers from far less problems.
–jeroen
PS: Thanks David Heffernan for indicating “Websearch for NTSTATUS. Knowledge of that macro name is the key.”
The Wiert Corner - irregular stream of stuff 
jpluimers said
Comment via G+ by David Heffernan:
https://plus.google.com/+JeroenPluimers/posts/JJvz3cNZazc
Strange choice of reference. These are NTSTATUS codes. Documented on MSDN: https://msdn.microsoft.com/en-gb/library/cc704588.aspx
Archived at https://web.archive.org/web/20180502094929/https://msdn.microsoft.com/en-gb/library/cc704588.aspx