mcuee / libusbk Goto Github PK

libusbk official github repo

C 65.89% C++ 14.15% Assembly 0.76% Makefile 1.74% Clojure 0.04% C# 5.61% Pascal 1.37% Boo 1.85% HTML 0.07% CSS 0.72% Batchfile 2.39% Visual Basic .NET 5.11% M4 0.21% Inno Setup 0.04% NSIS 0.06%

libusbk libusb libusb-win32 usb windows driver winusb

libusbk's Introduction

libusbK Overview

libusbK is a complete driver/library solution for vendor class usb device interfaces. If you are a usb developers or usb device manufacturer seeking a driver solution for a new USB widget then libusbK could be for you.

Main development site in github

https://github.com/mcuee/libusbk/

Main website in Sourceforge and main download location

http://sourceforge.net/projects/libusbk/

About

http://libusbk.sourceforge.net/UsbK3/usbk_about.html

Documentation

http://libusbk.sourceforge.net/UsbK3/index.html

Licensing

Dual license with New BSD option and GPL option. The New BSD Option will facilitate the WHQL certification now that Microsoft has added "excluded license" to the WLK license.

Code Examples

Many examples are provided for the library users to develop their own applications. https://github.com/mcuee/libusbk/tree/master/libusbK/examples

libusbk's People

Contributors

Stargazers

Watchers

libusbk's Issues

7zip changed their syntax causing re-pack.cmd script to fail

Ref: https://sourceforge.net/p/libusb-win32/mailman/message/36288961/

On Mon, Apr 9, 2018 at 3:01 PM, Travis <libusbdotnet@...> wrote:

Greetings,

Well that's annoying. Apparently 7zip changed their syntax a good long
while ago.

Thankfully, You can still get the one you need! Get version 9.20.
https://sourceforge.net/projects/sevenzip/files/7-Zip/9.20/

Regards,
Travis

On 4/9/2018 12:43 PM, Rafael Send wrote:

Hi,
I'm attempting to use InfWizard to create an installer for a custom USB
device (this alone works fine), but I need it to be silent. To that end I'm
attempting to modify the dpinst.xml file with the silent option (which also
works on its own), but I can't repackage an installer.
The re-pack.cmd script always fails with a 7zip error ("-ai switch not
valid for this command").

I've tried manually performing that step, but I have not been able to
repackage a working installer.

Is this a known current bug?

Cheers,
Rafael

klist enhancement for Superspeed Binary Device Object Store (BOS) descriptor and Microsoft OS Descriptors

It will be good for klist to be able to print out Microsoft OS Descriptors

libusbk for windows ARM64?

Hello @mcuee , when you are going to launch libusbk for windows 10 arm 64 bit?

To support Windows on ARM64

Windows on ARM64 will get more and more popular, it will be good to support Windows on ARM64. This will include libusbk.sys, libusbk.dll and libusbk-inf-wizard.

Ref:
mcuee/libusb-win32#29
pbatard/libwdi#155

To release 3.1.0

This is to track the milestone release.

libwdi/dpscat/libusbk-inf-wizard may not work under Windows 11

On-going discussion:
https://community.osr.com/discussion/293115/windows-11-and-alternative-driver-installation-method-in-libwdi

Pete Batard (developer of libwdi/Zadig, libwdi is used in dpscat and libusbk-inf-wizard)'s comments in libwdi.
pbatard/libwdi#155 (comment)

BSOD when unplugging USB device during activity

While doing tests of removing USB device abruptly (i.e. physically upluggin it) during activity (basically reading on a data enpoint in a loop) I systematically got a BSOD.

My stack is an application using libusb-1.0, libubsK.dll and libuskK.sys (latest signed versions)

Analysis of the minidump using WinDbg gave the following output, in which libusbK.sys is clearly identified as doing something wrong.

It is a bit beyond my knowledge, could someone have a look at it? I guess it's easily reproducible.. Thanks

Here is WinDbg output:

*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

KERNEL_SECURITY_CHECK_FAILURE (139)
A kernel component has corrupted a critical data structure.  The corruption
could potentially allow a malicious user to gain control of this machine.
Arguments:
Arg1: 0000000000000003, A LIST_ENTRY has been corrupted (i.e. double remove).
Arg2: fffffe80dfc26870, Address of the trap frame for the exception that caused the BugCheck
Arg3: fffffe80dfc267c8, Address of the exception record for the exception that caused the BugCheck
Arg4: 0000000000000000, Reserved

Debugging Details:
------------------


KEY_VALUES_STRING: 1

    Key  : Analysis.CPU.mSec
    Value: 1781

    Key  : Analysis.Elapsed.mSec
    Value: 11773

    Key  : Analysis.IO.Other.Mb
    Value: 1

    Key  : Analysis.IO.Read.Mb
    Value: 4

    Key  : Analysis.IO.Write.Mb
    Value: 12

    Key  : Analysis.Init.CPU.mSec
    Value: 109

    Key  : Analysis.Init.Elapsed.mSec
    Value: 60213

    Key  : Analysis.Memory.CommitPeak.Mb
    Value: 114

    Key  : Bugcheck.Code.LegacyAPI
    Value: 0x139

    Key  : Dump.Attributes.AsUlong
    Value: 1808

    Key  : Dump.Attributes.DiagDataWrittenToHeader
    Value: 1

    Key  : Dump.Attributes.ErrorCode
    Value: 0

    Key  : Dump.Attributes.KernelGeneratedTriageDump
    Value: 1

    Key  : Dump.Attributes.LastLine
    Value: Dump completed successfully.

    Key  : Dump.Attributes.ProgressPercentage
    Value: 0

    Key  : FailFast.Name
    Value: CORRUPT_LIST_ENTRY

    Key  : FailFast.Type
    Value: 3

    Key  : Failure.Bucket
    Value: 0x139_3_CORRUPT_LIST_ENTRY_libusbK!unknown_function

    Key  : Failure.Hash
    Value: {3e2f28bf-7cbf-dc2c-f08f-3b94cf8f94c5}

    Key  : Hypervisor.Enlightenments.ValueHex
    Value: 1417df84

    Key  : Hypervisor.Flags.AnyHypervisorPresent
    Value: 1

    Key  : Hypervisor.Flags.ApicEnlightened
    Value: 0

    Key  : Hypervisor.Flags.ApicVirtualizationAvailable
    Value: 1

    Key  : Hypervisor.Flags.AsyncMemoryHint
    Value: 0

    Key  : Hypervisor.Flags.CoreSchedulerRequested
    Value: 0

    Key  : Hypervisor.Flags.CpuManager
    Value: 1

    Key  : Hypervisor.Flags.DeprecateAutoEoi
    Value: 1

    Key  : Hypervisor.Flags.DynamicCpuDisabled
    Value: 1

    Key  : Hypervisor.Flags.Epf
    Value: 0

    Key  : Hypervisor.Flags.ExtendedProcessorMasks
    Value: 1

    Key  : Hypervisor.Flags.HardwareMbecAvailable
    Value: 1

    Key  : Hypervisor.Flags.MaxBankNumber
    Value: 0

    Key  : Hypervisor.Flags.MemoryZeroingControl
    Value: 0

    Key  : Hypervisor.Flags.NoExtendedRangeFlush
    Value: 0

    Key  : Hypervisor.Flags.NoNonArchCoreSharing
    Value: 1

    Key  : Hypervisor.Flags.Phase0InitDone
    Value: 1

    Key  : Hypervisor.Flags.PowerSchedulerQos
    Value: 0

    Key  : Hypervisor.Flags.RootScheduler
    Value: 0

    Key  : Hypervisor.Flags.SynicAvailable
    Value: 1

    Key  : Hypervisor.Flags.UseQpcBias
    Value: 0

    Key  : Hypervisor.Flags.Value
    Value: 21631230

    Key  : Hypervisor.Flags.ValueHex
    Value: 14a10fe

    Key  : Hypervisor.Flags.VpAssistPage
    Value: 1

    Key  : Hypervisor.Flags.VsmAvailable
    Value: 1

    Key  : Hypervisor.RootFlags.AccessStats
    Value: 1

    Key  : Hypervisor.RootFlags.CrashdumpEnlightened
    Value: 1

    Key  : Hypervisor.RootFlags.CreateVirtualProcessor
    Value: 1

    Key  : Hypervisor.RootFlags.DisableHyperthreading
    Value: 0

    Key  : Hypervisor.RootFlags.HostTimelineSync
    Value: 1

    Key  : Hypervisor.RootFlags.HypervisorDebuggingEnabled
    Value: 0

    Key  : Hypervisor.RootFlags.IsHyperV
    Value: 1

    Key  : Hypervisor.RootFlags.LivedumpEnlightened
    Value: 1

    Key  : Hypervisor.RootFlags.MapDeviceInterrupt
    Value: 1

    Key  : Hypervisor.RootFlags.MceEnlightened
    Value: 1

    Key  : Hypervisor.RootFlags.Nested
    Value: 0

    Key  : Hypervisor.RootFlags.StartLogicalProcessor
    Value: 1

    Key  : Hypervisor.RootFlags.Value
    Value: 1015

    Key  : Hypervisor.RootFlags.ValueHex
    Value: 3f7


BUGCHECK_CODE:  139

BUGCHECK_P1: 3

BUGCHECK_P2: fffffe80dfc26870

BUGCHECK_P3: fffffe80dfc267c8

BUGCHECK_P4: 0

FILE_IN_CAB:  092723-15156-01.dmp

DUMP_FILE_ATTRIBUTES: 0x1808
  Kernel Generated Triage Dump

TRAP_FRAME:  fffffe80dfc26870 -- (.trap 0xfffffe80dfc26870)
NOTE: The trap frame does not contain all registers.
Some register values may be zeroed or incorrect.
rax=fffffe80dfc26cb8 rbx=0000000000000000 rcx=0000000000000003
rdx=fffffe80dc7f6838 rsi=0000000000000000 rdi=0000000000000000
rip=fffff8000a91511d rsp=fffffe80dfc26a00 rbp=ffff9304dea3abb0
 r8=00000000000005c0  r9=fffff8000a990c08 r10=0000000000000000
r11=fffffe80dfc269e0 r12=0000000000000000 r13=0000000000000000
r14=0000000000000000 r15=0000000000000000
iopl=0         nv up ei pl nz na po nc
Wdf01000!RtlFailFast+0x5:
fffff800`0a91511d cd29            int     29h
Resetting default scope

EXCEPTION_RECORD:  fffffe80dfc267c8 -- (.exr 0xfffffe80dfc267c8)
ExceptionAddress: fffff8000a91511d (Wdf01000!RtlFailFast+0x0000000000000005)
   ExceptionCode: c0000409 (Security check failure or stack buffer overrun)
  ExceptionFlags: 00000001
NumberParameters: 1
   Parameter[0]: 0000000000000003
Subcode: 0x3 FAST_FAIL_CORRUPT_LIST_ENTRY 

BLACKBOXBSD: 1 (!blackboxbsd)


BLACKBOXNTFS: 1 (!blackboxntfs)


BLACKBOXPNP: 1 (!blackboxpnp)


BLACKBOXWINLOGON: 1

CUSTOMER_CRASH_COUNT:  1

PROCESS_NAME:  System

ERROR_CODE: (NTSTATUS) 0xc0000409 - The system detected an overrun of a stack-based buffer in this application. This overrun could potentially allow a malicious user to gain control of this application.

EXCEPTION_CODE_STR:  c0000409

EXCEPTION_PARAMETER1:  0000000000000003

EXCEPTION_STR:  0xc0000409

STACK_TEXT:  
fffffe80`dfc26548 fffff800`094477a9     : 00000000`00000139 00000000`00000003 fffffe80`dfc26870 fffffe80`dfc267c8 : nt!KeBugCheckEx
fffffe80`dfc26550 fffff800`09447d32     : ffff9304`e15f6dc0 fffff800`0a906e46 00006cfb`35d39300 ffff9304`aa010000 : nt!KiBugCheckDispatch+0x69
fffffe80`dfc26690 fffff800`09445b06     : 00000000`00000009 fffff800`0927d847 ffff9304`d9de8aa0 00000000`00000000 : nt!KiFastFailDispatch+0xb2
fffffe80`dfc26870 fffff800`0a91511d     : fffffe80`dfc26c40 ffff9304`dea3abb0 00000000`00000001 fffffe80`dfc26bd0 : nt!KiRaiseSecurityCheckFailure+0x346
fffffe80`dfc26a00 fffff800`0a9069c6     : fffff800`0aa80500 fffff800`0a929a00 fffffe80`dfc26bd0 00000000`00000004 : Wdf01000!FxIoTarget::SubmitLocked+0xeaad [minkernel\wdf\framework\shared\targets\general\fxiotarget.cpp @ 1536] 
fffffe80`dfc26aa0 fffff800`0a953dce     : fffffe80`dfc26bd0 fffffe80`dfc26b60 fffffe80`dfc26c40 fffffe80`dfc26cf0 : Wdf01000!FxIoTarget::Submit+0x3e [minkernel\wdf\framework\shared\targets\general\fxiotarget.cpp @ 1649] 
fffffe80`dfc26ae0 fffff800`0a954083     : ffff9304`db01aa00 fffff800`00000000 00000000`00000000 fffffe80`dfc26cf0 : Wdf01000!FxIoTarget::SubmitSync+0x126 [minkernel\wdf\framework\shared\targets\general\fxiotarget.cpp @ 1740] 
fffffe80`dfc26ba0 fffff800`0a95701c     : 00000000`00000000 fffffe80`dfc26c00 00000000`00000000 00000000`00000000 : Wdf01000!FxIoTarget::SubmitSyncRequestIgnoreTargetState+0x93 [minkernel\wdf\framework\shared\targets\general\fxiotarget.cpp @ 2697] 
fffffe80`dfc26bf0 fffff800`675033c1     : ffff9304`e5492b70 ffff9304`e15f6dc0 ffff9304`dea3abb0 00000000`00004000 : Wdf01000!imp_WdfUsbTargetPipeResetSynchronously+0x15c [minkernel\wdf\framework\shared\targets\usb\fxusbpipeapi.cpp @ 603] 
fffffe80`dfc26e80 ffff9304`e5492b70     : ffff9304`e15f6dc0 ffff9304`dea3abb0 00000000`00004000 ffff9304`e5492fa8 : libusbK+0x33c1
fffffe80`dfc26e88 ffff9304`e15f6dc0     : ffff9304`dea3abb0 00000000`00004000 ffff9304`e5492fa8 ffff9304`d23f1020 : 0xffff9304`e5492b70
fffffe80`dfc26e90 ffff9304`dea3abb0     : 00000000`00004000 ffff9304`e5492fa8 ffff9304`d23f1020 00000000`00000010 : 0xffff9304`e15f6dc0
fffffe80`dfc26e98 00000000`00004000     : ffff9304`e5492fa8 ffff9304`d23f1020 00000000`00000010 00000000`00000000 : 0xffff9304`dea3abb0
fffffe80`dfc26ea0 ffff9304`e5492fa8     : ffff9304`d23f1020 00000000`00000010 00000000`00000000 00006cfb`239a7238 : 0x4000
fffffe80`dfc26ea8 ffff9304`d23f1020     : 00000000`00000010 00000000`00000000 00006cfb`239a7238 00006cfb`1ab6d488 : 0xffff9304`e5492fa8
fffffe80`dfc26eb0 00000000`00000010     : 00000000`00000000 00006cfb`239a7238 00006cfb`1ab6d488 00000000`00004000 : 0xffff9304`d23f1020
fffffe80`dfc26eb8 00000000`00000000     : 00006cfb`239a7238 00006cfb`1ab6d488 00000000`00004000 00000000`00004000 : 0x10


SYMBOL_NAME:  libusbK+33c1

MODULE_NAME: libusbK

IMAGE_NAME:  libusbK.sys

STACK_COMMAND:  .cxr; .ecxr ; kb

BUCKET_ID_FUNC_OFFSET:  33c1

FAILURE_BUCKET_ID:  0x139_3_CORRUPT_LIST_ENTRY_libusbK!unknown_function

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {3e2f28bf-7cbf-dc2c-f08f-3b94cf8f94c5}

Followup:     MachineOwner

To create new benchmark firmware for STM32 MCU (Low Priority)

To create new benchmark firmware for STM32 MCU

libusbk does not list the USB device using WCID

Ref:
https://sourceforge.net/p/libusb-win32/mailman/message/36350250/

On Fri, Jun 22, 2018 at 4:33 PM, Chengda Guo <chengda.guo@...> wrote:

I had used the libusbk and winUsb driver which created by the libusbk-inf-wizard.exe
for installing my device, both of them are OK. And I can access the device by
LibUsbk.dll in my application. Now I would like to automatically install winusb driver
by Windows OS when the device plug into the system, and then use LibUsbk.dll
to access the device in my application. The first step automatically install winusb
driver was successful like below screen shot shows.
But in my application, the device can't be accessed by LibUsbk.dll(Din't find
the device, LstK_Init() succeed, but LstK_Count() return 0 device count).

Bluescreen with loose HDMI connection

A loose HDMI connector under vibration causes an Elgato CamLink to restart due to momentary loss of HDMI signal. When this happens during streaming via libUVC + libusbK from said connection, Windows Bluescreens and reboots. 100% repeatable.

reliable.mp4

