Driver unload problem

NTDEV
1

Hi all

I’m having some problems with a wdm driver for one of our USB devices not unloading. The problem is caused because we have introduced a “control device object” in much the same way as described http://support.microsoft.com/kb/262305

Now, if we plug the device in, open a handle to the control device object symbolic link from our app, do some ioctl stuff, close the handle and unplug the device then the driver unloads fine.

But if we unplug the device whilst the handle to the control device object is open, the device is suprise removed, then removed OK (I think…) but when we later close the handle the driver does not unload.

We haven’t any open handles to the device interface itself at this time.

I think the problem may be related to the sequence of deletion of the device object and control object. In the first case there isn’t an open handle to the control device object when the device removes so we delete the control device object during the device remove irp. The driver unloads fine. In the second case, this didn’t work and the driver doesn’t unload. I have tried different approaches and currently we wait until the control device object handle is closed before deleting it in the close irp. But this doesn’t work either!

In summary, the driver unload is not being triggered when we delete the control device object if the device has been removed earlier.

Any advice much appreciated.

Thanks

Sean

2

Oh…

http://blogs.msdn.com/b/usbcoreblog/archive/2009/10/06/why-doesn-t-my-driver-unload.aspx

Since a hybrid driver is also a pnp-driver, when the pnp-stack is removed as described above, the pnp manager will look to see if there is any dangling deviceobject. If the control-deviceobjects aren’t deleted prior to completing the remove request, there will be one or more dangling deviceobjects. As a result, the pnp manager will skip the attempt to unload the driver. This will lead to a wedged (stuck) driver in image. This driver cannot be ever unloaded again - even from usermode using SC. The reason for that is that SC doesn’t call unload if the driver is a pnp-driver. It figures out a driver is pnp or not by checking whether AddDevice routine is registered. This is one of the most common driver unload issues.

Sean

3

Make a control device a PnP child of the filtered devnode.

With KMDF, this is easy.

Then use PnP notifications in the app to close the handle to the control device.

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hi all
>
> I’m having some problems with a wdm driver for one of our USB devices not unloading. The problem is caused because we have introduced a “control device object” in much the same way as described http://support.microsoft.com/kb/262305
>
> Now, if we plug the device in, open a handle to the control device object symbolic link from our app, do some ioctl stuff, close the handle and unplug the device then the driver unloads fine.
>
> But if we unplug the device whilst the handle to the control device object is open, the device is suprise removed, then removed OK (I think…) but when we later close the handle the driver does not unload.
>
> We haven’t any open handles to the device interface itself at this time.
>
> I think the problem may be related to the sequence of deletion of the device object and control object. In the first case there isn’t an open handle to the control device object when the device removes so we delete the control device object during the device remove irp. The driver unloads fine. In the second case, this didn’t work and the driver doesn’t unload. I have tried different approaches and currently we wait until the control device object handle is closed before deleting it in the close irp. But this doesn’t work either!
>
> In summary, the driver unload is not being triggered when we delete the control device object if the device has been removed earlier.
>
> Any advice much appreciated.
>
> Thanks
>
> Sean
>
>
>
>
>

4

Hi Maxim

Thanks for the quick reply and advice. Is there any problem with using the remove lock system? This seems straightforward in a wdm, I could acquire a remove lock when I open the handle and release it when I close. The device remove would be sat waiting for the handle to close.

Thanks

Sean

5

>when I close. The device remove would be sat waiting for the handle to close.

…hanging the whole PnP manager during this (on pre-Vista at least).

–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com

6

In your application, register device notification handler for the control device HANDLE.
When your control device object gets IRP_MJ_PNP/IRP_MN_QUERY_DEVICE_RELATIONS/TargetRelations (that’s the only PNP IRP it may get), return a reference to the PNP stack PDO. When the device is unplugged or disabled, your application will get a notification; you should close the handle and deregister the notification. Your REMOVE_DEVICE handler should delete the control devobj before deleting the FDO.

Then everything will be OK.

7

That only works if you have one pnp device. You would have a premature close on the control devobj if pdo1 was removed and pdo2…N were still around.

d

dent from a phpne with no keynoard

-----Original Message-----
From: xxxxx@broadcom.com
Sent: September 04, 2010 3:35 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver unload problem

In your application, register device notification handler for the control device HANDLE.
When your control device object gets IRP_MJ_PNP/IRP_MN_QUERY_DEVICE_RELATIONS/TargetRelations (that’s the only PNP IRP it may get), return a reference to the PNP stack PDO. When the device is unplugged or disabled, your application will get a notification; you should close the handle and deregister the notification. Your REMOVE_DEVICE handler should delete the control devobj before deleting the FDO.

Then everything will be OK.

—
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

8

>That only works if you have one pnp device. You would have a premature close on
the control devobj if pdo1 was removed and pdo2…N were still around.

Then it should be a control devobj per FDO.

The OP doesn’t say what class the device is. If it’s a non-standard class, there is no point in having a separate control object.

9

Well, N control device objects defeats the whole purpose of a control devobj, no? now you have naming discovery problems, dealing with holes in the namespace, etc. usually you have just one CDO. If you have N CDOs, you might as well use a raw PDO for each stack and then you have none of these issues

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Saturday, September 04, 2010 4:40 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver unload problem

That only works if you have one pnp device. You would have a premature close on
the control devobj if pdo1 was removed and pdo2…N were still around.

Then it should be a control devobj per FDO.

The OP doesn’t say what class the device is. If it’s a non-standard class, there is no point in having a separate control object.

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

10

>N control device objects defeats the whole purpose of a control devobj,

no? now you have naming discovery problems, dealing with holes in the namespace,
etc.

Using just FDO with a device interface beats a CDO every day. More convenient, and with all discovery/arrival/removal problems solved.

11

Well, the whole reason to go down the CDO/raw PDO path is when the filter driver cannot be opened, so enabling a custom device interface on the filter does not make much sense in the situations when you can’t open the filter directly

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@broadcom.com
Sent: Sunday, September 05, 2010 4:27 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] Driver unload problem

N control device objects defeats the whole purpose of a control devobj,
no? now you have naming discovery problems, dealing with holes in the
namespace,
etc.

Using just FDO with a device interface beats a CDO every day. More convenient, and with all discovery/arrival/removal problems solved.

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