Heh Lars!
Hope your having a fine weekend - the long Victoria Day weekend here.
It`s a trap 3 which means it is a hard coded int3 breakpoint, put there deliberately by the programmer. The reason it fires is that something is calling/jumping to address 1000:0, that is, a ZERO offset. Since this is not expected and likely is a programmer error in that somebody tries to do an indirect near call/jump with a near NULL pointer, that is caught by this breakpoint.
Note that the trap address is 1000:0001 because for an int3 the trap screen will show the address of the instruction following the int3 and the int3 instruction is 1 byte long.
In order to analyze that, you´d need a trap dump in order to find out what code tried to call/jump to 1000:0 (or rather do an indirect near call/jump with a near NULL pointer).
Thinking about it: selector 1000 points to the DOSCODE segment that contains many low level kernel routines. And the DevHelp Routine is located in that segment (and all the subroutines it calls). The DevHelp Routine in turn is the main entry point for any device driver services and therefore used by about any device driver and a pointer to the DevHelp Routine is passed to each device driver on driver load. If that pointer is not properly saved or subsequently accidentally overwritten then you might see that trap.
So if it`s about a driver, Wim should check that the saved DevHelp pointer was not accidentally overwritten (the offset part of it) by a NULL value.
Thanks for the detailed explanation.
As mentioned I'm not a programmer myself, but I appreciate when someone will explain not just that there is a problem, but what it may be as well as its implications. It also assists greatly in testing at the moment, to analyze exactly what I did that made it trigger.
In this case I'm simply acting as a tester and reporting anything I may see, that may be of significance or interest, hopefully in a way useful to you, Wim, Jochen or anyone else participating or observing.
However, in my emergency / environmental consulting practice, as well as my senior roles in both government and corporate in my career, I've been a senior project manager leading teams of hundreds - I always appreciated being informed by my staff as to potential roadblocks, pitfalls or problems, and what may need to be done, in a way I can comprehend, as being forewarned allows planning to proceed smoothly. Analysis is key to success, as well as being methodical IMHO.
I've learned a lot in this what I consider a "project" - it is fascinating to look "under the hood" so to speak as to what actually makes up a device driver and how it operates.
Best!
M