Microsoft USB Blog articles

USB Driver Documentation Updates on UCSI, USB4 Testing

Ugan-Sivagnanenthirarajah — Fri, 27 Feb 2026 00:17:38 GMT

Over the past few months, we've been running a freshness pass across the USB driver documentation on Microsoft Learn and the USB4 design guidelines. The goal is straightforward: make sure the docs match the current Windows 11 driver stack, read clearly, and get you to the answer faster. Here's what changed.

USB4 required testing: new Basic Validation Tests

The USB4 ecosystem has grown significantly. As the number of USB4 router implementations grows, so does the need for a clear, repeatable validation baseline. We added a new Basic Validation Tests section to the USB4 Required Testing page.

The existing page already listed the recommended end-to-end test scenarios: driver verifier, domain power-down, wake replay, interdomain connections, and so on. What was missing was a concise set of smoke tests that OEMs and IHVs could run quickly to catch regressions in incremental USB4 firmware and driver updates without needing a full test pass. The new section fills that gap with nine concrete test scenarios:

USB4 HLK Tests: run all System.Fundamentals.SystemUSB.USB4.* and Device.BusController.USB4.* tests.
Basic Enumeration: attach a USB4 dock and a Thunderbolt 3 dock, each with a display, USB3 storage, and USB2 input. Verify clean enumeration in Device Manager, functional input, file copy, and display extension.
Display: verify two 4K displays at 60 Hz concurrently, both tunneled through a USB4 dock and directly via DisplayPort Alt Mode.
Camera (Isochronous) Streaming: stream from a USB3 camera through a USB4 dock for at least one minute with no visible glitches.
System Standby: attach a full dock topology, cycle standby five times with 30-second to 2-minute waits, and verify all devices survive each transition.
System Reboot: same topology, same verification, but with a full reboot instead of standby.
System Hibernate: same again, with hibernate.
Minimal Compatibility and Interoperability: test at least 3 display models and at least 10 USB4 dock or device models spanning Intel Thunderbolt 4, Intel Thunderbolt 5, Via USB4, Asmedia USB4, Realtek USB4, Intel Thunderbolt 3 Titan Ridge, and Intel Thunderbolt 3 Alpine Ridge.
Basic Plug/Unplug with USB4 Switch: configure the USB4 Switch with a USB4 dock on port 1 and a Thunderbolt 3 dock on port 2, run ConnExUtil.exe /cxstress for a minimum of 15 minutes (24+ hours for long-term stability), then verify the port still enumerates and charges after the test.

Each test includes explicit pass criteria: no yellow bangs, no visual glitches, expected resolution and refresh rates confirmed in the Advanced Display settings. The interoperability test (test 8) is particularly important as USB4 matures: it ensures your platform works across the full range of silicon vendors, not just the one on your bench.

If you're validating USB4 firmware or driver updates and need a quick confidence check before a broader test pass, this is the list to start with.

UCSI driver docs: cleaned up and refocused on Windows 11

The UCSI driver article got a thorough refresh: updated architecture diagram, clearer UCSI 2.0 _DSM backward-compatibility guidance, reformatted UCSIControl.exe test instructions with proper inline code for registry paths, and consistent code-style formatting across the DRP role detection and charger mismatch example flows. We also removed outdated Windows 10 Mobile references so the article now focuses exclusively on Windows 10 desktop and Windows 11.

USB generic parent driver (Usbccgp.sys): plain language rewrite

The Usbccgp.sys article, the starting point for anyone building composite USB devices, was rewritten for clarity. We simplified jargon-heavy sentences, expanded abbreviations on first use (e.g., "information (INF) file"), updated cross-references to sentence case per the Microsoft Learn style guide, and added customer-intent metadata for better search discoverability.

Community fix: interrupt endpoint direction

Here's a small one that matters more than it looks. In the How to send a USB interrupt transfer (UWP app) article, the Interrupt IN transfers section incorrectly stated that HID devices like keyboards "support interrupt OUT endpoints." Endpoint direction is fundamental (IN means device-to-host, OUT means host-to-device) and getting that wrong in official documentation can send you down entirely the wrong debugging path.

A community contributor spotted the error and submitted the fix. It now correctly reads "interrupt IN endpoints." If you've ever stared at a USB trace wondering why your interrupt transfer wasn't behaving, this might have been part of the confusion.

Thank you to everyone who submits pull requests. This is exactly the kind of contribution that makes the docs better for all of us.

What's next

These updates are part of a broader freshness initiative across the Windows Hardware driver documentation.

If you spot something that looks outdated or confusing, our documentation is open source. Submit a PR on the windows-driver-docs GitHub repository. You can also drop a comment below.

Exploring USB4 in Windows Device Portal

Ugan-Sivagnanenthirarajah — Thu, 27 Nov 2025 02:25:37 GMT

Overview
USB4™ brings high-speed connectivity and advanced tunneling capabilities to modern Windows devices. To help developers and IT professionals visualize and manage USB4 topologies, Windows provides the USB4 domain viewer via the Windows device portal.

A demo of USB4 Domain Viewer in Windows Device Portal.

Key Features of the USB4 Domain Viewer

Topology Visualization
- Displays USB4 host routers (in green) and device routers (in blue).
- Supports click-and-drag navigation and zooming for detailed inspection.
- Automatically updates as the topology changes.
Host Router Details
- Each host router includes Name, VendorId, and DeviceId.
- Selecting a router reveals additional details in the sidebar.
Device Router Details
- Shows adapters and ports, distinguishing in-use adapters from unused ones.
- Selecting an adapter highlights it with a red circle for quick identification.
Tunnel Visualization
- Tunnels between device routers are illustrated clearly.
- Each tunnel uses a colon-separated unique ID (e.g., 8:1:1:9) for easy reference.
Context-Specific Sidebar
- Updates dynamically based on selected elements (routers, adapters, tunnels).
- Allows collapsing or expanding details for streamlined viewing.

A Legend of the different areas of USB4 Domain Viewer

Why It Matters

The USB4 Domain Viewer simplifies troubleshooting and topology analysis for OEMs, IHVs, and developers. By providing real-time visualization and granular details, it accelerates debugging and ensures compliance with USB4 standards.

Getting Started

Access the USB4 Domain Viewer through the Windows Device Portal on supported devices. For more details, visit the official Microsoft Learn documentation.

© 2025 Microsoft. USB4®, USB Type-C® and USB-C®, USB 2.0 Type-C™ are registered trademarks of USB Implementers Forum, Inc. Thunderbolt™ is a trademark of Intel Corporation. This article is not endorsed by or affiliated with USB-IF.

USB Type-C Notifications in Windows: What OEMs Need to Know

Ugan-Sivagnanenthirarajah — Fri, 29 Aug 2025 23:00:00 GMT

Windows 11 includes built-in USB Type-C troubleshooting notifications designed to help users identify and resolve issues like slow charging, unsupported accessories, and faulty connections. These notifications are part of a broader effort to improve device reliability and user experience.

While our previous post focused on the user experience, this update is for OEMs highlighting what’s required to ensure these notifications function correctly on your platforms.

Why Notifications Might Not Appear

USB Type-C notifications rely on accurate platform configuration. If notifications aren’t showing up, it’s often due to:

Missing or incorrect ACPI markup: Windows uses ACPI descriptors to identify USB Type-C ports and their capabilities. If the port isn’t correctly marked as user-accessible or Type-C, notifications may not trigger.
Incorrect connector type reporting: Mislabeling a Type-A port as Type-C (or vice versa) can lead to unexpected behavior or missed alerts.
Internal vs. external port confusion: Ports marked as internal may suppress notifications even if they’re physically accessible to users.

Validation and Testing

To ensure compatibility:

Use the Windows Hardware Lab Kit (HLK) to validate USB port descriptors.
Confirm that _UPC (USB Port Capabilities) and _PLD (Physical Location of Device) ACPI methods are correctly implemented.
Test with various charging scenarios, including underpowered chargers and hubs, to verify that notifications appear as expected. The link below has a table of the notifications and expected behaviours.

Security Considerations

Some OEMs may choose to disable data over USB Type-C in untrusted environments. If implementing such features:

Ensure the policy applies only to externally accessible ports.
Consider offering user toggles for data disablement.
Validate that disabling data doesn’t interfere with critical internal devices (e.g., touchpad, keyboard).

Recommendations for OEMs

Audit ACPI descriptors and USB Device-Specific Method for all USB ports. See https://learn.microsoft.com/en-us/windows-hardware/drivers/bringup/usb-device-specific-method---dsm-#function-7-query-if-_upc-supports-usb-c-port-capabilities-as-defined-in-acpi-specification-65
Validate notification behavior across all supported configurations.
Coordinate with Microsoft WHCP to ensure new platforms meet testing requirements.
Document exceptions clearly if certain ports or configurations are unsupported.

Learn More

For technical details and troubleshooting guidance, refer to the official documentation:
https://learn.microsoft.com/windows-hardware/drivers/usbcon/usb-type-c-troubleshooting-notifications

Ending USB-C® Port Confusion

Ugan-Sivagnanenthirarajah — Tue, 23 Sep 2025 22:58:46 GMT

The Blank Display (and Why It Can Still Happen)

Five minutes before a customer demo, I plug my 4K monitor into the USB-C port on a brand-new laptop. The display doesn’t light up, and now I’m scratching my head—the cable fit, so why isn’t it working?

USB4® carries the promise of a single USB Type-C® port that can do it all – charging, high speed data, multiple displays, and compatibility with Thunderbolt™ peripherals. However, Windows Diagnostics Data shows that 27% of PCs with USB4 have encountered a limited functionality notification, meaning that a customer plugged a USB-C device in, but a feature (alternate mode) that device needs was not implemented on the PC and Windows notified the user. The reversible USB Type-C connector isn’t the problem, the inconsistent implementations of USB-C port capabilities across the PC ecosystem is.

USB Power Delivery on USB-C ports can deliver up to 240 W of power, and USB4 (which is only available over USB-C) can deliver up to 80Gbps bandwidth (up to 120Gbps for Displays), DisplayPort Alt Mode, DisplayPort and PCIe tunneling, and support for Thunderbolt™ peripherals – all through one connector. But the promise of 'universal' in Universal Serial Bus (USB) only matches user expectations if every port delivers a consistent experience, regardless of laptop manufacturer implementation choices.

So why does the demo fail? Because not all USB-C ports are created equal. You can’t tell which ones deliver the full experience just by looking at them. In this case, if the PC doesn’t support DisplayPort Alternate Mode functionality, that monitor won’t light up even though the cable fits. PC manufacturers can implement ports that look identical but differ wildly in functionality: one may charge your laptop and run a 4K display; another might only deliver USB 2.0 data speeds. The USB specification allows this, and without clear enforcement, the consumer experiences frustration, guesswork, and endless troubleshooting.

