Device Interface - Bizarre bug

NTDEV
1

I have a bug with the device interface for a USB device driver I am
modifying. Unplugging the device and plugging it back in before closing all
open handles causes problems, the device interface is lost.

The flow of a test case which shows the bug and some of the events the
driver sees:
There is one physical instance of the device and it is plugged in. the
device interface is registered
PDO-FDO one allocated
A handle is opened with the device interface
The device is unplugged
IRP_MN_QUERY_DEVICE_RELATIONS
IRP_MN_QUERY_DEVICE_RELATIONS
IRP_MN_SURPRISE_REMOVAL
The device is plugged back in
New PDO-FDO two allocated, device interface registered
DeviceTree shows the driver object with two device objects
A second handle is opened with the device interface
The second handle is closed
IRP_MJ_CLEANUP
IRP_MJ_CLOSE
The first handle is closed
IRP_MJ_CLEANUP
IRP_MJ_CLOSE
IRP_MN_REMOVE_DEVICE - PDO-FDO one
Try to open a third handle -
Attempts to find the handle (SetupDiEnumDeviceInterfaces) fails with
ERROR_NO_MORE_ITEMS
DeviceTree shows the driver object with one device object

There is no (apparent) problem if the handles are closed when the device is
unplugged.

CREATE CLOSE and REMOVE_DEVICE all operate on the device object passed in.

Any suggestions on finding my bug.

2

I have had much the same problem with a driver I have that does not attache
to the device stack, but simply does an IoGetDeviceObjectPointer. What I
found was that there was no way that I could get notification that the
hardware had been removed, where as anything in the device stack was indeed
notified. This results in multiple devices in the stack and eventually a
BSOD, since if an app attached to the first instance the underlying DO’s
were no longer there.

I’m not that familiar with the USB stack but are you simply getting the DO
or attaching?

–
Gary G. Little

“Edward Dekker” wrote in message
news:xxxxx@ntdev…
>
>
> I have a bug with the device interface for a USB device driver I am
> modifying. Unplugging the device and plugging it back in before closing
> all open handles causes problems, the device interface is lost.
>
> The flow of a test case which shows the bug and some of the events the
> driver sees:
> There is one physical instance of the device and it is plugged in. the
> device interface is registered
> PDO-FDO one allocated
> A handle is opened with the device interface
> The device is unplugged
> IRP_MN_QUERY_DEVICE_RELATIONS
> IRP_MN_QUERY_DEVICE_RELATIONS
> IRP_MN_SURPRISE_REMOVAL
> The device is plugged back in
> New PDO-FDO two allocated, device interface registered
> DeviceTree shows the driver object with two device objects
> A second handle is opened with the device interface
> The second handle is closed
> IRP_MJ_CLEANUP
> IRP_MJ_CLOSE
> The first handle is closed
> IRP_MJ_CLEANUP
> IRP_MJ_CLOSE
> IRP_MN_REMOVE_DEVICE - PDO-FDO one
> Try to open a third handle -
> Attempts to find the handle (SetupDiEnumDeviceInterfaces) fails with
> ERROR_NO_MORE_ITEMS
> DeviceTree shows the driver object with one device object
>
> There is no (apparent) problem if the handles are closed when the device
> is unplugged.
>
> CREATE CLOSE and REMOVE_DEVICE all operate on the device object passed in.
>
> Any suggestions on finding my bug.
>
>

3

Are you setting the interface state to FALSE in surprise remove? If
not, that is the bug. I am guessing that you set the state to FALSE in
remove device. so when the 1st pdo is removed, you are setting the
state to FALSE which removes the interface from the list.

Remember that device interfaces use the device instance path + GUID as
the unique-ification of the instace. As such, you have to unregister
during surprise remove b/c that is the last time you know that you are a
uniquely identified device. The rules are

If gracefully removed (query removed -> remove), disable in
IRP_MN_REMOVE_DEVICE
If surprise removed, disable in surprise remove device.

Note that these are mutually exclusive. WMI deregistration follows the
same rules (at least if you use the PDO as the instance name) as well.

