Re: What Could Possibly Crash PnpRemoveDevice()?

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

On Feb 7, 8:50 am, "Don Burn" <b...@xxxxxxxxxxxxxxxxxxxx> wrote:
I don't know audio drivers, but killing the thread would never work in most
drivers, there is a 12 step process that must be done for regular PnP
drivers (see IRP_MN_REMOVE documentation) and that includes deleting the
device object and calling the lower driver.


Don, once again thanks for your wise guidance. You are right in that
audio drivers are different than other drivers since the use (and rely
on) the PortCls subsystem to do most of the work.

In fact, until I added a system thread to help with handling CSQed
IRPs, I had no PnpHandler/DispatchPnP routine of my own - all was
taken care of automagically by the PortCls system since until then I
used only resources known to (and managed by) PortCls.

Then, when I added that thread, I discovered that I needed to stop it
before uninstalling/updating the driver, otherwise chaos will ensue. I
then replaced (in DriverEntry) the default PortCls IRP_MJ_PNP handler
with mine, not forgetting to forward all IRP_MJ_PNPs going through it
to PortCls, using PcDispatchIrp().

I thought that by identifying and handling only IRP_MN_REMOVE_DEVICE I
was "acting smart" by saving duplicate work that PortCls is doing
anyway. But thanks to your concised but right-on-target reply I
understand that there is much more to handling PNP - *if and when* I
have to add customized handling (i.e. that PortCls has no chance of
knowing about).

In particular, I at least needed to stop that thread in response to
IRP_MN_QUERY_REMOVE_DEVICE and not IRP_MN_REMOVE_DEVICE, right?

This is because by the time IRP_MN_REMOVE_DEVICE is received, the
device should have already been inactive in response to a prior
IRP_MN_QUERY_REMOVE_DEVICE.

Anyway, I think the time has come to (at least attempt to) handle all
8 minor PnP IRPs.



BTW, I just noticed in this WinDbg's crash handling:

================ START QUOTE ===============
IRQL_NOT_LESS_OR_EQUAL (a)

Arguments:
Arg1: 00000000, memory referenced
Arg2: 00000002, IRQL
Arg3: 00000001, value 0 = read operation, 1 = write operation
Arg4: 80525722, address which referenced memory

Debugging Details:
------------------

*** No owner thread found for resource 80558460
*** No owner thread found for resource 80558460
*** No owner thread found for resource 80558460

WRITE_ADDRESS: 00000000

CURRENT_IRQL: 2

FAULTING_IP:
nt!PoRegisterDeviceForIdleDetection+46
80525722 8901 mov dword ptr [ecx],eax
================ END QUOTE ===============

Which probably means that the fault occurred at
PoRegisterDeviceForIdleDetection() - way down the call stack from
PnpRemoveDevice().

The only pointer parameter that PoRegisterDeviceForIdleDetection()
receives (since the fault is a *write access violation*) is a pointer
to the FDO. And since the write address is reported by WinDbg as
00000000 this must be the deleted FDO, right?

If so, how is this possible? Yes, the eventual job of
IRP_MN_REMOVE_DEVICE is to stop the device and **delete the FDO**, but
my handler didn't delete and FDO, it merely passed it to the venerable
PcDispatchIrp().


Thanks,
Don


.

Relevant Pages