This isn’t new. As USB specification versions have evolved and added new capabilities, the complexity has sometimes left consumers in the dark, especially when ports aren’t labeled clearly. Most people don’t know what “USB 3.2 Gen 2x2” means or which port supports what features. That’s why we’re pleased to see the USB-IF introduce simpler, clearer branding guidelines like “USB 40Gbps” and “USB 80Gbps”, making it much easier for everyone to understand exactly what each port can do.

We think it’s important for this clear branding to carry through to the actual customer experience with USB-C ports on Windows 11 PCs. While the USB specifications give PC manufacturers the ability to choose which optional features the port supports, we set out to establish a minimum bar for USB-C port capabilities on PCs.

Figure 1 Table of the capabilities required by WHCP for mobile Windows systems

The Windows Hardware Compatibility Program (WHCP) comes in to turn this table into reality – turning optional features into mandatory ones, and ensure a consistent level of performance you can count on. The table above reflects what you can reliably expect from USB-C ports on WHCP-certified mobile PCs.

Some USB 40Gbps and USB 80Gbps ports on Windows 11 PCs are also certified by Intel under the Thunderbolt™ brand, allowing them to be labeled as Thunderbolt™ 4 or Thunderbolt™ 5, respectively. You can rest assured that Thunderbolt™-branded ports meet all the rigorous requirements of both Microsoft’s WHCP program and Intel’s Thunderbolt™ program. Additionally, to qualify to use the Thunderbolt™ brand from Intel, the product must first be certified by the USB-IF.

Two Firm Promises of USB-C on Windows 11

When we set out to improve the USB-C experience with WHCP, we started by defining the customer promises that we wanted to achieve. This came down to two simple goals:

USB Data, Charging and Display “just works” on all USB-C ports: Your favorite USB 1, USB 2, and USB 3 peripherals, chargers and displays will work exactly as advertised on any USB-C port on your WHCP-certified Windows 11 device.

Systems that support USB 40Gbps also give full compatibility with USB4 and Thunderbolt™ 3 peripherals: On a WHCP-certified USB 40Gbps system, you can also plug in any USB4 or Thunderbolt™ 3 device and trust it will work every time on every port.

To ensure that certified Windows 11 PCs deliver on these goals, we introduced new and updated WHCP requirements alongside the release of Windows 11, version 24H2, that are laser focused on them.

What every USB-C port needs to nail WHCP compliance

All mobile systems with USB-C ports

Meeting our first customer promise, that USB Data, Charging and Display “just works” on all USB-C ports, requires any WHCP compliant mobile PC with USB-C to support a baseline set of requirements. No matter what speeds your USB-C ports support, every port can be expected to deliver the following:

You can trust that your devices will work flawlessly, avoiding the frustration of unreliable connections, as we require USB-IF certified silicon in the PC. This guarantees that every connection is robust and reliable through USB-IF certification or equivalent electrical compliance, rigorously tested for compatibility in a lab.

Your devices will charge efficiently and consistently as every USB-C port on a certified PC needs to support USB Power Delivery charging.

DisplayPort Alt-Mode is required for all USB-C ports to support connecting monitors. When you plug a display in, you can feel confident it will work well because the ports have to be VESA certified.

The Microsoft driver stack requirement means PCs are validated using Microsoft’s built-in USB controller drivers. This ensures that security and feature updates arrive via Windows Update, keeping your system secure and up-to-date without any hassle.

All Mobile Systems Advertising USB 40Gbps or 80Gbps Support

WHCP qualified systems with USB 40Gbps or 80Gbps also deliver the second customer promise, full compatibility with USB4 and Thunderbolt™ 3 peripherals, ensuring top-tier performance and compatibility:

This ensures lightning-fast data transfers, making large file transfers and high-speed internet connections a breeze. Baseline bandwidth means every certified Windows 11 PC advertising USB 40Gbps must sustain full speed 40Gbps links on all USB-C ports.

To enable you to expand your system’s capabilities without any compatibility issues, we require PCI Express tunnelling that allows external GPUs and NVMe enclosures to work seamlessly because host routers tunnel PCIe on every port.

You can continue using your favorite peripherals without any interruptions as we require Thunderbolt™ compatibility ensures that existing Thunderbolt™ docks remain plug and play.

DisplayPort requirements ensure support for up to two 4K monitors at 60Hz, providing a stunning visual experience for your work and entertainment.

Finally, sleep and resume resilience ensures that host routers survive low-power states without dropping tunnels. This means your system remains reliable and connected, even when it’s in sleep mode.

WHCP eliminates the worry of powering devices you plug-in by requiring uniform port power requirements ensures that each USB 40Gbps port sources at least 15 W (7.5 W on tablets). Note: USB4 ports on the system must support sourcing at 15W from all ports but not all at the same time. Tablet form factor systems are not required to support 15W but must support at least 7.5W. Systems may limit individual port power below 15W when total requested power across multiple ports exceeds the system’s power budget.

WHCP already covers the next spec bump. Any PC that advertises USB 80 Gbps must meet all the above requirements, while also supporting operation in symmetric 80 / 80 Gbps mode and asymmetric 120 / 40 Gbps mode for increased display bandwidth.

How we enforce it: The Hardware Lab Kit

That “it just works” moment isn’t magic; it’s the result of a tightly choreographed process:

Translate Pain into Policy
We reflect on user feedback, telemetry, and field failures—like the left-port-only monitor issue—and convert each into a discrete WHCP requirement with acceptance criteria.
Author Automated Tests
Our team writes reproducible, automated Windows Hardware Lab Kit (HLK) test cases for every requirement: signaling timing, speed negotiation, power delivery, DisplayPort/PCIe tunnels, sleep/resume resilience, and more.
Partner-Led Validation
OEMs, silicon vendors, and accessory brands run these HLK tests and submit logs to Microsoft. Any failure halts certification until the issue is resolved in hardware or firmware.
Continuous Evolution
WHCP updates with every Windows release. New tests and criteria flow via Windows Update—so fixes and feature enhancements reach end users without new hardware.

Learn how to run HLK tests and meet the USB4 requirements at aka.ms/whcp

If You’re an OEM or Accessory Maker

Robust USB on Windows requires end-to-end testing—protocol compliance, signal integrity, power negotiation and security—and Microsoft’s USB Test Tool (MUTT) suite of hardware and automated scripts streamlines WHCP certification. Download MUTT and dive into the full device-, silicon-, and system-level requirements (including test collateral) for USB4 on Microsoft Learn:

MUTT suite: https://learn.microsoft.com/windows-hardware/drivers/usbcon/microsoft-usb-test-tool--mutt--devices

USB4 requirements: https://learn.microsoft.com/windows-hardware/design/component-guidelines/usb4-required-testing

PC manufacturers are on track to achieve WHCP compliance across most systems in the coming years.

© 2025 Microsoft. USB Type-C® and USB-C®, USB 2.0 Type-C™ are registered trademarks of USB Implementers Forum, Inc. Thunderbolt™ is a trademark of Intel Corporation. This article is not endorsed by or affiliated with USB-IF.

Discover USB Settings and Notifications in Windows 11

Ugan-Sivagnanenthirarajah — Fri, 28 Feb 2025 23:38:59 GMT

USB 40Gbps (also known as USB4) is the latest USB standard, offering faster data transfer speeds, improved power delivery, and better performance. The second revision, USB 80Gbps, (also known as USB4 V2) doubles the maximum data transfer rate to 80Gbps and supports 120Gbps in certain configurations, ensuring faster file transfers and enhanced video output. The benefits include full backwards compatibility with all USB peripherals, compatibility with Thunderbolt peripherals, and support for multiple DisplayPort streams.

USB4's tunneling technology efficiently transfers multiple data and display protocols over a single cable, making it ideal for high-performance applications. The USB4 settings page in Windows 11 provides a centralized location for users to view and manage their USB4 hubs and devices, simplifying the user experience and ensuring optimal performance. This blog post introduces the new USB4 settings page and provides an overview of the various USB settings available in Windows 11.

How can Windows help me with USB?

Windows has features that make using USB devices easy and user-friendly. It handles things like device power management automatically and lets you know if there’s an error. You can tweak these settings in USB Settings. While most users won’t need to change anything, this blog post will help you understand why some of these settings exist. Here are the details.

The options that show under the Windows 11 USB Settings page

Connection Notifications

We’ve designed Windows 11 to be your vigilant assistant, notifying you if there’s an issue connecting a USB device. This feature ensures you’re always in the know and can take immediate action. This lets Windows notify you when it detects a problem with a USB connection. You can learn more about the specific notifications that Windows sends, and what you can do in response to them here: https://support.microsoft.com/windows/fix-usb-c-problems-in-windows-f4e0e529-74f5-cdae-3194-43743f30eed2

Show a notification if this PC is charging slowly over USB

Did you know? Using an incompatible charger can slow down your PC’s charging speed. Always use the charger that supports the required power levels for your PC the fastest charging. This setting lets Windows notify you when your PC’s hardware indicates that it is charging slowly over USB. This could be due to a number of reasons:

The charger isn’t compatible with your PC.
The charger isn’t powerful enough to charge your PC.
The charger isn’t connected to a charging port on your PC.
The charging cable isn't powerful enough for the charger or PC.
Dust or dirt inside the USB port on your device prevented the charger from being inserted correctly.
The charger is connected through an external hub or dock.

You can resolve it by using making sure your charger and cable also support the power levels your PC requires for the faster charging. For example, if your PC requires 12V and 3A for the fastest charging, a 5V, 3A charger won’t give you the fastest charging.

USB Battery Saver

The USB battery saver is a feature designed to help conserve power by stopping USB devices that do not power down by themselves when the system enters standby. Most USB devices are well behaved and tend to power down or suspend when the system enters modern standby. When the feature is enabled, the USB bus will temporarily eject misbehaving devices (i.e. those that do not suspend) for the duration of the standby session. Not doing so would prevent the system from entering a low power standby state and significantly reduce battery life. Hence, this is particularly useful for extending battery life on devices that are battery-powered and support modern standby. When the USB battery saver is on, it prevents unnecessary battery usage from high-power-consuming USB devices by stopping them when the screen is off.

However, some older USB peripherals may have compatibility issues with low-power states, which is why the option to turn off the USB battery saver exists. Turning it off can have a significant impact on the system's battery life, as it may prevent the system from fully going to standby due to some USB devices still running.

Caution: Microsoft strongly recommends leaving the feature in its default-on enabled state.

USB4 Hubs and devices

