Pended IOCtrl + LoadLibrary == Deadlock?

Greetings,

I have been struggling for several days now with a deadlock. This is a
multithreaded app running on XP communicating with a software only NT
style driver. The basic symptom is the app opens two handles to the
driver. The main process thread uses one handle for "fast" IOCtrls
(meaning from the apps standpoint it does not care how long the driver
takes and assumes that time will be short) and the other handle is used
in a secondary thread that makes "blocking" calls (meaning the app
assumes that the driver will take a long time to satisfy the request -
which of course is true).

In this case, the secondary thread does indeed block for a very long
time as it is being used to set up a "call back" from the driver. When
the driver wants the usermode app to execute some command, it completes
this ioctrl which then makes the thread run and the command be executed.

The trouble I am having is that after the ioctrl is pended, the main app
thread does a LoadLibrary, which hangs for ever. If I comment out only
the IOCtrl (leaving the secondary thread creation and general operation
intact) the LoadLib is happy. Unfortunatly there are a number of other
threads running around to complicate things, and of course the
possibility that the driver is silently hacking something always exists,
but from my current analysis is seems pretty likely that this one thread
blocking on an ioctrl is the culprit. My "analysis" in this case being
the obervation that commenting in and out the ioctrl call nicely turns
on and off the error.

Is there any fundemental reason that I cannot block in an ioctrl and
then expect a loadlib to work? I know for example that there is a "Load
Lock" somewhere in LoadLib that you can get into trouble with (by for
example loading other libs within the libmain of another). Is that used
by IoCtrls as well? (BTW, softice tells me that the call stack of the
main thread is in the CRT io_init of the dll that is being loaded. The
last few functions are
NtQueryVolumeInformationFile,NtWriteFile,KiUnexpectedInterrupt).

Or is this more likely some subtle stupidity on my part? If this simply
cannot be done, I will have to redesign part of the app. Otherwise, I
will keep looking for my stupidity.

Best regards,

Tom Udale


.

Relevant Pages

  • Re: Pended IOCtrl + LoadLibrary == Deadlock?
    ... app and the video capture call graph that has been created. ... >> style driver. ... >> The trouble I am having is that after the ioctrl is pended, ... >> intact) the LoadLib is happy. ...
    (microsoft.public.development.device.drivers)
  • Re: Pended IOCtrl + LoadLibrary == Deadlock?
    ... > multithreaded app running on XP communicating with a software only NT ... > style driver. ... > this ioctrl which then makes the thread run and the command be executed. ... > intact) the LoadLib is happy. ...
    (microsoft.public.development.device.drivers)
  • Re: Pended IOCtrl + LoadLibrary == Deadlock?
    ... > multithreaded app running on XP communicating with a software only NT ... > style driver. ... > this ioctrl which then makes the thread run and the command be executed. ... > intact) the LoadLib is happy. ...
    (microsoft.public.development.device.drivers)
  • Re: Pended IOCtrl + LoadLibrary == Deadlock?
    ... > for the blocking "callback" IOCTL,does the driver mark the irp pending ... The basic symptom is the app opens two handles to the ... >> The trouble I am having is that after the ioctrl is pended, ... >> intact) the LoadLib is happy. ...
    (microsoft.public.development.device.drivers)
  • Re: Pended IOCtrl + LoadLibrary == Deadlock?
    ... you'd probably need to fix the driver. ... > multithreaded app running on XP communicating with a software only NT ... > this ioctrl which then makes the thread run and the command be executed. ... > intact) the LoadLib is happy. ...
    (microsoft.public.development.device.drivers)
Loading