Giving attribution is hard, but I suspect libusbK being involved, so I post it here. My exact setup surrounding this bug is posted in detail here libuvc/libuvc#245. Windows 11, Version 21H2 build 22000.1219

I have no idea how to debug on the system level with Windows. The only kernel level debugging I have ever done is with BSDs, so I don't even know where to begin. AFAIK libusbK is the first library with system level access in the chain of streaming video via libUVC. Thus I posted it here to gain some more insight. Of course, libusbK may not even be the culprit after all.

dpscat: On Windows 7 and higher, use a SHA-256 certificate

DarkCloud14@3e3ecfb
DarkCloud14@c943a69

Newer Windows versions (especially 10) don't like when the INF is signed by a
SHA-1 certificate. They don't block the installation, but they won't use the
driver automatically, either.

Invalid: Lower performance for SuperSpeed Interrupt Endpoint compare to Cypress Cyusb3

Device: Cypress FX3
FW: Interrupt Source Sink, modified from Bulk Source Sink example
Interrupt IN/OUT SuperSpeed Endpoint: 16 burst x 1024 Bytes = 16384 Bytes wMaxPacketSize
Expected Speed: 16384 Bytes / 125 us = 131,072 Bytes/ms = 131,072,000 Bytes/second

But kBench reaches much lower speed for both read and write.. And results are similar for different drivers: libusbK.sys, WinUSB and libusb0.sys.

PS C:\Users\xiaof> cd C:\libusbK-dev-kit_release\
PS C:\libusbK-dev-kit_release> .\kList.exe

Loading USB ID's maintained by Stephen J. Gowdy <[email protected]>..

 1. FX3 (Cypress Semiconductor Corp.) [Connected]
    Service              : libusbK
    ClassGUID            : {ECFB0CFD-74C4-4F52-BBF7-343461CD72AC}
    DeviceID             : USB\VID_04B4&PID_00F1\5&586B51A&0&13
    DeviceInterfaceGUID  : {6C2801DD-4728-5524-17C4-148C9EE7C087}
    SymbolicLink         : \\?\usb#vid_04b4&pid_00f1#5&586b51a&0&13#{6c2801dd-4728-5524-17c4-148c9ee7c087}
    DevicePath           : \\?\usb#vid_04b4&pid_00f1#5&586b51a&0&13#{6c2801dd-4728-5524-17c4-148c9ee7c087}
    SerialNumber         : 5&586B51A&0&13
    BusNumber            : 0
    DeviceAddress        : 13

Select device (1-1) :1

Loading driver api..
Getting descriptors..

-Device:
  bLength             :18
  bDescriptorType     :0x01
  bcdUSB              :0x0310
  bDeviceClass        :0x00 (Defined at Interface level)
  bDeviceSubClass     :0x00
  bDeviceProtocol     :0x00
  bMaxPacketSize0     :9
  idVendor            :0x04B4 (Cypress Semiconductor Corp.)
  idProduct           :0x00F1
  bcdDevice           :0x0000
  iManufacturer       :1 (Cypress)
  iProduct            :2 (FX3 BULKSRCSNK)
  iSerialNumber       :0
  bNumConfigurations  :1
!End Device
-Configuration:
  bLength             :9
  bDescriptorType     :0x02
  wTotalLength        :53
  bNumInterfaces      :1
  bConfigurationValue :0x01
  iConfiguration      :0
  bmAttributes        :0x80
  MaxPower            :50 (100ma)
 -Interface:
    bLength             :9
    bDescriptorType     :0x04
    bInterfaceNumber    :0x00
    bAlternateSetting   :0x00
    bNumEndpoints       :0
    bInterfaceClass     :0xFF (Vendor Specific Class)
    bInterfaceSubClass  :0x00
    bInterfaceProtocol  :0x00
    iInterface          :0
 !End Interface
 -Interface:
    bLength             :9
    bDescriptorType     :0x04
    bInterfaceNumber    :0x00
    bAlternateSetting   :0x01
    bNumEndpoints       :2
    bInterfaceClass     :0xFF (Vendor Specific Class)
    bInterfaceSubClass  :0x00
    bInterfaceProtocol  :0x00
    iInterface          :0
   -Endpoint:
      bLength             :7
      bDescriptorType     :0x05
      bEndpointAddress    :0x01
      bmAttributes        :0x03 (Interrupt)
      wMaxPacketSize      :1024
      bInterval           :0x01
     -SS Companion:
        bLength             :6
        bDescriptorType     :0x30
        bMaxBurst           :15 (16 Packets Per Burst)
        bmAttributes        :0x00
        wBytesPerInterval   :0
     !End SS Companion
   !End Endpoint
   -Endpoint:
      bLength             :7
      bDescriptorType     :0x05
      bEndpointAddress    :0x81
      bmAttributes        :0x03 (Interrupt)
      wMaxPacketSize      :1024
      bInterval           :0x01
     -SS Companion:
        bLength             :6
        bDescriptorType     :0x30
        bMaxBurst           :15 (16 Packets Per Burst)
        bmAttributes        :0x00
        wBytesPerInterval   :0
     !End SS Companion
   !End Endpoint
 !End Interface
!End Configuration
-BOS:
  bDescriptorType     :0x0F
  bLength             :5
  wTotalLength        :22
  bNumDeviceCapabilities:2
 -Capability: #0
    bLength             :7
    bDescriptorType     :0x10
    bDevCapabilityType  :0x02 (USB 2.0 extension)
    bmAttributes        :0x0000641E LPM
 !End Capability
 -Capability: #1
    bLength             :10
    bDescriptorType     :0x10
    bDevCapabilityType  :0x03 (Super speed USB specific device level capabilities)
    bmAttributes        :0x00
    wSpeedSupported     :0x000E FS HS SS
    bFunctionalitySupport:0x03
    bU1DevExitLat       :10 us
    bU2DevExitLat       :2047 us
 !End Capability
!End BOS
PS C:\libusbK-dev-kit_release> .\kBench.exe list mode=async write
device-count=1
1. FX3 (USB\VID_04B4&PID_00F1\5&586B51A&0&13) [libusbK]
Select device (1-1) :1

opened FX3 (USB\VID_04B4&PID_00F1\5&586B51A&0&13)..
Write Test Information
        Driver          : libusbK
        Vid / Pid       : 04B4h / 00F1h
        DevicePath      : \\?\usb#vid_04b4&pid_00f1#5&586b51a&0&13#{6c2801dd-4728-5524-17c4-148c9ee7c087}
        Device Speed    : High
        Interface #     : 00h
        Alt Interface # : 01h
        Num Endpoints   : 2
        Priority        : 0
        Read Size       : 4096
        Write Size      : 4096
        Buffer Count    : 1
        Display Refresh : 1000 (ms)
        Transfer Timeout: 5000 (ms)
        Retry Count     : 0
        Verify Data     : Off

Interrupt Write (Ep01h) Maximum Packet Size:1024

While the test is running:
Press 'Q' to quit
Press 'T' for test details
Press 'I' for status information
Press 'R' to reset averages

Press 'Q' to exit, any other key to begin..
Avg. Bytes/s: 31573501.48 Transfers: 7824 Bytes/s: 31573501.48
Avg. Bytes/s: 32099223.82 Transfers: 15791 Bytes/s: 32632832.00
Avg. Bytes/s: 32231376.45 Transfers: 23725 Bytes/s: 32497664.00
Avg. Bytes/s: 32310961.89 Transfers: 31672 Bytes/s: 32550912.00
Avg. Bytes/s: 31568194.62 Transfers: 38651 Bytes/s: 28585984.00
Avg. Bytes/s: 31472805.99 Transfers: 46218 Bytes/s: 30994432.00
Avg. Bytes/s: 31220687.10 Transfers: 53470 Bytes/s: 29704192.00
Avg. Bytes/s: 31291089.21 Transfers: 61230 Bytes/s: 31784960.00
Avg. Bytes/s: 31200081.50 Transfers: 68791 Bytes/s: 30482141.73
Avg. Bytes/s: 31072596.55 Transfers: 76096 Bytes/s: 29921280.00
Avg. Bytes/s: 31035062.64 Transfers: 83581 Bytes/s: 30658560.00
Avg. Bytes/s: 31010577.34 Transfers: 91086 Bytes/s: 30740480.00
Avg. Bytes/s: 30961874.91 Transfers: 98502 Bytes/s: 30375936.00
Avg. Bytes/s: 30749046.54 Transfers: 105332 Bytes/s: 27975680.00
Avg. Bytes/s: 30640377.48 Transfers: 112560 Bytes/s: 29139653.54
Avg. Bytes/s: 30190228.20 Transfers: 118277 Bytes/s: 23416832.00
Avg. Bytes/s: 29986074.27 Transfers: 124798 Bytes/s: 26710016.00
Avg. Bytes/s: 30082310.26 Transfers: 132653 Bytes/s: 31698600.99
Avg. Bytes/s: 30113829.82 Transfers: 140144 Bytes/s: 30683136.00
stopped Ep01h thread.   ExitCode=0
Write Test Information
        Driver          : libusbK
        Vid / Pid       : 04B4h / 00F1h
        DevicePath      : \\?\usb#vid_04b4&pid_00f1#5&586b51a&0&13#{6c2801dd-4728-5524-17c4-148c9ee7c087}
        Device Speed    : High
        Interface #     : 00h
        Alt Interface # : 01h
        Num Endpoints   : 2
        Priority        : 0
        Read Size       : 4096
        Write Size      : 4096
        Buffer Count    : 1
        Display Refresh : 1000 (ms)
        Transfer Timeout: 5000 (ms)
        Retry Count     : 0
        Verify Data     : Off