Imagine plugging in your USB4 device and instantly accessing a world of faster data transfer and improved power delivery. If your PC supports USB4, here’s what you can expect to see in your settings. C This page is intended to give users insights into their system and device/dock’s USB4 capabilities. It is also meant to support IT administrators and /or customer-support channels when troubleshooting certain problems. (Note: The page is designed to only show USB4 and Thunderbolt 3 devices/hubs attached to your system. If you do not see a device here, it indicates that you do not have a USB4 hub/device attached or that the device operating is not operating in USB4 mode.). Here’s an example of this page:

The USB hubs and devices pages provide useful information on your USB4 devices.

How do I adjust USB settings?

You can manage USB Settings on any Windows 11 device by opening the Settings app, and navigating to Bluetooth & devices > USB.

How do I know which USB Settings are available?

The following settings are available on all PCs:

Connection notifications: Show a notification if there are issues connecting a USB device
USB battery saver: Stop USB devices when my screen is off to help save battery

If your PC supports charging over a USB-C port you will see the following option:

Show a notification if this PC is charging slowly over USB

If your PC is a mobile system that supports USB you will see the following Settings available when using USB4 devices on a PC with USB4 ports):

USB4 hubs and devices

Conclusion

At the end of the day, our goal is to make USB technologies in Windows seamless and intuitive. We hope this blog post has given you a glimpse into the thought and care we put into every feature, making your experience as smooth as possible. While we don’t expect most users to have to tinker with their USB Settings, we hope this blog post gave you some useful insights into the motivation behind some of the USB settings.

Introducing the USB4™ Switch

Philip Froese — Fri, 10 Jan 2020 17:44:32 GMT

As part of the MUTT (Microsoft USB Test Tool) family and a follow-on to the USB Type-C Connection Exerciser, we are excited to introduce the USB4 Switch: a USB Type-C 1:2 programmable switch, compatible with USB4 as well as older protocols such as Thunderbolt™ 3, USB 3.2, USB Type-C Alternate Modes, and of course Power Delivery.

The USB4 Switch automates connect-disconnect of a USB Type-C port and will be used in stress testing, switching between peripherals (for example, a dock and a display), or any automated reconfiguration of a USB Type-C port. It is compatible with the Connection Exerciser tools and scripts and integrates with the Hardware Lab Kit (HLK) test content.

It will be a required test device for Windows Certification through the HLK but is highly recommended for use much earlier in your hardware development cycle as well. In our experience, long-run randomized switching on a USB Type-C port is highly effective in exposing bugs in the hardware-firmware-software stack, both in the USB Type-C controller as well as the underlying data protocols. We expect the USB4 Switch to have similar value in the development and validation of USB4 hardware and software.

The device is available to purchase from our partners at MCCI at https://mcci.com/usb/dev-tools/model-3141/

For UCSI based systems we recommended to perform testing with some additional settings to help discover firmware bugs. Please see “Converting firmware failures to bugchecks” in this blog post.

UCSI based USB Type-C systems may see a shutdown delay if connect changes race with power transition

Philip Froese — Tue, 25 Jun 2019 18:42:50 GMT

My system takes a long time to power down if a USB Type-C device, dock, or charger is plugged in or unplugged during the power transition.

A bug in the USB Type-C Connector System Software Interface (UCSI) software implementation in Windows 10, version 1809 can cause a 60 second delay in the system sleep or shutdown process if the power-down happens while the UCSI software is busy handling a new connect or disconnect event on a USB Type-C port. Apart from the extra one minute the sleep or shutdown process takes in this circumstance, this bug does not affect normal functionality of USB Type-C on your machine. The system and the USB Type-C ports should continue to function properly after the next wake or restart of the system.

Edits based on feedback:

1) This is resolved in Windows 10 version 1903, please update to the latest released build if you are impacted by this bug.

2) The issue described only affects Windows 10 version 1809 (17763) and is fixed in 1903.

3) Please use the Feedback Hub for further feedback or questions.

Debugging UCSI firmware failures

Rajib Dutta — Wed, 07 Nov 2018 21:59:23 GMT

Background

The UCSI driver in Windows communicates with the firmware UCSI component (called PPM or Platform Policy Manager) through the spec-defined command notification interfaces. While driver failures can be tracked using Windows Error Reporting or WER and driver traces, the firmware may run into failures as well which might go undetected at first but result into loss of functionality later in time. UCSI compliant machines in the wild do run into such failures every day in the tens of thousands.
This document intends to describe a way in which an OEM or a firmware developer may avoid these PPM failures pro-actively running some stress tests.

The most common PPM failure is UCSI command timeout.
UcmUcsiCx.sys is the inbox component in Windows that communicates with PPM. Here is a typical message flow between the driver and the firmware.
UcmUcsiCx.sys driver sends a UCSI command to PPM
PPM asynchronously sends command complete notification (CCI:: Command Complete Indicator*).
The driver receives the command complete notification and then send Ack to PPM (ACK_CC_CCI)
PPM asynchronously send ack complete notification (CCI::Acknowledge Command Indicator).
The driver waits for 10 seconds for an asynchronous notification (steps (2) and (4)) before giving up and generating failure report or a livedump.

*Note that the above steps are performed for all UCSI commands except PPM_RESET since after PPM_RESET the PPM Is expected to be in reset state where no notifications are enabled. The driver then polls for CCI::Reset Complete Indicator to be true.

Converting firmware failures to bugchecks

One way in which an OEM or a firmware developer can catch these failures in the lab or development environment is the configure the machine to bugcheck generating a kernel crashdump rather than livedump which may go undetected. In addition to repro the failure, we advise an OEM/firmware developer to use Connection Exerciser Stress test: CxStress. CxStress is a part of MUTT software pachage found in this location.

Setup Connection exerciser: An example connection is shown in the following picture where the Type-C connector of the SUT is connected to the connection exerciser. The 4 Type-C ports of the connection exerciser is connected to 4 different kinds of the partners. For example, one or more alt-mode docks (if applicable), one or more PD chargers, a Type-C MUTT or other USB-C devices like a USB-C mass storage device. Refer to the picture below for an example setup.

Configure UcmUcsiCx.sys to elevate livedump to crashdump
- Locate the device node in Device Manager (devmgmt.msc) named UCM-UCSI ACPI Device. The node is under the USB Connector Manager
- Right-click on the device, and select Properties and open the Details
- Select Device Instance Path from the drop-down and note the property value.
- On an elevated command prompt
  - reg add "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum\<device-instance-path>\Device Parameters" /v ForceCommandFailureCrash /t REG_DWORD /d 0x01
- Restart the device by selecting the Disable option on the device node in Device Manager, and then selecting Enable. Alternatively, you can simply restart the PC.
Run CxStess.cmd (typically found in “C:\Program Files (x86)\USBTest\x64”). For completeness, we recommend you to run this test overnight (~8 hours).
Keep an eye on bugchecks that might happen due to the above test. The next section talks about how to go about finding their root cause.

Analyzing Firmware Failures

This section goes through analysis of an example crash that occurred when UcmUcsiCx driver was configured to generate a crashdump instead of a livedump. Load the dump file in Windbg using <dir_path_to_windbg>\windbg.exe -z <path_to_memory_dump> from command line or run window. Refer analyzing kernel mode dumps for more details.

Run !analyze to check the failure type. Bugcheck code: 0x1D4 is the UCSI failure code.

1: kd> !analyze -v

UCMUCSI_FAILURE (1d4)
The UcmUcsi driver has encountered an error.
Arguments:
Arg1: 0000000000000000, A UCSI command has timed out because the firmware did not respond to the command in time.
Arg2: 0000000000000005, The UCSI command value.
Arg3: ffff988646b2f8d0, If non-zero, the pointer to additional information (dt UcmUcsiCx!UCMUCSICX_TRIAGE).
Arg4: 0000000000000000

Debugging Details:
..

Get UcmUcsiCx driver traces. The following text contains the last few lines of the trace which we are interested in. To dump the driver traces, we rely on a windbg command called 'rcdrlogdump' found in 'rcdrkd'. The last few entries in the traces are related to the driver trying to stop the state machine and generating a dump. Look for the state machine event called CommandTimeOut and retrace the state machine transitions back a few steps to find out which command has timed out. In this specific example, it happens to be SetNotificationEnable UCSI command. Refer line 1076, 1083 and 1085 in the following WPP trace dump from Windbg.

1: kd> !rcdrkd.rcdrlogdump ucmucsicx
Trace searchpath is: 

Trace format prefix is: %7!u!: %!FUNC! - 
Trying to extract TMF information from - C:\ProgramData\Dbg\sym\UcmUcsiCx.pdb\DA9957412F663B283F7EF8BE9406D0551\UcmUcsiCx.pdb
--- start of log ---
…
…
…
1073: UcmUcsiCx::CommandHandler::EvtLogTransition - [COMMAND HANDLER] SmFx transition [Transition: External][Source: WaitingForCommand][Event : CommandAvailable][Target: ProcessNextCommand]
1074: UcmUcsiCx::CommandHandler::EvtLogTransition - [COMMAND HANDLER] SmFx transition [Transition: Call][Source: ProcessNextCommand][Event : _noevent_][Target: RetreiveCommandType]
1075: UcmUcsiCx::CommandHandler::EvtLogTransition - [COMMAND HANDLER] SmFx transition [Transition: External][Source: RetreiveCommandType][Event : AsyncCommand][Target: SendNewCommandToPPM]
1076: UcmUcsiCx::CommandHandler::SendUCSICommandToPpm - [UCMUCSIPPM: 0x0000507062114698] Sending Command UcsiCommandSetNotificationEnable to client


