Brutally removing a device

NTDEV
1

Hi,
I’m looking for a way to remove a started device stack in which my driver is
not a member.
I thought about two options, but I’m not sure if any of them is legitimate
or safe:

  1. Attach a filter device to the running stack which forwards all IRP’s to
    the lower device (always using IoSkipCurrentIrpStackLocation() so I will not
    risk a NO_MORE_IRP_STACK_LOCATIONS bug check) except for
    IRP_MN_QUERY_PNP_DEVICE_STATE for which I set a completion routine that
    turns on the PNP_DEVICE_FAILED bit in the Information field of the iosb.
    After the filter is attached I will call IoInvalidateDeviceState() and this
    will eventually get the device to be surprise removed since the filter is
    going to turn on the PNP_DEVICE_FAILED bit.
  2. Somehow close all the open handles to the device stack (can anyone give
    me a clue about how this can be done?) and then request to remove the device
    using user mode API.

Can anyone suggest a new method or tell me why I should not use one of those
two?

Thanks,
Shahar

2

One thing that comes to mind: How do you plan to set a completion
routine without using a stack location?

Shahar Talmi wrote:

Hi,
I’m looking for a way to remove a started device stack in which my driver is
not a member.
I thought about two options, but I’m not sure if any of them is legitimate
or safe:

  1. Attach a filter device to the running stack which forwards all IRP’s to
    the lower device (always using IoSkipCurrentIrpStackLocation() so I will not
    risk a NO_MORE_IRP_STACK_LOCATIONS bug check) except for
    IRP_MN_QUERY_PNP_DEVICE_STATE for which I set a completion routine that
    turns on the PNP_DEVICE_FAILED bit in the Information field of the iosb.
    After the filter is attached I will call IoInvalidateDeviceState() and this
    will eventually get the device to be surprise removed since the filter is
    going to turn on the PNP_DEVICE_FAILED bit.
  2. Somehow close all the open handles to the device stack (can anyone give
    me a clue about how this can be done?) and then request to remove the device
    using user mode API.

Can anyone suggest a new method or tell me why I should not use one of those
two?

Thanks,
Shahar

–
…/ray..

Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.

3

We have discussed similar nonsense here repeatedly, and the general
consensus is ‘do not do this’. On the fly filter drivers are currently not
part of the NT design parameters. As the inimitable Don Burn might say,
please let me know what product this functionality will be incorporated in
so that I may be sure to never have this product anywhere near any computer
I have to use.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Wednesday, December 01, 2004 12:30 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Brutally removing a device

Hi,
I’m looking for a way to remove a started device stack in which my driver is
not a member.
I thought about two options, but I’m not sure if any of them is legitimate
or safe:

  1. Attach a filter device to the running stack which forwards all IRP’s to
    the lower device (always using IoSkipCurrentIrpStackLocation() so I will not
    risk a NO_MORE_IRP_STACK_LOCATIONS bug check) except for
    IRP_MN_QUERY_PNP_DEVICE_STATE for which I set a completion routine that
    turns on the PNP_DEVICE_FAILED bit in the Information field of the iosb.
    After the filter is attached I will call IoInvalidateDeviceState() and this
    will eventually get the device to be surprise removed since the filter is
    going to turn on the PNP_DEVICE_FAILED bit.
  2. Somehow close all the open handles to the device stack (can anyone give
    me a clue about how this can be done?) and then request to remove the device
    using user mode API.

Can anyone suggest a new method or tell me why I should not use one of those
two?

Thanks,
Shahar

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

4

Mark,
First: I know we discussed similar cases before (how can I forget ?), but I
think this case is a bit different:
The only thing this “on the fly filter” does is participate in handling
*one* type of IRP which can be sent *only* by the plug and play manager.
Don’t you think this is possible?

Second: The first method I suggested is probably unsafe and I hope someone
here can give me a reason it is dangerous, but what do you think about the
second method? Is it possible? Can you suggest a way to implement it?

