[BUG]: All KS hardware endpoints lost after USB dock swap; in-box usbaudio.sys and USBMidi2.sys both affected #AIgenerated

Report pre-requisites

• I have searched this repo for existing issues to confirm this is not a duplicate
• I agree to follow this project's Code of Conduct

Clarity and Disclosure

• I confirm that any AI analysis included in this report is clearly called out / tagged as AI-generated with "AI Generated Content". Reports with suspected AI content may be closed if not disclosed.
• I confirm that I will quickly follow-up to questions or requests for additional detail, otherwise the issue may be closed

Windows Version

11, 25H2, build 10.0.26200.8875

Type of bug

• Windows doesn't recognize MIDI device (doesn't show in device manager)
• Application doesn't recognize MIDI device or ports
• Cannot update firmware on MIDI device (specify device, app, and firmware info)
• MIDI device is recognized, but cannot send or receive messages
• Sent or received MIDI messages are corrupted
• Application not working as expected
• MIDI 1.0 ports not named as expected
• Performance not as expected
• Localization issue (incorrect or missing language for Windows running something other than en-US)
• General application crash or hang
• MIDI Service crash or hang requiring Windows reboot
• Windows bugcheck / BSOD
• Other or Unsure

Location

• Application using WinMM MIDI 1.0 (Classic API). Name provided below.
• Application using WinRT MIDI 1.0 (Windows 10 MIDI). Name provided below.
• Application using Windows MIDI Services SDK (MIDI 2.0). Name provided below.
• Other app/DAW/tool. Not sure about which API or SDK it uses. Name provided below.
• Windows MIDI Services tools like MIDI Settings, Console, etc.
• Directly in Windows MIDI Services SDK (for Developers only, please provide repro code)
• General Windows shell (Device Manager, Settings, Services, etc.). Name provided below.
• Windows MIDI 2.0 Class Driver (usbmidi2-acx)
• Windows MIDI 1.0 Class Driver (usbaudio)

Application Name and Version

Chrome / Edge (Web MIDI). Also reproduced below the app layer entirely, by calling midiInGetNumDevs() directly.

MIDI Device Name

Quilter Labs Stride (USB\VID_378D&PID_0103), class-compliant USB MIDI 1.0, bound to usbaudio.sys.

Control device: Morningstar MC3 (USB\VID_331B&PID_0005), bound to usbmidi2.inf / USBMidi2.

Output from the MIDI Diagnostics Tool

Not attached, deliberately — and I'd rather explain why than submit contaminated data.

The MIDI Settings app / SDK tools are not installed on this machine, and I would prefer not to install them onto the system that currently reproduces this. The failure is in hardware-endpoint enumeration by the KS transport, and adding MIDI Services components to a live stack that is currently in the failed state risks perturbing exactly what you'd want to inspect.

Happy to install and provide full mididiag output on request. Because the repro is deterministic (see below), I can capture it in either state — failed immediately after a dock swap, or healthy after a midisrv restart — or both for comparison. Just say which is more useful.

In the meantime, the equivalent raw data is inline under Additional notes: enumerated transports, WinMM device counts, PnP status and instance IDs, driver bindings, transport DLL versions, and file versions for midisrv.exe and usbaudio.sys. All collected directly on the affected machine while in the failed state.

Repro

• I confirm that I was able to reproduce this issue using a simple app like midi.exe, midi1monitor.exe or Pocket MIDI
• I tried but was unable to reproduce this issue using a simple application

Reproduced below the app layer entirely: a direct P/Invoke to winmm.dll!midiInGetNumDevs() from PowerShell returns 0. That is more primitive than any of the listed tools, so no application behaviour is involved in the observation.

Steps to reproduce

1. Dock a notebook via USB-C with a class-compliant USB MIDI device attached. Confirm ports are visible — midiInGetNumDevs() > 0.
2. Undock, move to a different dock, redock.
3. midiInGetNumDevs() now returns 0, and no MIDIU_KSA_* PnP nodes exist. The device itself remains present and healthy in Device Manager, ProblemCode 0, throughout.
4. Restart-Service midisrv -Force (elevated) → all endpoints return within a few seconds, with nothing replugged.

Reproduces on every dock swap. Persists across reboots until the service is restarted.

Note on step 4: applications that enumerate MIDI once at process start (Chrome, Edge) must also be fully restarted afterwards — a page reload is not sufficient, since the stale device list lives in the browser process.

Expected behavior

A USB topology change should cause the KS transport to re-enumerate hardware endpoints, as it does on an ordinary hotplug. Endpoints should not be silently lost until the service is manually restarted.

