That’s good. I own both drivers, so “I believe” I can guarantee the
deadlock you describe can’t happen. Thank you for all the valuable
advice. Regards, MKE.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Wednesday, May 17, 2006 9:19 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interface removal
“A callback routine must not open the device directly”.
This is a very conservative statement made in the DDK to cover all
cases. It guards against the case that your create call results in a
new pnp action, resulting in a deadlock b/c the callback is invoked
while under a lock. In reality if you that this will not happen (either
b/c you own the driver you are opening or you know the semantics of the
interface provider), you can make the create call directly in the
callback.
If you are going to queue the work item, you would need to make a deep
copy of the PUNICODE_STRING.
d
– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Eschmann,
Michael K
Sent: Wednesday, May 17, 2006 8:47 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interface removal
I was looking at the DDK page titled “Handling Device Interface Change
Events”. It specifically says “A callback routine must not open the
device directly”. What alternatives do you suggest?
Peter W., I was concerned that just copying the
DEVICE_INTERFACE_CHANGE_NOTIFICATION contents would be a bad idea as one
of the structure variables is a PUNICODE_STRING. The string might go
away on me, but this would be dealt with by allocating my own
UNICODE_STRING buffer and copying the buffer…effectively cloning the
DEVICE_INTERFACE_CHANGE_NOTIFICATION structure that comes in to the
callback handler.
Thanks, MKE.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Tuesday, May 16, 2006 10:57 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interface removal
What DDK topic are you referring to about launching a work item? Is it
the one talking about deadlocks when sending a create in the
notification callback? If so, there are limited cases (opening
streaming or audio devices) in which this deadlock can occur, otherwise
you are just adding unneeded complexity in your driver by queueing the
work item. In between the queueing of the work item and it running, the
interface can go away.
d
– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Eschmann,
Michael K
Sent: Tuesday, May 16, 2006 8:33 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interface removal
The DDK says that in a registered callback for device interface change
that we could launch a worker thread, which makes me wonder what the
lifetime of the PDEVICE_INTERFACE_CHANGE_NOTIFICATION structure is.
Do I need to copy the structure before launching the worker thread and
then returning from the callback handler? Or can I assume the structure
will stick around for a while?
Thanks, MKE.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, May 15, 2006 2:17 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interface removal
There are 2 types of registrations that come into play here:
-
you register for the arrival and departure of the device interfaces
themselves. You can register for this once in your driver and leave it
until you unload. This does not tell you have about specific device
state on a handle.
-
you register for notifications on a specific device handle. You
register this to receive query remove/cancel remove/surprise remove
notifications on the stack. This is required to release a file handle
during query remove. you would register it for every file handle you
open.
d
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Eschmann,
Michael K
Sent: Monday, May 15, 2006 1:48 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interface removal
Thanks Doron,
I had considered doing exactly what you wrote, but was worried that I’d
be breaking some rule in WDM land. I don’t need the file object, so
should be just fine. I do plan on re-registering for the interface once
the private function call completes during a remove, that way if the
removed device shows up again the interface can re-start.
Thanks again, MKE.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Doron Holan
Sent: Monday, May 15, 2006 1:25 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interface removal
Yes, that is the what is happening. You can make this work, but you to
create your own plumbing for the remove path. Once you get the arrival
notification, you open up the target device, get the interface in
question and immediately close the device. Part of the interface that
you retrieve from the target will have an INPUT parameter where you pass
the target a function pointer. This function pointer is called by the
target when it processes the IRP_MN_REMOVE_DEVICE irp. In this
callback, you stop sending new i/o and wait for any sent i/o to
complete. After this callback returns, you must not send any new i/o or
reference the target in any fashion.
If the target requires a PFILE_OBJECT in all the I/O that you send, this
method will not work and you must stop all i/o to the target when the
target is query removed.
d
– I can spell, I just can’t type.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Eschmann,
Michael K
Sent: Monday, May 15, 2006 9:19 AM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device interface removal
Then why might I be seeing a cancel-remove when this driver interface is
up during the query-remove? Seems likely the remove is being rejected
during the query because one of the drivers has an open handle to the
other that was opened with a IoGetDeviceObjectPointer during the arrival
notification callback.
Thank you, MKE.
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Maxim S.
Shatskih
Sent: Monday, May 15, 2006 8:55 AM
To: Windows System Software Devs Interest List
Subject: Re: [ntdev] Device interface removal
tearing down the interface during a query remove. It appears that I
must remove the interface during a query remove,
No. You must remove it in surprise removal though. Note: there are 2
kinds of removes - one after surprise removal (most cleanup is already
done in surprise removal path), another is after query remove (all
cleanup is yet to be done).
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
xxxxx@storagecraft.com
http://www.storagecraft.com
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
To unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer
