I have a KMDF USB driver that has been working fine for a long time but now has been causing some issues. The driver handles communication between a windows xp system and an add-on card with a cypress microcontroller via USB. This driver is being used on 24+ systems with a similar hardware setup.
After anywhere from several hours to a day, random systems will have the driver lockup. The system still responds but the driver no longer responds to any IOCTL requests and the application that last made a request cannot be closed no matter what I do (indicative that a request never got completed). I added a large number of trace logging messages and found that it would get stuck in seemingly random locations directly before the WdfRequestComplete. Sometimes it hangs in different callbacks but usually before some form of request complete line.
The fact that it’s hanging in random locations is making me think that another driver could somehow be corrupting the memory of this driver. We have some other hardware using a driver at the same time. We recently updated the code that is using that second driver and the frequency of hangs went way up. So I’m thinking there’s a good chance the other driver is somehow related.
Here is my relevant driver code and a few logs from before the hang. It should be noted that the system running this driver has no serial port, no firewire, and I don’t have a usb debugging dongle. So I don’t have a good way to do remote kernel debugging.
Code:
http://pastebin.com/ZRXPURRF
Logs, scroll to the bottom:
http://pastebin.com/B8Dp1gD6
http://pastebin.com/79JdtVQh
http://pastebin.com/fMBFPgPw
http://pastebin.com/mjSeeiTq
xxxxx@intel.com wrote:
I have a KMDF USB driver that has been working fine for a long time but now has been causing some issues.
…
After anywhere from several hours to a day, random systems will have the driver lockup.
…
The fact that it’s hanging in random locations is making me think that another driver could somehow be corrupting the memory of this driver. We have some other hardware using a driver at the same time. We recently updated the code that is using that second driver and the frequency of hangs went way up. So I’m thinking there’s a good chance the other driver is somehow related.
Is that second driver a filter driver in your stack? Memory corruption
is not usually as consistent as this. This looks like some driver
further up the stack is blocking things.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
The second driver is a UMDF driver built to work with the WinUSB.sys driver. I don’t believe it is a filter driver. What would be the best way for me to get more information about the stack without remote kernel debugging?
Why can’t you attach a kernel debugger? Otherwise, take a full kernel dump. Or a full dump if you want to capture umdf state
d
debt from my phone
From: xxxxx@intel.com
Sent: 11/5/2012 3:44 PM
To: Windows System Software Devs Interest List
Subject: RE:[ntdev] KMDF USB driver randomly hanging when completing requests
The second driver is a UMDF driver built to work with the WinUSB.sys driver. I don’t believe it is a filter driver. What would be the best way for me to get more information about the stack without remote kernel debugging?
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
I have to have a serial/firewire connection to remote kernel debug. The best I can do on this system is use something like sysinternals NotMyFault to force a bugcheck and dump kernel memory. If I have a kernel memory dump, what would I need to do to see if another driver is blocking things? Would a WdfLogDump be sufficient?
wrote in message news:xxxxx@ntdev…
> I have to have a serial/firewire connection to remote kernel debug. The
> best I can do on this system is use something like sysinternals NotMyFault
> to force a bugcheck and dump kernel memory. If I have a kernel memory
> dump, what would I need to do to see if another driver is blocking things?
> Would a WdfLogDump be sufficient?
>
This is how crash dump can be obtained:
http://msdn.microsoft.com/en-us/library/ff545499.aspx
A common problem with these USB cables is, when it gets surprise-removed
(because of ESD, or the target resets, or whatever) the host app
does not correctly handle this and reconnect to the new instance.
– pa