USB device surprise removal / remove device issue

Hi,

We have a WDM driver for a usb device. Consider the following scenario: An application is reading/ writing to the device continuously.The device is surprise removed and then inserted back in while the Writes continues, Surprise Remove device IRP appears but not the Remove device IRP. After the writes stop and the application exits, Remove device IRP appears which was probably missing earlier and the device gets deregistered. In a normal surprise remove case, the remove device irp gets invoked after the application handles get cleared. But in this case, the device has been inserted back in and the removal irp gets invoked wrongly. Similar scenario also occurs when multiple removal/insertions take place when the writes are happening. However, exactly one remove device IRP is invoked at the end of the writes cycle. (probably corresponding to the first surprise removal as described earlier).

This can be prevented at the application end by freeing all application handles on device removal and not attempting to write when the device is not present. But we need to make our device more robust and independent of what the application does.

Presently, we handle this anomaly by identifying this particular situation and simply complete the said IRP without doing any removal related processing. However, on enabling the Enhanced I/O option in the driver verifier, we get a bugcheck on reproducing the above scenario.

DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)

The IO manager has caught a misbehaving driver.

Arguments:

Arg1: 0000021d, (Fatal error) An IRP dispatch handler has not properly detached from the

stack below it upon receiving a remove IRP. (DeviceObject, Dispatch

Routine, and IRP specified.)

Arg2: af867c30

Arg3: 00000000

Arg4: 85668b28

What is the correct way to handle this scenario.

It is not your device that needs to be more robust, it is your device driver. There will be a 1:1 correspondence between the number of times you have plugged your device in and yanked it out and the number of surprise remove+remove irps you will get. It does not mean that the remove irp will always arrive before the device is reenumerated though. As long as your app has a handle open, the old instance of your driver stack will be in the surprise removed state. Once the last handle is closed, the device will receive the remove irp. When the device is plugged back in, you will create a new device object and you will have a new pnp state for that devobj. When the old surprise removed instance has its last handle closed, the remove irp will be sent to the last device object.

As long as you do not have global data/pointers to your device objects, this should just b/c these device objects do (nor should) not share state or data. If you have global pointers to your device objects, get rid of them.

d

-----Original Message-----
From: xxxxx@lists.osr.com [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@honeywell.com
Sent: Wednesday, December 17, 2008 2:48 AM
To: Windows System Software Devs Interest List
Subject: [ntdev] USB device surprise removal / remove device issue

Hi,

We have a WDM driver for a usb device. Consider the following scenario: An application is reading/ writing to the device continuously.The device is surprise removed and then inserted back in while the Writes continues, Surprise Remove device IRP appears but not the Remove device IRP. After the writes stop and the application exits, Remove device IRP appears which was probably missing earlier and the device gets deregistered. In a normal surprise remove case, the remove device irp gets invoked after the application handles get cleared. But in this case, the device has been inserted back in and the removal irp gets invoked wrongly. Similar scenario also occurs when multiple removal/insertions take place when the writes are happening. However, exactly one remove device IRP is invoked at the end of the writes cycle. (probably corresponding to the first surprise removal as described earlier).

This can be prevented at the application end by freeing all application handles on device removal and not attempting to write when the device is not present. But we need to make our device more robust and independent of what the application does.

Presently, we handle this anomaly by identifying this particular situation and simply complete the said IRP without doing any removal related processing. However, on enabling the Enhanced I/O option in the driver verifier, we get a bugcheck on reproducing the above scenario.

DRIVER_VERIFIER_IOMANAGER_VIOLATION (c9)

The IO manager has caught a misbehaving driver.

Arguments:

Arg1: 0000021d, (Fatal error) An IRP dispatch handler has not properly detached from the

stack below it upon receiving a remove IRP. (DeviceObject, Dispatch

Routine, and IRP specified.)

Arg2: af867c30

Arg3: 00000000

Arg4: 85668b28

What is the correct way to handle this scenario.


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