none
UMDF v2 USB template gives 'Device cannot start' after call with uninitialized parameter RRS feed

  • Question

  • I am trying to create a Windows 10 compatible driver for a simple legacy USB 1.1 device. So far, I succeeded to build a KMDF driver using the KMDF USB template. After changing the VID/PID, my target system was able to start the driver. Then I filled the MyDeviceEvtIoDeviceControl function in Queue.c with some USB control transfer calls and created a symbolic link to communicate with legacy applications. The driver works correctly.

    However, when I try to achieve the same with the UMDF v2 USB template, I run into all kinds of problems. After changing the VID/PID, the debugger hits a breakpoint after loading WINUSB.DLL, for which I don't have the code. After continuing, the driver stops in Device.c where the template generated code calls WdfUsbTargetDeviceCreateWithParameters with an uninitialized &createParams config argument. The device manager then shows "The device cannot start. The specified information record length does not match the length required for the specified information class.". WdfUsbTargetDeviceCreate documentation advises to use WdfUsbTargetDeviceCreateWithParameters with UMDF 2.0 drivers, which suggests to initialize the config with USBD_CLIENT_CONTRACT_VERSION_602, but this constant seems to be unavailable for UMDF drivers.

    I prefer to use UMDF v2 instead of KMDF because of the less strict signing requirements for Windows 10 64-bit, but the template code seems to be a work in progress? Did anybody succeed to create a working driver with this template? Is there a NativeUSB version available?

    I tried the following versions:

    Visual Studio Community 2017 version 15.4.4, version 15.4.5, version 15.5.1
    WDK for Windows 10, version 1709
    Windows 10 Pro version 1709 build 16299.125

    Loaded module 'C:\Windows\System32\WINUSB.DLL', Symbol status: <Deferred>
    Loaded module 'C:\WINDOWS\System32\KERNEL32.DLL', Symbol status: <Symbols loaded>
    The thread 'Thread 0x8' (0x8) has exited with code 1852990827 (0x6e72656b).
    Loaded module 'C:\Windows\System32\WUDFHost.exe', Symbol status: <Deferred>
    Loaded module 'C:\Windows\System32\drivers\UMDF\MyDevice.dll', Symbol status: <Deferred>
    Loaded module 'C:\Windows\System32\WUDFHost.exe', Symbol status: <Deferred>
    Loaded module 'C:\WINDOWS\System32\KERNEL32.DLL', Symbol status: <Symbols loaded>
    Loaded module 'C:\Windows\System32\WppRecorderUM.dll', Symbol status: <Deferred>
    Loaded module 'C:\Windows\System32\dbghelp.dll', Symbol status: <Deferred>
    Loaded module 'C:\Windows\System32\WUDFHost.exe', Symbol status: <Deferred>
    Loaded module 'C:\Windows\System32\WUDFx02000.dll', Symbol status: <Deferred>
    The thread 'Thread 0x5' (0x5) has exited with code -268370176 (0xf000ff00).
    The thread 'Thread 0x6' (0x6) has exited with code -1241696281 (0xb5fd37e7).
    The thread 'Thread 0x7' (0x7) has exited with code 0 (0x0).
    The thread 'Thread 0x4' (0x4) has exited with code 404762236 (0x18202e7c).
    The thread 'Thread 0x8' (0x8) has exited with code 404796800 (0x1820b580).
    The thread 'Thread 0x2' (0x2) has exited with code -2147451008 (0x80007f80).
    The thread 'Thread 0x1' (0x1) has exited with code 0 (0x0).
    The thread 'Thread 0x3' (0x3) has exited with code 66 (0x42).
    The thread 'Thread 0x9' (0x9) has exited with code 404762380 (0x18202f0c).
    The program '[0x27D8]' has exited with code 7 (0x7).

    Wednesday, December 13, 2017 4:26 PM

All replies

  • I prefer to use UMDF v2 instead of KMDF because of the less strict signing requirements for Windows 10 64-bit,

    all drivers, UMDF or KMDF or WDM, have the same signing requirements.


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, December 13, 2017 6:05 PM
  • Yes, the template is missing the call to  WDF_USB_DEVICE_CREATE_CONFIG_INIT to initialize the createParams, you need to add it. USBD_CLIENT_CONTRACT_VERSION_602 is defined in usbdlib.h, but is meant to be consumed only by kernel mode compilation targets. In the interim, you can define it on your own

    #define USBD_CLIENT_CONTRACT_VERSION_602 0x602

    I will ask the USB team look at these issues.


    d -- This posting is provided "AS IS" with no warranties, and confers no rights.

    Wednesday, December 13, 2017 6:15 PM
  • You can refer to this OSR USB Fx2 sample that uses NativeUSB. UMDF V2 NativeUSB Sample
    Wednesday, December 13, 2017 7:22 PM
  • Thanks for the fast responses! As Doron Holan suggested, I added the following call before WdfUsbTargetDeviceCreateWithParameters:

    WDF_USB_DEVICE_CREATE_CONFIG_INIT(&createParams, 0x602);

    Unfortunately, the driver is still not able to start. According to the debugger, WdfUsbTargetDeviceCreateWithParameters now returns STATUS_UNSUCCESSFUL (0xc0000001).

    I analyzed the USB communication and it shows that the the user mode reflector driver uses a slightly different device initialization sequence compared to KMDF. After enumerating all USB descriptors, the UMDF driver also sends a GET STATUS Request to the USB device. It turns out that my device is not fully USB compliant and does not answer this request. I tried both WinUSB and NativeUSB as Shyamal Varma suggested, but in both situations the request is sent. I also tried to acquire the power policy ownership but this does not help. Any other ideas how to prevent the GET STATUS request from being sent to the device?

    About the signing requirements, the documentation says that driver packages need a digital signature. Additionally, it says that *kernel mode* drivers need to be signed with an EV certificate and then submitted to Microsoft for cross signing in order to use it without test mode enabled. From what I understand, a UMDFv2 driver is a user mode driver, not a kernel mode driver. The package only contains the DLL and may use the WinUSB kernel driver that is already signed and present on the system. I thought I can put my code as open source on github and then get away with a cheap open source code signing certificate to sign the package. 

    I understand that EV signing and submission to Microsoft are there for a reason. Secure boot doesn't make sense without proper signatures for kernel mode drivers, but I don't understand why a regular code signing certificate would be insufficient for user mode drivers. Note that I do not want to distribute the driver through Windows update. Manual installation is fine and a warning that the driver is not WHQL certified is acceptable as long as the user does not need to disable secure boot or enable test mode.

    • Edited by paperclipke Thursday, December 14, 2017 2:21 PM USB analysis added
    Wednesday, December 13, 2017 9:21 PM