[patch] recognise when an exec()d process terminates due to unhandled exception
Fri Mar 14 12:40:00 GMT 2008
On Mar 14 04:08, Brian Dessent wrote:
> 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.
That's really cool. Your patch looks good, but it's Chris' code so
he will have the final say.
What we also could do instead of adding this to the DLL is to add this
to cygcheck and/or strace only. If somebody complains on the list that
a process just exits, we can point him to "run it under cygcheck and it
will tell you what's wrong". That would be already quite nice, imho.
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Project Co-Leader cygwin AT cygwin DOT com
More information about the Cygwin-patches