Thanks,
Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Wednesday, December 01, 2004 8:40 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Brutally removing a device

We have discussed similar nonsense here repeatedly, and the general
consensus is ‘do not do this’. On the fly filter drivers are currently not
part of the NT design parameters. As the inimitable Don Burn might say,
please let me know what product this functionality will be incorporated in
so that I may be sure to never have this product anywhere near any computer
I have to use.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Wednesday, December 01, 2004 12:30 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Brutally removing a device

Hi,
I’m looking for a way to remove a started device stack in which my driver is
not a member.
I thought about two options, but I’m not sure if any of them is legitimate
or safe:

  1. Attach a filter device to the running stack which forwards all IRP’s to
    the lower device (always using IoSkipCurrentIrpStackLocation() so I will not
    risk a NO_MORE_IRP_STACK_LOCATIONS bug check) except for
    IRP_MN_QUERY_PNP_DEVICE_STATE for which I set a completion routine that
    turns on the PNP_DEVICE_FAILED bit in the Information field of the iosb.
    After the filter is attached I will call IoInvalidateDeviceState() and this
    will eventually get the device to be surprise removed since the filter is
    going to turn on the PNP_DEVICE_FAILED bit.
  2. Somehow close all the open handles to the device stack (can anyone give
    me a clue about how this can be done?) and then request to remove the device
    using user mode API.

Can anyone suggest a new method or tell me why I should not use one of those
two?

Thanks,
Shahar

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

5

I meant to say that I will not use a stack location when handling all the
IRP’s *except* for IRP_MN_QUERY_PNP_DEVICE_STATE.
The bug check I mentioned will occur if the sender of the IRP allocated it
before I attached to the stack AND if all the devices in the device stack
also set a completion routine. My assumption is that the PnP Manager
allocates the IRP_MN_QUERY_PNP_DEVICE_STATE when IoInvalidateDeviceState()
is called (which is after I’m attached). I guess that one of the things I
need answered is if this assumption is correct.

Theoretically, I could just set the PNP_DEVICE_FAILED bit on the way down
and not set a completion routine even for this IRP. But since I’ve
encountered drivers that clear all the bits when they receive this IRP
(usbccgp.sys is the best example), I decided I must do this in a completion
routine.

Thanks,
Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
Sent: Wednesday, December 01, 2004 8:27 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Brutally removing a device

One thing that comes to mind: How do you plan to set a completion routine
without using a stack location?

Shahar Talmi wrote:

Hi,
I’m looking for a way to remove a started device stack in which my
driver is not a member.
I thought about two options, but I’m not sure if any of them is
legitimate or safe:

  1. Attach a filter device to the running stack which forwards all
    IRP’s to the lower device (always using
    IoSkipCurrentIrpStackLocation() so I will not risk a
    NO_MORE_IRP_STACK_LOCATIONS bug check) except for
    IRP_MN_QUERY_PNP_DEVICE_STATE for which I set a completion routine that
    turns on the PNP_DEVICE_FAILED bit in the Information field of the iosb.
    After the filter is attached I will call IoInvalidateDeviceState() and
    this will eventually get the device to be surprise removed since the
    filter is going to turn on the PNP_DEVICE_FAILED bit.
  2. Somehow close all the open handles to the device stack (can anyone
    give me a clue about how this can be done?) and then request to remove
    the device using user mode API.

Can anyone suggest a new method or tell me why I should not use one of
those two?

Thanks,
Shahar

–
…/ray..

Please remove “.spamblock” from my email address if you need to contact me
outside the newsgroup.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

6

I meant to say that I will not use a stack location when handling all the
IRP’s *except* for IRP_MN_QUERY_PNP_DEVICE_STATE.
The bug check I mentioned will occur if the sender of the IRP allocated it
before I attached to the stack AND if all the devices in the device stack
also set a completion routine. My assumption is that the PnP Manager
allocates the IRP_MN_QUERY_PNP_DEVICE_STATE when IoInvalidateDeviceState()
is called (which is after I’m attached). I guess that one of the things I
need answered is if this assumption is correct.

