Doubt about IRP_MN_REMOVE_DEVICE

NTDEV
1

Hi all

I have a doubt about IRP_MN_REMOVE_DEVICE. If the driver is an intermediate
driver, if somebody has some references still pending on top layer driver,
is it possible that Intermediate driver get an IRP_MN_REMOVE_DEVICE request
? What should an Intermediate driver should do if it gets
IRP_MN_REMOVE_DEVICE request but still reference count exists for the device
object. Should we delete the device object or not ? what is the best way to
handle this situation ?

Anybody has any suggestions ?

Thanks
srinivasa

2

From the DDK (IoDeleteDevice):

>
When a driver calls IoDeleteDevice, the I/O Manager deletes the target
device object if there are no outstanding references to it. However, if any
outstanding references remain, the I/O Manager marks the device object as
“delete pending” and deletes the device object when the references are
released.
<<

Hope this answers your question :slight_smile:

Mathieu Routhier

-----Original Message-----
From: Deevi, Srinivasa [mailto:xxxxx@microtune.com]
Sent: Wednesday, February 05, 2003 3:08 PM
To: NT Developers Interest List
Subject: [ntdev] Doubt about IRP_MN_REMOVE_DEVICE

Hi all

I have a doubt about IRP_MN_REMOVE_DEVICE. If the driver is an intermediate
driver, if somebody has some references still pending on top layer driver,
is it possible that Intermediate driver get an IRP_MN_REMOVE_DEVICE request
? What should an Intermediate driver should do if it gets
IRP_MN_REMOVE_DEVICE request but still reference count exists for the device
object. Should we delete the device object or not ? what is the best way to
handle this situation ?

Anybody has any suggestions ?

Thanks
srinivasa

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

3

“Deevi, Srinivasa” wrote:

I have a doubt about IRP_MN_REMOVE_DEVICE. If the driver is an intermediate
driver, if somebody has some references still pending on top layer driver,
is it possible that Intermediate driver get an IRP_MN_REMOVE_DEVICE request
? What should an Intermediate driver should do if it gets
IRP_MN_REMOVE_DEVICE request but still reference count exists for the device
object. Should we delete the device object or not ? what is the best way to
handle this situation ?

There was a recent discussion about this point in one of the three
driver-programming newsgroups, so you might want to search archives. To
summarize, a filter driver (which is what I think you mean when you say
“intermediate” driver) should call IoAcquireRemoveLock at the entry to a
dispatch routine that will forward an IRP and should call
IoReleaseRemoveLock when the IRP completes. Its REMOVE_DEVICE handler
should pass the IRP down, call IoReleaseRemoveLockAndWait, and then
IoDetachDevice + IoDeleteDevice.

There’s more to it than this (many pages in ch. 6 of my 2d ed), but what
I just described will give you almost complete safety. Complete safety
requires that you use IoSetCompletionRoutineEx but increases the cost of
IRP handling too much to be acceptable. Microsoft will eventually have
to come up with a better solution than the remove lock as a mechanism
for keeping drivers in memory while they’re needed.

–
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

4

Hi walter oney

Thanks for the reply.

I think that I messed up what I want to ask . I have a driver based on your
multifunc sample as shown below

Microsoft Audio stack
|
USB Audio driver
|
Our driver-----PDO created by our driver

Loading of MS audio driver and working with it is fine. Now the problem is ,
I see a reference count in the child device object and active thread count
as zero . I found this value when I got IRP_MN_REMOVE_DEVICE for child DO.
This problem occurs only in Windows 98 . I don’t have any problem with
windows 2K and XP . Because of this our driver does not unload since there
is a reference to our child device object . For our base driver does not
have any reference count and active thread count.

any suggestions how to solve this problem.

thanks in advance
sri

-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Wednesday, February 05, 2003 3:05 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Doubt about IRP_MN_REMOVE_DEVICE

“Deevi, Srinivasa” wrote:

I have a doubt about IRP_MN_REMOVE_DEVICE. If the driver is an
intermediate
driver, if somebody has some references still pending on top layer driver,
is it possible that Intermediate driver get an IRP_MN_REMOVE_DEVICE
request
? What should an Intermediate driver should do if it gets
IRP_MN_REMOVE_DEVICE request but still reference count exists for the
device
object. Should we delete the device object or not ? what is the best way
to
handle this situation ?

There was a recent discussion about this point in one of the three
driver-programming newsgroups, so you might want to search archives. To
summarize, a filter driver (which is what I think you mean when you say
“intermediate” driver) should call IoAcquireRemoveLock at the entry to a
dispatch routine that will forward an IRP and should call
IoReleaseRemoveLock when the IRP completes. Its REMOVE_DEVICE handler
should pass the IRP down, call IoReleaseRemoveLockAndWait, and then
IoDetachDevice + IoDeleteDevice.

There’s more to it than this (many pages in ch. 6 of my 2d ed), but what
I just described will give you almost complete safety. Complete safety
requires that you use IoSetCompletionRoutineEx but increases the cost of
IRP handling too much to be acceptable. Microsoft will eventually have
to come up with a better solution than the remove lock as a mechanism
for keeping drivers in memory while they’re needed.

–
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

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

5

“Deevi, Srinivasa” wrote:

Loading of MS audio driver and working with it is fine. Now the problem is ,
I see a reference count in the child device object and active thread count
as zero . I found this value when I got IRP_MN_REMOVE_DEVICE for child DO.
This problem occurs only in Windows 98 . I don’t have any problem with
windows 2K and XP . Because of this our driver does not unload since there
is a reference to our child device object . For our base driver does not
have any reference count and active thread count.

