As part of my ongoing work towards making our USB device driver as robust as possible, I have been going through the shutdown and cleanup process and making sure that everything is done nicely. Found a minor problem with the help of driver verifier and all was well. On my test systems I can set it going transferring data and then just unplug the device and watch the driver get a few errors, then surprise removal causing a general clean up and shut down and finally remove unloading the device.
So I was very pleased with all that until I tested on Win7 - the test systems were W2K and XP. On Win7 everything works fine until I unplug the device while IO is in action and then !!bang!! the OS completely hangs with even the mouse pointer and keyboard dead. This happens in 32 and 64-bit systems, my main testbed is a toshiba satellite pro running on an i5 processor with the 64-bit OS.
So clearly something very nasty is happening but I am at my wits end trying to locate what and where - debug output does not show the key area of course. I can say:
- Driver verifier does not see anything
- Surprise removal when nothing is going on works fine
- Cancelling a pending IN or OUT IRP when not part of a surprise removal works fine
- The USB bus analyser shows nothing useful, just a completed normal transaction then nothing.
Does anybody have suggestions on how I can get any further or has information on what Win7 does differently with a surprise removal? Given the way that Windows freezes up, could this be a lower level driver\hardware issue?
windbg: !pnptriage
You should be able to reproduce this with a debugger attached.
Mark Roddy
On Thu, Jan 6, 2011 at 11:57 AM, wrote:
> As part of my ongoing work towards making our USB device driver as robust as possible, I have been going through the shutdown and cleanup process and making sure that everything is done nicely. Found a minor problem with the help of driver verifier and all was well. On my test systems I can set it going transferring data and then just unplug the device and watch the driver get a few errors, then surprise removal causing a general clean up and shut down and finally remove unloading the device.
>
> So I was very pleased with all that until I tested on Win7 - the test systems were W2K and XP. On Win7 everything works fine until I unplug the device while IO is in action and then !!bang!! the OS completely hangs with even the mouse pointer and keyboard dead. This happens in 32 and 64-bit systems, my main testbed is a toshiba satellite pro running on an i5 processor with the 64-bit OS.
>
> So clearly something very nasty is happening but I am at my wits end trying to locate what and where - debug output does not show the key area of course. I can say:
>
> 1. Driver verifier does not see anything
> 2. Surprise removal when nothing is going on works fine
> 3. Cancelling a pending IN or OUT IRP when not part of a surprise removal works fine
> 4. The USB bus analyser shows nothing useful, just a completed normal transaction then nothing.
>
> Does anybody have suggestions on how I can get any further or has information on what Win7 does differently with a surprise removal? Given the way that Windows freezes up, could this be a lower level driver\hardware issue?
>
> —
> 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
>
> You should be able to reproduce this with a debugger attached.
Even when the test system freezes absolutely? OK, I’ll give it a try.
Sigh … it was a stupid in my code
Basically, I was still holding the spinlock that I use to protect chars_from_device data in the device extension when I called IoCallDriver. In Windows 7 the Irp is completed immediately (synchronously) if the hardware has been removed so my completion routine got called, tried to get the spinlock … deadlock. I had assumed that IoCallDriver always just returns and the completion routine is never called directly - clearly MS have made a bit of an adjustment in Win7 so that missing hardware is dealt with faster.
Thank you Mark for pushing me to use WinDbg - I had assumed that it wouldn’t cope with a frozen system (and am a touch daunted by getting it set up for remote debug) - I should have known better.
Tim Bergel wrote:
Thank you Mark for pushing me to use WinDbg - I had
assumed that it wouldn’t cope with a frozen system (and
am a touch daunted by getting it set up for remote debug
The thing is, your system wasn’t frozen. It was in a tight loop at DISPATCH_LEVEL, so it *appeared* frozen, but it was still executing code. Windbg can break in under these circumstances.
> The thing is, your system wasn’t frozen. It was in a tight loop at DISPATCH_LEVEL, so it *appeared*
frozen, but it was still executing code. Windbg can break in under these circumstances.
You are, of course, correct but I expected that a system in that state would not show a frozen mouse pointer - I have got used to only something catastrophic killing that. Things change…
xxxxx@ced.co.uk wrote:
> The thing is, your system wasn’t frozen. It was in a tight loop at DISPATCH_LEVEL, so it *appeared*
> frozen, but it was still executing code. Windbg can break in under these circumstances.
You are, of course, correct but I expected that a system in that state would not show a frozen mouse pointer - I have got used to only something catastrophic killing that.
A PS/2 mouse is fairly resistant to that kind of lockup. All it needs
is a working interrupt. A USB mouse requires a lot more infrastructure,
and unfortunately is easily crunched.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
> You are, of course, correct but I expected that a system in that state would not show a frozen mouse
I had such on one of my machines ones, attaching WinDbg have shown that this is a DPC bug in the Ethernet chip driver.
Downgrading the driver to previous version solved the issue.
And yes, WinDbg can connect even if the mouse is frozen.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com