libusbk WDF_Violation (BSoD) if device removed during UsbK_SetCurrentAlternateSetting

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