libusbk does not list the USB device using WCID

[mcuee]

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).

[mcuee]

Ref: https://github.com/pbatard/libwdi/wiki/WCID-Devices https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/microsoft-defined-usb-descriptors

[mcuee]

Apparently Microsoft's old recommendation on the WinUSB inf is using DeviceInterfaceGUIDs. https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/winusb-installation#inf libusbK is written in a way to look for DeviceInterfaceGUIDs.

;
;
; Installs WinUsb
;

[Version]
Signature = "$Windows NT$"
Class     = USBDevice
ClassGUID = {88BAE032-5A81-49f0-BC3D-A4FF138216D6}
Provider  = %ManufacturerName%
CatalogFile = WinUSBInstallation.cat
DriverVer=09/04/2012,13.54.20.543

; ========== Manufacturer/Models sections ===========

[Manufacturer]
%ManufacturerName% = Standard,NTamd64

[Standard.NTamd64]
%DeviceName% =USB_Install, USB\VID_0547&PID_1002

; ========== Class definition ===========

[ClassInstall32]
AddReg = ClassInstall_AddReg

[ClassInstall_AddReg]
HKR,,,,%ClassName%
HKR,,NoInstallClass,,1
HKR,,IconPath,%REG_MULTI_SZ%,"%systemroot%\system32\setupapi.dll,-20"
HKR,,LowerLogoVersion,,5.2

; =================== Installation ===================

[USB_Install]
Include = winusb.inf
Needs   = WINUSB.NT

[USB_Install.Services]
Include =winusb.inf
Needs   = WINUSB.NT.Services

[USB_Install.HW]
AddReg=Dev_AddReg

[Dev_AddReg]
HKR,,DeviceInterfaceGUIDs,0x10000,"{9f543223-cede-4fa3-b376-a25ce9a30e74}"

; [DestinationDirs]
; If your INF needs to copy files, you must not use the DefaultDestDir directive here.  
; You must explicitly reference all file-list-section names in this section.

; =================== Strings ===================

[Strings]
ManufacturerName=""
ClassName="Universal Serial Bus devices"
DeviceName="Fx2 Learning Kit Device"
REG_MULTI_SZ = 0x00010000

[mcuee]

But then for WinUSB device mentioned here https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/automatic-installation-of-winusb Microsoft changed to use DeviceInterfaceGUID.

To identify a USB device as a WinUSB device, the device firmware must have these Microsoft OS Descriptors.

Supporting extended feature descriptors

In order for the USB driver stack to know that the device supports extended feature descriptors, the device must define an OS string descriptor that is stored at string index 0xEE. During enumeration, the driver stack queries for the string descriptor. If the descriptor is present, the driver stack assumes that the device contains one or more OS feature descriptors and the data that is required to retrieve those feature descriptors.

The retrieved string descriptor has a bMS_VendorCode field value. The value indicates the vendor code that the USB driver stack must use to retrieve the extended feature descriptor.

For information about how to define an OS string descriptor, see "The OS String Descriptor" in the Microsoft OS Descriptor Specification.

Setting the compatible ID

An extended compat ID OS feature descriptor that is required to match the in-box Winusb.inf and load the WinUSB driver module.

The extended compat ID OS feature descriptor includes a header section followed by one or more function sections depending on whether the device is a composite or non-composite device. The header section specifies the length of the entire descriptor, number of function sections, and version number. For a non-composite device, the header is followed by one function section associated with the device’s only interface. The compatibleID field of that section must specify "WINUSB" as the field value. For a composite device, there are multiple function sections. The compatibleID field of each function section must specify "WINUSB".

Registering a device interface GUID

An extended properties OS feature descriptor that is required to register its device interface GUID. The GUID is required to find the device from an application or service, configure the device, and perform I/O operations.

In previous versions of Windows, device interface GUID registration is done through the custom INF. Starting in Windows 8, your device should report the interface GUID by using extended properties OS feature descriptor.

The extended properties OS feature descriptor includes a header section that is followed by one or more custom property sections. The header section describes the entire extended properties descriptor, including its total length, the version number, and the number of custom property sections. To register the device interface GUID, add a custom property section that sets the bPropertyName field to "DeviceInterfaceGUID" and wPropertyNameLength to 40 bytes. Generate a unique device interface GUID by using a GUID generator and set the bPropertyData field to that GUID, such as "{8FE6D4D7-49DD-41E7-9486-49AFC6BFE475}". Note that the GUID is specified as a Unicode string and the length of the string is 78 bytes (including the null terminator).

[mcuee]

libusbK.dll needs to be changed to accommodate both DeviceInterfaceGUID and DeviceInterfaceGUIDs.

[mcuee]

Ref: https://www.osronline.com/showthread.cfm?link=289556

xxxxx@gmail.com wrote:

I have a doubt with regard to the two documentations from Microsoft.

1) The following document is clear to use "DeviceInterfaceGUID" and ... 2) However, in the other official Microsoft document here, the sample inf uses "DeviceInterfaceGUIDs", ... Question: which is correct? Or the device can use both?

If you do a hex dump of winusb.sys, you'll see that it contains both strings. The original author probably made one choice, someone else accidentally used the wrong one in an important place, and the author was forced to add support for both.

So, basically, you can use either one.

Another question, in the above question, it is saying that WinUSB has a limitation so that it can not be used to retrieve the Extended Properties Feature Descriptor. Is this correct? Is the limitation a bug or a feature?

It's a security feature. You are only allowed to make interface-related requests on the interfaces that you have been assigned.

-- Tim Roberts, xxxxx@probo.com Providenza & Boekelheide, Inc.

[TravisRo]

Yes. Microsoft do that to us. I've added support for both "DeviceInterfaceGUID" and "DeviceInterfaceGUIDs" to the DLL but the libusbK driver will still require the latter.