Windows USB-C Notifications: OEM ACPI/UCSI, UcmCx, and WHCP

Microsoft has quietly pushed PC makers to stop treating USB Type‑C as merely a cosmetic port and to implement the platform-level hooks Windows needs to deliver consistent, actionable notifications when Type‑C connections misbehave — a move that aims to end years of “plug‑and‑pray” frustration but which hinges on firmware, ACPI, and driver work at the OEM level. (learn.microsoft.com)

Background​

USB Type‑C promised simplicity: a single reversible plug for power, data, and alternate‑mode protocols such as DisplayPort and Thunderbolt. In practice, the connector’s physical uniformity has masked wildly different internal implementations. Consumers frequently encounter blank external displays, partially functional docks, or chargers that appear to plug in yet don’t charge — and Windows’ ability to explain what’s happening depends on accurate platform telemetry that only firmware and OEM drivers can provide. (learn.microsoft.com)
Microsoft’s latest guidance — now tied into Windows certification and validation tooling — is not a UI change so much as a demand that OEMs supply the correct metadata and connector‑management plumbing so Windows can tell the user why a particular cable or accessory is failing, or why charging will be slow. That guidance covers ACPI descriptors, preferred driver stacks (UCSI / UCM‑UCSI inbox paths or UcmCx client drivers), validation using the Windows Hardware Lab Kit (HLK) and Microsoft USB test tools, and clear documentation of any design exceptions. (learn.microsoft.com)

---

What Microsoft is asking OEMs to do — the technical checklist​

Microsoft’s recommendations are concrete and technical. The main requirements can be summarized as follows:

• Audit and implement ACPI descriptors for every physical USB port, especially the _UPC (USB Port Capabilities) and _PLD (Physical Location of Device) objects so Windows can determine whether a port is external and what it supports. (learn.microsoft.com)
• Prefer UCSI (USB Connector System Software Interface) where hardware supports an embedded controller and ACPI transport, enabling the in‑box UCM‑UCSI ACPI client driver to manage connector state. (learn.microsoft.com) (learn.microsoft.com)
• When UCSI isn’t possible, implement a compliant UcmCx client driver that reports PD negotiation results and charging states to Windows using the documented DDIs. (learn.microsoft.com)
• Validate with Microsoft tooling — HLK tests, the Microsoft USB Test Tool (MUTT), and UCSIControl.exe for low‑level validation — and run stress tests across real‑world charging scenarios (underspec chargers, hubs, and docks). (learn.microsoft.com)
• Surface notifications via Windows UI, not proprietary OEM dialogs, and provide user‑facing toggles where the device policy requires disabling USB data in untrusted scenarios (applies only to external ports; internal devices must not be blocked). (prod.support.services.microsoft.com)

These items are not cosmetic: missing or mis‑constructed ACPI entries are a primary root cause for why Windows doesn’t display alerts such as “Slow charger,” “PC isn’t charging,” or “Display connection might be limited.” (learn.microsoft.com)

---

Deep dive: ACPI, _UPC, and _PLD — why they matter​

What the OS needs to know​

Windows uses ACPI objects to determine whether a USB port is user‑accessible and which capabilities it advertises. Two ACPI objects are central:

• _UPC (USB Port Capabilities) indicates whether a port is connectable, which connector type it is (Type‑A, Type‑C, etc.), and other capability bits.
• _PLD (Physical Location of Device) describes whether a port is visible to the user (user‑visible bit) and supplies spatial metadata used to assign device containers correctly.

If a port is marked as not‑connectable or internal via these objects, Windows will treat the port as an internal device or suppress standard port notifications. Conversely, a properly set _UPC/_PLD ensures devices connected to that port are placed in the correct device container and that the OS can decide when to display troubleshooting toasts. Microsoft documents concrete ASL examples for both internal and external ports to guide OEMs. (learn.microsoft.com)

Common firmware mistakes OEMs make​

• Marking a user‑visible Type‑C port as internal in _PLD (suppresses notifications). (learn.microsoft.com)
• Incorrect _UPC connector type values (for example, labeling a Type‑C port as Type‑A), which prevents the OS from applying Type‑C‑specific logic. (learn.microsoft.com)
• Omitting _UPC or _PLD entirely for ports, leaving Windows unable to distinguish exposed ports from embedded ones.

These are not edge‑case niceties — they materially affect whether a consumer sees helpful diagnostics or ends up at the support desk with inscrutable symptoms.

---

UCSI vs. UcmCx: the preferred driver models​

UCSI (preferred path)​

