Tracking down who's holding a reference to our driver's USB FDO and preventing its removal.

[i_like_gkc]

I have a customer using our USB functional driver on their Windows 7 SP1 (32-bit) platform and their USB is experiencing a lot of disruptions. The URB's from our driver complete with errors and finally we get PNP IRP_MN_SURPRISE_REMOVAL for our USB FDO (call it FDO-A) . That's okay, the driver is designed to recover from USB disconnects / reconnects. Usually when we receive the surprise removal it is followed immediately by IRP_MN_REMOVE_DEVICE. But in one particular situation, the driver unloads and reloads, another USB disconnect happens and we receive the surprise removal but instead of next receiving IRP_MN_REMOVE_DEVICE, we receive START_DEVICE for the very same device. I thought you would have to receive IRP_MN_REMOVE_DEVICE before you would ever get another START_DEVICE but Microsoft tells me this could happen if there is still an outstanding reference to FDO-A. As it turns out, eventually after several more USB disconnect/reconnect cycles we finally receive the IRP_MN_REMOVE_DEVICE for FDO-A some 12 minutes later. But this causes big problems for our driver which was not designed to handle a situation like that and we end up referencing a stale data structure and blue-screening.

I'm hoping somebody could help me come up with some way to determine who/what is holding a reference to FDO-A. I have the crashdump. Is there anyway I could track it down from that? Perhaps at that point it is too late. The customer has McAfee installed on their platform and I'm wondering if it could be the culprit. Needless to say, our driver needs to eventually be re-written to properly handle this anamoly but for the time being I'm hoping to track down who's holding that reference and perhaps that can be addressed as a work-around.


Tim

Continue reading...