1077: UcmUcsiCx::CommandHandler::EvtLogEventEnqueue - [COMMAND HANDLER] SmFx event: RequestCompletedSuccessfully
1078: UcmUcsiCx::CommandHandler::EvtLogTransition - [COMMAND HANDLER] SmFx transition [Transition: Call][Source: SendNewCommandToPPM][Event : _noevent_][Target: WaitingForRequestCompletion]
1079: UcmUcsiCx::CommandHandler::EvtLogTransition - [COMMAND HANDLER] SmFx transition [Transition: ExplicitPop][Source: WaitingForRequestCompletion][Event : RequestCompletedSuccessfully][Target: SendNewCommandToPPM]
1080: UcmUcsiCx::CommandHandler::EvtLogTransition - [COMMAND HANDLER] SmFx transition [Transition: External][Source: SendNewCommandToPPM][Event : Succeeded][Target: StartingCommandCompleteTimer]
1081: UcmUcsiCx::CommandHandler::EvtLogTransition - [COMMAND HANDLER] SmFx transition [Transition: External][Source: StartingCommandCompleteTimer][Event : Done][Target: WaitingForCommandComplete]
1082: UcmUcsiCx::Opm::EvtLogTransition - [OPM] SmFx transition [Transition: Call][Source: EnableCmdCompleteNotificationOnPowerUp][Event : _noevent_][Target: WaitingForCommandCompletion]
1083: UcmUcsiCx::CommandHandler::PrettyPrintCCI - [CCI] ConnChange:0x0 | DataLength:0x0 | NotSupported:0 | CancelCompleted:0 | ResetCompleted:1 | Busy:0 | AckCommand:0 | Error:0 | CommandComplete:0 |
1084: UcmUcsiCx::CxDevice::EvtDeviceWdmPreprocessSetPowerIrp - [WDFDEVICE: 0x000050706D0133C8] System Power Down to SYSTEM_POWER_STATE:0x5
1085: UcmUcsiCx::CommandHandler::EvtLogEventEnqueue - [COMMAND HANDLER] SmFx event: CommandTimedOut
1086: UcmUcsiCx::CommandHandler::EvtLogTransition - [COMMAND HANDLER] SmFx transition [Transition: ExplicitPop][Source: WaitingForCommandComplete][Event : CommandTimedOut][Target: ProcessNextCommand]
1087: UcmUcsiCx::CommandHandler::EvtLogTransition - [COMMAND HANDLER] SmFx transition [Transition: ImplicitPop][Source: ProcessNextCommand][Event : UnrecoverableFailure][Target: Started]
1088: UcmUcsiCx::CommandHandler::EvtLogTransition - [COMMAND HANDLER] SmFx transition [Transition: External][Source: Started][Event : UnrecoverableFailure][Target: Failed]
1089: UcmUcsiCx::Opm::EvtCommandCompletionReceived - [UCMUCSIPPM: 0x0000507062114698] Response timed out for command UcsiCommandSetNotificationEnable, 0x00000102(STATUS_TIMEOUT)
1090: UcmUcsiCx::Opm::EvtLogEventEnqueue - [OPM] SmFx event: Stop
1091: UcmUcsiCx::Opm::EvtLogTransition - [OPM] SmFx transition [Transition: External][Source: WaitingForCommandCompletion][Event : Stop][Target: WaitingForCommandCompletionAfterStop]
1092: UcmUcsiCx::Opm::EvtLogEventEnqueue - [OPM] SmFx event: CommandComplete
1093: UcmUcsiCx::Opm::EvtLogTransition - [OPM] SmFx transition [Transition: ExplicitPop][Source: WaitingForCommandCompletionAfterStop][Event : CommandComplete][Target: EnableCmdCompleteNotificationOnPowerUp]
1094: UcmUcsiCx::Opm::EvtLogTransition - [OPM] SmFx transition [Transition: ImplicitPop][Source: EnableCmdCompleteNotificationOnPowerUp][Event : Stop][Target: PowerDownAndWaitForPowerUp]
1095: UcmUcsiCx::Opm::EvtLogTransition - [OPM] SmFx transition [Transition: ImplicitPop][Source: PowerDownAndWaitForPowerUp][Event : Stop][Target: PpmOperational]
1096: UcmUcsiCx::Opm::EvtLogTransition - [OPM] SmFx transition [Transition: ExplicitPop][Source: PpmOperational][Event : Stop][Target: Started]
1097: UcmUcsiCx::Opm::EvtLogTransition - [OPM] SmFx transition [Transition: External][Source: Started][Event : Stop][Target: PurgingUnserviceCommandsDueToStop]
1098: UcmUcsiCx::Opm::EvtLogTransition - [OPM] SmFx transition [Transition: External][Source: PurgingUnserviceCommandsDueToStop][Event : Done][Target: StopCommandHandlerMachine]
1099: UcmUcsiCx::CommandHandler::EvtLogEventEnqueue - [COMMAND HANDLER] SmFx event: Stop
1100: UcmUcsiCx::CxDevice::UnrecoverableFailureEncountered - [WDFDEVICE: 0x000050706D0133C8] An unrecoverable failure has been encountered. The device will now restart.
---- end of log ----

To summarize the above failure, UcmUcsiCx driver sends SetNoficationEnable command to the firmware and the firmware fails to send command complete notification within the timeout period of 10 seconds. Instead it sends a Reset Complete notification.

When such a failure occurs, we advise an OEM with work with firmware developer to fix the problem.

Introducing USB Type-C Connector System Software Interface (UCSI) Class Extension

Rajib Dutta — Wed, 07 Nov 2018 21:31:58 GMT

USB Type-C Connector System Software Interface (UCSI) defines the commands and notifications to manage a platform that exposes one or more USB Type-C connectors. The combination of hardware and firmware and any vendor-provided OS software that provides this interface is referred to as the Platform Policy Manager or the PPM. UCSI PPM is typically implemented by an Embedded Controller (EC) which may either implement Power Delivery (PD) state machines or interface a PD controller. An OEM may interface with EC over the physical transport of their choice. Historically, this transport has been ACPI but we have recently seen an upsurge of PCI, UART, I2C, USB being adopted as means to connect an EC in the system.

Windows has for several releases had inbox support for UCSI over ACPI using UcmUcsi.sys. This was a client driver to USB Connector Manager Class Extension or UcmCx. However, starting with the RS5 release (or Windows 10 October 2018 update), Windows includes UCSI Class Extension (UCSI Cx, binary name: UcmUcsiCx.sys) which is a transport agnostic implementation of UCSI logic. This update also includes inbox ACPI client (binary name: UcmUcsiAcpiClient.sys) support for this class extension.

UCSI Cx implements the OPM (OS Policy Manager) state machines that decide which UCSI command to be sent to the PPM and when. The client to this class extension is expected to be thin and has the following responsibilities:

Initialize connectors with UCSI Cx.
Notify UCSI Cx of start and stop of the PPM using DDIs.
Receive a UCSI data block from the Cx using IOCTLs and send it to the EC over the transport that it supports.
Relay a UCSI notification from EC to the Cx.
Become the power policy owner for the driver.

If you are bringing up support for a system that has UCSI EC connected over a non-ACPI transport, we would recommend you develop your transport specific USCI Cx client driver. This document is a good place to start.

Bringing Device Support to Windows Containers

Shyamal Varma — Fri, 12 Oct 2018 22:57:23 GMT

First published on MSDN on Sep 05, 2018
We’ve been working with several different feature teams within Microsoft to enable access to various hardware devices from inside Windows Containers running on Windows IoT. The link below provides more details about this effort and would be the right place to provide feedback on the progress made so far, and suggestions for additional functionality you may need.

https://blogs.technet.microsoft.com/virtualization/2018/08/13/bringing-device-support-to-windows-server-containers/

Running USB Type-C System HLK tests with the Type-C MUTT

Shyamal Varma — Thu, 02 May 2024 19:09:25 GMT

First published on MSDN on Jun 05, 2018
Authored by Philip Froese [MSFT]

[Last updated May 2, 2024]

In the next release of the HLK, the UCSI tests have been updated to run against the new Type-C SuperMUTT device instead of a partner system. This means the test setup will be simpler, the tests will run more quickly, and test content will be more thorough than in Windows 10 April 2018 Update HLK and earlier. The new preview tests are only in pre-release HLK builds 17676 and higher.

New Test Setup

The new test setup is simple: it requires a single Windows PC with Type-C, designated the System Under Test (SUT), and the Type-C SuperMUTT connected to one of the Type-C connectors on the system. See the image below.

Type-C SuperMUTT

The Type-C SuperMUTT is the newest edition to the Microsoft USB Test Tool (MUTT) family of devices. It incorporates the functionality of the legacy SuperMUTT device as well as Type-C and PD functionality.

The software and firmware utilities are available in the MUTT Package download: https://docs.microsoft.com/en-us/windows-hardware/drivers/usbcon/mutt-software-package

And the tool is available for purchase through MCCI: http://www.mcci.com/mcci-v5/devtools/type-c-supermutt.html

Firmware version 45 or later, available in MUTT Package v2.6 and later, is required to run the UCSI HLK tests in the next release of the HLK. See the TypeCSuperMUTT.pdf documentation in the MUTT Package download for more information.

New Test Names

The UCSI compliance tests have been replaced with a new version of the tests to run against the Type-C SuperMUTT. The new version of the test has the tag “[Type-C MUTT]” added to the test name.

What is Different?

Beyond a new name and a simpler test setup, what else is new in the tests? For the most part, the tests cover the same features in the same manner as the original tests did. However, there are some cases where the new tests will be more rigorous.

Take USB Operation Role tests for example. Many desktop UCSI systems do not support being set into the UFP role, though they may resolve to that role initially when connected to a pure DFP (such as a charger). This behavior makes it difficult to test every permutation of DFP/UFP/DRP connections that a platform may have to support if it is tested against a functionally equivalent peer device. However, with the Type-C SuperMUTT the test can deterministically place the Type-C SuperMUTT into a specific, known port direction or configuration before connecting it to the SUT and is thus able to provide more complete test coverage of USB Operation Role features.

Thus, there may be some test cases in next release of the HLK that are more thorough and thus uncover new platform quirks that Windows 10 April 2018 Update HLK and earlier test content did not.

You will also notice that some tests have been removed. Some tests were determined to be redundant when run against the Type-C SuperMUTT and so were removed. Others targeted UCSI commands that have been removed in UCSI v1.1, and which Windows never supported, so were removed as obsolete.

USB Type-C UCSI Data and Power Role Swap Tests

Applicable Tests

USB Type-C UCSI Data Role Swap
USB Type-C UCSI Power Role Swap

Hardware Requirements

One UCSI compliant Windows system.
One Type-C MUTT device.

Test Setup

Install HLK client on the System Under Test (SUT).
Connect the Type-C MUTT to any USB Type-C port on the SUT.
Locate the device node in Device Manager (devmgmt.msc) named "UCM-UCSI ACPI Device". The node is under the "USB Connector Managers" category.
Right-click on the device, and select "Properties" and open the "Details" tab.
Select "Device Instance Path" from the drop-down and note the property value.
Open Registry Editor (regedit.exe).
Navigate to the device instance path under this key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\<device-instance-path from step 6>\Device Parameters
Create a DWORD value named "TestInterfaceEnabled" and set the value to 0x1.
Restart the device by selecting the "Disable" option on the device node in Device Manager, and then selecting "Enable". Alternatively, you can simply restart the PC.

Test Parameters

Parameter NameParameter Description

SwapsToPerform	Number of data role swaps to perform. The minimum is 2 so that both host and function mode are tested.
ValidateUsbFn	If ValidateUsbFn = true, the test will validate function stack behavior.

Troubleshooting

Some UCSI commands are marked "optional" in the UCSI specification. However, Microsoft requires some optional commands to be implemented in order for the UCSI driver to function. The tests may fail if you've forgotten to implement one of these commands in your BIOS. You can find that list of commands here .

