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

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

> 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.
>
handle tracing is an OS concept, and it does not depend on the target
application
or on the debugger. Try this:
c:\>gflags /v IMAGE /enable devenv.exe HANDLE_CHECKS
c:\>gflags /v IMAGE /enable TestApp.exe HANDLE_CHECKS

and then run devenv.exe under cdb/ntsd/windbg, and, when you have
the original probelm in the debugger, attach a non invasive debugger
to the target application spawned by devenv.exe (cdb -pv -p <PID>)
and execute !htrace in both devenv.exe and the target app.

> When I run the app (F5) I get fault traps that I had never seen before
> (presumably generated by AV).

You should prompthly investigate those new AVs, because they may show
that the root cause of the problem is yet to be found

> 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 should pursue the root cause from the scenario when the app
is launched from devenv.exe. It's most likely an interaction problem with
devenv.exe

--
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:QMidnTJca5smJIXeRVn-qA@xxxxxxxxxxxxxx
> 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?
    ... I have run appverifier and!htrace on the app. ... If I try to reproduce the error by launching the app from DevStudio, ... >> ....looking at the docs for STARTUPINFO, ... > you seem to have KD and a user mode debugger. ...
    (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)