If you’d said you were having this problem on all OS’s, I’d have guessed
that it was caused by the fact that KS.SYS likes to keep drivers loaded
just in case they might be needed again later today (it uses a timeout
value that keeps increasing as you continue to load and unload the same
driver). Is it possible that this really is what you’re experiencing
instead of a difference between OS’s?

If the timed delay before unloading feature isn’t the source of your
problem, you’ve probably just encountered a bug in 98. Since it will
almost surely not be fixed, my advice is to just ignore it and let your
driver stay in memory.

–
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

6

Hi Walter Oney

Thanks for the reply.

No, the problem happens only on Windows 98 . And also this problem comes
only when I open waveIn of USB audio device that is exposed from any
application. After I don’t receive the unload routine . If I open waveOut of
USB audio device there is no problem. If I just plug in and plug out then
also I get unload routine properly.

When the bus driver is not unloaded , I found the following modules are not
unloaded which are redbook.sys, swmidi.sys and wdmaud.sys along with the bus
driver. Through softice when I checked the device objects of each driver I
did not find any reference count or any IRP pending . But on the bus driver
the reference count is set to 1 . But in bus driver there is no IRP pending
or any resource unreleased.

Leaving the driver is ok , the problem is when I put the device back into
the system, the device instance is increasing. If the Audio device is not
installed for that instance it is going through standard mechanism of
looking for the drivers which is annoying .

Any ideas what else I can do ?

Thanks in advance
sri.

-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Thursday, February 06, 2003 1:43 AM
To: NT Developers Interest List
Subject: [ntdev] Re: Doubt about IRP_MN_REMOVE_DEVICE

“Deevi, Srinivasa” wrote:

Loading of MS audio driver and working with it is fine. Now the problem is
,
I see a reference count in the child device object and active thread count
as zero . I found this value when I got IRP_MN_REMOVE_DEVICE for child DO.
This problem occurs only in Windows 98 . I don’t have any problem with
windows 2K and XP . Because of this our driver does not unload since there
is a reference to our child device object . For our base driver does not
have any reference count and active thread count.

If you’d said you were having this problem on all OS’s, I’d have guessed
that it was caused by the fact that KS.SYS likes to keep drivers loaded
just in case they might be needed again later today (it uses a timeout
value that keeps increasing as you continue to load and unload the same
driver). Is it possible that this really is what you’re experiencing
instead of a difference between OS’s?

If the timed delay before unloading feature isn’t the source of your
problem, you’ve probably just encountered a bug in 98. Since it will
almost surely not be fixed, my advice is to just ignore it and let your
driver stay in memory.

–
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

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

7

“Deevi, Srinivasa” wrote:

Any ideas what else I can do ?

Well, one idea is to post your question on the WDMAUDIODEV mailing list
and see if anybody there knows the answer. On occasion, I’ve restored to
doing an extra ObDereferenceObject when I was convinced that somebody
was taking an extra reference they didn’t need, but this is pretty
dangerous…

–
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

8

Hi walter oney

Thanks for the reply.

I have already tried to dereference the child DO when I found the reference
count on it, but it did not help . After looking for a while I found
something interesting I believe .

Microsoft Audio stack (
redbook.sys,sysaudio.sys,swmidi.sys)
|
USB Audio device
|
Our Bus driver – Child PDO

When I see the problem , I think USB audio device also should not be
unloaded right . Correct If I am wrong . As you said I believe some audio
drivers left like that and I confirmed that with another USB audio device.
In our case the same drivers left loaded (same audio drivers). But USB audio
device is unloaded and don’t see any in driver list that are loaded
currently.

When I checked our driver information through softice I found an attached
DO to our bus FDO. When I went to the details of attached DO , it found to
be USB Audio DEvice ( I figured that is the one that is attached ). In the
driver details of USB audio device there is no DO , and the flags are set to
DRVO_UNLOAD_INVOKED . I am assuming that unload routine of USB audio device
is called but it did not come for our bus driver.

Are there any reasons that unload routine for USB audio is invoked but that
was not propagated to bus driver ?

Thanks in advance
sri.

-----Original Message-----
From: Walter Oney [mailto:xxxxx@oneysoft.com]
Sent: Thursday, February 06, 2003 2:09 PM
To: NT Developers Interest List
Subject: [ntdev] Re: Doubt about IRP_MN_REMOVE_DEVICE

“Deevi, Srinivasa” wrote:

Any ideas what else I can do ?

Well, one idea is to post your question on the WDMAUDIODEV mailing list
and see if anybody there knows the answer. On occasion, I’ve restored to
doing an extra ObDereferenceObject when I was convinced that somebody
was taking an extra reference they didn’t need, but this is pretty
dangerous…

–
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

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

9

“Deevi, Srinivasa” wrote:

When I checked our driver information through softice I found an attached
DO to our bus FDO. When I went to the details of attached DO , it found to
be USB Audio DEvice ( I figured that is the one that is attached ). In the
driver details of USB audio device there is no DO , and the flags are set to
DRVO_UNLOAD_INVOKED . I am assuming that unload routine of USB audio device
is called but it did not come for our bus driver.

Are there any reasons that unload routine for USB audio is invoked but that
was not propagated to bus driver ?

If he forgot to do an IoDetachDevice, that would explain what you’re
seeing. The existence of an attached device keeps the device object in
memory.

–
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