This post has been republished via RSS; it originally appeared at: Microsoft USB Blog articles.First published on MSDN on May 14, 2015
The purpose of this blog post is to provide a resource with solutions to common problems encountered in the USB tests within the Windows 10 Hardware Lab Kit (HLK). This blog will be categorized into the following areas: “Recent/Upcoming Fixes”, “Known Issues” and “Common Questions.”
As you run these tests, please continue to provide feedback! This blog post will be updated as necessary with new guidance as it arises and old items will be phased out as test updates become widely available.
Common QuestionsUSB Internal Device Idle Test
Why is the USB Internal Device Idle Test failing? The system does not have internal devices or they are all suspended and the test still does not pass?
Please ensure that all external USB devices are unplugged from the system under test before scheduling the test. Failure to remove all external USB devices often results in a test failure indicating that a device or multiple devices failed to suspend. All internal devices should support suspend and go to suspend during a period of inactivity.
USB-IF Certification Validation Test (Device)
I ran the USB-IF compliance tests myself, do I need to submit the logs via the HLK?
This test records the status of USB-IF certification for the device under test. There are two ways to assert USB-IF certification. The first option is to get full certification from the USB-IF and submit the test ID (TID) supplied by the USB-IF. The second option is to download the USB-IF Compliance tools online (see test documentation for more details) and run them yourself on the device under test. If you have run and passed the required USB-IF tests yourself, then you will simply submit the following Test ID (TID) when scheduling the test in the HLK: SELF_TEST . Using this Test ID is an assertion that the device under test has completed and passed all required USB-IF testing.
Recent/Upcoming FixesUSB Exposed Port Test
Had a bug handling non-contiguous xHCI root port numbers. Manifested as a crash in the TAEF framework. Fixed in 10120.
USB3 Termination Test
1) Had a bug handling non-contiguous xHCI root port numbers. Manifested as an error stating that there was an “invalid string” encountered. Fixed in 10120.
2) Unable to pass on systems without a user-connectable SuperSpeed capable USB port. The fix will be available in an upcoming release of the kit.
3) The USB3 Termination Test requires a SuperSpeed device to be attached downstream from a SuperSpeed xHCI port. However a bug in the test precludes most SuperSpeed storage devices from being recognized. For now, please use a SuperMUTT device, or other SuperSpeed device without a USB serial number, to run the test. The fix will be available in an upcoming release of the kit.
USB Generic HID Test
This test requires a SuperMUTT. The version 43 firmware that shipped in an early release of the HLK caused this test to fail. Current version 44 of the firmware shipping in the latest EEAP release resolves the issue. Update to the latest HLK and from the system project, run the MUTT Firmware Update for Systems job with the SuperMUTT connected to the system, and the new firmware will be applied. Fixed in 10108.
To determine the firmware version on the SuperMUTT device, first attach the device to a Windows PC. Open the Device Manager and locate the “SuperMUTT” under the “Universal Serial Bus devices” group. Double click the SuperMUTT to open the Properties window and open the Details tab. Select the “Hardware Ids” property. You will see a hardware Id string like the following: USB\VID_045E&PID_078F&REV_0044. The last number is the firmware version number, in this example it is version 44. If your device ID shows REV_0043, you need to follow the procedure above to update to version 44.
Known IssuesUSB (USBDEX) Verifier Test Problem
A kit infrastructure issue is causing this test to fail to load the correct logging module in recent release of the kit which cases the “Disable Flags” setup task to fail. Expanding the error simply shows it failing with exit code 1.
The work-around for running this test until the kit infrastructure issue is resolved is to manually register the appropriate logging module:
- On the client PC, open an administrator command prompt
- Navigate to the following folder: <SystemDrive>:\Program Files\Windows Kits\10\Hardware Lab Kit\Client\
- Run: “regsvr32 /s wttlogcm.dll”
- Re-schedule the test through the HLK Studio
USB Serial Number Test Problem
There is a known limitation in this test such that if the device under test provides a serial number, both instances must be in D0 for the test to correctly read the serial number strings. The failure pattern is an error statement saying that the serial number string was not NULL terminated, which is incorrect, the test actually wasn’t able to retrieve it at all.
Ensure that the device is in D0 when the test runs. The test run only takes a few seconds so this can be as simple as re-attaching in the devices immediately before scheduling the test so it executes before the suspend timeout occurs, or using the device during the test (move/click input device, access network, read/write files, etc.)USB Device Connection S3 + S4 + Connected Standby And USB Hardware Verifier Test Problem
These tests may fail on some systems with incomplete xHCI port mapping reported by the system. This is a problem with the HLK client PC firmware, not with the device under test. The failure pattern is an error statement saying that “IOCTL_USB_GET_PORT_CONNECTOR_PROPERTIES returned invalid port number.”
Fortunately on common platforms we have seen with this issue, the problematic port mapping is only for a few of the ports, and other ports are properly mapped and able to fully support device level testing. To find a usable port, run USBView, and be sure the device under test is connected to a port with a non-zero “Companion Port Number”. Unfortunately some tests are dependent on the Device Instance ID so you cannot simply change ports during the middle of a test project, if for example the device does not support a unique serial number. If you find that the host platform has this port mapping problem, you may need to re-create the project with the device under test connected to one of the good ports.
USB xHCI Transfer Speed Test And USB3 Termination Test Problem
These are system level tests that fail for the same reason as USB Device Connection and USB Hardware Verifier tests: incomplete xHCI port mappings reported by the system. Since these are system tests, this is indeed a problem with the system under test that needs to be corrected. However the USB Exposed Port Test is specifically checking the port mappings and it is still valuable to validate the transfer speed and SuperSpeed terminations on these platforms. The failure pattern will manifest as an error stating that an “invalid” device or port was detected.
Attach the SuperSpeed device, for example a SuperMUTT, to a port on the system that is properly mapped. You can confirm in USBView if there is such a port on the system by checking the SuperSpeed port nodes for one where the “Companion Port Number” is non-zero.USB3 Termination Test Problem
The test may fail with the following error indicating that no USB 2.0 companion ports were found in the ETW rundown:
Errata number 5597 has been provided to filter out this error. Please apply the latest errata to your submission if you see this error in the test log for the USB3 Termination Test.