Prev: nonPNP sample driver won't install when running .exe
Next: wdk Vista mirror driver
From: BubbaGump on 5 Oct 2006 23:51
The documentation for IRP_MN_QUERY_REMOVE_DEVICE in the DDK mentions
that if a driver has an outstanding reference against itself from
IRP_MN_QUERY_INTERFACE that it should fail the query remove IRP. That
makes sense. So, some query interface reference count needs to be
checked before succeeding a query remove (except there's no need to
wait for it to drop to 0 like with a remove lock because it can't be
predicted how far into the future the interface reference would
finally be released).

Also, some mechanism needs to make query interface IRPs begin failing
after a query remove IRP handler has begun. Otherwise letting out an
interface reference would race with the query remove, an interface
reference could be let out afterwards, and then the device couldn't
later be removed as should be expected when a query remove succeeds.

The "toaster" sample does the first part but not the second. That's a
mistake, isn't it?


(also, this made me think what other sorts of operations should be
waited for in IRP_MN_REMOVE_DEVICE vs. IRP_MN_QUERY_REMOVE_DEVICE. Is
it that IRP_MN_REMOVE_DEVICE can wait for operations that take a short
period of time to finish and clean up while IRP_MN_QUERY_REMOVE_DEVICE
is for ones that would take so long that removal should simply be
canceled?)

From: BubbaGump on 6 Oct 2006 12:39
On Thu, 05 Oct 2006 23:51:36 -0400, BubbaGump <> wrote:

>(also, this made me think what other sorts of operations should be
>waited for in IRP_MN_REMOVE_DEVICE vs. IRP_MN_QUERY_REMOVE_DEVICE. Is
>it that IRP_MN_REMOVE_DEVICE can wait for operations that take a short
>period of time to finish and clean up while IRP_MN_QUERY_REMOVE_DEVICE
>is for ones that would take so long that removal should simply be
>canceled?)

By the way, what happens if an IRP_MN_SURPRISE_REMOVAL or subsequent
IRP_MN_REMOVE_DEVICE is sent while there's an outstanding reference
from a IRP_MN_QUERY_INTERFACE? Unlike with a query remove, a surprise
remove can't be failed, right? So what can the driver do besides hang
the IRP forever until its interface is finally released?

From: Don Burn on 6 Oct 2006 12:43
It can fail all the requests to the interface currently in progress and
issued in the future, it can not hold the SURPRISE_REMOVAL forever.


--
Don Burn (MVP, Windows DDK)
Windows 2k/XP/2k3 Filesystem and Driver Consulting
http://www.windrvr.com
Remove StopSpam from the email to reply



<BubbaGump> wrote in message
news:7b1di2hbqo4m05cp2qn4a7qc0rkgs54t9d(a)4ax.com...
> On Thu, 05 Oct 2006 23:51:36 -0400, BubbaGump <> wrote:
>
>>(also, this made me think what other sorts of operations should be
>>waited for in IRP_MN_REMOVE_DEVICE vs. IRP_MN_QUERY_REMOVE_DEVICE. Is
>>it that IRP_MN_REMOVE_DEVICE can wait for operations that take a short
>>period of time to finish and clean up while IRP_MN_QUERY_REMOVE_DEVICE
>>is for ones that would take so long that removal should simply be
>>canceled?)
>
> By the way, what happens if an IRP_MN_SURPRISE_REMOVAL or subsequent
> IRP_MN_REMOVE_DEVICE is sent while there's an outstanding reference
> from a IRP_MN_QUERY_INTERFACE? Unlike with a query remove, a surprise
> remove can't be failed, right? So what can the driver do besides hang
> the IRP forever until its interface is finally released?
>


From: BubbaGump on 6 Oct 2006 12:52
What about the REMOVE_DEVICE that follows the SURPRISE_REMOVAL? That
must be held forever until the interface is released, since it might
allow the unload of the code and data to which the interface refers.




On Fri, 6 Oct 2006 12:43:53 -0400, "Don Burn" <burn(a)stopspam.acm.org>
wrote:

>It can fail all the requests to the interface currently in progress and
>issued in the future, it can not hold the SURPRISE_REMOVAL forever.

From: BubbaGump on 6 Oct 2006 13:35
....forever...unless there's some way to notify whoever has references
to the interface to please release it?




On Fri, 06 Oct 2006 12:52:02 -0400, BubbaGump <> wrote:

>What about the REMOVE_DEVICE that follows the SURPRISE_REMOVAL? That
>must be held forever until the interface is released, since it might
>allow the unload of the code and data to which the interface refers.
>
>
>
>
>On Fri, 6 Oct 2006 12:43:53 -0400, "Don Burn" <burn(a)stopspam.acm.org>
>wrote:
>
>>It can fail all the requests to the interface currently in progress and
>>issued in the future, it can not hold the SURPRISE_REMOVAL forever.

 |  Next  |  Last
Pages: 1 2 3
Prev: nonPNP sample driver won't install when running .exe
Next: wdk Vista mirror driver