Cortex XDR triggers Code 10 on USB Audio despite exception - Vendor not selectable, need per-device allow without vendor or something

[M.Simanic]

Environment

• Endpoint OS: Windows 10/11 (latest patches)
• Device: USB Audio (composite device, audio system)
• Driver: wdma_usb.inf / service usbaudio.sys (MEDIA class)
• Cortex XDR Agent: 8.9.0
• Policy: Custom Device Control rule set (USB mass-storage = Block) with an exception intended for this audio device

Problem
• With the Default Device Control policy (Allow) → device initializes and works.
• With our custom Device Control policy (Block) + exception for this device → Windows Device Manager shows “This device cannot start (Code 10)” on initialization.
• Switching Exploit/Malware profiles to REPORT (or even disabling them for testing) does not change the behavior → this points to Device Control as the root cause.
• Without the XDR agent, the device works immediately.

What we already tested
• Removed the device including “delete driver software” → reboot → same result under custom DC policy.
• Tried with Exploit/Malware on REPORT/Disabled → no effect.
• Under Default Device Control the device consistently works → confirms DC policy path as the trigger.

Ive also tried to add the device in to the global excpetions, also tried to add the class GUID in the device management and then applying this to the device configuration profile

Observations
• We see Device Control violation events when the custom policy is active.
• The serial shown in the violation sometimes does not match what a USB inventory/scanner tool shows for the same hardware (likely due to composite device / interface (MI_00/MI_01…) specifics).
• In the Device Control exception UI, the device vendor (VID) for this hardware is not offered in the dropdown, so we cannot build a clean Vendor + Serial allow rule.
• Result: even with an intended exception, initialization fails (Code 10) under the custom policy; with Default (Allow) it succeeds.

Hypothesis
• Either an exception matching issue with composite USB devices (parent vs. interface instance: …&MI_00 etc.), where the exception is not applied to the actual interface that initializes, or
• a timing/priority problem where block evaluation happens before the exception is resolved (thus the driver never gets a chance to start), or
• a regression in Device Control for USB Audio in 8.7–8.9.

Questions to the community / PAN
1. How to allow-list a single USB Audio device when the vendor is not available in the UI?
• Can we create an exception by Device Instance Path or ContainerID/Parent (to cover all interfaces of a composite device)?
• Are wildcards supported for serial matching to handle interface-level serial differences?
2. Composite devices & serial/ID source
• Which identifier does Device Control use in violation events for composite USB audio (interface serial, parent serial, ContainerID)?
• What is the recommended identifier to build a stable exception that covers all interfaces (MI_00/MI_01…)?
3. Known issues / regressions
• Are there known issues (successors to CPATR-26882) in 8.7–8.9 where Device Control prevents USB Audio (usbaudio.sys) initialization despite an exception?
• If yes, what fix version or workaround is recommended?
4. Rule evaluation order
• Does a Block rule take effect before an Exception on device initialization for composite devices?
• Is there documentation on matching priority (Block vs. Exception) and the correct exception scope (parent vs. interface) for USB Audio?

Temporary workaround (works)
• Apply Default Device Control (Allow) on the affected host → device works immediately.
• Exploit/Malware profiles can remain at standard/report; they do not influence this issue in our tests.

Ask
• Looking for a concrete recipe to allow-list this specific USB Audio device without vendor selection (e.g., via Instance Path / ContainerID / Parent), and best practices for composite USB audio exceptions in Cortex XDR Device Control.
• Pointers to any known fixes or Engineering statements are appreciated.

[eluis]

Hi @M.Simanic 

Please add a new custom device class using a valid unique GUID identifier. 

You need to add a different custom device class for every different device with different GUID, so you cant use wildcards, wont be safe since you will be allowing maybe hundreds ? thousands ? of devices at once. 

Please check the how to doc: 

https://docs-cortex.paloaltonetworks.com/r/Cortex-XDR/Cortex-XDR-4.x-Documentation/Device-control?se...

Yes, you are right that malware or exploit profiles do not affect the device control policies and exceptions. 

Once you create the exception of the new custom device class, please perform a couple of check-ins (heart-beats) endpoint-tenant so that the config youve just created is sent to the agent and changes take effect. 

I almost forget: if the above does not work, please open a TAC support case, since there might be a bug to fix there. A SUEX might be needed. 

If you feel this has answered your query, please let us know by clicking like and on "mark this as a Solution". 

Thank you.

KR,

Luis