- If the test is not detecting the Type-C MUTT:
  - Check your cable connection to the Type-C MUTT.
  - Check in Device Manager. Has the Type-C MUTT enumerated?

USB Type-C UCM Data and Power Role Swap Tests

Applicable Tests

USB Type-C UCM Data Role Swap

USB Type-C UCM Power Role Swap

Hardware Requirements

One Windows system with a USB Type-C connector.
One Type-C MUTT device.

Test Setup

Install the HLK client on the System Under Test (SUT).
Connect the Type-C MUTT to any USB Type-C port on the SUT.
Ensure all other USB Type-C ports are disconnected.

Test Parameters

Parameter NameParameter Description

SwapsToPerform	Number of data role swaps to perform. The minimum is 2 so that both host and function mode are tested.
ValidateUsbFn	If ValidateUsbFn = true, the test will validate function stack behavior.

Troubleshooting

"No USB Type-C Connectors found with partners attached".
- Check your cable connection to the Type-C MUTT.
- Check in Device Manager. Has the Type-C MUTT enumerated?
  - Look for the "SuperMUTT" device with hardware ID USB\VID_045E&PID_078F in the Device Manager.
  - If your system is using UCSI, you can take UCSI logs during attach to investigate why the attach has not been reported to the OS.

UCSI Compliance tests

Applicable tests

This category of tests refers to all tests in the HLK with a name that begins with "UCSI" and is post-fixed with “[Type-C MUTT]”. The early pre-release HLK builds will include the original UCSI Compliance Tests as well, these tests have the same names, but without the “[Type-C MUTT]” suffix. Unless you are specifically running the old test for comparison, you should ignore the old versions of the tests.

UCSI Compliance Tests are meant to test the UCSI-capable Type-C system’s compliance to UCSI Specification.

Broad Categories of UCSI Compliance Tests

UCSI Command Interface tests.
- Tests all of the UCSI commands that are claimed to be supported by the SUT.
USB Operation Mode tests.
- Tests all of the USB Operation Modes that are claimed to be supported by the SUT on the given Connector.
USB Operation Role tests.
- Tests all of the USB Operation Roles and role swaps that are claimed to be supported by the SUT on the given Connector.
Power Direction Role Tests.
- Tests all of the Power Direction Roles that are claimed to be supported by the SUT on the given Connector. Performs role swaps.
UCSI Notification tests.
- Tests all of the UCSI notifications that are claimed to be supported by the System under Test on the given Connector.

Hardware Requirements

One UCSI compliant Windows system.
One USB Type-C MUTT device.

How to identify Connector 1

In the next release of the HLK, the tests can be run against any available connector on the SUT, but you will need to specify the connector that the Type-C MUTT is connected to via the UcsiConnectorNumber parameter. If you do not know the connector numbers on a multi-port system, the UCSI Connector One Identification [Type-C MUTT] test can help you identify which is connector 1. If the SUT has 3 or more connectors, and you don’t know their mapping, you will simply need to experiment by connecting the Type-C MUTT to an unknown port, setting UcsiConnectorNumber to a new value, and running a test to see if the device is found on that connector; repeat with a new connector number until successful. This should just take a few attempts to establish the connector number layout for any new system.

Test Setup

Install the HLK client on the System Under Test (SUT).
Connect the Type-C MUTT to any USB Type-C port on the SUT.
Record the connector number to which the Type-C MUTT is attached. You will supply this number when scheduling the tests.
Install TestUcsi.sys driver on the SUT. On systems with USB dule-role controllers such as some ARM64 systems, it is important that the Type-C MUTT is connected before the test driver is installed, otherwise the USB host stack may not get loaded.
1. In Device Manager, find the device "UCM-UCSI ACPI Device". This device will have the driver UcmUcsiAcpiClient.sys installed.
2. Right-click the device and select "Update Driver Software"
  1. Enter the path to TestUcsi.inf
    1. TestUcsi.inf and TestUcsi.sys are located in \TestUcsi\<ARCHITECTURE>\
  2. Follow the prompts to complete the driver installation. This will replace UcmUcsiAcpiClient.sys with TestUcsi.sys.Right-click the device and select "Update Driver Software"

Test Parameters

Parameter NameParameter Description

UcsiConnectorNumber	The Type-C connector number on which the Type-C MUTT device is attached.
WaitTimeInMinutes	For tests that require manual intervention, this is the amount of time in minutes the test will wait to see the event that is expected to occur in response to the requested manual action.
WaitTimeMultiplier	An integral multiplier of wait times required in the test when interacting with the Type-C MUTT. Some systems may take somewhat longer than expected to enumerate the device when it reconnects.

Test Execution

The Type-C MUTT allows the HLK tests to emulate and automate all scenarios in next release of the HLK that previously may have required manual intervention. You can select all of them at once, or only run a subset of them if you wish.

Test Cleanup

The UCSI Data and Power role swap tests require UcmUcsiAcpiClient.sys rather than TestUcsi.sys. If you plan to run the UCSI Data Role Swap or UCSI Power Role Swap tests in the HLK after this test, be sure to clean up your test environment after running the UCSI compliance tests. You can do this by replacing TestUcsi.sys with the original UcmUcsiAcpiClient.sys or by reinstalling Windows on both systems.

Troubleshooting

Please review the HLK test log to determine why the test failed. In many cases, the test log will state common known causes of a given failure and how it may be resolved.

Examine the driver logs per the guidance provided in the following blog post:

If the test failure is unclear from both the test and driver logs or you believe it to be incorrect, and you are going to reach out to Microsoft for additional guidance, please prepare the following when reporting the issue to us. This will help us get to the bottom of your bug report as quickly as possible!

The HMD Exerciser Kit- A Test Kit for VR HMDs

Shyamal Varma — Fri, 12 Oct 2018 22:56:58 GMT

First published on MSDN on Jan 19, 2018
Authored by Matthew Hartman [MSFT]

To support the wave of VR HMDs coming to market, Microsoft has developed the HMD Exerciser Kit . This kit is based on the MUTT ConnEx platform and is specifically tailored for HMD testing.

The HMD Exerciser Kit provides

USB Plug/Unplug/Multiplexing

HDMI Plug/Unplug/Multiplexing

IR User Presence Detection Spoofing

Independent Display Brightness/Color Detection

2x Servo Control with Independent Servo Power

HMD Audio Level Monitoring

USB Voltage/Current Polling

The setup is flexible and can be designed to meet your specific test requirements. Here’s an example of how we used the HMD Exerciser Kit in our lab. In this configuration, we have also have the two motion controllers and the HMD on turntables for movement/FOV testing.

HMD Exerciser Kit Hardware

The kit includes two main components. The HMD Exerciser (left) and the HMD Board (right).

The HMD Exerciser is the main unit for all the connections to the HMD and PC. It handles all of the measurements, multiplexing, and PC communication. More details about the components that make up the HMD board are available in the Documentation .

The HMD Board contains the hardware that interacts with the HMD’s displays and presence sensor. The two TCS34725 color sensors are placed to line up with each display. This allows independent brightness/color measurement. The IR photodiode and LED match the typical placement of IR user presence sensors. They are used in combination to spoof user presence or absence. The desired user presence state is controllable via software.

The HMD Board fits in a 3D printed mount which is designed to clip securely into the HMD. This mount is designed for the Acer Windows Mixed Reality HMD.

The HMD Board attaches to the HMD Exerciser using the flat ribbon cable shown above. Each HMD Exerciser can test up to two HMDs with a single PC.

Find more details in the docs here .

HMD Exerciser Kit Software

The HMD Exerciser Kit is controlled either through a command line executable or managed class. The command line utility is available in the MUTT tools , and the managed class is available in the BusIoTools Git repo . Look for more details in the Microsoft Docs .

To get started with the command line tool, identify which ports your HMD is plugged in to on the HMD Exerciser and select those ports to connect the HMD. For this example, we’ll use USB and HDMI port 1.

Next, tell the kit what port (1 or 2) your HMD Board is plugged in to. For this example, we’re using port 1.

After this command, all the display/audio/presence commands will apply to the HMD on port 1. Now we can grab the HMD’s display brightness, display color and audio level. We can also set user presence spoofing if the HMD uses IR user presence detection.

To disconnect the USB or HDMI ports, just set the port to ‘0’ in the command

More Info and Purchasing

Check out the HMD Exerciser Kit documentation on Microsoft Docs and buy the hardware from MCCI.

Reading Driver Logs in USB Type-C HLK Tests

Shyamal Varma — Fri, 12 Oct 2018 22:55:25 GMT

First published on MSDN on Aug 03, 2017
Authored by Philip Froese [MSFT]

Newly added in the RS3 preview builds of the HLK, the USB Type-C HLK tests for UCM and UCSI will automatically capture debug traces from the relevant driver(s) during the test.

Note: if you are used to manually capturing the driver traces, that method should no longer be used during HLK testing. Only one trace session can be active simultaneously, so enabling a separate trace will preclude the HLK from capturing meaningful diagnostic data. This applies only to the UCSI specific tests in the HLK.

Locating the Log File

After running the USB Type-C HLK test(s) of interest, switch to the Results tab of the HLK Studio.

Expand the test result of interest and locate the failing Run Test

Right click on Run Test , and then select Additional Files from the context menu. You should see an .etl file in the list. Select Show All to open the file location in Windows Explorer. Copy the .etl file for the next step.

Parsing the Log File using TraceView

For more information and detailed instructions about using TraceView to view existing ETL logs, see Displaying a Trace Log with a PDB File .

Start TraceView , you will find it in the WDK under the .\Tools\<Architecture>

Select the Options menu and Configure Symbols . Enter the following into the Symbols Path field to direct TraceView to the Microsoft public symbol server, and click OK .

SRV*https://msdl.microsoft.com/download/symbols

Select the File menu, and Open Existing Log File .

Enter the log file path and name into the Log File Name box, or navigate to the log file with the button to the right.

On the next menu, select the Auto option and click OK .

It may take several seconds for the symbols to be retrieved and the trace parsed, but once that completes, you should see an output like the following. In this example, for clarity only the Name , System Time and Message columns are displayed. You can change the columns by right clicking on any column header and selecting from the context menu.

Reading the Trace

The driver traces contain a lot of low-level details which will not all be relevant to your investigation and may be difficult to make sense of. However, as the example below will attempt to show, with a few tips and tricks, knowledge of the UCSI specification, and some experience, they can be valuable debugging tools.

A few tips before we get to the example:

When starting to investigate a failure, use the HLK test log to understand the high-level flow of the test, what action failed and the nature of the failure.