• UCSI (USB Connector System Software Interface) is an ACPI/firmware interface that lets Windows query connector state (PD negotiation, alternate modes, etc.) without vendor‑specific drivers. When UCSI is implemented in the embedded controller and exposed via ACPI, Windows loads the in‑box UcmUcsiCx.sys and UcmUcsiAcpiClient.sys drivers to manage ports. This reduces vendor surface area and makes notifications more reliable if the ACPI implementation is correct. (learn.microsoft.com)
• Microsoft requires certain UCSI commands and responses (GET_CONNECTOR_STATUS, GET_ALTERNATE_MODES, GET_PDOS, and specific notifications) to be implemented so the OS can map platform conditions to user messages. Testing tools like UCSIControl.exe and HLK tests are available to validate implementations. (learn.microsoft.com)

UcmCx client drivers (fallback)​

• Systems that implement the PD state machine in silicon or expose connector control over non‑ACPI transports must provide a UcmCx client driver that reports connector type and charging state via documented Device Driver Interfaces (DDIs). When done correctly, the client driver calls UcmConnectorPdConnectionStateChanged, UcmConnectorChargingStateChanged, and related DDIs so Windows can generate the right notifications. (learn.microsoft.com)
• Microsoft provides samples and a class extension to simplify writing these drivers, but OEMs still need to ensure correct signaling and state reporting. (learn.microsoft.com)

---

How Windows maps platform state to notifications​

Windows translates specific PD and connector conditions into user‑facing notifications. Key examples include:

• Slow charger: Triggered when PD negotiation yields a slow or trickle charging capability; the UCSI GET_CONNECTOR_STATUS response or a UcmCx ChargingState enum value indicates this. (learn.microsoft.com)
• PC isn’t charging: Triggered when the negotiated contract is not charging despite a plug. (learn.microsoft.com)
• USB device might need more power: Triggered when a connected device’s Request Data Object indicates a capability mismatch (bit 26). (learn.microsoft.com)
• Mode or alternate‑mode failures (DisplayPort, Thunderbolt, USB4): When a device exposes a Billboard descriptor reporting an alternate mode that the host doesn’t support or that isn’t configured, Windows shows targeted messages such as “Display connection might be limited” or “USB4 device functionality might be limited.” As of Windows 11 24H2, Windows recognizes Thunderbolt, DisplayPort, MHL, and USB4 modes for these notifications. (learn.microsoft.com)

These mappings are precise: notifications are generated only when the platform reports the correct status bits or when a UcmCx driver raises the matching charging/mode state.

---

Validation: HLK, MUTT, UCSIControl — the testing playbook​

Microsoft doesn’t expect OEMs to guess; it expects them to validate:

• Windows Hardware Lab Kit (HLK): Run the USB and Type‑C HLK tests to validate ACPI descriptors and connector behavior. HLK contains both automated and manual interop procedures for real‑world test cases. (learn.microsoft.com)
• Microsoft USB Test Tool (MUTT) and UCSIControl.exe: Use MUTT for device/host tests and UCSIControl.exe to send and inspect low‑level UCSI commands during development and bring‑up (requires enabling a test interface on the UCSI driver). (learn.microsoft.com)
• Stress and scenario testing: Test with under‑powered chargers, cheap hubs, multistage docks, and mixed vendor environments to ensure notifications appear consistently and appropriately. Microsoft explicitly recommends this because real users rarely use lab‑grade chargers exclusively.

Running these tests in pre‑production is essential — they’re how OEMs catch mislabeling, incorrect _PLD bits, or driver state‑reporting gaps before a product ships.

---

WHCP enforcement and market impact​

Microsoft has baked these expectations into the Windows Hardware Compatibility Program (WHCP), effectively setting a certification floor for USB‑C functionality on new Windows devices. WHCP test cases and system requirements now include USBTypeCCharging and Type‑C behavioral validation so that certified devices cannot ship with half‑baked Type‑C implementations that would confuse users. (learn.microsoft.com)
A few practical implications:

• New devices that seek WHCP/Windows certification will need to meet these Type‑C minimums or document clear exceptions.
• Existing installed base is unaffected until devices are refreshed; meaningful improvement is gradual and tied to product refresh cycles and OEM engineering cadence.
• Enterprise procurement can now demand WHCP certification as a procurement lever when USB‑C behavior matters to deployments (docking fleets, display thin clients, etc.).

Microsoft’s combination of software capabilities and certification pressure is a pragmatic way to force better alignment across chip vendors, EC firmware, and OEMs — but it is not an instant fix for older hardware.

---

Strengths of Microsoft’s approach​

• Systemic enforcement: Tying requirements into WHCP gives the guidance teeth — OEMs that want certification must conform.
• Standardized interfaces reduce fragmentation: Favoring UCSI and the inbox UCM‑UCSI path reduces vendor driver surface area, making Windows the single, maintained point that turns platform status into user messaging. (learn.microsoft.com)
• Better user experience and lower support costs: Accurate platform telemetry + consistent notifications should reduce help‑desk tickets and returns caused by misinterpreted port behavior.