Additional notes

Evidence, captured in the failed state

midisrv is Running, but the only enumerated transports are the six software ones — zero MIDIU_KSA_*:

SWD\MIDISRV\MIDIU_APP_TRANSPORT
SWD\MIDISRV\MIDIU_DIAG_LOOPBACK_A
SWD\MIDISRV\MIDIU_DIAG_LOOPBACK_B
SWD\MIDISRV\MIDIU_DIAG_PING
SWD\MIDISRV\MIDIU_DIAG_TRANSPORT
SWD\MIDISRV\MIDIU_LOOP_TRANSPORT

midiInGetNumDevs()  = 0
midiOutGetNumDevs() = 1     (Microsoft GS Wavetable Synth only)

The device is present and healthy the entire time:

Status  Class  FriendlyName          InstanceId
OK      MEDIA  Stride                USB\VID_378D&PID_0103&MI_00\...
OK      USB    USB Composite Device  USB\VID_378D&PID_0103\...

Descriptors verified correct — Interface 0 Audio/AudioControl, Interface 1 Audio/MIDIStreaming with bulk endpoints 0x01 OUT / 0x81 IN, 101 bytes, no IAD. usbaudio.sys binds cleanly and creates the KS filter \\?\usb#vid_378d&pid_0103&mi_00#...\global.

Midi2KSTransport and Midi2KSAggregateTransport are registered with Enabled=1, DLLs present at C:\Windows\System32\Midi2.KS*Transport.dll v1.0.15.0 — enabled and loadable, enumerating nothing.

Vendor-independent control test

A Morningstar MC3 (VID_331B&PID_0005) bound to the USBMidi2 class driver (usbmidi2.inf, ProblemCode 0) — a different in-box driver stack — yields zero MIDI ports at the same time. Two vendors, two in-box driver paths, one simultaneous failure. That is what points at the KS transport rather than at either driver.

Relationship to existing issues

• #928 (devices installed while the service is running are not visible) is the closest existing report, but is explicitly scoped to vendor-provided custom drivers and states it does not occur with in-box USBAUDIO.sys or USBMidi2.sys. This case is in-box drivers only, on two stacks simultaneously — so either #928 is broader than currently believed, or this is a separate path to the same end state.
• #585 (SDK reports old endpoints after resume from sleep) is the closest conceptual match — a system-level transition leaving endpoint state wrong, fixed by a service restart — but is filed as stale endpoints with "Unsure on steps". If the root cause is shared, the dock-swap repro here is deterministic and may be the reliable trigger that issue has been missing.
• #1061 is on this exact build (26200.8875) and also involves class-compliant USB MIDI 1.0 across both drivers, but the symptom differs (no UMP endpoint after rebind, and send failure after ~88 messages) rather than total loss of all hardware endpoints.

Ruled out

• Not the device. Descriptors correct, ProblemCode 0 throughout, works immediately after a service restart with nothing replugged.
• Not one vendor or one driver. Two vendors, two in-box stacks, simultaneous.
• Not a servicing fault. midisrv.exe reports 10.0.26100.7705 next to usbaudio.sys at .8875, which looks like version skew but is not: System32\midisrv.exe is hardlinked to, and SHA256-identical with, the .8875 microsoft-windows-devices-midi2 component in WinSxS (630,784 bytes, BAD13BB5DA86…). WinSxS folder names carry the package version, not the contained file's version resource. sfc and DISM find nothing to repair. Flagging this specifically because the version pair looks alarming and is a dead end.
• Not a port or cable. Occurs across different docks and direct ports.
• Not stale state. Survives reboots until midisrv is restarted.

Workaround

Restart-Service midisrv -Force (elevated), then fully restart any application that enumerates MIDI at process start.

---

AI Generated Content disclosure: diagnostic collection and the drafting of this report were AI-assisted (Claude / Opus 5). Every measurement quoted above was taken directly on the affected machine and verified by me; nothing is inferred, reconstructed, or recalled from documentation. The one thing worth calling out is that the AI-assisted analysis initially proposed a midisrv/usbaudio version-skew theory, then disproved it by hash comparison — that is why the "Ruled out" section flags it explicitly, so nobody else follows the same dead end.

Reproduce the dock-swap sequence and observe midiInGetNumDevs(), MIDIU_KSA_* nodes, and the enumerated transports before and after restarting midisrv. Start by investigating the KS transport path involving Midi2.KS*Transport.dll, usbaudio.sys, and USBMidi2. Done means hardware MIDI endpoints reappear after a topology change without restarting midisrv, while both in-box driver paths remain functional.