Interrupt Write (Ep01h) Maximum Packet Size:1024
        Total Bytes     : 574033920
        Total Transfers : 140145
        Avg. Bytes/sec  : 30114044.70
        Elapsed Time    : 19.06 seconds

Press any key to exit..
PS C:\libusbK-dev-kit_release> .\kBench.exe list mode=async read
device-count=1
1. FX3 (USB\VID_04B4&PID_00F1\5&586B51A&0&13) [libusbK]
Select device (1-1) :1

opened FX3 (USB\VID_04B4&PID_00F1\5&586B51A&0&13)..
Read Test Information
        Driver          : libusbK
        Vid / Pid       : 04B4h / 00F1h
        DevicePath      : \\?\usb#vid_04b4&pid_00f1#5&586b51a&0&13#{6c2801dd-4728-5524-17c4-148c9ee7c087}
        Device Speed    : High
        Interface #     : 00h
        Alt Interface # : 01h
        Num Endpoints   : 2
        Priority        : 0
        Read Size       : 4096
        Write Size      : 4096
        Buffer Count    : 1
        Display Refresh : 1000 (ms)
        Transfer Timeout: 5000 (ms)
        Retry Count     : 0
        Verify Data     : Off

Interrupt Read (Ep81h) Maximum Packet Size:1024

While the test is running:
Press 'Q' to quit
Press 'T' for test details
Press 'I' for status information
Press 'R' to reset averages

Press 'Q' to exit, any other key to begin..
Avg. Bytes/s: 31468579.31 Transfers: 7798 Bytes/s: 31468579.31
Avg. Bytes/s: 31874583.95 Transfers: 15805 Bytes/s: 32280188.98
Avg. Bytes/s: 32096369.52 Transfers: 23751 Bytes/s: 32546816.00
Avg. Bytes/s: 32231485.98 Transfers: 31720 Bytes/s: 32641024.00
Avg. Bytes/s: 32272181.28 Transfers: 39639 Bytes/s: 32436224.00
Avg. Bytes/s: 32300060.35 Transfers: 47559 Bytes/s: 32440320.00
Avg. Bytes/s: 32182608.00 Transfers: 55361 Bytes/s: 31484721.18
Avg. Bytes/s: 32167470.11 Transfers: 63314 Bytes/s: 32062488.19
Avg. Bytes/s: 32114863.83 Transfers: 71051 Bytes/s: 31690752.00
Avg. Bytes/s: 31915989.66 Transfers: 78403 Bytes/s: 30113792.00
Avg. Bytes/s: 31891925.51 Transfers: 86130 Bytes/s: 31649792.00
Avg. Bytes/s: 31778467.25 Transfers: 93582 Bytes/s: 30523392.00
Avg. Bytes/s: 31727870.32 Transfers: 101303 Bytes/s: 31127181.10
Avg. Bytes/s: 31654532.75 Transfers: 108797 Bytes/s: 30695424.00
Avg. Bytes/s: 31585761.51 Transfers: 116272 Bytes/s: 30617600.00
Avg. Bytes/s: 31606812.79 Transfers: 124066 Bytes/s: 31924224.00
Avg. Bytes/s: 31584865.68 Transfers: 131691 Bytes/s: 31232000.00
stopped Ep81h thread.   ExitCode=259
Read Test Information
        Driver          : libusbK
        Vid / Pid       : 04B4h / 00F1h
        DevicePath      : \\?\usb#vid_04b4&pid_00f1#5&586b51a&0&13#{6c2801dd-4728-5524-17c4-148c9ee7c087}
        Device Speed    : High
        Interface #     : 00h
        Alt Interface # : 01h
        Num Endpoints   : 2
        Priority        : 0
        Read Size       : 4096
        Write Size      : 4096
        Buffer Count    : 1
        Display Refresh : 1000 (ms)
        Transfer Timeout: 5000 (ms)
        Retry Count     : 0
        Verify Data     : Off

Interrupt Read (Ep81h) Maximum Packet Size:1024
        Total Bytes     : 539410432
        Total Transfers : 131692
        Avg. Bytes/sec  : 31585105.52
        Elapsed Time    : 17.08 seconds

Press any key to exit..

libusbk is now considered as unmaintained

I have marked libusbk as unmaintained as Travis is no longer
active in maintaining the project.

Ref:
https://github.com/mcuee/libusbk

Status: unmaintained and with limited support as lack of developers
to take over

github action

It may be a good idea to set up github action for CI/CD.

klist: to catch up with new version of usb.ids file

klist: to catch up with usb.ids file
http://www.linux-usb.org/usb.ids

New release of libusbk will come with signed 3.0.7.0 version of libusbk.sys

liusbk 3.0.8.0 and 3.1.0.0 release come with signed libusbk.sys 3.0.7.0 version and it still works with Windows 7/8/8.1/10 (and should work under Windows XP/Vista as well but you should really not using those ancient OS, now that even Windows 7 is out of support).

We do not have a EV certificate for code signing now so this is not possible to go for Microsoft attestation for new version of libusbk.sys. Luckily libusbk.sys still works very well.

Keep getting an error that the handle is invalid

import ctypes
from ctypes import Structure, c_uint, c_ubyte, c_void_p, POINTER

# 加载libusbK.dll
my_dll = ctypes.CDLL("libusbK.dll")

# 定义libusbK的函数原型
UsbK_Initialize = my_dll.UsbK_Initialize
UsbK_Initialize.argtypes = [c_void_p, POINTER(c_void_p)]
UsbK_Initialize.restype = ctypes.c_bool

UsbK_ControlTransfer = my_dll.UsbK_ControlTransfer
UsbK_ControlTransfer.argtypes = [c_void_p, c_void_p, POINTER(c_ubyte), c_uint, POINTER(c_uint), c_void_p]
UsbK_ControlTransfer.restype = ctypes.c_bool

LstK_Init = my_dll.LstK_Init
LstK_Init.argtypes = [POINTER(c_void_p), c_uint]
LstK_Init.restype = ctypes.c_bool

LstK_MoveNext = my_dll.LstK_MoveNext
LstK_MoveNext.argtypes = [c_void_p, POINTER(c_void_p)]
LstK_MoveNext.restype = ctypes.c_bool

LstK_Free = my_dll.LstK_Free
LstK_Free.argtypes = [c_void_p]
LstK_Free.restype = ctypes.c_bool

# 定义设备句柄类型
KUSB_HANDLE = c_void_p
KLST_HANDLE = c_void_p

# 设备列表句柄
deviceList = KLST_HANDLE()

def main():
    # 初始化设备列表句柄
    if LstK_Init(ctypes.byref(deviceList), 0):
        print("设备列表句柄创建成功！")
    else:
        print("设备列表句柄创建失败！")
        return

    # 枚举设备列表并打印设备信息
    while True:
        deviceInfo = KUSB_HANDLE()
        if not LstK_MoveNext(deviceList, ctypes.byref(deviceInfo)):
            break

        # 在这里可以根据需要获取设备信息并进行处理
        # 例如，可以使用UsbK_Initialize来创建libusbK接口句柄
        print("找到设备！设备句柄：", deviceInfo)

        # 模拟按下Home键
        class WINUSB_SETUP_PACKET(Structure):
            _fields_ = [
                ("RequestType", c_ubyte),
                ("Request", c_ubyte),
                ("Value", c_uint),
                ("Index", c_uint),
                ("Length", c_uint),
            ]

        setup_packet = WINUSB_SETUP_PACKET(0x21, 0x09, 0x0200, 0, 8)  # HID报告数据

        # 发送控制传输
        transferred = c_uint(0)
        success = UsbK_ControlTransfer(deviceInfo, ctypes.byref(setup_packet), None, 0, ctypes.byref(transferred), None)

        print("Home键模拟成功！" if success else "Home键模拟失败！")
        error_code = ctypes.windll.kernel32.GetLastError()
        print(f"设备句柄创建失败，错误代码: {error_code}")
        # 输出更多的错误信息
        buffer_size = 256
        error_message = ctypes.create_string_buffer(buffer_size)
        ctypes.windll.kernel32.FormatMessageA(0x00001000, None, error_code, 0x00000400, error_message, buffer_size,
                                              None)
        # 将错误信息转换为Unicode编码并忽略无法解码的字符
        error_message_unicode = error_message.value.decode('mbcs', 'ignore')
        print(f"错误信息: {error_message_unicode}")

    # 释放设备列表句柄
    if LstK_Free(deviceList):
        print("设备列表句柄释放成功！")
    else:
        print("设备列表句柄释放失败！")