Use the timestamps in the test log and in the driver trace to correlate what the test was doing with the events in the driver. This can help you isolate the area of interest to a few dozen lines of what may be a very large trace file.

Familiarize yourself with the UCSI command codes (Table A-1) and command data payloads (Section 4) defined in the UCSI specification as this information will be necessary to decode portions of the driver traces.

The UCSI Compliance Tests, which use the testucsi driver enable several extraneous providers for which there are no symbols. You can ignore events from Unknown Provider in those traces. These events are mostly useful for debugging the test code itself and may be removed from the HLK in the future.

In the Ucm and Ucsi Role Swap Test traces, you will see events from UcmCx and the PolicyManager which you can largely ignore. The UcmUcsi provider will contain the lowest level details and specific notifications and message payloads.

Example

In this example, the USB Type-C UCSI Power Role Swap Test has failed with the following sequence in the HLK test log:

This trace is telling us that the connector was initially a power provider. The test then sent the Set Power Direction Role command, and re-checked the port status at which point the port was still a power provider. Let’s look at the driver trace.

First, we’ll copy UcsiRoleSwapTrace.etl from the HLK results temporary location, and open it with TraceView. The timestamp in the test log for the SetPdr command is 8:39:13:382, so we’ll start there in the driver trace and look forwards for the Set Power Direction Role command. We find it recorded in the trace with a timestamp 12 ms later:

In this case, the UCSI test interface accessed by the HLK test records that this is a “ SetPowerRole ” command, but we can inspect the actual command in the third line to confirm that it is indeed command 0xB , which we see in Table A-1 of the UCSI specification is the SET_PDR command. The second line in this snippet reports that “Power role change to 0x1 was requested.” The value of 0x1 represents an internal enumeration value in the UcmCx driver which maps 0x1 to the Sink power role, and 0x2 to the Source power role. (Please note, this does not match the Power Direction Role value specified in Table 4.24 of the UCSI specification). So, now we have confirmed that we see the correct SET_PDR command being successfully sent to the UCSI device to switch the connector to the consumer role.

Next, since this was an asynchronous command, let’s look for the completion. We find it approximately 200ms later in the trace:

Here we see a notification with only bit 32 of the CCI set which per Table 3-2 of the specification is the Command Completed Indicator . We see that printed in the next line, which also confirms that this was command 0xB ( SET_PDR ). The final line of this snippet is confirmation that the UCSI driver believes that the SET_PDR to role 0x1 ( consumer ) is completed successfully.

Going back to the HLK log, we see that at 8:39:13.890, the test logs that the connector is still in the provider mode and fails. This means that the test must have queried the connector status before this point, so we can go to this timestamp in the log and work backwards looking for a GET_CONNECTOR_STATUS ( 0x12 ) command. Here’s what we find:

We have command 0x12 completing successfully with a data payload of 9 bytes based on the CCI. See Table 3-2 of the UCSI spec to parse the specific fields in the CCI. Reviewing section 4.5.18 of UCSI for the Get Connector Status data payload, we see that it is indeed 72 bits (or 9 bytes) long. Now for the tricky part, what was the connector status? Unfortunately, this is a place where the clarity of the log file is lacking and you will just have to follow these rules to interpret the connector status result:

Third from the bottom is a blank log line. This indicates that none of the Connector Status Change bits were set. If they were, this log line would contain the string names of each set Connector Status Change bits (see Table 4-46 in the specification).

Second from the bottom, we have three named fields, Connect , PartnerFlags and RDO . These correspond to the Connect Status , Connector Partner Flags , and Request Data Object fields in Table 4-45 of the spec respectively.

The last row of the above snippet is four single digit hexadecimal numbers. Unfortunately, these are not explicitly named in the log, but they correspond, in order, to the Power Operation Mode , Power Direction , Connector Partner Type , and Battery Charging Status fields of Table 4-45.
- If the Provider Capabilities Limited Reason field is set, the reason will be printed as a string-name in this line as well. In our example, it is not set.

In this example, we see that the connector is reporting a connection, it is in PD power mode, it is operating as a provider, and the partner is a UFP and operating in an alternate mode in addition to USB.

This example is somewhat trivial: we went through a failure in the HLK log and simply checked that each step was completed in the driver as expected, and confirmed that the connector status did indeed report an unexpected power direction. At this point we would need to work with the firmware engineers for this UCSI implementation to understand why the SET_PDR command completed successfully but the role did not change.

Using UsbCApiCmd for basic USB Type-C validation

Shyamal Varma — Wed, 23 Jan 2019 17:46:29 GMT

First published on MSDN on Feb 01, 2017
Authored by Michelle Bergeron [MSFT]

UsbCApiCmd is a simple tool that you can use for basic validation of your Type-C implementation on Windows.

Who can use UsbCApiCmd?

UsbCApiCmd is applicable only to USB Type-C Connectors which use Microsoft's USB Type-C Stack, the USB Connector Manager. UcmCx.sys needs to be loaded and running on the system. The tool is not applicable to systems which use other methods to manage the USB Type-C ports.

How to get UsbCApiCmd

UsbCApiCmd is included in the MUTT Software Package.

How to use UsbCApiCmd

Open a command prompt or PowerShell window on the system with the USB Type-C connector(s) you wish to validate. Run UsbCApiCmd.exe.

For as long as the program is running, the console will print out information about the USB Type-C connectors on the system that are registered with the USB Connector Manager (UcmCx). It will also print out information about detected Attach/Detach events on a connector. You can use it to validate that the Type-C software is seeing the events that you expect it to.

To stop execution, you may press Ctrl+C.

The below example is from a system using UCSI to manage its connectors with Windows. It has not detected any attach or detach events since the program started running.

Setting up an environment to run USB Type-C system HLK tests

Shyamal Varma — Tue, 16 Oct 2018 20:22:24 GMT

First published on MSDN on Jul 06, 2016
Authored by Michelle Bergeron [MSFT] and Makarand Sonare [MSFT]

[Last updated 10/3/2017]

There are new tests in the Hardware Lab Kit (HLK) that target systems with USB Type-C. These tests are available for the Windows Anniversary Update version of HLK and Windows 10. Some of the tests require extra configuration – here is a guide to help you set up your test environment for them.

USB Type-C UCSI Data and Power Role Swap tests

Applicable tests

USB Type-C UCSI Data Role Swap

USB Type-C UCSI Power Role Swap

Hardware Requirements

Two UCSI 1.0 compliant Windows desktop systems.

UcmUcsi.sys must be loaded as the UCSI controller driver.

USB Type-C cable.

Note: If your Type-C system does not use UCSI, the test will detect this and allow your system to pass.
Test Setup

Designate one system as the System Under Test (SUT) and the other as the "Partner" system.

Install HLK client on the SUT.

Connect the UCSI Type-C connector on the SUT to the UCSI Type-C connector on the Partner via the Type-C cable.

Locate the device node in Device Manager (devmgmt.msc) named "UCSI USB Connector Manager". The node is under the "Universal Serial Bus controllers" category.

Right-click on the device, and select "Properties" and open the "Details" tab.

Select "Device Instance Path" from the drop-down and note the property value.

Open Registry Editor (regedit.exe).

Navigate to the device instance path under this key: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Enum\<device-instance-path from step 6>\Device Parameters

Create a DWORD value named "TestInterfaceEnabled" and set the value to 0x1.

Restart the device by selecting the "Disable" option on the device node in Device Manager, and then selecting "Enable". Alternatively, you can simply restart the PC.

Tracing Instructions
Please note that for RS3 UCSI HLK tests, tracing is automatically captured as noted in this blog post . For Windows 10 Anniversary Update and Creators Update, tracing still needs to be started manually using the instructions below.

Test failures for the UCSI data and power role swap tests can be investigated by collecting logs as per the below instructions.

Start WPP tracing before executing tests. Run the following from an elevated command prompt:
logman start -ets ucmucsi -ct perf -p {EAD1EE75-4BFE-4E28-8AFA-E94B0A1BAF37} 0xffffffff 0xff -o c:\ucmucsi\ucmucsilogs.etl

Stop WPP tracing after running the tests. Add the following commands to a .cmd file and run from an elevated command prompt once the test completes.
logman stop ucmucsi -ets

You will be able to view the resulting logs in UcmUcsiLogs.etl.

Test Parameters
Parameter NameParameter Description

SwapsToPerform	Number of data role swaps to perform. The minimum is 2 so that both host and function mode are tested.
ValidateUsbFn	If ValidateUsbFn = true, the test will validate function stack behavior.

Troubleshooting

Some UCSI commands are marked "optional" in the UCSI specification. However, Microsoft requires some optional commands to be implemented in order for the UCSI driver to function. The tests may fail if you've forgotten to implement one of these commands in your BIOS. You can find that list of commands here .

If the test is not detecting an attached partner

USB Type-C UCM Data and Power Role Swap tests

Applicable tests

USB Type-C UCM Data Role Swap

USB Type-C UCM Power Role Swap

Hardware Requirements

Two Windows systems, each with a USB Type-C connector.

The Type-C connector on the SUT must have a UcmCx client driver. For information about developing a UcmCx client driver, visit USB Type-C connector driver programming reference .

USB Type-C cable.

Note: If your Type-C system implements UCSI, this test is still applicable because UcmUcsi.sys is a UcmCx client driver.
Test Setup

Designate one system as the System Under Test (SUT) and the other as the "Partner" system.

Install HLK client on the SUT.

Connect the Type-C connector on the SUT to the Type-C connector on the Partner via the Type-C cable.

Test Parameters
Parameter NameParameter Description

SwapsToPerform	Number of data role swaps to perform. The minimum is 2 so that both host and function mode are tested.
ValidateUsbFn	If ValidateUsbFn = true, the test will validate function stack behavior.

Troubleshooting

"No USB Type-C Connectors found with partners attached".

UCSI Compliance tests

Applicable tests
This category of tests refers to all tests in the HLK with a name that begins with "UCSI". UCSI Compliance Tests are meant to test the UCSI-capable Type C system’s compliance to UCSI Specification V1.0 . These tests are marked as "manual" in the HLK. The test binaries are included in the HLK; however, you will need to run them yourself using the instructions below.
Broad Categories of UCSI Compliance Tests

UCSI Command Interface tests.

USB Operation Mode tests.

USB Operation Role tests.

Power Direction Mode tests.

Power Direction Role tests.

UCSI Notification tests.

Hardware Requirements

Two UCSI 1.0 compliant Windows desktop systems.

Connection Exerciser hardware (optional - unless you are running the test from HLK Studio. If you are running the test in HLK Studio, the Connection Exerciser is required.)

USB Type-C PD capable cable.

USB 2.0 and USB 3.0 device

Debug accessory (if supported)

Analog audio accessory (if supported)

