Problem with IoReleaseRemoveLockAndWait in a non-PNP driver

Hello,

DDK document suggests using IoReleaseRemoveLockAndWait in
IRP_MN_REMOVE_DEVICE dispatch code. However, my driver is not PNP.
I try to use the function in the Unload routine,
but it does not do what it’s supposed to do.

Excerpt from code

/////////////////////////
// FilterDispathRoutine
/////////////////////////

IoAcquireRemoveLock(DeviceExtension->RemoveLock, tag);
IoSetCompletionRoutine(Irp,
MyCompletionRoutine,
(PVOID) tag,
TRUE,
TRUE,
TRUE);
return IoCallDriver(pDevExt->FileSysObjPtr, Irp);

////////////////////////
// MyCompletionRoutine
////////////////////////

IoReleaseRemoveLock(&DeviceExtension->RemoveLock, tag);

///////////
// Unload
///////////

IoAcquireRemoveLock(DeviceExtension->RemoveLock, tag);
IoReleaseRemoveLockAndWait(DeviceExtension->RemoveLock, tag);
IoDetachDevice(DeviceExtension->FileSysObjPtr);
IoDeleteDevice(CurrentDeviceObject);

///////////

I got a DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS
if the driver is unloaded when there are on-going read/write
to the device. Please tell me what I missing. Your help
is greatly appreciated.

Chu Bun

You should check the status code returned by IoAcquireRemoveLock and
only proceed if it returns NT_SUCCESS. Also, !remlock

remlock> to show the outstanding count.

If you are running a chk version of your driver, you can specify 0x1 for
the flags and you will see the list of outstanding references.

d

-----Original Message-----
From: ChuBun [mailto:xxxxx@yahoo.com]
Sent: Thursday, May 01, 2003 9:51 AM
To: NT Developers Interest List

Hello,

DDK document suggests using IoReleaseRemoveLockAndWait in
IRP_MN_REMOVE_DEVICE dispatch code. However, my driver is not PNP.
I try to use the function in the Unload routine,
but it does not do what it's supposed to do.

Excerpt from code

/////////////////////////
// FilterDispathRoutine
/////////////////////////
...
IoAcquireRemoveLock(DeviceExtension->RemoveLock, tag);
IoSetCompletionRoutine(Irp,
MyCompletionRoutine,
(PVOID) tag,
TRUE,
TRUE,
TRUE);
return IoCallDriver(pDevExt->FileSysObjPtr, Irp);

////////////////////////
// MyCompletionRoutine
////////////////////////
...
IoReleaseRemoveLock(&DeviceExtension->RemoveLock, tag);

///////////
// Unload
///////////
...
IoAcquireRemoveLock(DeviceExtension->RemoveLock, tag);
IoReleaseRemoveLockAndWait(DeviceExtension->RemoveLock, tag);
IoDetachDevice(DeviceExtension->FileSysObjPtr);
IoDeleteDevice(CurrentDeviceObject);

///////////

I got a DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS
if the driver is unloaded when there are on-going read/write
to the device. Please tell me what I missing. Your help
is greatly appreciated.

Chu Bun

---
You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

ChuBun wrote:

DDK document suggests using IoReleaseRemoveLockAndWait in
IRP_MN_REMOVE_DEVICE dispatch code. However, my driver is not PNP.
I try to use the function in the Unload routine,
but it does not do what it’s supposed to do.

Give us some more details about your filter. You say you’re not PNP, yet
you call IoDetachDevice in your “unload” routine.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com

I do check the return value in my code.
I tried your suggestion. The dumped content for the RemoveLock look fine.
(IsRemoved = 1, IoCount = 0). From my DbgPrint, look like the driver
fails just before it returns from the Completion routine

FLTR: cmd.exe - FilterDispatchRoutine “in”
FLTR: cmd.exe - --fileName: \
FLTR: cmd.exe - FilterDispatchRoutine “out”(set CompletionRoutine, retunr
IoCallDriver)

FLTR: System - Unloaded “in”
FLTR: cmd.exe - Completion “in” <== there should be a matching “out”
FLTR: System - Detach filter device on l: from fileSystemObject
FLTR: System - Delete filter device on l:
FLTR: System - Delete the main device
FLTR: System - Unloaded “out”

… bug check here

Any idea where is this pending operation? Thanks.

