Confusion about remove locks

NTDEV
1

Hello,

I’ve read the article “My device is gone. Why am I still getting IRPs?” and am still a bit unsure about the purpose of remove locks.

The article states:
“A WDM driver might receive additional IRPs after it has processed a device-removal IRP and freed driver-allocated memory. Attempting to reference the freed memory while processing the additional IRPs can crash the system.”

What exactly does “driver-allocated memory” mean?

Remove locks are typically part of the device extension, so if the device object with its extension is gone, a dispatch routine might still access invalid memory (i.e., the remove lock).

Or to paraphrase my concern, while processing an IRP, is there a guarantee that the associated device object doesn’t vanish?

Are remove locks basically just a convenient way to know that an IRP_MN_REMOVE_DEVICE request has occured (plus synchronization)?

Thanks.

2

> Or to paraphrase my concern, while processing an IRP, is there a guarantee that

the associated device object doesn’t vanish?

What do you think reference counting is for??? As long as an outstanding refcount to the device is nonzero, it is not going to be deleted from RAM by IoDeleteDevice() call - it will be just marked for a deletion, but still present in RAM until reference count goes down to zero. Therefore, as long as a driver/OS component that sends an IRP to your device references it (as properly written driver should do) you don’t have to worry about it…

Anton Bassov

3

Anton,

" it will be just marked for a deletion, but still present in RAM until
reference count goes down to zero"

Regarding reference counting and your post, is it marked for deletion before
or after the ref count goes to zero? I would think after, but your post
indicated prior.

On 10/4/07, xxxxx@hotmail.com wrote:
>
> > Or to paraphrase my concern, while processing an IRP, is there a
> guarantee that
> > the associated device object doesn’t vanish?
>
>
>
> What do you think reference counting is for??? As long as an outstanding
> refcount to the device is nonzero, it is not going to be deleted from RAM by
> IoDeleteDevice() call - it will be just marked for a deletion, but still
> present in RAM until reference count goes down to zero. Therefore, as long
> as a driver/OS component that sends an IRP to your device references it (as
> properly written driver should do) you don’t have to worry about it…
>
> Anton Bassov
>
>
> —
> NTDEV is sponsored by OSR
>
> For our schedule of WDF, WDM, debugging and other seminars visit:
> http://www.osr.com/seminars
>
> To unsubscribe, visit the List Server section of OSR Online at
> http://www.osronline.com/page.cfm?name=ListServer
>

4

> Regarding reference counting and your post, is it marked for deletion before

or after the ref count goes to zero? I would think after, but your post indicated prior.

It will be marked for a deletion at the moment IoDeleteDevice() call is made ( I assume
nonzero refcount, so that IoDeleteDevice() does not remove it from RAM), and *actually* removed from RAM when refcount goes down to zero. Think about it yourself, and you will understand the logic behind the whole thing…

Anton Bassov

5

Thanks for your reply, Anton.

In this case, I don’t need remove locks at all, because I’m just accessing the device extension.

Anton Bassov wrote:

Therefore, as long as a driver/OS component that sends an IRP to your device references it
(as properly written driver should do) you don’t have to worry about it…
I assume drivers don’t have to reference it themselves, because the respective APIs already take care of that. Right?

6

> I assume drivers don’t have to reference it themselves, because the respective

APIs already take care of that. Right?

In most cases yes, but still not necessarily…

For example, consider the scenario when a driver gets a pointer to your device with IoGetAttachedDevice(), rather than with IoGetAttachedDeviceReference(), and sends an IRP to it. In this case it is client driver’s responsibility to reference your device after having obtained a pointer to it…

Anton Bassov

7

> ----------

From: xxxxx@lists.osr.com[SMTP:xxxxx@lists.osr.com] on behalf of xxxxx@hushmail.com[SMTP:xxxxx@hushmail.com]
Reply To: Windows System Software Devs Interest List
Sent: Thursday, October 04, 2007 11:35 AM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Confusion about remove locks

In this case, I don’t need remove locks at all, because I’m just accessing the device extension.

I don’t think it is a good conclusion. As you originally wrote, remove lock is a convenient way how to know your driver already received remove IRP. It allows you to complete all your tasks and wait for finishing all operations before passing remove IRP down the stack. It is important in some cases; sending remove IRP down while some other IRPs are pending can lead to BSOD. For USB drivers it is even documented driver has to wait for D0 IRP completion before passing remove IRP down (forgot where, I just have a note in my code).

Best regards,

Michal Vodicka
UPEK, Inc.
[xxxxx@upek.com, http://www.upek.com]