Ports and Interfaces > USB
HID compliant device not recognized by Windows 10
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.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version