if __name__ == "__main__":
    main()

About UVC Button Event

Hello,

I am using Camera device which has still pin button on it (Webcam/DentalCam). I want to capture the button of the USB device. Would it be possible with this library.

Kind Regards,
Manish

Release plan

This is used to track the milestone.

Driver installation failed on Mi 5 phone

Add MS OS descriptor 2.0 for the Benchmark FW examples

It will be good to add MS OS descriptor 2.0 for the Benchmark FW examples, at least for the Cypress FX3.

Is there any way to overwrite Configuration Descriptor?

Hi.

I have a usb device with wrong configuration descriptor.
I installed libusbk using Zadig 2.7, then it is recognized by LibUsbDotNet, but I can't communicate with the usb device (HID Device).

Here is the usb descriptor from Thethycon USB Descriptor Dumper.

------------------------------
Device Descriptor:
------------------------------
0x12	bLength
0x01	bDescriptorType
0x0110	bcdUSB
0xFF	bDeviceClass      (Vendor specific)
0x04	bDeviceSubClass   
0x00	bDeviceProtocol   
0x08	bMaxPacketSize0   (8 bytes)
0x0AE4	idVendor
0x0004	idProduct
0x0100	bcdDevice
0x01	iManufacturer
0x02	iProduct     
0x03	iSerialNumber
0x01	bNumConfigurations
Hex dump: 
0x12 0x01 0x10 0x01 0xFF 0x04 0x00 0x08 0xE4 0x0A 
0x04 0x00 0x00 0x01 0x01 0x02 0x03 0x01 


-------------------------
Configuration Descriptor:
-------------------------
0x09	bLength
0x02	bDescriptorType
0x0029	wTotalLength   (41 bytes)
*** ERROR: Found error in descriptor: incomplete descriptor
0x01	bNumInterfaces
*** ERROR: Found error in descriptor: incomplete descriptor
0x01	bConfigurationValue
0x00	iConfiguration
0xA0	bmAttributes   (Bus-powered Device, Remote-Wakeup)
0x0A	bMaxPower      (20 mA)
Hex dump: 
0x09 0x02 0x29 0x00 0x01 0x01 0x00 0xA0 0x0A 

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x00	bInterfaceNumber
0x00	bAlternateSetting
0x01	bNumEndPoints
*** ERROR: Found error in descriptor: incomplete descriptor
0x03	bInterfaceClass      (Human Interface Device Class)
0x00	bInterfaceSubClass   
0x00	bInterfaceProtocol   
0x00	iInterface
Hex dump: 
0x09 0x04 0x00 0x00 0x01 0x03 0x00 0x00 0x00 

Endpoint Descriptor:
------------------------------
0x07	bLength
0x05	bDescriptorType
0x81	bEndpointAddress  (IN endpoint 1)
0x03	bmAttributes      (Transfer: Interrupt / Synch: None / Usage: Data)
0x0008	wMaxPacketSize    (1 x 8 bytes)
0x14	bInterval         (20 frames)
Hex dump: 
0x07 0x05 0x81 0x03 0x08 0x00 0x14 

*** ERROR: Specified length (0x73) of descriptor (type: 0x55) is greater than the remaining descriptor data 
Microsoft OS Descriptor is not available. Error code: 0x000003E3


--------------------------------
String Descriptor Table
--------------------------------
Index  LANGID  String
0x00   0x0000  
Hex dump: 

0x01   0x0000  Request failed with 0x000001B1
Hex dump: 

0x02   0x0000  Request failed with 0x000001B1
Hex dump: 

0x03   0x0000  Request failed with 0x000001B1
Hex dump: 

------------------------------

Whole Device Descriptor as hex dump: 
0x12, 0x01, 0x10, 0x01, 0xFF, 0x04, 0x00, 0x08, 0xE4, 0x0A, 
0x04, 0x00, 0x00, 0x01, 0x01, 0x02, 0x03, 0x01

Whole Configuration Descriptor as hex dump: 
0x09, 0x02, 0x29, 0x00, 0x01, 0x01, 0x00, 0xA0, 0x0A, 0x09, 
0x04, 0x00, 0x00, 0x01, 0x03, 0x00, 0x00, 0x00, 0x07, 0x05, 
0x81, 0x03, 0x08, 0x00, 0x14, 0x73, 0x55, 0x7E, 0x7B, 0xCA, 
0xD8, 0x01, 0x20, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 
0x00


------------------------------

I found the configuration descriptor's wTotalLength 0x0029 is incorrect. 0x0019 is correct.
I forked libusbk and fix to override wTotalLength to 0x0019. Then the device worked!
But I don't have code certificate because it is so expensive, so I don't want to use the method.
So I want to override wTotalLength(or configuration descriptor) or communicate with the device with wrong configuration descriptor.
Is there any way to communicate with it?

libusb_alloc_streams

I didn't find function that allocate stream numbers like libusb on libusbK,
Does the libusbK support this funciton?

xfer-async.exe hangs

Hello.
First of all I'd like to thank you for this excellent library. It is very well 
documented and set up easily. All the samples compiled without any problems and 
I was happy to see show-device.exe hooking up my test device (Transcend USB 
flash drive). It is a pity though that the library is not cross-platform.

The only problem I have experienced so far is the hanging of one of your sample 
programs.

What steps will reproduce the problem?
1. Insert USB flash drive ("test device")
2. Using Driver Install Creator Wizard specify the libusbK v 3.0.4.2 driver for 
the test device (by the way, is it OK that liusbK driver has version 3.0.4.2?)
3. Run show-device.exe to get pid and vid of the test device (vid=0457, 
pid=0151)
4. Run xfer-async.exe with these pid and vid

What is the expected output? What do you see instead?
I expect that the program writes something to console, maybe waits for some 
time and finishes normally. 
I see messages:
Looking for device vid/pid 0457/0151..
Using 0457:0151 (1B5454055201B6): USB Mass Storage Device - Silicon Integrated 
Systems Corp.
Device opened successfully!
Bench_Configure failed.
Transfer #0 submitted for 4096 bytes.
Transfer #1 submitted for 4096 bytes.
Transfer #2 submitted for 4096 bytes.

At this point the program hangs. It does not respond neither to Ctrl+C nor to 
Stop process requests via the task manager. I had to reboot my system to close 
the console window. I should notice, however, that while I was writing this 
text, another console window with the xfer-async.exe running finished. I have 
started it again and can confirm that it finishes but after too long period of 
time (several minutes).

What version of the product are you using? On what operating system?
libusbK installed from libusbK-3.0.5.1-setup.exe
OS: Windows 7 64 bit on HP 4510s laptop

Please provide any additional information below.
I have run the program in a debugger and found out that it hangs inside the 
OvlK_WaitAndRelease call. As I understand it waits for the feedback from the 
device, as specified in asynchronous mode of isochronous transfer. However, 
hanging does not seem correct, because there is timeout set to 1000 ms, so the 
function should have returned after this time elapsed.

Original issue reported on code.google.com by [email protected] on 7 Jan 2012 at 7:27

WinUSB Isochronous Transfer support

libusbK-inf-wizard enhancement: to catch up with new version of libwdi (low priority)

libusbK-inf-wizard enhancement: to catch up with new version of libwdi

Added enclosed value of CN in double quotes to avoid problems with special characters like comma etc

DarkCloud14@216e6f7

ALLOW_PARTIAL_READS pipe policy may not be implemented in a way compatible to WinUSB

Copies from Sourceforge:
https://sourceforge.net/p/libusbk/tickets/2/

Ref:
http://libusbx-devel.narkive.com/TKaErHI0/libusb-win32-and-libusbk-support-has-now-been-pushed-to-mainline#post13

https://sourceforge.net/p/libusbx/mailman/message/29736015%20/

[deleted issue]

[deleted issue]

Libusbk packet loss

When using libusbk to test the USB camera, it is found that the pipe packet is lost