“Doron Holan” wrote in message
news:xxxxx@ntdev…

You should check the status code returned by IoAcquireRemoveLock and
only proceed if it returns NT_SUCCESS. Also, !remlock remlock> to show the outstanding count.

If you are running a chk version of your driver, you can specify 0x1 for
the flags and you will see the list of outstanding references.

d

-----Original Message-----
From: ChuBun [mailto:xxxxx@yahoo.com]
Sent: Thursday, May 01, 2003 9:51 AM
To: NT Developers Interest List

Hello,

DDK document suggests using IoReleaseRemoveLockAndWait in
IRP_MN_REMOVE_DEVICE dispatch code. However, my driver is not PNP.
I try to use the function in the Unload routine,
but it does not do what it’s supposed to do.

Excerpt from code

/////////////////////////
// FilterDispathRoutine
/////////////////////////

IoAcquireRemoveLock(DeviceExtension->RemoveLock, tag);
IoSetCompletionRoutine(Irp,
MyCompletionRoutine,
(PVOID) tag,
TRUE,
TRUE,
TRUE);
return IoCallDriver(pDevExt->FileSysObjPtr, Irp);

////////////////////////
// MyCompletionRoutine
////////////////////////

IoReleaseRemoveLock(&DeviceExtension->RemoveLock, tag);

///////////
// Unload
///////////

IoAcquireRemoveLock(DeviceExtension->RemoveLock, tag);
IoReleaseRemoveLockAndWait(DeviceExtension->RemoveLock, tag);
IoDetachDevice(DeviceExtension->FileSysObjPtr);
IoDeleteDevice(CurrentDeviceObject);

///////////

I got a DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS
if the driver is unloaded when there are on-going read/write
to the device. Please tell me what I missing. Your help
is greatly appreciated.

Chu Bun


You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The 3rd parameter should tell you which function was left pending. If
it is your irp’s completion routine, you should use
IoSetCompletionRoutineEx which will make sure there is a reference to
your device object until after the completion routine has exitted. Be
warned that you *must* check the return value from this function (unlike
IoSetCompletionRoutine which returns no value) b/c it can fail.

d

-----Original Message-----
From: ChuBun [mailto:xxxxx@yahoo.com]
Sent: Thursday, May 01, 2003 1:51 PM
To: NT Developers Interest List

I do check the return value in my code.
I tried your suggestion. The dumped content for the RemoveLock look
fine.
(IsRemoved = 1, IoCount = 0). From my DbgPrint, look like the driver
fails just before it returns from the Completion routine

FLTR: cmd.exe - FilterDispatchRoutine “in”
FLTR: cmd.exe - --fileName: \
FLTR: cmd.exe - FilterDispatchRoutine “out”(set CompletionRoutine,
retunr
IoCallDriver)

FLTR: System - Unloaded “in”
FLTR: cmd.exe - Completion “in” <== there should be a matching “out”
FLTR: System - Detach filter device on l: from fileSystemObject
FLTR: System - Delete filter device on l:
FLTR: System - Delete the main device
FLTR: System - Unloaded “out”

… bug check here

Any idea where is this pending operation? Thanks.

“Doron Holan” wrote in message
news:xxxxx@ntdev…

You should check the status code returned by IoAcquireRemoveLock and
only proceed if it returns NT_SUCCESS. Also, !remlock remlock> to show the outstanding count.

If you are running a chk version of your driver, you can specify 0x1 for
the flags and you will see the list of outstanding references.

d

-----Original Message-----
From: ChuBun [mailto:xxxxx@yahoo.com]
Sent: Thursday, May 01, 2003 9:51 AM
To: NT Developers Interest List

Hello,

DDK document suggests using IoReleaseRemoveLockAndWait in
IRP_MN_REMOVE_DEVICE dispatch code. However, my driver is not PNP.
I try to use the function in the Unload routine, but it does not do what
it’s supposed to do.

Excerpt from code

/////////////////////////
// FilterDispathRoutine
/////////////////////////

IoAcquireRemoveLock(DeviceExtension->RemoveLock, tag);
IoSetCompletionRoutine(Irp,
MyCompletionRoutine,
(PVOID) tag,
TRUE,
TRUE,
TRUE);
return IoCallDriver(pDevExt->FileSysObjPtr, Irp);

////////////////////////
// MyCompletionRoutine
////////////////////////