KMDF handles all of these rules for you BTW, you just register and
forget about it.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Edward Dekker
Sent: Tuesday, July 05, 2005 11:06 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device Interface - Bizarre bug

I have a bug with the device interface for a USB device driver I am
modifying. Unplugging the device and plugging it back in before closing
all
open handles causes problems, the device interface is lost.

The flow of a test case which shows the bug and some of the events the
driver sees:
There is one physical instance of the device and it is plugged
in. the
device interface is registered
PDO-FDO one allocated
A handle is opened with the device interface
The device is unplugged
IRP_MN_QUERY_DEVICE_RELATIONS
IRP_MN_QUERY_DEVICE_RELATIONS
IRP_MN_SURPRISE_REMOVAL
The device is plugged back in
New PDO-FDO two allocated, device interface registered
DeviceTree shows the driver object with two device
objects
A second handle is opened with the device interface
The second handle is closed
IRP_MJ_CLEANUP
IRP_MJ_CLOSE
The first handle is closed
IRP_MJ_CLEANUP
IRP_MJ_CLOSE
IRP_MN_REMOVE_DEVICE - PDO-FDO one
Try to open a third handle -
Attempts to find the handle
(SetupDiEnumDeviceInterfaces) fails with
ERROR_NO_MORE_ITEMS
DeviceTree shows the driver object with one device
object

There is no (apparent) problem if the handles are closed when the device
is
unplugged.

CREATE CLOSE and REMOVE_DEVICE all operate on the device object passed
in.

Any suggestions on finding my bug.

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

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

4

Thank you.

I was setting the interface state to false in remove device.

Ed

At 02:26 PM 7/5/2005, you wrote:

Are you setting the interface state to FALSE in surprise remove? If
not, that is the bug. I am guessing that you set the state to FALSE in
remove device. so when the 1st pdo is removed, you are setting the
state to FALSE which removes the interface from the list.

Remember that device interfaces use the device instance path + GUID as
the unique-ification of the instace. As such, you have to unregister
during surprise remove b/c that is the last time you know that you are a
uniquely identified device. The rules are

If gracefully removed (query removed -> remove), disable in
IRP_MN_REMOVE_DEVICE
If surprise removed, disable in surprise remove device.

Note that these are mutually exclusive. WMI deregistration follows the
same rules (at least if you use the PDO as the instance name) as well.

KMDF handles all of these rules for you BTW, you just register and
forget about it.

d

-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Edward Dekker
Sent: Tuesday, July 05, 2005 11:06 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] Device Interface - Bizarre bug

I have a bug with the device interface for a USB device driver I am
modifying. Unplugging the device and plugging it back in before closing
all
open handles causes problems, the device interface is lost.

The flow of a test case which shows the bug and some of the events the
driver sees:
There is one physical instance of the device and it is plugged
in. the
device interface is registered
PDO-FDO one allocated
A handle is opened with the device interface
The device is unplugged
IRP_MN_QUERY_DEVICE_RELATIONS
IRP_MN_QUERY_DEVICE_RELATIONS
IRP_MN_SURPRISE_REMOVAL
The device is plugged back in
New PDO-FDO two allocated, device interface registered
DeviceTree shows the driver object with two device
objects
A second handle is opened with the device interface
The second handle is closed
IRP_MJ_CLEANUP
IRP_MJ_CLOSE
The first handle is closed
IRP_MJ_CLEANUP
IRP_MJ_CLOSE
IRP_MN_REMOVE_DEVICE - PDO-FDO one
Try to open a third handle -
Attempts to find the handle
(SetupDiEnumDeviceInterfaces) fails with
ERROR_NO_MORE_ITEMS
DeviceTree shows the driver object with one device
object

There is no (apparent) problem if the handles are closed when the device
is
unplugged.

CREATE CLOSE and REMOVE_DEVICE all operate on the device object passed
in.

Any suggestions on finding my bug.

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

You are currently subscribed to ntdev as: xxxxx@windows.microsoft.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: unknown lmsubst tag argument: ‘’
To unsubscribe send a blank email to xxxxx@lists.osr.com