Theoretically, I could just set the PNP_DEVICE_FAILED bit on the way down
and not set a completion routine even for this IRP. But since I’ve
encountered drivers that clear all the bits when they receive this IRP
(usbccgp.sys is the best example), I decided I must do this in a completion
routine.

Thanks,
Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
Sent: Wednesday, December 01, 2004 8:27 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Brutally removing a device

One thing that comes to mind: How do you plan to set a completion routine
without using a stack location?

Shahar Talmi wrote:

Hi,
I’m looking for a way to remove a started device stack in which my
driver is not a member.
I thought about two options, but I’m not sure if any of them is
legitimate or safe:

  1. Attach a filter device to the running stack which forwards all
    IRP’s to the lower device (always using
    IoSkipCurrentIrpStackLocation() so I will not risk a
    NO_MORE_IRP_STACK_LOCATIONS bug check) except for
    IRP_MN_QUERY_PNP_DEVICE_STATE for which I set a completion routine that
    turns on the PNP_DEVICE_FAILED bit in the Information field of the iosb.
    After the filter is attached I will call IoInvalidateDeviceState() and
    this will eventually get the device to be surprise removed since the
    filter is going to turn on the PNP_DEVICE_FAILED bit.
  2. Somehow close all the open handles to the device stack (can anyone
    give me a clue about how this can be done?) and then request to remove
    the device using user mode API.

Can anyone suggest a new method or tell me why I should not use one of
those two?

Thanks,
Shahar

–
…/ray..

Please remove “.spamblock” from my email address if you need to contact me
outside the newsgroup.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

7

You can’t just sometimes not have a stack location. Either you have a stack
location or you don’t. But that is just one of the many issues with on the
fly filter drivers. Here is another one: how does your on the fly filter
driver coordinate its on the fly filtering with my on the fly filter driver?

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Wednesday, December 01, 2004 1:44 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Brutally removing a device

I meant to say that I will not use a stack location when handling all the
IRP’s *except* for IRP_MN_QUERY_PNP_DEVICE_STATE.
The bug check I mentioned will occur if the sender of the IRP allocated it
before I attached to the stack AND if all the devices in the device stack
also set a completion routine. My assumption is that the PnP Manager
allocates the IRP_MN_QUERY_PNP_DEVICE_STATE when IoInvalidateDeviceState()
is called (which is after I’m attached). I guess that one of the things I
need answered is if this assumption is correct.

Theoretically, I could just set the PNP_DEVICE_FAILED bit on the way down
and not set a completion routine even for this IRP. But since I’ve
encountered drivers that clear all the bits when they receive this IRP
(usbccgp.sys is the best example), I decided I must do this in a completion
routine.

Thanks,
Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ray Trent
Sent: Wednesday, December 01, 2004 8:27 PM
To: Windows System Software Devs Interest List
Subject: Re:[ntdev] Brutally removing a device

One thing that comes to mind: How do you plan to set a completion routine
without using a stack location?

Shahar Talmi wrote:

Hi,
I’m looking for a way to remove a started device stack in which my
driver is not a member.
I thought about two options, but I’m not sure if any of them is
legitimate or safe:

  1. Attach a filter device to the running stack which forwards all
    IRP’s to the lower device (always using
    IoSkipCurrentIrpStackLocation() so I will not risk a
    NO_MORE_IRP_STACK_LOCATIONS bug check) except for
    IRP_MN_QUERY_PNP_DEVICE_STATE for which I set a completion routine
    that
    turns on the PNP_DEVICE_FAILED bit in the Information field of the iosb.
    After the filter is attached I will call IoInvalidateDeviceState() and
    this will eventually get the device to be surprise removed since the
    filter is going to turn on the PNP_DEVICE_FAILED bit.
  2. Somehow close all the open handles to the device stack (can anyone
    give me a clue about how this can be done?) and then request to remove
    the device using user mode API.

