IRP_MJ_POWER in Disk filter hanging shutdown

This is a problem that has been brought up on this list a few times in the
past (see articles titled IRP_MJ_POWER in March 2000, June 2000, and
February, 2002). However, nobody’s posted a solution to the problem yet
that I could find, so I wanted to pose the question again.

I have a filter driver that sits on a DiskDevice stack. It handles a few
IOCTL requests, but for the most part passes all IRPs down the stack. The
problem I’m seeing is that system shutdown hangs. I get the message:

Waiting on: \Driver\NCR_LKF \Device\LKFPhysicalDisk1 irp (8124d2a8)
SetPower-Shutdown status c00000bb

repeated every 15 seconds or so, after which I have to manually reboot the
system.

8124d2a8 is the address of an IRP_MJ_POWER IRP that I see come through my
DispatchPower handler. I also see that the IoStatus.Status of the request
is c00000bb at my stack location.

Initially, I had a very simple DispatchPower routine that handled the
requests in the standard way: PoStartNextPowerIrp(),
IoSkipCurrentStackLocation(), PoCallDriver(). Then I saw some guidelines in
the latest DDK documentation about calling PoStartNextPowerIrp from a filter
driver. Based on those guidelines, I set up a Completion routine that gets
called if I get a DevicePowerState type of request. The completion routine
calls PoStartNextPowerIrp(), rather than the Dispatch routine. But the
result was the same when I used the new dispatch / completion handler
routines.

My system has two physical disk devices, and the IRP that appears to be
causing the hang always is one that is sent to the second disk. And it is
always a SET_POWER request for PowerSystemStateShutdown. That may just be
coincidence, or it may be relevant.

So, does anyone have an idea what’s going wrong? I’ve got a workaround that
I don’t especially like - I register for shutdown notification, and detach
from the stack when I get IRP_MJ_SHUTDOWN, so I never get the POWER IRP’s,
and this seems to work OK. But it’s definitely not an ideal solution by any
means.

Thanks for any help you can provide on this!

Ernie Coskrey
SteelEye Technology, Inc.