Re: Reprise: Pended IOCtrl + LoadLibrary == Deadlock?

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Ivan,

I have run appverifier and !htrace on the app. Here is what I
did/found:

I add my app to appverifier (AV).

============
If I try to reproduce the error by launching the app from DevStudio,
here is what happens:

DevStudio loads fine.
When I run the app (F5) I get fault traps that I had never seen before
(presumably generated by AV).
These are interestingly in the same area of code (CRT _ioinit) but they
occur for the app itself when it is very first loaded and for every
single DLL that is loaded (including things like ntdll). I cannot tell
if this is completely spurious or if AV is right and DevStu6 is mucking
things up royally.


============
If I run the app either directly from the shell or via windbug
_on_the_target_ (not from my km debugging host I have been mentioning
before) the app does not fail and naturally AV and !htrace confirm that
nothing odd is happening. The handle that the driver ends up with is
used several times for other purposes before the driver gets the value,
but they are all perfectly symetrical open/close pairs and no events on
that handle value occur after the driver is opened.




You mention below turning on handle tracing in devenv.exe. After poking
around for a bit I have realized that this will not work for me as I am
running DevStu 6, not .NET.

I have not tried the dll version of the CRT yet, I will do that in a
bit.

I think though that since I can use windbg on the target to easily (well
relative to using the KM debugger) debug the UM stuff I will probably
just do that. I guess re-upping my MSDN subscription is in order and
seeing if the newer IDEs fix this trouble.

Thanks again,

Tom








"Ivan Brugiolo [MSFT]" <ivanbrug@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:%23Fq9yG%23rFHA.2996@xxxxxxxxxxxxxxxxxxxxxxx
> > ....looking at the docs for STARTUPINFO, I see its purpose. And I
see
> > that it does allow you to override stdin, stdout, etc. Assuming
that
> > this structure or something very like it is sitting in memory at the
> > time the main thread is executing the call stack I have posted, it
is
> > possible I guess that somehow the in memory locations for
> >
> > HANDLE hStdInput;
> > HANDLE hStdOutput;
> > HANDLE hStdError;
> >
> > are getting over written with 644.
> >
> > It seems highly unlikely as I believe all other threads to be
stopped
> > before the main thread goes down that road.
> >
> Most likely they are not getting overwritten in memory
> Let's assume that devenv.exe creates a handle to a pipe, 0x644, and
> lets the child process to inherit that handle, and passes that handle
> to STARTUP info. At this point, the handle table of the child
> process has 0x644 as a valid handle, and, the startup info has 0x644
> as a valid handle for the C-Runtime to poke with.
> Then, later, something/somebody messes around with handle, and, 0x644
> gets reused, and, it gets reused as a handle for your device.
> Assuming that makes sense, `!htrace` would be your friend.
>
> As far as your debugging configuration is concerned,
> you seem to have KD and a user mode debugger.
> Windbg is yet-another-shell over dbgeng.dll.
> DevEnv.exe is knonw to behave poorly with KD enabled, mostly because
> it's also a managed debugger, and, the managed-code debugging
infrastructure
> is fundamentally flawed with regard of KD and exception dispatching.
> You may compensate for that with kdbgctrl.exe.
>
> You may also consider cdb/ntsd/windbg as a user-mode debugger,
> to see if ti changes the way STARTUPINFO is used.
>
> One other workaround could be to link against msvcrt.dll instead of
> linking the static version of the C-Rutnime
>
> --
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> Use of any included script samples are subject to the terms specified
at
> http://www.microsoft.com/info/cpyright.htm
>
>
> "Tom Udale" <email@xxxxxxxxxxx> wrote in message
> news:opydnRIeqrRr5oXeRVn-1g@xxxxxxxxxxxxxx
> > Dear Ivan,
> >
> >> > When you say this, do you mean limited information about this
> > specific
> >> > case or limited information about how the MS compiler supplied
> > startup
> >> > routines work in general?
> >>
> >> I'm familair with the C-Rutnime IO initialization, but, it's not
clear
> >> the sequence of events that "pollutes" the IO information
> >> or the process startup information.
> >
> > I see.
> >
> >> > It seems plausible from the evidence. Although why on earth
would
> > they do
> >> > that?
> >> >
> >> To avoid crashing on bogous handles, or handles to files that lacks
> >> a certain semantic.
> >
> > That part I get. I just don't get why the dll CRT startup is
> > enumerating _all_ the handles for the process it is loading into. I
> > figured it would just be trying to get stdin, stderr, etc which I
was
> > under the impression were at "known" locations (stdin == 0, etc).
> >
> > Assuming it validated this handle in question, 644, what would the
CRT
> > do with it?
> >
> >
> >> >> Can you elaborate on handle inheritance and process creation
> > hierarchy ?
> >> > Do you mean what I am doing to create all these threads/load
these
> > DLLs,
> >> > or what the OS is doing for us? I am doing very little magic
> > myself.
> >> >
> >> I ment:
> >> do you (or does the shell) pass handle to the process via
STARTUPINFO
> > ?
> >> If yes, what are the chances of those handles being closed / reused
?
> >> In this case, Pavel's suggestion of !htrace seems a way to proceed.
> >
> > No, no. I have never even heard of STARTUPINFO (never needed its
> > functionality I guess). The process is loaded via a link on the
desktop
> > or via Developer Studio.
> >
> > ....looking at the docs for STARTUPINFO, I see its purpose. And I
see
> > that it does allow you to override stdin, stdout, etc. Assuming
that
> > this structure or something very like it is sitting in memory at the
> > time the main thread is executing the call stack I have posted, it
is
> > possible I guess that somehow the in memory locations for
> >
> > HANDLE hStdInput;
> > HANDLE hStdOutput;
> > HANDLE hStdError;
> >
> > are getting over written with 644.
> >
> > It seems highly unlikely as I believe all other threads to be
stopped
> > before the main thread goes down that road.
> >
> >> > Is it possible that this is _entirely_ a side effect of the
> > debugger? Not
> >> > that I can let that go as completing this project without the IDE
> > debugger
> >> > would be painful to say the least.
> >> >
> >> The VS debugger might indeed create the process with something
> >> in the startup information to display the debug spew / the standard
> > output.
> >> In this case, you would need to also run devenv.exe with
> > handle-tracing
> >> enalbed,
> >> so that you can track the proper path of handle duplication.
> >>
> >> > At any rate, the reason I am reminded of this is that I would
like
> > to use
> >> > windbg to step through this code as it has much more accurate
call
> > stacks
> >> > and so on. But, I cannot figure out how to set the breakpoint.
> >> >
> >> > Devstudio and windbg both use int 3 for breakpoints. If I set
the
> > int 3
> >> > from windbg, it is actually trapped first by devstudio which then
> > takes
> >> > over. I cannot figure out how to transfer control from
devstudio,
> > or
> >> > alternately, prevent it from trapping int 3s from the get-go.
> > Softice
> >> > solves this sort of thing by allowing you to turn on and off int
3
> >> > trapping. Is there something analogous for DevStudio? I could
not
> > find
> >> > it.
> >> >
> >> in cdb/ntsd/cdb, you have to use "bp" to set a breakpoint.
> >> dbgeng.dll can set a berakpoint on something that exists with "bp",
> >> and, one something that is not loaded yet with "bu".
> >> This is the short version of the story. The debugger documents
> >> has the whole story for setting breakpoints.
> >
> > Right of course, this is what I am doing.
> >
> >
> >> I'm also not sure how you were running 2 debuggers at the same time
> > against
> >> the same process.
> >
> > Easy.
> >
> > On KM debugging host machine I have windbg running talking to target
> > machine over 1394. I was doing this because I thought my problem
was in
> > KM. While debugging the KM side, I saw that windbg gives a very
clear
> > picture of the actual call stack when the various threads were
blocked
> > (among other obvious advantages over the UM debugger in DevStudio).
> >
> > On target machine (which is where I do most of my builds and general
UM
> > debugging) I boot with /debug /debugport 1394. I then run DevStudio
> > (version 6 btw), open my project and hit F5. At this point, there
are
> > two debuggers running. The DevStudio one has priority over the KM
one
> > in terms of trapping breakpoints and so-on. Thus if I do a bp from
the
> > host and run the app, DevStudio suddenly breaks on the target. It
is of
> > course a little confused since it did not set the bp itself. But it
> > traps just fine as if I had hit F9 right there. So what I was
looking
> > for was away to tell DevStudio "Look, I know you think you are the
> > debugger here, but could you not trap int3s for a moment please"?
That
> > way windbg on the host would get the trap and then I could step
through
> > the code with all the power of windbg at hand.
> >
> >
> > Regards,
> >
> > Tom
> >
> >
> >
>
>


