Re: libusbk WDF_Violation (BSoD) if device removed during UsbK_SetCurrentAlternateSetting
Travis <[email protected]>
| Newsgroups | gmane.comp.lib.libusb.devel.windows |
|---|---|
| Message-ID | <[email protected]> |
Use kList to dump your descriptor information and post that as well. Regards, Travis On 4/11/2014 6:16 PM, Matt Liberty wrote: > Travis, > > I looked back through the email list and saw Ekkahard's posts. My > problem does seem similar, but slightly different. The root cause may > very well be the same. I quickly tried adding a Sleep(x) statement > after shutting down the ISO streaming but before calling > UsbK_SetCurrentAlternateSetting. As I mentioned in the previous > email, my PC takes 500 ms calling UsbK_SetCurrentAlternateSetting. I > am not sure why my PC (a Dell Precision M4600) takes so long. With a > Sleep(500) statement, the time inside the call to > UsbK_SetCurrentAlternateSetting is reduced from 500 ms to only 80 to > 95 ms. This change also makes producing the WDF_Violation more > difficult, but it still occurs. I hypothesize that the reduced amount > of time in calling UsbK_SetCurrentAlternateSetting resulted in the > reduced probability of catching my test in a > UsbK_SetCurrentAlternateSetting when I unplugged the device, but the > underlying cause was unchanged. I am out of time for tonight, but I > will investigate more tomorrow. I will try to strip down my example > to the bare essentials so that I can better isolate the problem and > share source code. If you think of anything that I can try to help > isolate the problem, please let me know. > > Thanks for your quick reply! > > - Matt > > -- > Matthew Liberty > President > Jetperch LLC > 202.681.7801 | [email protected] <mailto:[email protected]> > http://www.jetperch.com/ > > > On Fri, Apr 11, 2014 at 7:37 PM, Travis <[email protected] > <mailto:[email protected]>> wrote: > > Thanks for the support! > > I think Ekkehard had a similar problem after stopping an ISO > stream. If > I remember correctly, adding some delay after stopping the ISO stream > solved the problem. Give this a try and let me know if it works then > perhaps we can come up with a more elegant solution. > > Some part's of the BSOD report don't add up but that's not all that > uncommon. I don't see how it could be a "framework object handle > of the > incorrect type". The value comes directly from > "WdfUsbTargetPipeGetIoTarget". IE: > WdfIoTargetStart(WdfUsbTargetPipeGetIoTarget(PipeContext->Pipe)) > > According to the report, checking the handle value wouldn't do any > good > because it it non null (00001ffff49bafd8). > > I will see if I can reproduce it this weekend as I already have some > libusbK time set aside. > > Regards, > Travis > > On 4/11/2014 3:31 PM, Matt Liberty wrote: > > Greetings, > > > > First, thanks for creating the excellent libusbk driver and library. > > I have been successfully using libusbk to convey bulk and > isochronous > > data, and it works great! The fact that I have gone from > nothing to a > > working USB device without joining this list earlier is a > testament to > > the solid design, good documentation and great examples. > > > > I think that I may have stumbled onto a corner case when the > alternate > > interface setting is changing while the device is being removed. I > > have noticed that my PC can take up to 500 milliseconds to perform > > UsbK_SetCurrentAlternateSetting just after stopping isochronous data > > streaming. Some PCs are much faster, like 20 milliseconds. If the > > device is removed during the user-space call to > > UsbK_SetCurrentAlternateSetting, I usually get a WDF_violation on > > Windows 8 & 8.1, and a Blue Screen of Death on Windows 7. The > output > > from WinDbg is attached below. > > > > Should libusbk.sys be validating the handle before calling > > imp_WdfIoTargetStart? This seems like a dangerous race > condition that > > should be handled by Windows, but I have never done Windows driver > > development before. Any recommendations on how I can address > this issue? > > > > Thanks! I also saw your request for donations, and I am happy > to add > > $100 to support libusbk. > > > > - Matt > > > > > > > ******************************************************************************* > > * * > > * Bugcheck Analysis * > > * * > > > ******************************************************************************* > > > > Use !analyze -v to get detailed debugging information. > > > > BugCheck 10D, {5, 1ffff49bafd8, 1200, ffffe0000b253e20} > > > > Probably caused by : libusbK.sys ( libusbK!Pipe_InitContext+cb ) > > > > Followup: MachineOwner > > --------- > > > > 2: kd> !analyze -v > > > ******************************************************************************* > > * * > > * Bugcheck Analysis * > > * * > > > ******************************************************************************* > > > > WDF_VIOLATION (10d) > > The Kernel-Mode Driver Framework was notified that Windows > detected an > > error > > in a framework-based driver. In general, the dump file will yield > > additional > > information about the driver that caused this bug check. > > Arguments: > > Arg1: 0000000000000005, A framework object handle of the incorrect > > type was passed to > > a framework object method. > > Arg2: 00001ffff49bafd8, The handle value passed in. > > Arg3: 0000000000001200, Reserved. > > Arg4: ffffe0000b253e20, Reserved. > > > > Debugging Details: > > ------------------ > > > > > > BUGCHECK_STR: 0x10D_5 > > > > CUSTOMER_CRASH_COUNT: 1 > > > > DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT > > > > PROCESS_NAME: stream.exe > > > > CURRENT_IRQL: 0 > > > > ANALYSIS_VERSION: 6.3.9600.17029 (debuggers(dbg).140219-1702) > amd64fre > > > > LAST_CONTROL_TRANSFER: from fffff80000358caa to fffff802eeb52ca0 > > > > STACK_TEXT: > > ffffd000`3a4d91b8 fffff800`00358caa : 00000000`0000010d > > 00000000`00000005 00001fff`f49bafd8 00000000`00001200 : > nt!KeBugCheckEx > > ffffd000`3a4d91c0 fffff800`0032b673 : ffffe000`0b645020 > > ffffe000`0ba742f0 00001fff`f49bafd8 fffff800`0036f8d5 : > > Wdf01000!FxVerifierBugCheck+0x1e > > ffffd000`3a4d9200 fffff800`00361039 : 00001fff`f49bafd8 > > 00001fff`ff560458 00000000`7562696c fffff800`00366aef : > > Wdf01000!FxObjectHandleGetPtrQI+0x3c927 > > ffffd000`3a4d9270 fffff800`041c310b : ffffd000`3a4d9350 > > ffffe000`0b250000 00000000`00000000 00000000`00000001 : > > Wdf01000!imp_WdfIoTargetStart+0x6a > > ffffd000`3a4d92b0 fffff800`041c1d47 : 00000000`c0000000 > > 00000000`00000000 ffffe000`0ba74b30 ffffe000`0ba742f0 : > > libusbK!Pipe_InitContext+0xcb > > > [z:\svnmain\googlecode\usb-travis\trunk\libusbk\src\sys\drv_pipe.c > @ 432] > > ffffd000`3a4d92e0 fffff800`041c213a : 00000000`c000000e > > ffffe000`0ba742f0 ffffe000`0ba742f0 ffffd000`3a4d93f0 : > > libusbK!Interface_Start+0x37 > > > [z:\svnmain\googlecode\usb-travis\trunk\libusbk\src\sys\drv_interface.c > @ > > 86] > > ffffd000`3a4d9310 fffff800`041c689b : 00000000`00000000 > > ffffe000`0ba742f0 00000000`00000000 00001fff`f458bff8 : > > libusbK!Interface_SetAltSetting+0x24e > > > [z:\svnmain\googlecode\usb-travis\trunk\libusbk\src\sys\drv_interface.c > @ > > 232] > > ffffd000`3a4d93b0 fffff800`002e59ce : ffffe000`0b2c3cd0 > > ffffe000`00b55c20 00000000`00000018 00001fff`f4d3c328 : > > libusbK!DefaultQueue_OnIoControl+0x13a3 > > > [z:\svnmain\googlecode\usb-travis\trunk\libusbk\src\sys\drv_queue_default.c > > @ 376] > > ffffd000`3a4d9460 fffff800`002e5123 : ffffc000`1b3f2800 > > ffffe000`0ba69880 00000000`00000300 00000000`00000001 : > > Wdf01000!FxIoQueue::DispatchRequestToDriver+0x1be > > ffffd000`3a4d9530 fffff800`002ec2f2 : ffffe000`00b55c20 > > ffffd000`3a4d9600 00000000`00000000 ffffe000`00b55c01 : > > Wdf01000!FxIoQueue::DispatchEvents+0x363 > > ffffd000`3a4d95f0 fffff800`002ec658 : 00000000`00000001 > > ffffe000`04ed5660 00000000`00000000 ffffe000`0b4e0000 : > > Wdf01000!FxPkgIo::EnqueueRequest+0x252 > > ffffd000`3a4d96c0 fffff800`041c2c30 : ffffe000`0b2c3e70 > > ffffe000`0ba74000 00000000`00000000 ffffe000`0b2c3cd0 : > > Wdf01000!imp_WdfDeviceEnqueueRequest+0xc9 > > ffffd000`3a4d9720 fffff800`002e99bd : 00000000`00000001 > > 00001fff`f4d3c328 ffffe000`046aa240 00000000`00000018 : > > libusbK!Request_PreIoInitialize+0x130 > > > [z:\svnmain\googlecode\usb-travis\trunk\libusbk\src\sys\drv_request.c > > @ 304] > > ffffd000`3a4d9790 fffff802`eedb03e5 : 00000000`00000000 > > ffffd000`3a4d9b01 ffffe000`0ba74001 fffff802`00000001 : > > Wdf01000!FxDevice::DispatchWithLock+0x77d > > ffffd000`3a4d9870 fffff802`eedb0d7a : ffffd000`3a4d9a38 > > 00000000`0000005f 00000000`00000000 000000f7`2fe0ec88 : > > nt!IopXxxControlFile+0x845 > > ffffd000`3a4d9a20 fffff802`eeb5e4b3 : ffffe000`0ba69880 > > 00000000`001f0003 000000f7`2fe0eb48 00000000`00000000 : > > nt!NtDeviceIoControlFile+0x56 > > ffffd000`3a4d9a90 00007ffb`182665ea : 00000000`00000000 > > 00000000`00000000 00000000`00000000 00000000`00000000 : > > nt!KiSystemServiceCopyEnd+0x13 > > 000000f7`2fe0eab8 00000000`00000000 : 00000000`00000000 > > 00000000`00000000 00000000`00000000 00000000`00000000 : > > 0x00007ffb`182665ea > > > > > > STACK_COMMAND: kb > > > > FOLLOWUP_IP: > > libusbK!Pipe_InitContext+cb > > > [z:\svnmain\googlecode\usb-travis\trunk\libusbk\src\sys\drv_pipe.c > @ 432] > > fffff800`041c310b 8bf8 mov edi,eax > > > > FAULTING_SOURCE_LINE: > > z:\svnmain\googlecode\usb-travis\trunk\libusbk\src\sys\drv_pipe.c > > > > FAULTING_SOURCE_FILE: > > z:\svnmain\googlecode\usb-travis\trunk\libusbk\src\sys\drv_pipe.c > > > > FAULTING_SOURCE_LINE_NUMBER: 432 > > > > FAULTING_SOURCE_CODE: > > No source found for > > 'z:\svnmain\googlecode\usb-travis\trunk\libusbk\src\sys\drv_pipe.c' > > > > > > SYMBOL_STACK_INDEX: 4 > > > > SYMBOL_NAME: libusbK!Pipe_InitContext+cb > > > > FOLLOWUP_NAME: MachineOwner > > > > MODULE_NAME: libusbK > > > > IMAGE_NAME: libusbK.sys > > > > DEBUG_FLR_IMAGE_TIMESTAMP: 5207c443 > > > > IMAGE_VERSION: 3.0.6.0 > > > > BUCKET_ID_FUNC_OFFSET: cb > > > > FAILURE_BUCKET_ID: 0x10D_5_libusbK!Pipe_InitContext > > > > BUCKET_ID: 0x10D_5_libusbK!Pipe_InitContext > > > > ANALYSIS_SOURCE: KM > > > > FAILURE_ID_HASH_STRING: km:0x10d_5_libusbk!pipe_initcontext > > > > FAILURE_ID_HASH: {fbb003e7-b70a-0bc3-4274-781915951631} > > > > Followup: MachineOwner > > --------- > > > > > > > > > ------------------------------------------------------------------------------ > > Put Bad Developers to Shame > > Dominate Development with Jenkins Continuous Integration > > Continuously Automate Build, Test & Deployment > > Start a new project now. Try Jenkins in the cloud. > > http://p.sf.net/sfu/13600_Cloudbees > > > > > > _______________________________________________ > > Libusb-win32-devel mailing list > > [email protected] > <mailto:[email protected]> > > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Libusb-win32-devel mailing list > [email protected] > <mailto:[email protected]> > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel > > > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > > > _______________________________________________ > Libusb-win32-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel ------------------------------------------------------------------------------ Put Bad Developers to Shame Dominate Development with Jenkins Continuous Integration Continuously Automate Build, Test & Deployment Start a new project now. Try Jenkins in the cloud. http://p.sf.net/sfu/13600_Cloudbees