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

[brian-neunaber]

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

• [BUG]: MIDI devices installed while MIDI Service is running are not visible to apps (Vendor custom driver only) #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 [BUG]: MIDI devices installed while MIDI Service is running are not visible to apps (Vendor custom driver only) #928 is broader than currently believed, or this is a separate path to the same end state.
• [BUG]: SDK reports old endpoints after PC has resumed from sleep #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.
• [BUG]: Polyend Play issues (KB5101650 (26200.8875) regresses class-compliant USB MIDI 1.0 devices: rebound to USBMidi2 driver yields no UMP endpoint; usbaudio.sys fallback dies after ~88 sent messages #AIgenerated (Fable 5)) #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.

[Psychlist1972]

Hi Brian. Thanks for the report.

The only thing KS and KSA have in common is the PnP stack and its notifications that service Windows. Otherwise, completely different drivers and code paths through the service. So it seems we're not getting a PnP notification that these devices have been added. This may be similar to what we saw with the Montage when the vendor driver for the Montage is in use, and it had to do with the USB hub that's embedded in there.

Does the docking station / hub have a valid USB iSerialNumber do you know?

What brand/brands /models of docking station are you using? In my experience so far, this appears to be specific to characteristics of certain USB hubs.

Also, do the MIDI devices have valid iSerialNumber entries in their descriptors?

FWIW, midiInGetNumDevs and the WinMM stack in general are not the lowest layer. The midi.exe direct-to-ump is a lower layer. There's a whole separate step to create the MIDI 1 legacy API ports after the initial UMP Endpoints are created. Nevertheless, I don't think that's material here.

Pete
Microsoft

[Psychlist1972]

Hi Brian Neunaber (@brian-neunaber)

Any answers to the above questions? If not, I'll need to close this as no-repro.

Pete
Microsoft

[brian-neunaber]

Apologies for the delay, Pete.

Q1 — does the dock/hub have a valid iSerialNumber? No. None of the hubs on
this machine do; every one is port-path keyed:

Generic USB Hub USB\VID_0BDA&PID_5411\9&21CDE682&0&4
Generic SuperSpeed USB Hub USB\VID_03F0&PID_066B\5&E5148C&0&2
Generic SuperSpeed USB Hub USB\VID_0BDA&PID_0411\8&4052A7A&0&4
Generic USB Hub USB\VID_1A40&PID_0101\9&21CDE682&0&1
Generic USB Hub USB\VID_03F0&PID_036B\5&709897D&0&1

Hub silicon is Realtek (0BDA), HP (03F0) and Terminus (1A40).

Q2 — dock brand/models. Both are HP USB-C Dock G5. The repro is moving
between two docks of the same model, so the swap changes the port path without
changing hub characteristics.

Q3 — do the MIDI devices have valid iSerialNumber entries?

At the time I filed, the Stride did not. It declared a serial-number index and
returned an empty string, so Windows keyed its instance on the port path. I found
that during unrelated work and have since fixed it to a per-unit serial derived
from the MCU UID:

before:  USB\VID_378D&PID_0103\<port-path>
after:   USB\VID_378D&PID_0104\20A130CF4D42

The MC3 is serial-keyed but the value is degenerate — constant rather than
per-unit, though stable across ports:

USB\VID_331B&PID_0005\4294967295          (0xFFFFFFFF)

I have no evidence either way yet on whether serial validity is related to the
trigger, so I am not claiming it is. If it is worth ruling in or out I can run a
controlled dock swap from a verified-healthy state with the corrected firmware,
and reflash the old firmware to A-B-A it.

New data — the state recurred today, and I captured it before recovering

Failed state, midisrv Running:

midiInGetNumDevs  = 0
midiOutGetNumDevs = 1        (GS Wavetable only)
MIDIU_KSA_*       = none     (only the six software transports)

Both the Stride and the MC3 present and healthy in Device Manager throughout,
ProblemCode 0.

Then, with midisrv Stopped:

midiInGetNumDevs  = 5
MIDIU_KSA_...     = present

So MIDI 1.0 enumerates fully with the service stopped, and not at all with it
running in the failed state. The failed state is strictly worse than the service
being absent.

Two practical notes for anyone reproducing this:

• midisrv is trigger-started on an RPC interface event, so Stop-Service
  frequently reports a bare OpenError while the service bounces straight back,
  and sc start then returns 1056. Holding it down needs
  sc.exe config midisrv start= disabled first.
• Recovery today did not require a deliberate Restart-Service — the stop
  being bounced by that trigger was enough.

Also, on new arrivals: the MC3 in my original report was connected while
already in the failed state. It appeared in Device Manager immediately with
ProblemCode 0 and never became visible to any MIDI application. That is a new
arrival being missed rather than an existing endpoint being lost, which is the
shape of #928 — but on in-box drivers.

This machine enters the state repeatedly, so I can capture whatever you want from
it, including mididiag in both states if you would like me to install the tools.

---

AI Generated Content disclosure: as with the original report, diagnostic
collection and drafting were AI-assisted (Claude / Opus 5). Every value above was
measured on this machine and verified by me.

[brian-neunaber]

Follow-up to my 2026-08-10 reply. The state recurred on 2026-08-13 after an office→home dock swap (HP USB-C Dock G5 at both ends, as before), making this the third capture. Two things that reply did not cover:

1. Not a service-start race. midisrv had been running since boot — 25.7 h uptime, never restarted — when the fault appeared.

2. Still present on the current build. This machine has since moved to 26200.9168, and usbaudio.sys was rebuilt to 10.0.26100.8972 on 2026-08-11, while midisrv.exe and both KS transports are unchanged.

State at fault time:

Windows                    25H2 build 26200.9168
midisrv.exe                10.0.26100.7705   (Running, since boot)
Midi2.KSTransport          1.0.15.0
Midi2.KSAggregateTransport 1.0.15.0
usbaudio.sys               10.0.26100.8972
WinMM midiInGetNumDevs     0
SWD\MIDISRV\MIDIU_KSA_*    0
Other MIDISRV nodes        6  (APP_TRANSPORT, DIAG_LOOPBACK_A/B, DIAG_PING,
                               DIAG_TRANSPORT, LOOP_TRANSPORT)
USB\VID_378D&PID_0104      present, CM_PROB_NONE

As on 2026-08-10, the pedal was healthy on USB throughout and never became visible to any MIDI application until the service was restarted.

We have since shipped a WebUSB fallback that bypasses the MIDI stack entirely, so we are no longer blocked. This is everything we have.

[Psychlist1972]

We have since shipped a WebUSB fallback that bypasses the MIDI stack entirely, so we are no longer blocked. This is everything we have.

Thanks. Some notes on serial from your previous info

• A hard-coded iSerialNumber string that is not unique adds a lot of unnecessary churn in the PnP stack if there are multiples of the same device
• An iSerialNumber that points to a blank or invalid string resource should be fixed. Same with any other i index that points to a missing string resource.

There is a bug (or was, I need to check) where a missing iSerialNumber will fail device load when using usbmidi2-acx

I've also noticed that Chromium web midi requires you to restart ALL browser instances if you restart the MIDI service. Otherwise, it seems most or all sites don't get a port list, even after a page refresh. Something to keep in mind. There's not really anything we can do about that behavior.

Quilter Labs Stride (USB\VID_378D&PID_0103), class-compliant USB MIDI 1.0

I couldn't find this when I did a search on your site. Is this available to reproduce the scenario?

I don't know what's inside the device, but the issue we ran into with the Montage, when on a hub, is that the device caused a PnP storm on disconnect/reconnect that was timing out internal Windows PnP alerts. That was because the Montage includes built-in hubs and has quite a bit of topology. I'm guessing this device is less complex.

Perhaps an easier option, if you are open to it, would be to take a repro trace, recording what is happening when you do this. But I know this is no longer blocking for you, so entirely up to you.

Pete
Microsoft

[Psychlist1972]

Brian Neunaber (@brian-neunaber)

So MIDI 1.0 enumerates fully with the service stopped, and not at all with it running in the failed state. The failed state is strictly worse than the service being absent.

That doesn't quite make sense as written. There's no enumeration without the service. I assume what is happening there is stopping the service causes us to re-enumerate everything next time the service is loaded up.

When you make a WinMM call, it makes the RPC call through wdmaud2 which starts the service and then enumerates MIDI endpoints. Because that's a fresh list, it will contain everything that is recognized and connected at that time.

The issue here sounds similar to the Montage one where moves between hubs don't get us PnP notifications under certain circumstances, so we don't know we have to enumerate something new. We are 100% event driven.

Pete
Microsoft