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

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]
http://www.jetperch.com/


On Fri, Apr 11, 2014 at 7:37 PM, Travis <[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]
> > 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

_______________________________________________
Libusb-win32-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libusb-win32-devel