---

Risks, limitations, and caveats​

• Hardware is immutable: Many legacy designs or cost‑optimized boards simply cannot support required PD, Alt Mode, or bandwidth features. Software and firmware can only document these limitations; they cannot restore missing hardware lanes.
• Implementation complexity for smaller OEMs: Updating ACPI tables, embedded‑controller firmware, or writing UcmCx drivers requires engineering effort and coordination with silicon partners, which can be non‑trivial for boutique vendors.
• Mislabelling and human error: If OEMs incorrectly set _UPC/_PLD values — for example marking an exposed Type‑C as Type‑A or internal — Windows will intentionally suppress notifications, sometimes making the user experience worse. These mistakes must be caught in validation.
• Partial implementations and multiple performance tiers: USB performance tiers (5Gbps, 10Gbps, USB4 40Gbps/80Gbps, Thunderbolt variants) complicate messaging. Even with WHCP there remains room for confusion unless OEMs use clear markings and OS UI cues.

Where claims about OEM adoption timelines are made, they remain estimates: practical rollout timing varies by vendor, region, and product line, and cannot be guaranteed.

---

A practical checklist for OEMs and engineers​

• Audit ACPI tables for every physical USB port; implement and test _UPC and _PLD objects. (learn.microsoft.com)
• If your platform supports an EC with ACPI transport, implement UCSI in firmware and use the in‑box UCM‑UCSI client driver. (learn.microsoft.com)
• If UCSI is not feasible, ship a UcmCx client driver that correctly reports PD state and charging flags to Windows. (learn.microsoft.com)
• Validate with HLK, MUTT, and UCSIControl.exe, and run stress tests with under‑powered chargers, hubs, and third‑party docks. (learn.microsoft.com)
• Never replace Windows’ built‑in notifications with a proprietary overlay; instead ensure Windows notifications are accurate and used as the canonical UI path.
• If security requires USB‑data disable policies in certain modes, implement per‑port toggles that exclude internal devices (keyboard, touchpad) and document those exclusions clearly.

---

How IT admins and power users can triage existing devices​

• Check Device Manager for UCM‑UCSI ACPI device: If present and healthy, the platform exposes connector state via UCSI; if it’s missing or erroring, notifications may be unreliable. Use Device Manager > Universal Serial Bus controllers to inspect the “UCSI USB Connector Manager” node. (learn.microsoft.com, prod.support.services.microsoft.com)
• Inspect ACPI tables: Advanced technicians can dump ACPI tables (acpidump, UEFI tools) and look for _UPC/_PLD definitions matching each USB port’s _ADR. Missing or incorrect values point to firmware issues that OEMs must fix. (learn.microsoft.com)
• Use UCSIControl.exe or a PD analyzer: Validate PD negotiations and see reported capabilities; confirm whether the negotiated RDO indicates a capability mismatch or slow charging state. (learn.microsoft.com)
• Watch for Billboard descriptors: When a display or hub fails to enter an alternate mode, the connected peripheral often enumerates a Billboard device that contains SVID and configuration bits which Windows uses to generate a targeted notification. Detecting a Billboard device is a clear sign of an alternate‑mode mismatch. (learn.microsoft.com)
• Procure WHCP‑certified devices: For deployments where USB‑C behavior matters, insist on WHCP certification to reduce surprise incompatibilities. (learn.microsoft.com)

---

Final assessment — measured optimism, practical realities​

Microsoft’s guidance moves the industry toward clarity: when Windows can depend on accurate ACPI descriptors and standardized connector management, the platform can be the single, reliable messenger that explains why a cable, charger, or dock isn’t delivering the expected outcome. Tying these expectations into WHCP and providing concrete HLK/MUTT validation steps gives OEM engineering teams a clear to‑do list and gives enterprise buyers a procurement lever. (learn.microsoft.com)
That said, the pragmatic picture includes friction: legacy hardware cannot be retrofitted cheaply, smaller OEMs face engineering burdens, and human errors in ACPI markup will continue to create intermittent regressions until industry workflows mature. Consumers and IT teams should therefore expect gradual improvement rather than an immediate fix. In the meantime, the best short‑term mitigations are proper validation during bring‑up, sensible procurement (insist on WHCP where it matters), and clear OEM documentation for any intentional exceptions.
Microsoft’s move reframes USB Type‑C from a marketing checkbox into a software‑visible platform capability — and that is the only practical path to making Type‑C behave like the universal, trustworthy connector it was always meant to be. (learn.microsoft.com)

---

Source: Windows Report Microsoft Issues New Guidance Related to USB Type-C Notifications in Windows for OEMs