hk.txt:13687: 10.3 73680 IN 07 06 07 07 07 07 07 06 06 07 07 07 06 07 07 07 ................ 649us 13666.1.0 2021/08/13 09:53:58.147 unknown
hk.txt:13688: 10.3 4 IN 07 06 06 06 .... 582us 13667.1.0 2021/08/13 09:53:58.147 unknown
hk.txt:13689: 10.3 4 IN 07 06 06 06 .... 561us 13668.1.0 2021/08/13 09:53:58.148 unknown
hk.txt:13690: 10.3 4 IN 07 06 06 06 .... 569us 13669.1.0 2021/08/13 09:53:58.148 unknown
hk.txt:13691: 10.3 4 IN 07 06 06 06 .... 538us 13670.1.0 2021/08/13 09:53:58.149 unknown
hk.txt:13692: 10.3 4 IN 07 06 06 06 .... 558us 13671.1.0 2021/08/13 09:53:58.149 unknown
hk.txt:72363: 10.3 73680 IN 08 09 08 08 08 08 09 09 09 09 07 09 08 09 08 08 ................ 693us 72342.1.0 2021/08/13 10:01:03.371 unknown
hk.txt:72364: 10.3 4 IN 0b 0b 0a 0a .... 512us 72343.1.0 2021/08/13 10:01:03.372 unknown
hk.txt:72365: 10.3 4 IN 0b 0b 0a 0a .... 565us 72344.1.0 2021/08/13 10:01:03.373 unknown
hk.txt:72366: 10.3 4 IN 0b 0b 0a 0a .... 563us 72345.1.0 2021/08/13 10:01:03.373 unknown
hk.txt:74156: 10.3 73680 IN 0a 0b 0a 0b 09 0a 0b 0a 0a 0a 0b 0a 0c 0a 0b 0b ................ 1.8ms 74135.1.0 2021/08/13 10:01:16.361 unknown
hk.txt:74157: 10.3 4 IN 08 08 09 09 .... 577us 74136.1.0 2021/08/13 10:01:16.362 unknown
hk.txt:74158: 10.3 4 IN 08 08 09 09 .... 607us 74137.1.0 2021/08/13 10:01:16.363 unknown
hk.txt:74159: 10.3 4 IN 08 08 09 09 .... 569us 74138.1.0 2021/08/13 10:01:16.363 unknown
hk.txt:74160: 10.3 4 IN 08 08 09 09 .... 614us 74139.1.0 2021/08/13 10:01:16.364 unknown
hk.txt:95564: 10.3 168964 IN 07 06 07 07 07 06 06 07 06 07 06 07 07 07 07 07 ................ 844us 95543.1.0 2021/08/13 10:03:51.479 unknown
hk.txt:95565: 10.3 4 IN 06 06 06 06 .... 556us 95544.1.0 2021/08/13 10:03:51.480 unknown
hk.txt:95566: 10.3 4 IN 06 06 06 06 .... 561us 95545.1.0 2021/08/13 10:03:51.480 unknown
hk.txt:95568: 10.3 4 IN 06 06 06 06 .... 138us 95547.1.0 2021/08/13 10:03:51.481 unknown
hk.txt:95569: 10.3 4 IN 06 06 06 06 .... 564us 95548.1.0 2021/08/13 10:03:51.482 unknown
hk.txt:95570: 10.3 4 IN 06 06 06 06 .... 546us 95549.1.0 2021/08/13 10:03:51.482 unknown

After the comparative test, it is found that it is really caused by the driver. There will be no problem in the official driver pressure test of USB camera. Batch transmission is used. The computer performance is very good. Can you help analyze it? It's been analyzed for two weeks and no reason has been found.

The official driver is libusb-win32. I use libusbk. It is normal to test other USB cameras, such as Basler, IDS, Point Grey and so on. There is a problem with one camera. It is preliminarily judged that the driver processing is not fast enough or the data is lost due to program switching.

kList hangs Mi Wireless Mouse with libusb0.sys filter driver attached to the USB receiver

Device: Mi Bluetooth/Wireless dual mode Wireless Mouse, with USB receiver, so working as a USB wireless mouse
Driver: libusb0.sys 1.2.7.3 filter driver attached to the USB receiver
Windows 10 64bit

kList works fine, but then the mouse will not work after running KList. I need to remove the filter driver in order for the mouse to work again.

C:\libusbK-dev-kit> .\kList.exe

Loading USB ID's maintained by Stephen J. Gowdy <[email protected]>..

 1. USB Serial Converter (FTDI) [Connected]
    Service              : FTDIBUS
    ClassGUID            : {36FC9E60-C465-11CF-8056-444553540000}
    DeviceID             : USB\VID_0403&PID_6001\FTDCRPIE
    DeviceInterfaceGUID  : {F9F3FF14-AE21-48A0-8A25-8011A7A931D9}
    SymbolicLink         : \\?\usb#vid_0403&pid_6001#ftdcrpie#{f9f3ff14-ae21-48a0-8a25-8011a7a931d9}
    DevicePath           : \\.\libusb0-0001
    SerialNumber         : FTDCRPIE
    BusNumber            : 0
    DeviceAddress        : 2

 2. USB Input Device ((Standard system devices)) [Connected]
    Service              : HidUsb
    ClassGUID            : {745A17A0-74D3-11D0-B6FE-00A0C90F57DA}
    DeviceID             : USB\VID_2717&PID_5013\5&E9F3E45&0&1
    DeviceInterfaceGUID  : {F9F3FF14-AE21-48A0-8A25-8011A7A931D9}
    SymbolicLink         : \\?\usb#vid_2717&pid_5013#5&e9f3e45&0&1#{f9f3ff14-ae21-48a0-8a25-8011a7a931d9}
    DevicePath           : \\.\libusb0-0002
    SerialNumber         : 5&E9F3E45&0&1
    BusNumber            : 0
    DeviceAddress        : 1

Select device (1-2) :2

Loading driver api..
Getting descriptors..

-Device:
  bLength             :18
  bDescriptorType     :0x01
  bcdUSB              :0x0110
  bDeviceClass        :0x00 (Defined at Interface level)
  bDeviceSubClass     :0x00
  bDeviceProtocol     :0x00
  bMaxPacketSize0     :64
  idVendor            :0x2717 (Xiaomi Inc.)
  idProduct           :0x5013
  bcdDevice           :0x0625
  iManufacturer       :1 (MI)
  iProduct            :2 (Mi Wireless Mouse)
  iSerialNumber       :0
  bNumConfigurations  :1
!End Device
-Configuration:
  bLength             :9
  bDescriptorType     :0x02
  wTotalLength        :34
  bNumInterfaces      :1
  bConfigurationValue :0x01
  iConfiguration      :0
  bmAttributes        :0xA0 (Self-Powered)
  MaxPower            :50 (100ma)
 -Interface:
    bLength             :9
    bDescriptorType     :0x04
    bInterfaceNumber    :0x00
    bAlternateSetting   :0x00
    bNumEndpoints       :1
    bInterfaceClass     :0x03 (Human Interface Device)
    bInterfaceSubClass  :0x01 (Boot Interface Subclass)
    bInterfaceProtocol  :0x02 (Mouse)
    iInterface          :0
   -Hid:
      bLength             :9
      bDescriptorType     :0x21
      bcdHID              :0x0110
      bCountry            :0x00 (Not supported)
      bNumDescriptors     :1
     -Report:
        bReportType         :0x22
        wReportLength       :215
        Usage Page          :0x01 (Generic Desktop Controls)
        Usage               :0x002 (Mouse)
       *Collection            :0x01 (Application)
          Usage               :0x001 (Pointer)
         *Collection            :0x00 (Physical)
            Report ID           :0x01
            Usage Page          :0x09 (Buttons)
            Usage Minimum       :0x01
            Usage Maximum       :0x05
            Logical Minimum     :0x00
            Logical Maximum     :0x01
            Report Count        :0x05
            Report Size         :0x01
            Input               :0x02
            Report Count        :0x01
            Report Size         :0x03
            Input               :0x01
            Usage Page          :0x01 (Generic Desktop Controls)
            Usage               :0x030 (Direction-X)
            Usage               :0x031 (Direction-Y)
            Logical Minimum     :0x8000
            Logical Maximum     :0x7FFF
            Report Size         :0x10
            Report Count        :0x02
            Input               :0x06
         !End Collection
         *Collection            :0x00 (Physical)
            Usage Page          :0x01 (Generic Desktop Controls)
            Usage               :0x038 (Wheel)
            Logical Minimum     :0x81
            Logical Maximum     :0x7F
            Report Size         :0x08
            Report Count        :0x01
            Input               :0x06
         !End Collection
         *Collection            :0x00 (Physical)
            Usage Page          :0x0C (Consumer)
            Usage               :0x238 (AC Pan)
            Report Count        :0x01
            Report Size         :0x08
            Logical Minimum     :0x81
            Logical Maximum     :0x7F
            Input               :0x06
         !End Collection
       !End Collection
        Usage Page          :0xFF01 (Generic Desktop Controls)
        Usage               :0x000 (Undefined)
       *Collection            :0x01 (Application)
          Report ID           :0x02
          Usage               :0x000 (Undefined)
          Logical Minimum     :0x00
          Logical Maximum     :0x00FF
          Report Size         :0x08
          Report Count        :0x07
          Input               :0x02
       !End Collection
        Usage Page          :0x0C (Consumer)
        Usage               :0x001 (Consumer Control)
       *Collection            :0x01 (Application)
          Report ID           :0x05
          Logical Minimum     :0x00
          Logical Maximum     :0x023C
          Usage Minimum       :0x00
          Usage Maximum       :0x023C
          Report Size         :0x10
          Report Count        :0x01
          Input               :0x00
       !End Collection
        Usage Page          :0x01 (Generic Desktop Controls)
        Usage               :0x080 (System Control)
       *Collection            :0x01 (Application)
          Report ID           :0x03
          Usage Minimum       :0x81
          Usage Maximum       :0x83
          Logical Minimum     :0x00
          Logical Maximum     :0x01
          Report Count        :0x03
          Report Size         :0x01
          Input               :0x02
          Report Count        :0x01
          Report Size         :0x05
          Input               :0x01
       !End Collection
        Usage Page          :0xFFBC
        Usage               :0x88
       *Collection            :0x01 (Application)
          Report ID           :0x04
          Report Count        :0x01
          Report Size         :0x08
          Logical Minimum     :0x00
          Logical Maximum     :0x00FF
          Usage Minimum       :0x00
          Usage Maximum       :0x00FF
          Input               :0x00
       !End Collection
        Usage Page          :0xFF02 (Simulation Controls)
        Usage               :0x002 (Automobile Simulation Device)
       *Collection            :0x01 (Application)
          Report ID           :0x06
          Usage               :0x002 (Automobile Simulation Device)
          Logical Minimum     :0x00
          Logical Maximum     :0x00FF
          Report Size         :0x08
          Report Count        :0x07
          Feature             :0x02
       !End Collection
     !End Report
   !End Hid
   -Endpoint:
      bLength             :7
      bDescriptorType     :0x05
      bEndpointAddress    :0x81
      bmAttributes        :0x03 (Interrupt)
      wMaxPacketSize      :8
      bInterval           :0x02
   !End Interface
 !End Configuration