Can anyone suggest a new method or tell me why I should not use one of
those two?

Thanks,
Shahar

–
…/ray..

Please remove “.spamblock” from my email address if you need to contact me
outside the newsgroup.

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

8

Even if it “normally” allocates the IRP on the fly, you can’t guarantee
that it will always do so. I doubt you can guarantee it now, but you
certainly can’t guarantee it for the future.

Also, among many other problems, you need to worry about race conditions
and other third party interactions. What if someone *else* sends an
IRP_MN_QUERY_PNP_DEVICE_STATE just before you attach (perhaps as a
result of calling IoInvalidateDeviceState)? Could you ever really be
sure the OS couldn’t allocate the Irp based on the stack that was
present just before you attached?

I will say that most of the usual complaints about on-the-fly filters
probably don’t really apply to a filter whose only purpose is to destroy
the device stack.

BTW, there probably isn’t any safe way to directly force all the open
handles to be closed.

What are you actually trying to accomplish here (i.e. why do you want to
do this)? It’s possible there’s some other way to do what you want. I’m
trying to imagine a scenario where I would think it was a good idea to
rip a device out from underneath someone that was actively using it, and
I’m struggling…

You might be able to use the user-mode APIs to disable the device (and,
as a result, tear down the driver stack), but I’m not sure what, if
anything, that will do if there are open handles. Try it with Device
Manager or devcon and see what happens.

Also, if it’s a particular device that you know you want to do this to
(for some reason related to the use of the device), you could always
just install yourself as a filter all the time and pass through
everything except when needed.

Shahar Talmi wrote:

Mark,
First: I know we discussed similar cases before (how can I forget ?), but I
think this case is a bit different:
The only thing this “on the fly filter” does is participate in handling
*one* type of IRP which can be sent *only* by the plug and play manager.
Don’t you think this is possible?

Second: The first method I suggested is probably unsafe and I hope someone
here can give me a reason it is dangerous, but what do you think about the
second method? Is it possible? Can you suggest a way to implement it?

Thanks,
Shahar

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Roddy, Mark
Sent: Wednesday, December 01, 2004 8:40 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Brutally removing a device

We have discussed similar nonsense here repeatedly, and the general
consensus is ‘do not do this’. On the fly filter drivers are currently not
part of the NT design parameters. As the inimitable Don Burn might say,
please let me know what product this functionality will be incorporated in
so that I may be sure to never have this product anywhere near any computer
I have to use.

=====================
Mark Roddy

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Shahar Talmi
Sent: Wednesday, December 01, 2004 12:30 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Brutally removing a device

Hi,
I’m looking for a way to remove a started device stack in which my driver is
not a member.
I thought about two options, but I’m not sure if any of them is legitimate
or safe:

  1. Attach a filter device to the running stack which forwards all IRP’s to
    the lower device (always using IoSkipCurrentIrpStackLocation() so I will not
    risk a NO_MORE_IRP_STACK_LOCATIONS bug check) except for
    IRP_MN_QUERY_PNP_DEVICE_STATE for which I set a completion routine that
    turns on the PNP_DEVICE_FAILED bit in the Information field of the iosb.
    After the filter is attached I will call IoInvalidateDeviceState() and this
    will eventually get the device to be surprise removed since the filter is
    going to turn on the PNP_DEVICE_FAILED bit.
  2. Somehow close all the open handles to the device stack (can anyone give
    me a clue about how this can be done?) and then request to remove the device
    using user mode API.

Can anyone suggest a new method or tell me why I should not use one of those
two?

Thanks,
Shahar

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256

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

–
…/ray..

Please remove “.spamblock” from my email address if you need to contact
me outside the newsgroup.