.

Relevant Pages

  • Re: Reprise: Pended IOCtrl + LoadLibrary == Deadlock?
    ... the original probelm in the debugger, ... and execute!htrace in both devenv.exe and the target app. ... > If I try to reproduce the error by launching the app from DevStudio, ... >>> ....looking at the docs for STARTUPINFO, ...
    (microsoft.public.development.device.drivers)
  • Re: Install problem (previous version of windows mobile)
    ... Are you sure your app can handle the screen resolution of the ... Pocket PC 2003 you've been testing? ... When I run programs under the Windows CE debuggers, ... run on their on (on real devices without a debugger). ...
    (microsoft.public.pocketpc.developer)
  • Re: Device driver crash ?? - in udevice.exe
    ... Thanks again - will get back once I've had a play with the debugger:-O. ... document somewhere which explains this (KITL etc.) process ??. ... NB I need to use the serial ports for my app - so need KITL to use ... device drivers - and it seems to be running some 33 threads - normally ...
    (microsoft.public.windowsce.embedded)
  • Re: Windows Forms apps not "ending" when you close the form window
    ... I would suspect that the application starts a worker thread ... The thread, in turn, prevents the app from finishing. ... the debugger on any regular basis. ... Either it's breaking before the closing ...
    (microsoft.public.dotnet.languages.vc)
  • Re: Reprise: Pended IOCtrl + LoadLibrary == Deadlock?
    ... > this structure or something very like it is sitting in memory at the ... process has 0x644 as a valid handle, and, the startup info has 0x644 ... you seem to have KD and a user mode debugger. ... >>> Devstudio and windbg both use int 3 for breakpoints. ...
    (microsoft.public.development.device.drivers)