Hi All,
I am just curious about how does the surprise removal event
travel in the driver stack. From bottom up where the Bus driver will
notify the Fn driver of the event or the application will which has
opened the handle to my device will get the notification first.
Basicall who gets the event first??
Any help is appriciated.
The surprise removal irp travels down the stack to the PDO, it does not originate in the PDO. AFAIK, the order in which the driver stack is notified and the application is notified is not documented. You as the driver writer have to defensively code for both situations regardless (since the app can send i/o after it has been notified of the removal).
Are you curious or is there an underlying problem that you are trying to solve?
thx
d
Ajitabh Saxena wrote:
I am just curious about how does the surprise removal event
travel in the driver stack. From bottom up where the Bus driver will
notify the Fn driver of the event or the application will which has
opened the handle to my device will get the notification first.Basicall who gets the event first??
The details are kind of interesting. It’s Plug-n-Play’s job to handle
this. The bus driver notices that a device is gone, and calls
IoInvalidateDeviceRelations. This tells PnP that something has changed
in the bus and that it should ask about it. PnP then asks the bus to
enumerate its device relations. When it notices the list is different
from before, PnP will send the surprise removal notification down the stack.
Note that your app won’t get notified at all unless it has registered
for PnP callbacks. Your driver will stay in memory as a valid target
for I/O requests until the last handle is gone. It is your driver’s
responsibility to return some reasonable error to the application if it
makes such a request, and it is your application’s responsibility to
close the handle when it sees that reasonable error. That allows the
driver to finally and mercifully be removed.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
I have a controller on which there is active DMA going on. These
operations are started by the application using the private interface. I
want to be able to handle the IOCTL at the time the device is removed
and don’t do any invalid operation. I think that after this information
I will be fine.
One more question. On device removal once the device is deleted what
happens to the DeviceIoControl call that the application makes using a
‘stale’ handle???
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@Microsoft.com
Sent: Thursday, January 18, 2007 4:15 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Removal Notificaiton.
The surprise removal irp travels down the stack to the PDO, it does not
originate in the PDO. AFAIK, the order in which the driver stack is
notified and the application is notified is not documented. You as the
driver writer have to defensively code for both situations regardless
(since the app can send i/o after it has been notified of the removal).
Are you curious or is there an underlying problem that you are trying to
solve?
thx
d
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
You can’t close the window of having an invalid operation occur. Even if you know about the removal of the device before the application, there is a window where the hardware is gone and the underlying bus has not yet detected this or reported it to the PnP manager. You will have to be able to handle hw errors.
As long as the app has a handle open, your device will remain in the surprise removed state. In this state you should fail the IOCTLs which touch your hardware. When the app closes its handle, you will be put into the removed state. It is only in this state that you can delete your device. Since there are no open handles, there are no IOCTLs to deal with.
BTW, this is trivial to do in KMDF by setting up a power managed queue to handle your IOCTLs. The rest is done for you. In a WDM driver, you will be tracking a lot more state.
d
The device object cannot be deleted until all references to it are released, including the user-mode handle to the file object (which has a reference to the device object). Your driver will still receive the IRP_MJ_DEVICE_CONTROL requests from the user-mode app. The app is responsible for listening for device-removal notifications, and closing the handle when it is informed that the device under the handle has been removed.
Your driver will need to maintain some state (usually in the device extension), so that it knows when the device has been removed, so that it can immediately fail any new IRP_MJ_DEVICE_CONTROL (or IRP_MJ_READ, WRITE, etc.) requests.
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ajitabh Saxena
Sent: Friday, January 19, 2007 12:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Removal Notificaiton.
I have a controller on which there is active DMA going on. These
operations are started by the application using the private interface. I
want to be able to handle the IOCTL at the time the device is removed
and don’t do any invalid operation. I think that after this information
I will be fine.
One more question. On device removal once the device is deleted what
happens to the DeviceIoControl call that the application makes using a
‘stale’ handle???
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@Microsoft.com
Sent: Thursday, January 18, 2007 4:15 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Removal Notificaiton.
The surprise removal irp travels down the stack to the PDO, it does not
originate in the PDO. AFAIK, the order in which the driver stack is
notified and the application is notified is not documented. You as the
driver writer have to defensively code for both situations regardless
(since the app can send i/o after it has been notified of the removal).
Are you curious or is there an underlying problem that you are trying to
solve?
thx
d
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
The device object will never be deleted while an open file handle exists [unless you mean the app closed the handle before using it, in which case the call will fail as having an invalid handle]. Your driver remains loaded, and has to handle the I/O to the removed device (by failing it appropriately).
-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of Ajitabh Saxena
Sent: Friday, January 19, 2007 12:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Removal Notificaiton.
I have a controller on which there is active DMA going on. These
operations are started by the application using the private interface. I
want to be able to handle the IOCTL at the time the device is removed
and don’t do any invalid operation. I think that after this information
I will be fine.
One more question. On device removal once the device is deleted what
happens to the DeviceIoControl call that the application makes using a
‘stale’ handle???
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@Microsoft.com
Sent: Thursday, January 18, 2007 4:15 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Removal Notificaiton.
The surprise removal irp travels down the stack to the PDO, it does not
originate in the PDO. AFAIK, the order in which the driver stack is
notified and the application is notified is not documented. You as the
driver writer have to defensively code for both situations regardless
(since the app can send i/o after it has been notified of the removal).
Are you curious or is there an underlying problem that you are trying to
solve?
thx
d
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
Device removal won’t happen until all the handles to the device are
closed so it shouldn’t happen that you get requests trhough “stale
handles”
-p
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Ajitabh Saxena
Sent: Friday, January 19, 2007 12:13 PM
To: Windows System Software Devs Interest List
Subject: RE: [ntdev] Device Removal Notificaiton.
I have a controller on which there is active DMA going on. These
operations are started by the application using the private interface. I
want to be able to handle the IOCTL at the time the device is removed
and don’t do any invalid operation. I think that after this information
I will be fine.
One more question. On device removal once the device is deleted what
happens to the DeviceIoControl call that the application makes using a
‘stale’ handle???
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of
xxxxx@Microsoft.com
Sent: Thursday, January 18, 2007 4:15 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Device Removal Notificaiton.
The surprise removal irp travels down the stack to the PDO, it does not
originate in the PDO. AFAIK, the order in which the driver stack is
notified and the application is notified is not documented. You as the
driver writer have to defensively code for both situations regardless
(since the app can send i/o after it has been notified of the removal).
Are you curious or is there an underlying problem that you are trying to
solve?
thx
d
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