This is the mail archive of the cygwin-patches mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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
> UNICODE.
> 
> 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

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]