Problem in Surprice removal

[MS]

Hi All
here i'm working on USB camera device and an streaming application which can
capture Video data.
Now the problem is,while i'm running the streaming application and unplug
the usb cable(surprice removal) after sometime the system crashes.
i'm able to capture the surprise removal event in the driver.but how to
handle the driver while the application is still running.how do i do the
cleanup operation.
ie how do i close the application.

regards
raj

 

[Doron Holan [MS]]

you don't close the app. you cancel all i/o you have sent to the device and
fail all new incoming i/o that the app sends to you that requires you to
talk to the hardware. you would also fail all pended i/o that the
application sent with an approriate error code. you will stay in the
surprise removed state until the app closes the handle. the application can
register for file handle notifications on the handle and be notified that
the device has been surprise removed.

d

 

[fat_boy]

Your app can handle the WM_DEVICECHANGE message to get device events.

You are interested in the DBT_DEVICEARRIVAL and
DBT_DEVICEREMOVECOMPLETE.

Your app can register for device events at two levels:

1) DBT_DEVTYP_DEVICEINTERFACE

2) DBT_DEVTYP_HANDLE

If you have registered for DBT_DEVTYP_HANDLE, you will not get the
DBT_DEVICEREMOVECOMPLETE untill you unregister for DBT_DEVTYP_HANDLE.
So it is probably not worth registering for DBT_DEVTYP_HANDLE.

There is no surprise, and, if you have a USB device that does not show
in the safe remove dialog, you wont get the DBT_DEVICEQUERYREMOVE
message.


Alternatively, rather than registering for device events, your driver
can do is to return an invalid state (STATUS_INVALID)DEVICE_STATE or
some such) in response to an IRP_MJ_READ. But leave the driver
response to IRP_MJ_CLEANUP and IRP_MJ_CLOSE as STATUS_SUCCESS.

Then, when the app sees this invalid read return, it cancels all IO
requests, and closes the handle to your driver. Your driver unloads and
the system wont crash.


Becarefull aware of a Windows bug in the IO manager that sends Irps to
a driver after it had been unloaded. This was triggered by an
application sending a barrage of Irps while doing a CloseHandle() from
a different thread. We had to delay the return from the IRP_MJ_CLOSE
handler if the device was surprise removed to allow time for the IO
manager to flush its queues.