How to Identify Connector 1
All of the UCSI compliance tests assume Partner system or Devices are connected on Connector 1. To identify Connector 1, perform the following steps:

On the SUT, open an elevated command prompt.

From the elevated command prompt on the SUT, run the following test to identify Connector 1:
Te.exe UcsiComplianceTest.dll /name:TestUcsi::UcsiCommandInterfaceTests::TestIdentifyConnectorOne /p:WaitTimeInMinutes=5
You must specify the WaitTimeInMinutes parameter in order for the test to pass.

Repeat Step 2 on the Partner system to identify Connector 1.

Test Setup

Designate one system as the System Under Test (SUT) and the other as the "Partner" system.

Install HLK client on both systems. You will only schedule tests on the SUT.

Connect the Type-B port on the Connection Exerciser Arduino to the SUT on any port other than Connector 1

Connect Connector 1 of the SUT to J1 connector on the Connection Exerciser directly.

Connect Connector 1 of the Partner to J2 or J3 connector on Connection Exerciser via Type-C cable.

Install TAEF on both systems

Install the TestUcsi.sys driver on both systems.

Test Parameters
Parameter NameParameter Description

IsRunningOnSystemUnderTest	Identifies whether the test is running on the System Under Test or Partner machine. Values: true - If test is executed on SUT. false - If test is executed on Partner.
PartnerMachineName	Machine name of the partner machine that is connected to the SUT using a USB C-to-C cable. The test performs TAEF network remote execution to execute code on this partner machine.
WaitTimeInMinutes	For tests that require manual intervention, this is the amount of time in minutes the test will wait to see the event that is expected to occur in response to the requested manual action.

Test Execution with Connection Exerciser

Connect the SUT and Partner system via a Connection Exerciser and Type-C Cable on Connector 1.

Refer to the Test Setup section for more information.

On the SUT, run UcsiCommandInterfaceTests.
te.exe UcsiComplianceTest.dll /name:TestUcsi::UcsiCommandInterfaceTests::*

On the SUT, run UcsiTests.
te.exe UcsiComplianceTest.dll /name:TestUcsi::UcsiTest::* /p: IsRunningOnSystemUnderTest=true /p:waittimeinminutes=1 /p:partnerMachine=<MACHINE_NAME>

Test Execution without Connection Exerciser

Connect the SUT and Partner system via a Type-C Cable on Connector 1.

On the SUT, run UcsiCommandInterfaceTests.
te.exe UcsiComplianceTest.dll /name:TestUcsi::UcsiCommandInterfaceTests::*

On the SUT, run UcsiTestsManual.
te.exe UcsiComplianceTest.dll /name:TestUcsi::UcsiTestsManual::* /p:IsSUT=true /p:waittimeinminutes=1 /p:partnerMachine=<MACHINE_NAME>

Each test requires executing some TAEF tests on the Partner system as per the instructions given on the command prompt.

Example: When running UcsiTestsManual::TestDFPModeToUFP on the System Under Test:
CMD> te.exe UcsiComplianceTest.dll /name:TestUcsi::UcsiTestsManual::TestDFPModeToUFP /p:IsSUT=true /p:waittimeinminutes=1 /p:partnermachine=<MACHINE_NAME>
Test Authoring and Execution Framework v5.6 for x64
Resetting the PPM
Enabling All Notifications

StartGroup: TestUcsi::UcsiTestsManual::TestDFPModeToUFP
Setting USB Operation Mode to Dfp on Connector 1
1. On Partner Machine
Run: CMD Prompt>Te.exe UcsicomplianceTest.dll /p:IsSUT=false /p:waitTimeInMinutes=<timeInMinutes> /name:TestUcsi::UcsiTestsManual::TestUFPModeOnPartner
2. Connect the Partner
3. Waiting for 1 minutes

Waiting for: ConnectChange

The above test sets Connector 1's USB Operation Mode to DFP on the SUT. It then requires you to run the following command on the Partner system:
Te.exe UcsicomplianceTest.dll /p:IsSUT=false /p:waitTimeInMinutes=<timeInMinutes> /name:TestUcsi::UcsiTestsManual::TestUFPModeOnPartner
Tracing Instructions
Test failures for the UCSI compliance tests can be investigated by collecting logs as per the below instructions.

Start WPP tracing before executing tests. Add the following commands to a .cmd file and run from an elevated command prompt:
logman start -ets testucsi -ct perf -p {C9ED7F4E-286B-4054-B74F-7DE43EFBCA2A} 0xffffffff 0xff -o c:\testucsi\testucsi.etl
logman start -ets testucsicontroller -ct perf -p {EBFD4AED-ED11-4F0C-8F37-9C93084D1530} 0xffffffff 0xff -o c:\testucsi\TestUcsiController.etl
logman start -ets ucsitest -ct perf -p {F8BADD54-3B0F-4B79-8389-D0ABB7AE242B} 0xffffffff 0xff -o c:\testucsi\ucsitest.etl

Stop WPP tracing after running the tests. Add the following commands to a .cmd file and run from an elevated command prompt once the test completes.
logman stop testucsi -ets
logman stop ucsitest -ets
logman stop testucsicontroller -ets

You will be able to view the resulting logs in UcsiTest.etl, TestUcsi.etl, and TestUcsiController.etl.

Test Cleanup
The UCSI Data and Power role swap tests require UcmUcsi.sys rather than TestUcsi.sys. If you plan to run the UCSI Data Role Swap or UCSI Power Role Swap tests in the HLK after this test, be sure to clean up your test environment after running the UCSI compliance tests. You can do this by replacing TestUcsi.sys with the original UcmUcsi.sys or by reinstalling Windows on both systems.
Troubleshooting

"Unable to connect to TE.Service"

No USB error notifications while using the UCSI test driver

One of my role swap tests failed because "UcsiConnectorPartnerTypePoweredCableWithUfp".

Selecting the tests in HLK

The following steps illustrate where to find the tests in the HLK.

Add the SUT as your test target

Right click on the machine, click "Add/Modify features". Verify that System.Fundamentals.SystemUSB.USBC is selected (and System.Fundamentals.SystemUSB.USBTypeCUCSI if your system is UCSI).

Select the "Tests" tab. Scroll down and see that the tests are available. In the example, the SUT uses UCSI.

Do I need to write a driver for my USB Type-C hardware?

Shyamal Varma — Tue, 16 Oct 2018 20:25:45 GMT

First published on MSDN on Jun 20, 2016
Authored by Michelle Bergeron [MSFT]

Windows 10 introduced support for the USB Type-C connector. With many USB Type-C systems and devices hitting the market, the USB team is frequently asked: "If I'm building a USB peripheral device or system with a Type-C connector, do I need to write a custom driver for it to work on Windows?"

The answer depends on the type of product you are building.

USB Type-C peripherals without alternate modes

USB Type-C supports alternate modes, which allow different protocols other than USB to be carried out over the Type-C connector.

If you're building a Type-C peripheral device that does not use alternate modes, you do not need to write a new USB client driver as long as you can use one of the inbox USB device class drivers from Microsoft. From Windows' standpoint, your device looks no different from a legacy USB device without a USB Type-C connector.

Microsoft provides inbox drivers for several classes of USB devices. If your product is one of these device classes, you will not need to write a USB client driver because Windows' existing USB device class driver will be able to automatically work with your Type-C peripheral. Review the list of USB device class drivers included in Windows to check if you can take advantage of one of these drivers for your product.

You will need to write a custom driver only if you are unable to use one of Windows' built-in device class drivers. If you have determined that you must write a new client driver for your USB device, start at Developing Windows client drivers for USB devices .

USB Type-C peripherals with alternate modes

If you are bringing up a peripheral which can operate in an alternate mode, you do not need to take any extra steps in your USB driver to make it work with a Windows system that supports the alternate mode.

However, the peripheral's alternate mode will only work if the system to which it is attached has the hardware capabilities for the specific alternate mode. Since hardware capabilities vary widely between systems, do not take any dependencies on a system supporting your alternate mode.

When your alternate mode device is connected to a system which does not support the alternate mode, you should provide a backup experience over USB. For example, if you are building a Type-C flash drive that uses Thunderbolt alternate mode, you will need to use the USB mass storage device class for the case that Thunderbolt is not present on the connected PC.

Also, you must correctly implement the Billboard specification in your device so it can notify the system if an alternate mode was not successfully entered. The Billboard Device Class specification is available from the USB-IF.

USB Type-C systems

If you are building a system that features a USB Type-C connector, there will likely be driver or firmware work required to bring up your system in Windows. Please refer to the MSDN documentation on this subject. Start at Windows support for USB Type-C connectors to learn more about USB Type-C connectors on Windows and to determine the steps that you will need to take to bring up your USB Type-C system and develop a driver for it.

Filing USB feedback with Repro Mode in Windows 10

Shyamal Varma — Fri, 12 Oct 2018 22:52:42 GMT

First published on MSDN on Aug 17, 2015
Authored by Michelle Vogel [MSFT]

Feedback from users is one of the many ways the USB team identifies and prioritizes issues and fixes. However, not all feedback is actionable; many times, we need detailed logs to understand what is causing and issue and sometimes which component the issue is even in. For example, you might have a USB keyboard that is not working, to fix the issue our team first needs to determine if the issue is the USB Controller, the device, the HID layer, or even in an intermediate hub. Gathering all the logs to investigate an issue can a bit painful, so we have worked to make it easy to use the capabilities of the Windows Feedback Hub application to provide the most actionable feedback as possible.

This blog post details the resources available to end-users in providing the most actionable feedback to the USB team under Windows 10. A key requirement to filing actionable USB feedback is to use the Recreate my problem feature in the Windows Feedback Hub application. Monitoring mode allows us to configure a rich set of custom log collection to help root root-cause USB issues. At the time of this writing, USB host logs can be captured on either Desktop or Mobile. If you use Recreate my problem we will get logs containing ETW traces of USB2, USB3, UsbUcx, and hub events, which are not filtered. USB function logs will not be captured. If you do not use Recreate my problem, we will not get these logs. Be aware that logs may be as small as 10mb or as large as 100mb depending on how much USB traffic and how much time you spend with Recreate my problem enabled. When you send feedback using Recreate my problem, please make sure you actually reproduce the issue .

Please continue to provide feedback on our blogs! This blog will be updated as necessary with new guidance and information. If you choose to capture your own USB logs outside of Windows Feedback Hub Repro Mode, look through our other blog entries on how to do this, for example this blog.

Windows Feedback on Desktop

1. Launch the Feedback Hub from the Start menu. The Feedback Hub tile should be located in the alphabetical menu or may be pinned to your favorites.

2. After launching the Feedback Hub, select the feedback tab from the drop down menu on the left hand side of the screen