libusbK-inf-waizard "Install Only" option does not work under Windows 10

Please take note that libusbK-inf-waizard "Install Only" option may not not work under Windows 10. You can use the other two options ("Client Installer" or "Legacy Package").

How to handle the stall PID and what causes it?

How to build libusbk

I notice that build using make.cmd needs doscmd.exe
but there's nothing explaining what is doscmd.exe and where it comes from and its source code
Sadly, this tool doesn't run under XP SP3, then how to setup an environment to build?

To port to later Windows WDK

Currently WDK7 is used. It will be good to update to new WDK like Windows 11 WDK.

In this case we will need to drop Windows XP and Vista support. Anyway, I can not test for Windows XP and Windows Vista anyway. Microsoft has dropped the support of Windows XP and Vista for quite some time. Even Windows 7 main stream support has ended.

To release 3.0.8.0

To release 3.0.8.0 -- this issue is used to track the milestone.

babble detected

A babble detected error was generated，How to handle this exception? Communication failed after this error

LIBUSB_MAX_CONTROL_TRANSFER_TIMEOUT avoid infinite timeout

Hi team;
thanks for providing this driver to the community, it is especially useful for the device including DFU features.

I have realized in recent experimentation that the timeout parameter attached to libusb_control_transfer() cannot be infinite as there is a test in the source code which maximize it to the value of LIBUSB_MAX_CONTROL_TRANSFER_TIMEOUT, which is defined in sys/drv_private.h.

this is a problem because the DFU protocol erase the flash memory at the first control request and this can take more than 5 seconds !

would you be so kind to change the value to a larger one (say 30 seconds) and make a new release ? or to change the different tests against this value and maximize it to say 30seconds when the value given is 0, so that is closer to infinite :)

many thanks

dotnet example of kList and kBench

