CCSTUDIO-THEIA: Request for a WHCP-signed XDS560v2 USB driver (sdusb2em.sys) — blocked by the Windows Driver Policy after the April 2026 Windows update.

Hello,

Sang-il Nam said:

* OS : Windows 11 (24H2/25H2), after the April 2026 cumulative/security update

I have the WIndows 11 24H2 security update from June 9 (26100.8655) and I am still able to use my Spectrum Digital XDS560v2.

Was everything working on the PC in question until it was updated with the April security update? Or is this happening on a machine after the update which never had the spectrum drivers installed before?

Thanks

ki

Hi Ki,

Having this update applied doesn't mean the driver is blocked the instant you connect an XDS560v2 on every affected PC. In fact, several of the PCs I manage are on the same update and version, yet on some of them the driver is not being blocked. That said, this does not appear to mean that using the XDS560v2 on a PC where the driver isn't blocked is safe forever.

Here is my understanding of the Windows driver policy (kernel Code Integrity) in Microsoft's April 2026 security patch:
The Spectrum Digital XDS560v2 emulator driver sdusb2em.sys appears to be signed under the old cross-signed program and is not WHCP-signed. On affected Windows systems this driver is currently audited (logged but still allowed), and once a system meets the transition criteria it will be blocked, at which point the XDS560v2 will fail to enumerate/operate.

* On a PC with the security patch applied, an old cross-signed driver is initially handled in audit mode (the driver is not blocked).
* If the driver is not loaded while the conditions of 250 hours (previously 100 hours) + 3 restarts are all met, the system transitions to enforcement mode (the driver is blocked).
* If the driver is loaded before those 250 hours + 3 restarts conditions are met, the counter is reset.

To summarize : on a PC that continuously connects and uses the XDS560v2, the driver gets loaded — and the counter reset — before the transition conditions from audit mode to enforcement mode are met, so the PC stays in audit mode and the driver is never blocked. However, if the device is left unused for a certain period at any point, the system can transition to enforcement mode and the driver will be blocked.

Indeed, on the managed PCs where the XDS560v2 driver is not blocked, if you check the Windows Event Viewer logs for the sdusb2em.sys driver, you can confirm it is in audit mode — corresponding to Event ID 3076 and policy GUID {784c4414-79f4-4c32-a6a5-f0fb42a51d0d}, as shown in the image below. If the XDS560v2 is not connected on that PC for a certain period, it will transition (to enforcement mode) — Event ID 3077, policy GUID {8F9CB695-5D48-48D6-A329-7202B44607E3} — and the driver will be blocked. Ultimately, the definitive fix is for the sdusb2em.sys driver to obtain WHCP signing, or to be added to the allow list.