3. From the Category drop down menu select Hardware, Devices, and Drivers.

4. From the Subcategory drop down menu select USB attached devices.

5. Click on Add new feedback.

6. You should see a screen like this. Make sure you select “Problem” when filling out the form. Give a descriptive name in the summary and any details you think we need. Then select "Recreate my problem"

7. This will open up a sub menu to start your data capture. Please disconnect all other USB devices from the system except for the device on which you reproduce the issue before selecting the Start Capture button. Then Select Start Capture .

8. After clicking Start Capture you will see this screen. The stopwatch logo in the bottom right corner indicates that logs are being collected. Proceed to duplicate whatever action caused the issue. This will capture the USB logs while you repro the issue.

8. Navigate back to the application and select Stop Capture. You should see the attachment icon below the grayed out Start Capture button. If you need to abort, hit Cancel and go back. If you need to try again, click Remove next to Recorded background data and Recorded screenshots. Do not click the Submit button if you do not want to submit your logs. If you want to look at the logs or keep a copy for yourself select the check mark next to Save a local copy of diagnostics and attachments created when giving feedback. You will be given a link to their location on the computer after you click Submit.

9. Click Submit & this feedback will be sent to the USB team with logs. Thank you!

Windows Feedback on Mobile

1. Launch the Windows Feedback Hub app from the Start screen. The Feedback Hub tile should look like this:

2. After launching the Feedback Hub app, select the menu icon on the top.

3. Select Feedback from the drop down menu.

4. On the next page select the + to add new feedback.

5.On the next page, make sure you select Problem for the kind of feedback. Give a brief summary of your issue.

6. Next scroll down to select a category and subcategory and under Category select Hardware, Devices and Drivers. Under Subcategory select USB attached devices.

7. Next scroll down until you expose Begin monitoring. Click on it and you have 60 seconds to repeat the action that caused the error problem. This will capture logs for the USB team to investigate while you reproduce the issue. The red stop watch in the bottom corner of the app indicates that logs are being captured.

8. Click Stop monitoring to stop collecting logs.

9. After hitting stop you will see a file icon with the name "System monitoring file". If you want to try to reproduce the issue again, select Remove. If you no longer want to send any logs, select Cancel. Otherwise select Submit to send your logs.

10. This feedback will be provided to the USB team with logs. Thank you!

What is new with Serial in Windows 10

Shyamal Varma — Tue, 16 Oct 2018 20:28:13 GMT

First published on MSDN on Jul 29, 2015

Authored by George Roussos [MSFT]

The Serial Communication protocol is everywhere; it is broadly available, easy to learn, and low cost. It is used across many different transports: typically over USB, in cases over Bluetooth and even over TCP/IP. Many people are familiar with COM ports and programs that read data from and/or write data to them. Today we find Serial Communications in both 30 year old hardware like natural gas meters and new products like many 3D Printers or those in the prototyping stage based upon Arduino boards.

We listened to customer feedback on Serial while planning Windows 10 and acted upon two high level points:

Improve Serial over USB driver support from Windows.

Provide a Windows Runtime API for communication with Serial devices.

This blog entry focuses on enhancements for USB connected Serial devices in Windows 10, and how customers can provide additional feedback on them which we can efficiently act upon.

1. Improved Serial over USB driver support in Windows 10

Earlier versions of Windows contained a driver for USB connected serial devices: usbser.sys . However the driver did not include a compatible ID match in an INF. The driver had to be included using modem INFs which was not standard.

In Windows 10, we added inbox support for USB CDC Abstract Control Model (ACM) compliant hardware. Usbser.sys is now installed as a compatible ID match for USB CDC compliant hardware, without requiring a 3 ^rd party driver or inclusion via modem INFs.

Now devices that report these compatible IDs:

USB\Class_02&SubClass_02&Prot_01

USB\Class_02&SubClass_02

… including popular prototyping boards like Arduinos – just work with our built-in driver.

Also usbser.sys has been completely re-written in WDF, improving its overall reliability as well incorporating new features for power management i.e. USB Selective Suspend. See USB Serial driver on MSDN for details.

2. A Windows Runtime API for communication with Serial devices

Windows 10 includes the Windows.Devices.SerialCommunication universal API designed for these three scenarios:

USB Peripherals like Arduinos – including as a USB Accessory on new Phones and Tablets

Peripherally connected USB to RS-232 Adapters

UARTs inside embedded systems like MinnowBoard Max or Raspberry Pi v2 running Windows IoT SKU

This API does not include support for accessing UARTs/COM ports inside Phones/Tablets/PCs; Windows 10 focused on above 3 scenarios.

//Build/ 2015 USB Accessories including SerialCommunications session introduces this API and walks thru the design and usage of it.

Windows 10 SDK includes two Universal SDK samples illustrating this API:

CustomSerialDeviceAccess SDK Sample

New SerialArduino SDK Sample from above //build talk is now available including C# and Arduino sketch source code.

How to Provide Feedback

We listen and act upon customer feedback; all of above are all results of prior feedback. If you have encountered a problem with functionality described in this blog entry, or want additional functionality, please see below.

Our team listens to two feedback channels to provide feedback: Forums and the Feedback App (see Feedback App post for additional information) are available to everyone. Please follow below guidance on where to provide your feedback and what to include to help us efficiently act upon your feedback.

Forums

Please create a new post on the Windows Insider Program forum under the ‘Devices and Drivers’ Topic.

Feedback App

Please file a bug under:
Category: Hardware, Devices, and Drivers
Sub-Category: USB devices and connectivity

What information to include

To help us efficiently act upon any bugs for feedback you have, please include relevant information below.

Problems with built-in USBSer.sys
USBSerial driver for USB CDC compliant devices

Feedback or Bugs: Please include ‘USBSer’ in bug title

Bugs, please add:

Crisp steps to reproduce the issue

Hardware IDs and Compatible IDs for target device (below)

If problem involves data transfer, please include Traces as described under Tracing below.

Problems with Windows.Devices.SerialCommunication Universal API

Feedback or Bugs: Please include ‘Windows.Devices.SerialCommunication’ in bug title

Bugs, please add:

a sample code fragment that illustrates the problem

All App manifest device capabilities declarations, like

</Device>

</DeviceCapability>

</Device>

</DeviceCapability>

How to capture Hardware IDs

Attach your Arduino, open Device Manager, select the board, select Properties, then Details tab

Select Hardware IDs from Property dropdown

Select the values, right click and “copy” them – and paste into the bug.

Select Compatible IDs from Property dropdown

Select the values, right click and “copy” them – and paste into the bug.

Example: Arduino Uno R3

Hardware IDs
USB\VID_2341&PID_0043&REV_0001
USB\VID_2341&PID_0043

Compatible IDs
USB\Class_02&SubClass_02&Prot_01
USB\Class_02&SubClass_02
USB\Class_02

Tracing

Please enter the copy and paste below commands into an Administrative command window, reproduce the problem, and attach the resultant trace files into a bug:

Before Repro

logman create trace -n Serial_WPP -o %SystemRoot%\Tracing\Serial_WPP.etl -nb 128 640 -bs 128

logman update trace -n Serial_WPP -p {7F82DC23-235A-4CCA-868C-59531F258662} 0x7FFFFFFF 0xFF

logman update trace -n Serial_WPP -p {8FBF685A-DCE5-44C2-B126-5E90176993A7} 0x7FFFFFFF 0xFF

logman update trace -n Serial_WPP -p {0ae46f43-b144-4056-9195-470054009d6c} 0x7FFFFFFF 0xFF

logman start -n Serial_WPP

<Reproduce the problem at this point (do not copy and paste this)>

AfterRepro

logman stop -n Serial_WPP

logman delete -n Serial_WPP

md %systemroot%\Tracing\Logs

move /Y %SystemRoot%\Tracing\Serial_WPP_000001.etl %SystemRoot%\Tracing\Logs\Serial_WPP.etl

USB tests in the Windows 10 Hardware Lab Kit (HLK)

Shyamal Varma — Fri, 12 Oct 2018 22:49:33 GMT

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 Questions

USB 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 Fixes

USB 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 Issues

USB (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.

Solution

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.

Solution

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

Solution

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.

Solution

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:

Solution

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.

New in Windows 10: USB Dual Role on Mobile

Shyamal Varma — Fri, 12 Oct 2018 22:48:10 GMT

First published on MSDN on May 11, 2015

Authored by Andrea Keating [MSFT]

Have you ever wanted to watch the video that was sitting on your flash drive when all you have is your phone? What about editing a Microsoft Word document from your phone with the comforts of a “real” keyboard and mouse? Are you a developer who wants to make USB accessories that work with both Windows Mobile and Desktop devices? Well, in Windows 10 now you can…

In Windows 10, Microsoft is introducing support for USB Dual Role. USB Dual Role refers to the ability of a system to behave as a USB Device or a USB Host. This is a really exciting feature as it adds the ability to use your USB devices with your Mobile phone for the first time ever in Windows!

Please note, this feature will only be available on new Windows 10 devices that support USB Dual Role. This is because of the hardware changes required for the USB port to support device enumeration. While there are devices in the market today that have USB Dual Role capable controllers, the platforms were not designed to support USB Dual Role. New hardware may advertise that they are Dual Role capable.

To support these new devices on the Windows 10 Mobile OS, we are including the following class drivers. These class drivers have been selected for inclusion in Windows 10 for Mobile due to (a) their popularity and (b) key Windows 10 scenarios we are enabling.

USB Host class drivers supported on Windows 10 for phones	Examples of Devices Covered by these drivers
USB Hubs (USBHUB)	USB Hubs
HID (HidClass, KBDCLass, MouClass, KBDHid, MouHid)	Keyboard, mouse
USB Mass Storage (Bulk & UASP)	Flash Drive
USB Audio in / out (USBAUDIO)	Speakers
Serial Devices (USBSER)	Arduino
Bluetooth (BTHUSB)	Bluetooth dongle
Generic USB Host Driver (WinUSB)	Scientific Data Acquisition

The Windows team will continue to monitor the top devices that are plugged into a Windows 10 Mobile system. With this data in hand, we will be in a position to know which additional drivers should be considered for inclusion in future release of Windows. Leveraging WinUSB and our WinRT APIs, a developer can create a custom device that works with a custom app on the Windows Mobile OS.

For more details:

· The Enabling New USB Connectivity Scenarios WinHEC presentation here: https://channel9.msdn.com/Events/WinHEC/2015/WHT200

· The Building New Apps for USB Accessories //BUILD presentation here: https://channel9.msdn.com/events/Build/2015/3-81

· Developer documentation is also available on MSDN here: https://msdn.microsoft.com/en-us/library/windows/hardware/dn957036(v=vs.85).aspx