HID compliant device not recognized by Windows 10

[yossef cohen]

Hi all,

We have a proprietary USB device which has HID interface (no subclass).
It is finely detected in Windows 7 and is recognized as USB Input device (under the Human Interface Devices).
See attached picture

However when connecting it to Windows 10 it is failing to install correctly (see attached picture).

I searched for information but without success.

Could you help telling what could be the reason?

Thanks a lot

[Jan Axelson]

First step - view the Windows device installation file. Google for info on how to view.

A USB protocol analyzer can also offer clues.

[yossef cohen]

Hi Jan,

Thank you for your answer.

I attach the files:
1) The setupapi.dev.log  (hoping it is the file you are talking about!)
2) 2 Log files from Beagle 12 USB analyzer. One of WIndows 7 and one of Windows 10

I will be happy to get some help !!!

Thanks a lot
 

[Jan Axelson]

Can you post the tdc files as images?

[yossef cohen]

Hi Jan,

Please use this link to get the files (too big to upload to your forum)

https://we.tl/jH50NsP2yJ

Thanks in advance for your help.

[Jan Axelson]

Re the setupapi message "Additional software is requested so a WER report should be sent, but the sending of WER reports from drvinst has been suppressed." see:

https://msdn.microsoft.com/en-us/library/windows/desktop/bb513613(v=vs.85).aspx

Regardless, it appears that the OS installed the device as a generic HID (no additional filter drivers).

In the analyzer logs, you want to look for anything that doesn't look right, for example:

An interrupt IN token packet where the endpoint didn't return NAK or data.

An interrupt OUT token packet where the endpoint didn't return NAK or ACK.

In a control transfer, a Setup packet where the endpoint didn't return ACK.

In a control Read transfer, a Data stage where the endpoint didn't return NAK or data or a Status stage where the endpoint didn't return ACK or NAK.

In a control Write transfer, a Data stage where the endpoint didn't return NAK or ACK or a Status packet where the endpoint didn't return NAK or a 0-length data packet.

After a few failures of these types, the OS will report a problem and stop trying to communicate.

It's possible to have a device that works under Win7 but fails under Win10 because that OS does things a little differently and exposes a problem with the device.

[yossef cohen]

Hi Jan,

You said:
"It's possible to have a device that works under Win7 but fails under Win10 because that OS does things a little differently and exposes a problem with the device."

OK! So, do I have something to do with the device? We cannot change the firmware to be compatible to Windows 10. Is it possible to resolve the issue from Windows 10?

Thanks

[Jan Axelson]

The problem is very likely with the device, not the OS. An earlier host system may have been more forgiving of devices that don't fully comply with the specs, or the host might just perform differently (for example, as I recall, years ago, problems with some devices surfaced when an OS reduced the delays between the stages of control transfers).

In any case, the first step is to identify the source of the problem.

[ulao]

Not going to help much but sharing my experience.  Windows has always been rather sloppy when it comes to usb. Things like not enforcing power rules and allowing for some crummy descriptors. Windows 10 is the first time in a long time where Microsoft decided to revisit the kernel code for the USB. Now like Linux windows is going to make sure you cross your T's and dot your I's. Its good but on the same token a pain. Especially if you have firmware that you know works on earlier Windows.  Chances are your device or report descriptors have a type-o or bug.

[yossef cohen]

Thanks ulao and Jan for your efforts to help.

1) Which tools do you recommend to use in order to analyze and diagnose the problem?
May CV 2.0 help?

Assuming the device is HID compliant (without specific subclass), is there a tool which could help to point out exactly on the problem?

2) Assuming the issue is within the device, is there a way to bypass it by writing a dedicated Windows driver? Do you have any recommendation\tips...?

Thanks a lot.

[Jan Axelson]

If the device isn't installing, check the setupapi device installation file:

https://docs.microsoft.com/en-us/windows-hardware/drivers/install/setupapi-device-installation-log-entries

If the device does install, use single-stepping and breakpoints to determine what your application is seeing when it looks for the device.

A protocol analyzer can also offer clues. A hardware-based analyzer can show transaction-level detail:

http://janaxelson.com/development_tools.htm#analyzers

Any driver you write will need to be digitally signed.

https://msdn.microsoft.com/en-us/library/windows/hardware/hh406260(v=vs.85).aspx

http://janaxelson.com/usb_host_software.htm#generic_drivers

[yossef cohen]

Hi,

In previous reply, I have attached the setupapi.dev.log.

Is there someone who could comment\explain what is the error which causes the device to be not started and rejected !!

Thanks a lot

[Jan Axelson]

The setupapi log shows that the device successfully enumerated as a HID, but when the OS attempted to use (start) the device, the communications failed.

So you know that the descriptors and enumeration are likely OK. 

A protocol analyzer will show what happened when the OS tried to use the device. For example, for a HID, the OS will typically begin sending interrupt IN token packets, and the IN endpoint must respond with NAK or data.

If you don't have a protocol analyzer, use whatever other tools you have to try to isolate the problem (watchpoints, breakpoints, etc.)

[yossef cohen]

Hi,

Someone helped me to find out the problem.

Your USB device is reporting an invalid USB version (USB version 10.01, rather than 1.0, 2.0,2.1 or 3.0 which are the current existing USB versions):

High USB versions are required to supply a BOS descriptor. Starting windows 8, MS enforces this and fails enumeration for devices that do not supply a BOS descriptor:

For Windows 8 MS supplied a workaround,  I assume this will work also for windows 10, but I don't have the actual device in order to test:

Workaround
To apply the workaround for a specific device, add a REG_DWORD value named SkipBOSDescriptorQuery that has a value of 1 to the following registry subkey:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\usbflags\vvvvpppprrrr
(where vvvv is the device's Vendor ID, pppp is the device's Product ID, and rrrr is the device's Revision number. You can get the VID/PID/REV numbers from the device manager's details tab. This number is encoded in the HardwareIDs of the device)
1. Click Start, click Run, type regedit in the Open box, and then click OK .
2. Locate and then click the following subkey in the registry:
        HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\UsbFlags
3. On the Edit menu, point to New, and then click Key.
4.Type the name of the new key in the following form:
        vvvvpppprrrr
        where
        vvvv is a 4-digit hexadecimal number that identifies the vendor (idDevice from the USB Deviceescriptor),
        pppp is a 4-digit hexadecimal number that identifies the product (idVendor from the USB Device Descriptor)
        rrrr is a 4-digit binary-coded decimal number that contains the revision number of the device
              (bcdDevice from the USB Device Descriptor).
5. On the Edit menu, point to New, and then click DWORD (32-bit) Value.
6. Type SkipBOSDescriptorQuery for the name of the DWORD Value, and then press ENTER.
7. Right-click SkipBOSDescriptorQuery, and then click Modify.
8. In the Value data box, type 1 , and then click OK.
9. Exit Registry Editor.
10. Unplug and re-plug the device for the workaround to take effect.

Creating the registry key bypasses the problem.

Thanks to all for the efforts !!

[ulao]

USB version 10.01, rather than 1.0

Endianness can bite you.