I have a USB gizmo, and I’m trying to beat out the assorted PnP and power
transitions. Pretty much it seems to be working, except for the case where
the user pulls the plug while the device is open by the application.
When I pull the plug, I see a transition from Working to SurpriseRemoval.
The outstanding IOs and the like get cleaned up, the remove lock gets
decremented back to 0, and I see StopDevice get called and exited. Next I
see an IRP_MJ_CLEANUP. And that is it. I never finish device removal or
driver removal.
Am I supposed to be doing something useful in the cleanup routine to push
device removal along? The docs seem to indicate that I should be canceling
and completing IOs here, but that happened long before and there is nothing
to deal with here.
Any suggestions on what I might have screwed up?
Loren
Most likely you have an open handle to a device object. Do you have a test
app that holds your gizmo device open?
-----Original Message-----
From: xxxxx@lists.osr.com
[mailto:xxxxx@lists.osr.com] On Behalf Of Loren Wilton
Sent: Monday, December 08, 2003 9:26 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] Surprise removal while device in use
I have a USB gizmo, and I’m trying to beat out the assorted
PnP and power transitions. Pretty much it seems to be
working, except for the case where the user pulls the plug
while the device is open by the application.
When I pull the plug, I see a transition from Working to
SurpriseRemoval.
The outstanding IOs and the like get cleaned up, the remove
lock gets decremented back to 0, and I see StopDevice get
called and exited. Next I see an IRP_MJ_CLEANUP. And that
is it. I never finish device removal or driver removal.
Am I supposed to be doing something useful in the cleanup
routine to push device removal along? The docs seem to
indicate that I should be canceling and completing IOs here,
but that happened long before and there is nothing to deal with here.
Any suggestions on what I might have screwed up?
Loren
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as:
xxxxx@hollistech.com To unsubscribe send a blank email to
xxxxx@lists.osr.com
> Most likely you have an open handle to a device object. Do you have a test
app that holds your gizmo device open?
Yes I do. But even closing the app doesn’t result in device removal if I
pull the plug on the USB device before the app is closed. And as I read
IPR_MJ_CLEANUP, it seem this should be being sent to me pretty much as the
last action in close as the handle is being invalidated.
The physical device at the lower USB layers seems to get freed up though,
since plugging it in later creates a second instance of my device from my
driver. However, the first device instance is still there, even though it
should have long since gone away.
Loren
We had similar problems and if memory serves, you need to look at using
remove locks (IoAcquireRemoveLock etc.)
Walter Oneys book, Programming the Windows Driver Model has a section on the
subject…
Duncan
-----Original Message-----
From: Loren Wilton [mailto:xxxxx@earthlink.net]
Sent: 10 December 2003 01:51
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: Surprise removal while device in use
> Most likely you have an open handle to a device object. Do
you have a test
> app that holds your gizmo device open?
Yes I do. But even closing the app doesn’t result in device
removal if I
pull the plug on the USB device before the app is closed.
And as I read
IPR_MJ_CLEANUP, it seem this should be being sent to me
pretty much as the
last action in close as the handle is being invalidated.
The physical device at the lower USB layers seems to get
freed up though,
since plugging it in later creates a second instance of my
device from my
driver. However, the first device instance is still there,
even though it
should have long since gone away.
Loren
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@des.co.uk
To unsubscribe send a blank email to xxxxx@lists.osr.com
when i get suprise removed, i do the following
1)? fail all outstanding pended io (that was sent from above)
2)? fail any io that is currently being processed / non cancelable (could be at a later time)?
3)? kill the lower edge io
4)? fail any new io, but allow cleanup and close to come through.? complete these successfully
?
the remove will not come until all handles are closed.? you will get the cleanup when the app closes the handle or is terminated, at this time it is when you should complete all io associated with that handle (the io subsystem will not cancel the request on behalf of the app).? you will only get the close when all io has finished and all references to the handle have closed.
?
one way to debug this is with !process 0.? find your process and rerun !process 7.?? this will show you all threads in the process; i would bet one is stuck in the rundown code somewhere.
?
D
This posting is provided “AS IS” with no warranties, and confers no rights
?
________________________________________
From: Loren Wilton
Sent: Tue 12/9/2003 5:50 PM
To: Windows System Software Devs Interest List
Subject: [ntdev] RE: Surprise removal while device in use
> Most likely you have an open handle to a device object. Do you have a test
> app that holds your gizmo device open?
Yes I do. But even closing the app doesn’t result in device removal if I
pull the plug on the USB device before the app is closed. And as I read
IPR_MJ_CLEANUP, it seem this should be being sent to me pretty much as the
last action in close as the handle is being invalidated.
The physical device at the lower USB layers seems to get freed up though,
since plugging it in later creates a second instance of my device from my
driver. However, the first device instance is still there, even though it
should have long since gone away.
Loren
—
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
>> Most likely you have an open handle to a device object. Do you have a test
> app that holds your gizmo device open?
Yes I do. But even closing the app doesn’t result in device removal if I
pull the plug on the USB device before the app is closed. And as I read
IPR_MJ_CLEANUP, it seem this should be being sent to me pretty much as the
last action in close as the handle is being invalidated.
The physical device at the lower USB layers seems to get freed up though,
since plugging it in later creates a second instance of my device from my
driver. However, the first device instance is still there, even though it
should have long since gone away.
Is it possible that there is still an outstanding IRP being held
somewhere that is escaping completion? IRP_MJ_CLOSE will not be called
while any outstanding IRP’s exist.
Rob
xxxxx@telusplanet.net
>one way to debug this is with !process 0. find your process and rerun
!process 7. this will show you all threads in the process; i would
bet one is stuck in the rundown code somewhere.
Thanks. Yes, this indeed turned out to be the problem. Fell into a small
timing hole that I still don’t understand in the driver, but I came up with
a band-aid solution that will work until I have time to rework that part of
the driver and do things right. Took me a while to find it, because there
was code to make that particular IO go away in exactly this case, but it
seems that code isn’t working the way it should for some reason.
Ah well. Now that I’ve replaced all of the power and PnP code with Walter’s
stuff instead of the original totally broken code and have the driver back
to basically working again, I can get time to clean up a lot of the other
messes in the original code.
Loren
> Is it possible that there is still an outstanding IRP being held
somewhere that is escaping completion? IRP_MJ_CLOSE will not be called
while any outstanding IRP’s exist.
Thanks, yup, that turned out to be the case. The code to make that
particular IO go away seems to have a timing hole. Kludged around it until
I can get the time to rewrite that entire area.
Loren