It will be great to have a port of dotnet (especially C#) for kList and kBench.

To pull patches from https://github.com/LibUsbDotNet/libusbk

Invalid: Lower performance for High Bandwidth High Speed Interrupt OUT Endpoint compare to Cypress Cyusb3

Speed from libusbK.

Idealy the speed should be 12MB/sec for the high bandwidth high speed Interrupt IN/OUT endpoint when bInterval = 2 (250us).

3072 B / 250 us = 120,288 Bytes/sec.

PS C:\libusbK-dev-kit_release> .\klist

Loading USB ID's maintained by Stephen J. Gowdy <[email protected]>..

 1. EZ-USB (Cypress Semiconductor Corp.) [Connected]
    Service              : WinUSB
    ClassGUID            : {88BAE032-5A81-49F0-BC3D-A4FF138216D6}
    DeviceID             : USB\VID_04B4&PID_1004\6&8694159&0&3
    DeviceInterfaceGUID  : {B89F58FD-B8D4-D215-4D39-0CBD5FC94C6C}
    SymbolicLink         : \\?\usb#vid_04b4&pid_1004#6&8694159&0&3#{b89f58fd-b8d4-d215-4d39-0cbd5fc94c6c}
    DevicePath           : \\?\usb#vid_04b4&pid_1004#6&8694159&0&3#{b89f58fd-b8d4-d215-4d39-0cbd5fc94c6c}
    SerialNumber         : 6&8694159&0&3
    BusNumber            : 0
    DeviceAddress        : 3

Select device (1-1) :1

Loading driver api..
Getting descriptors..

-Device:
  bLength             :18
  bDescriptorType     :0x01
  bcdUSB              :0x0200
  bDeviceClass        :0x00 (Defined at Interface level)
  bDeviceSubClass     :0x00
  bDeviceProtocol     :0x00
  bMaxPacketSize0     :64
  idVendor            :0x04B4 (Cypress Semiconductor Corp.)
  idProduct           :0x1004
  bcdDevice           :0x0000
  iManufacturer       :1 (Cypress)
  iProduct            :2 (EZ-USB)
  iSerialNumber       :0
  bNumConfigurations  :1
!End Device
-Configuration:
  bLength             :9
  bDescriptorType     :0x02
  wTotalLength        :32
  bNumInterfaces      :1
  bConfigurationValue :0x01
  iConfiguration      :0
  bmAttributes        :0x80
  MaxPower            :50 (100ma)
 -Interface:
    bLength             :9
    bDescriptorType     :0x04
    bInterfaceNumber    :0x00
    bAlternateSetting   :0x00
    bNumEndpoints       :2
    bInterfaceClass     :0xFF (Vendor Specific Class)
    bInterfaceSubClass  :0x00
    bInterfaceProtocol  :0x00
    iInterface          :0
   -Endpoint:
      bLength             :7
      bDescriptorType     :0x05
      bEndpointAddress    :0x02
      bmAttributes        :0x03 (Interrupt)
      wMaxPacketSize      :1024 X 3 (3072 bytes)
      bInterval           :0x02
   !End Endpoint
   -Endpoint:
      bLength             :7
      bDescriptorType     :0x05
      bEndpointAddress    :0x86
      bmAttributes        :0x03 (Interrupt)
      wMaxPacketSize      :1024 X 3 (3072 bytes)
      bInterval           :0x02
   !End Interface
 !End Configuration
 -MSOSV1:
    bDescriptorType     :0x08
    bLength             :02
    bMS_VendorCode      :0x00
    qwSignature         :
 !End MSOSV1
PS C:\libusbK-dev-kit_release> .\kBench.exe list notestselect mode=async
device-count=1
1. EZ-USB (USB\VID_04B4&PID_1004\6&8694159&0&3) [WinUSB]
Select device (1-1) :1

opened EZ-USB (USB\VID_04B4&PID_1004\6&8694159&0&3)..
Loop Test Information
        Driver          : WinUSB
        Vid / Pid       : 04B4h / 1004h
        DevicePath      : \\?\usb#vid_04b4&pid_1004#6&8694159&0&3#{b89f58fd-b8d4-d215-4d39-0cbd5fc94c6c}
        Device Speed    : High
        Interface #     : 00h
        Alt Interface # : 00h
        Num Endpoints   : 2
        Priority        : 0
        Read Size       : 4096
        Write Size      : 4096
        Buffer Count    : 1
        Display Refresh : 1000 (ms)
        Transfer Timeout: 5000 (ms)
        Retry Count     : 0
        Verify Data     : Off

Interrupt Read (Ep86h) Maximum Packet Size: 3072
Interrupt Write (Ep02h) Maximum Packet Size: 3072

While the test is running:
Press 'Q' to quit
Press 'T' for test details
Press 'I' for status information
Press 'R' to reset averages

Press 'Q' to exit, any other key to begin..
Avg. Bytes/s: 10217361.02 Transfers: 6008 Bytes/s: 10217361.02
Avg. Bytes/s: 10220688.83 Transfers: 12070 Bytes/s: 10224672.79
Avg. Bytes/s: 10230490.22 Transfers: 18076 Bytes/s: 10250240.00
Avg. Bytes/s: 10235536.74 Transfers: 24083 Bytes/s: 10250752.00
Avg. Bytes/s: 10237243.47 Transfers: 30084 Bytes/s: 10244096.00
Avg. Bytes/s: 10213852.43 Transfers: 36095 Bytes/s: 10098393.70
Avg. Bytes/s: 10237089.84 Transfers: 42100 Bytes/s: 10379413.85
Avg. Bytes/s: 10242299.69 Transfers: 48105 Bytes/s: 10279478.11
Avg. Bytes/s: 10225146.27 Transfers: 54113 Bytes/s: 10089826.77
Avg. Bytes/s: 10240310.16 Transfers: 60118 Bytes/s: 10379413.85
Avg. Bytes/s: 10238514.73 Transfers: 66182 Bytes/s: 10221189.04
Avg. Bytes/s: 10233624.97 Transfers: 72244 Bytes/s: 10180535.43
Avg. Bytes/s: 10234192.07 Transfers: 78246 Bytes/s: 10241024.00
Avg. Bytes/s: 10235042.93 Transfers: 84251 Bytes/s: 10246144.00
Avg. Bytes/s: 10235678.61 Transfers: 90253 Bytes/s: 10244608.00
Avg. Bytes/s: 10235245.96 Transfers: 96252 Bytes/s: 10228736.00
Avg. Bytes/s: 10236155.57 Transfers: 102259 Bytes/s: 10250752.00
Avg. Bytes/s: 10236879.26 Transfers: 108263 Bytes/s: 10249216.00
Avg. Bytes/s: 10235380.72 Transfers: 114315 Bytes/s: 10208982.38
Avg. Bytes/s: 10235125.51 Transfers: 120321 Bytes/s: 10230718.42
Avg. Bytes/s: 10240170.16 Transfers: 126379 Bytes/s: 10341376.00
waiting for Ep86h thread..
stopped Ep86h thread.   ExitCode=0
stopped Ep02h thread.   ExitCode=0
Loop Test Information
        Driver          : WinUSB
        Vid / Pid       : 04B4h / 1004h
        DevicePath      : \\?\usb#vid_04b4&pid_1004#6&8694159&0&3#{b89f58fd-b8d4-d215-4d39-0cbd5fc94c6c}
        Device Speed    : High
        Interface #     : 00h
        Alt Interface # : 00h
        Num Endpoints   : 2
        Priority        : 0
        Read Size       : 4096
        Write Size      : 4096
        Buffer Count    : 1
        Display Refresh : 1000 (ms)
        Transfer Timeout: 5000 (ms)
        Retry Count     : 0
        Verify Data     : Off

Interrupt Read (Ep86h) Maximum Packet Size: 3072
        Total Bytes     : 45186048
        Total Transfers : 88254
        Avg. Bytes/sec  : 2046654.95
        Elapsed Time    : 22.08 seconds

Interrupt Write (Ep02h) Maximum Packet Size: 3072
        Total Bytes     : 180736000
        Total Transfers : 44125
        Avg. Bytes/sec  : 8186248.75
        Elapsed Time    : 22.08 seconds

Press any key to exit..

FW source codes -- minor modifiction from Cypress BulkSrcSink to use Interrupt Endpoint.

Take note WIndows will not be able to enumerate the device if bInterval = 1 for both Interrupt IN/OUT endpoint in this case.

Int_src_3072.zip

libusbK allows claiming the interface from different applications at the same time

From libusb project

libusb/libusb#807

libusb/libusb#807 (comment)

This is really a libusbK issue. The underlying driver is responsible for enforcing mutual exclusion, so I'm going to close this.

Maybe something can be done from libusbk side.

Potential issue of libusbk.sys

Ref: libusb/libusb#622

The issue with libusb0.sys has been fixed in the libusb-win32 snapshot release (unsigned). Maybe libusbk.sys still has the issue.

During our trial to be compatible with HCVI mode in windows 10 version 1809 or later, we run the following command verifier.exe /flags 0x02000000 /driver <driver.sys> (https://docs.microsoft.com/en-us/windows-hardware/test/hlk/testref/driver-compatibility-with-device-guard).

When the device using the driver libusb0.sys is plugged, it causes a bluescreen with DRIVER_VERIFIED_DETECTED_VIOLATION.

Also tested with LibusbK.sys and ended with same bluescreen with DRIVER_VERIFIED_DETECTED_VIOLATION.

libusb-win32 developer community fixed it in the following release https://sourceforge.net/projects/libusb-win32/files/libusb-win32-snapshots/20190918/ and source code in git : mcuee/libusb-win32@9afd01f

libusbk and libusbdotnet

Ref: LibUsbDotNet/LibUsbDotNet#158

Supposedly libusbk.sys is almost a drop in replacement of libusb0.sys, so by right it should work together with libusbdotnet. Somehow it does not. I am not so sure why.

ISO-transfer and USB HUB

I developing both the device and host end for an embedded system, where the host will serve as a control "panel" for the device.

I am using C# binding for libusbK, where i am having some issues, which i now believe i have point pointed to somewhere in my host application.

The issue:
I am using iso-transfers between the host and device to "steam" process data. This works fine without a hub attached, but once the host and device communicates through any usb HUB i get issues. Based on my USB analysis tool (Beagle 480), it seems that the following code generates 2 iso-transfer requests:

public int SubmitNextRead()
        {
            // Pull from head of Completed list and push to end of Outstanding list
            IsoTransferItem isoTransferItem = Completed.First.Value;
            Completed.RemoveFirst();
            Outstanding.AddLast(isoTransferItem);

            // Prepare the OvlK handle to be submitted.
            OvlK.ReUse(isoTransferItem.Ovl);

            // Set the frame number this transfer will be submitted on (used for logging only)

            //isoTransferItem.FrameNumber = isoTransferItem.Container.FrameNumber;
            uint currentFrameNumber = 0;
            this.Usb.GetCurrentFrameNumber(out currentFrameNumber);
            //Program.Test.LogLn("#StartFrame={0:X8}h, currentFrame={1:X8}h", isoTransferItem.Container.FrameNumber, currentFrameNumber);
            currentFrameNumber += 10;
            // submit the transfer. use 0 for length and 0 for number of packets to use the values the isoch handle was initialized with
            //Usb.IsochReadPipe(isoTransferItem.Iso.Handle, 0, ref isoTransferItem.Container.FrameNumber, 0, isoTransferItem.Ovl);
            Usb.IsochReadPipe(isoTransferItem.Iso.Handle, 0, ref currentFrameNumber, 1, isoTransferItem.Ovl);
            //Usb.IsochReadPipe();

            //byte[] test = new byte[1500];
            //Usb.IsoReadPipe(0x82, ref test, 1500, isoTransferItem.Iso.Handle, null);
            // IsochReadPipe will always return false so we need to check the error code
            int errorCode = Marshal.GetLastWin32Error();

            // 997 is ERROR_IO_PENDING. For async, this means so far so good.
            // IE: The transfer is submitted but we won't know if a problem occurs until it is completed.
            if (errorCode != ErrorCodes.IoPending)
            {
                //Completed.RemoveFirst();
                //Outstanding.AddLast(isoTransferItem);
                Completed.AddFirst(isoTransferItem);
                Outstanding.RemoveLast();
                return errorCode;
            }

            return 0;
        }

I came to that conclusion by placing a breakpoint right after this line, but the USB-sniffer report that the request was made twice. see the screenshot below. Because 2 requests are quickly after each other, the device if unable to re-arm the endpoint in time, and the resulting in a data payload of 0-bytes for the following transfer request. How, this does not always happens.

The issues get worse with large data payload, and do not occur for every transfer. I am really puzzled by this, and it might not be related to libusbK, but i was hoping someone might have an idea. Does anyone know if there exists some tool/software where i could quickly test this issue?

The screenshot below shows that this "double" event does not always occur. Ideally, I am trying to send a request every 10 frames, which can also be seen on the timestamp. However, when i have the double event the second event is always right after the first..

The device: microchip DSPIC33.

If this is outside the scope of this library, i am sorry.

kList -- add an option to use external usb.ids file

usb.ids file is here. Maybe it is good to add an option for the users to use the following URL for the latest usb.ids file or maybe a newer version of the file in the current directory.
http://www.linux-usb.org/usb.ids