Re: libusbk WDF_Violation (BSoD) if device removed during UsbK_SetCurrentAlternateSetting

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]
> 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