IoReleaseRemoveLock(&DeviceExtension->RemoveLock, tag);

///////////
// Unload
///////////

IoAcquireRemoveLock(DeviceExtension->RemoveLock, tag);
IoReleaseRemoveLockAndWait(DeviceExtension->RemoveLock, tag);
IoDetachDevice(DeviceExtension->FileSysObjPtr);
IoDeleteDevice(CurrentDeviceObject);

///////////

I got a DRIVER_UNLOADED_WITHOUT_CANCELLING_PENDING_OPERATIONS
if the driver is unloaded when there are on-going read/write to the
device. Please tell me what I missing. Your help is greatly
appreciated.

Chu Bun


You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com


You are currently subscribed to ntdev as: xxxxx@windows.microsoft.com
To unsubscribe send a blank email to xxxxx@lists.osr.com

The driver is a filter driver based on the FileMon sample code.
It consists of one main device object to handle IOCTL requests and a
number of filter devices. The filter devices are stacked on top of the file
system object. In the Unload routine, I have a loop to detach and
delete the filters. Then I delete the main device object. Bang! bug
check.
I find a workaround by implementing an unload-filter IOCTL, and always
send an unload-filter request then wait a second before unload the driver.
It works but not very clean.

Give us some more details about your filter. You say you’re not PNP, yet
you call IoDetachDevice in your “unload” routine.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com

The third parameter is “beb2541d”. But I dont know how to make any sense
of it. Here is a few lines in the debug screen with that number:
READ_ADDRESS: beb2541d Nonpaged pool expansion
be9c5a2c beb2541d badb0d00 00000000 00000246 nt!MiDbgReleaseAddress+0xc3
I like to try the IoSetCompletionRoutineEx function but it is not support
under NT 2000.

“Doron Holan” wrote in message
news:xxxxx@ntdev…

The 3rd parameter should tell you which function was left pending. If
it is your irp’s completion routine, you should use
IoSetCompletionRoutineEx which will make sure there is a reference to
your device object until after the completion routine has exitted. Be
warned that you must check the return value from this function (unlike
IoSetCompletionRoutine which returns no value) b/c it can fail.

d

ChuBun wrote:

The driver is a filter driver based on the FileMon sample code.
It consists of one main device object to handle IOCTL requests and a
number of filter devices. The filter devices are stacked on top of the file
system object. In the Unload routine, I have a loop to detach and
delete the filters. Then I delete the main device object. Bang! bug
check.
I find a workaround by implementing an unload-filter IOCTL, and always
send an unload-filter request then wait a second before unload the driver.
It works but not very clean.

Oh. It’s a *file system* filter! Use the filter sample in the IFS kit as
your model. You *definitely* want to forget about the remove lock, too.
It’s of no help when it comes to unloading a file system filter.


Walter Oney, Consulting and Training
Basic and Advanced Driver Programming Seminars
Now teaming with John Hyde for USB Device Engineering Seminars
Check out our schedule at http://www.oneysoft.com

> I find a workaround by implementing an unload-filter IOCTL, and
always

send an unload-filter request then wait a second before unload the
driver.
It works but not very clean.

It is not possible to write an FS filter with reliable unload feature.
MS suggests just to not implement unload in FS filters.

Max

>

Oh. It’s a *file system* filter! Use the filter sample in the IFS kit as
your model. You *definitely* want to forget about the remove lock, too.
It’s of no help when it comes to unloading a file system filter.

At the moment, I cannot afford the kit :frowning: Structurally, my driver is
identical
to the FileMon driver. FileMon use
////
KeWaitForMutexObject(&CountMutex, Executive, KernelMode, FALSE, NULL)
OutstandingIRPCount++;
or
OutstandingIRPCount–;
KeReleaseMutex(&CountMutex, FALSE)
////
To keep track of the outstanding IRPs which I guess is no different from
using
IoAcquireRemoveLock
IoReleaseRemoveLock

Should I try using the Kexxx functions and hope for the best?

Chu Bun

>

It is not possible to write an FS filter with reliable unload feature.
MS suggests just to not implement unload in FS filters.

Max

I am aware of this but in my experience with using FileMon, it is
very stable. I hope by using FileMon as a template I can figure
out a workable solution. FileMon has some code to prevent
unloading if some conditions are not met. Maybe I should look
into this. Thanks.