[patch] recognise when an exec()d process terminates due to unhandled exception

Brian Dessent brian@dessent.net
Fri Mar 14 11:09:00 GMT 2008

Brian Dessent wrote:

> isn't present, etc.  I was really hoping to figure out a cool way to get
> that info, perhaps by poking around in the TEB or PEB somewhere, but I
> haven't gotten that far.  If anyone has any general ideas where to look
> for NTLDR's internal state, I'm all ears.  I have a hunch it would be
> possible to get if we were running the exec'd process in a debugger loop
> and pumping WaitForDebugEvent() messages, since those can have
> parameters attached to exception codes.  But that's a little too
> extreme.

For anyone curious, it's absolutely possible to do the above.  For the
C0000139 fault (missing procedure point entry), %ebx at the time of the
fault points right at the AsciiZ name of the missing import in the
.idata section, -8(%ebp) points to the import name in UNICODE, and
-10(%ebp) points to the DLL name in UNICODE.

For the C0000135 fault (the "unable to locate component popup"), %esi at
the time of the fault points right to the missing library name in

For the C0000005 fault (the LDR hits an access violation trying to fixup
a reloc .rdata), %ebx points to an AsciiZ name of the symbol it was
relocating and 24(%ebp) points to an AsciiZ filename of the module which
that symbol is supposed to be pointing into.

Now I'm sure a lot of those above offsets are just coincidental, as I
haven't done much testing to see if it's reliably set as above.  However
it does mean that it would be relatively easy to use the debug API to
step a process through its initialization and find out exactly why it's
faulting.  I've been working on something along those lines for cygcheck
which will also give dynamic process tracing, i.e. runtime LoadLibrary
stuff.  Combined with enabling the LDR snaps debug output, there is a
tremendous amount of debug capability hidden here.


More information about the Cygwin-patches mailing list