I'd like to (1) confirm this is on TI's radar, and (2) ask whether a WHCP-signed sdusb2em.sys is planned (or inclusion on Microsoft's cross-signed allow list).

[Reference links]
https://support.microsoft.com/en-us/windows/hardware/drivers/the-windows-driver-policy 
https://techcommunity.microsoft.com/blog/windows-itpro-blog/advancing-windows-driver-security-removing-trust-for-the-cross-signed-driver-pro/4504818 

The following section organizes the key explanations from the links above, framed specifically around the XDS560v2 device driver.

[Summary]
Starting with the April 2026 Windows servicing update, Windows no longer trusts kernel-mode drivers signed only under the legacy cross-signed root program by default. Kernel drivers now need WHCP (Windows Hardware Compatibility Program) certification/signing to load, unless they are on Microsoft's curated allow list.

The Spectrum Digital XDS560v2 emulator driver sdusb2em.sys appears to be signed under the old cross-signed program and is not WHCP-signed. On affected Windows systems this driver is currently audited (logged but still allowed), and once a system meets the transition criteria it will be blocked, at which point the XDS560v2 will fail to enumerate/operate.

[What Microsoft changed]
The cross-signed root program let third-party CAs, countersigned by Microsoft, vouch for kernel driver code. Those certificates have long since expired, but Windows kept trusting drivers signed under the program — a path that has been abused in Bring-Your-Own-Vulnerable-Driver (BYOVD) attacks.

With the April 2026 update, that default trust is removed. Only two categories load by default going forward:
* Drivers properly signed through the Microsoft WHCP certification process, and
* A limited allow list of reputable, widely-used drivers that were signed under the cross-signed program.

[Affected systems]
* Windows 11 24H2, 25H2, 26H1
* Windows Server 2025
* All future Windows client/server releases enforce this going forward.
* User-mode applications are not affected — this is kernel-mode drivers only.

[How the transition works (evaluation → enforcement)]
To avoid breaking machines on day one, the policy first ships in evaluation (audit) mode, then transitions to enforcement on a per-system basis. A system only graduates to enforcement after it demonstrates that it can run cleanly (no untrusted cross-signed drivers) for a sustained period.

Evaluation criteria — both must be met (AND):

(*) The uptime threshold was originally announced as 100 hours and was revised to 250 hours effective with the June 9 (6B) release. Please treat 250 h as the current value and confirm against the latest Microsoft guidance.

The two independent criteria ensure both runtime drivers (covered by uptime) and boot-start drivers (covered by restart sessions) are exercised before the policy is activated.

At the assessment point (once both criteria are met):
* If all drivers loaded during the evaluation window are trusted by the kernel policy → the system activates enforcement. From then on, untrusted cross-signed drivers are blocked, and the policy persists across reboots.
* If any untrusted cross-signed driver was audited during the evaluation window → the policy is not activated, the system stays in evaluation, and the evaluation period is reset (counters back to zero). The system remains in evaluation until the offending driver is no longer seen in the audit.

[The key nuance: the reset loop]
This is the part that matters most for a device like the XDS560v2 that is used regularly on a developer's machine.

Graduating to enforcement effectively requires an unbroken clean streak: 250 hours of uptime plus the required restarts with zero untrusted-cross-signed-driver loads. Each time sdusb2em.sys is audited (Event ID 3076), that clean streak is invalidated and the counters restart from zero.

Consequently:
* On a machine where the XDS560v2 is used frequently, sdusb2em.sys keeps re-appearing in the audit, the counters keep resetting, and the system never naturally transitions to enforcement. The driver keeps working — but only because enforcement is perpetually deferred.
* This is not a safe steady state. If usage becomes intermittent (e.g., the emulator is unplugged for a stretch), the machine can accumulate a clean 250 h / N-restart window, flip to enforcement, and then block sdusb2em.sys (Event ID 3077) the next time it's connected.

[How to verify on an affected machine]
Event Viewer → Applications and Services Logs → Microsoft → Windows → CodeIntegrity → Operational
* Event ID 3076 — a driver was audited (would have been blocked, but was allowed because the policy is still in audit mode). Seeing sdusb2em.sys here confirms it is not trusted under the new policy.
* Event ID 3077 — a driver was blocked from loading under enforcement.

[Request to TI]
1). Is a WHCP-signed build of sdusb2em.sys planned for the XDS560v2 (and, by extension, other Spectrum Digital emulators using the same driver)? If so, is there a target timeframe?
2). Alternatively, is there any effort to get the existing driver onto Microsoft's cross-signed allow list?
3). For the interim, can you confirm the recommended supported workaround?

This affects industrial/embedded customers who rely on the XDS560v2 for C2000 and other TI development on Windows 11 / Server 2025 machines, so a properly signed driver would be the cleanest long-term path.

Thanks in advance.

Best regards,
Sang-il

Sang-il Nam said:

1). Is a WHCP-signed build of sdusb2em.sys planned for the XDS560v2 (and, by extension, other Spectrum Digital emulators using the same driver)? If so, is there a target timeframe?

Please note that the Spectrum Digital drivers are not developed or supported by TI. It is simply bundled by the CCS installter.

Unfortunately, Spectrum Digital is no longer in business. Hence the support for the drivers are limited (if any). I will see what level of support TI can provide.

Sang-il Nam said:

2). Alternatively, is there any effort to get the existing driver onto Microsoft's cross-signed allow list?

Not at the moment. The support for the SD drivers is in question. See above.

Sang-il Nam said:

3). For the interim, can you confirm the recommended supported workaround?

None that I am aware of.

Thanks

ki

Thank you for your reply. Since the reference design belongs to Spectrum Digital, which has gone out of business, I had anticipated that immediate support would be difficult.

For now, the only solution appears to be the method described on the official Microsoft web page linked in the original post (disabling the Windows Driver Policy) — switching back from enforcement mode to evaluation mode restores the ability to use the blocked driver. However, if the XDS560V2 device goes unused for a while and the evaluation-mode → enforcement-mode transition conditions (250 hours & 3 restarts) are met again, the same problem seems to recur. In other words, unless a WHCP-signed driver is provided, this will not be a permanent fix.

It would be ideal if there were a solution that TI could support.

Additional question:

The XDS100v2/v3, XDS110, XDS200, and XDS560V2 technologies are all currently in use, but since the XDS100 series does not support the C29x core, it seems likely to be phased out over time, with the XDS110 and XDS200 technologies expected to become the mainstream choices. It appears that the debug probe TI currently recommends across its various MCU/DSP series is the XDS110 family. I'm wondering whether TI has any plans to release a top-tier debug probe to replace the XDS560V2 technology, or whether the currently recommended XDS110 series is the only alternative going forward.

Best regards,
Sang-il

Thank you for the positive response — I'm glad to hear it.
I hope the new WHCP-signed XDS560V2 driver can be bundled with the next CCS release.

Best regards,
Sang-il

It is tentatively targeted for a release towards the end of the year.

Tracking link: https://sir.ext.ti.com/jira/browse/EXT_EP-13527

Thanks

ki