So a little more on this topic of my USB driver that failed Device Path Exerciser earlier because of some deadlock between handle open and close.
This is maybe more of a DTM question, but they’re taking a little more time than I’d like, so…
Again, this new situation is a USB composite device, with two interfaces, each interface has some bulk endpoints. usbccgp is loaded, giving two child devices. Same function driver loaded on each interface, and the function driver has already passed WHQL on a single interface device (no generic parent).
Inside EvtFileCreate() I’m starting up two continuous readers and in D0Exit() or EvtIoCleanup() I’m shutting them down. During the “10,000 open/close” test, I’ve seen up to 200ms for WdfIoTargetStop() to return. Of course this doesn’t bode well for 40,000 opens and closes. Sometimes the exerciser just gets hung up here and dies. Other times it doesn’t take too long, other times it takes an extremely long time and then fails.
I’m also getting (on XP only – not Vista) some failure at the very end of the entire test. Something about “the driver must be able to handle a query function where the input buffer is not big enough”. I only see this on XP and only while sitting on the generic parent. How can I find out what’s really going on? Any idea why it was introduced?
Also, one last question about speed. We have an older WDM USB PNP driver that just exposes some custom interfaces (it’s not part of any predefined setup class).
It did the entire Device Path Exerciser test in probably less than 30 seconds (and maybe 2 seconds for 10,000 open/close). Our KMDF driver takes hours to do it. Is there something inherently slower in KMDF with respect to this?
Inheritly, there is nothing in KMDf that should make this slower. You would need to run a profiler and see where the time is being spent. Is the same WDM driver doing the same synchronization on stopping i/o on close? Are the KMDF and WDM drivers functionally equivalent?
Once you get the results from the profiler, we can look at the results
d
Well, no, the WDM driver doesn’t do anything on open/close, compared to my KMDF driver which does a lot.
That explains that part, but there are other parts of Device Path Exerciser (where it calls ZwQueryInformation or whatever with bogus data) that are much slower as well. I’ll run the profiler as soon as I can.
One other thing. I got a crash dump from someone. My driver’s EvtClose routine starts off like this:
VOID EvtFileClose(IN WDFFILEOBJECT FileObject)
{
WDFDEVICE device = WdfFileObjectGetDevice(FileObject);
…
}
The last few frames of the stack backtrace look like this:
b4328414 b3dd5662 872752c8 00000005 00000000 Wdf01000!FxVerifierBugCheck+0x24
b4328440 b3dd883a 872752c8 00000000 00001018 Wdf01000!FxObjectHandleGetPtr+0x71
b432845c b409bb16 87275380 00000000 b4328498 Wdf01000!imp_WdfFileObjectGetDevice+0x21
b432846c b409ba92 00000000 b268dc95 b43284a0 mymodem!WdfFileObjectGetDevice+0x16 [c:\winddk\6000\inc\wdf\kmdf\10\wdffileobject.h @ 95]
b4328498 b3df1fd4 00000000 874f3488 8732a07c mymodem!EvtFileClose+0x32 [c:\mymodem\readwrit.c @ 96]
The KMDF documentation doesn’t say anything about that WDFFILEOBJECT ever being bad, so I was a little surprised. Any ideas? The device was not removed when this happened.
The modem stack has a bug in it where it sends the incorrect PFILE_OBJECT in the close irp (it rolls its own), so we don’t have a mapping from the WDM PFILE_OBJECT -> KMDF WDFFILEOBJECT
b4328498 b3df1fd4 >00000000< 874f3488 8732a07c mymodem!EvtFileClose+0x32 [c:\mymodem\readwrit.c @ 96]
^^^^^^^^
The handle is NULL b/c we don’t have the mapping
!wdflogdump on your driver will confirm what happens.
KMDF does have a workaround for this but we only apply it if we can determine you are a serial port, so you have to do the following during init
- set your device object type to FILE_DEVICE_SERIAL_PORT (WdfDeviceInitSetDeviceType)
- mark yourself as exclusive (WdfDeviceInitSetExclusive)
If you already has this, it would be good to send the output of !wdflogdump
d
At first I was going to say that I had both of those, but then realized I took out the exclusive call recently while trying something – and naturally, it never got put back. Thanks for the tip.