[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))

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

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 (please include in the areas below the device id from Windows Settings About page or a link to your crash dump uploaded to a sharing service)
• Other or Unsure (please indicate in additional notes section below)

Location

mididiag_kb5101650.txt

• 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)
• Vendor-provided MIDI driver (please provide details below)
• Other or Unsure (please indicate in additional notes section below)

Application Name and Version

Bitwig 6.1 Beta 4

MIDI Device Name

Polyend Play

Output from the MIDI Diagnostics Tool

Environment

• Windows 11 Insider Dev Channel, Build 26200.8875 (KB5101650, installed 2026-07-16)
• In-box service: midisrv.exe / wdmaud2.drv 10.0.26100.8875
• Transports: Midi2.KSAggregateTransport.dll 1.0.16.1, Midi2.KSTransport.dll 1.0.15.0 (both stamped by the CU)
• GitHub SDK/Tools: 1.0.16-rc.3.3, developer mode enabled
• Drivers32: midi=wdmaud.drv, midi1=wdmaud2.drv, MidisrvTransferComplete=1
• Device: Polyend Play, USB\VID_16D0&PID_0EA0&REV_0101, class-compliant USB MIDI 1.0 (Class_01&SubClass_03&Prot_00)

Summary

Before KB5101650 this device was bound to usbaudio.sys (wdma_usb.inf, matching USB\Class_01) and worked for months as a KSA endpoint, including sustained MIDI clock from a DAW. The CU introduced/activated usbmidi2.inf_amd64_a8d6f5e8e782632d (DriverVer 10.0.26100.8737) whose model line USB\CLASS_01&SUBCLASS_03&PROT_00 outranks wdma_usb's generic match; setupapi.dev.log shows the device being reflected to USBMidi2Device on 2026-07-16 00:52. After that, both driver bindings are broken:

Issue 1 — USBMidi2 binding: no UMP endpoint is created

• Device Manager: device OK, CM_PROB_NONE, service USBMidi2
• midiksinfo.exe shows a healthy KS filter with two MIDI 2 UMP format pins (In + Out)
• But: midi.exe enumerate endpoints does not list the device, DEVPKEY_Device_Children is empty, no WinMM port appears
• Result: device invisible to every application

Issue 2 — manual rebind to usbaudio.sys: KSA output path dies under sustained load

Rebinding the device to "USB Audio Device" (wdma_usb.inf) restores the KSA endpoint and WinMM ports. Low-rate traffic works. Sustained output does not:

• WinMM midiOutShortMsg, MIDI clock (0xF8) at ~50 msg/s on an open handle
• After ~88 messages (~2 s) every subsequent send permanently returns MMSYSERR_ERROR (1), including after pauses; handle later becomes MMSYSERR_INVALHANDLE
• MidiSrv then re-enumerates the endpoint (WinMM port order changes)
• Reproducible every time. DAW symptom (Bitwig as clock master): transport works for a few seconds, then "could not send MIDI"; subsequent program changes never arrive

Control: iRig PRO DUO (Thesycon vendor driver) on the same KSA transport: 950 clock messages over 30 s, zero errors. The regression is specific to the in-box driver paths, not to KSA clients in general.

Expected

Either binding should work: USBMidi2-bound MIDI 1.0 devices should get a UMP endpoint via the KS transport, and the KSA path over usbaudio.sys should survive sustained output (it did before this CU).

Notes

• KB5101650 is a checkpoint cumulative — wusa /uninstall fails with 0x800f0926, so there is no rollback path for affected users
• mididiag output attached

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

Steps to reproduce

No screenshots applicable — the failures are programmatic; key console output is quoted inline, full mididiag output attached.

Issue 1 — USBMidi2 binding creates no UMP endpoint

1. Windows 11 Build 26200.8875 (KB5101650). Connect a class-compliant USB MIDI 1.0 device (here: Polyend Play, USB\VID_16D0&PID_0EA0, 1 in / 1 out). After this CU it binds to USBMidi2-ACX automatically (before the CU it bound to usbaudio.sys).
2. Device Manager: device reports OK, CM_PROB_NONE, service USBMidi2.
3. Run midiksinfo.exe → KS filter is healthy, two MIDI 2 UMP format pins (In + Out) are present.
4. Run midi.exe enumerate endpoints → device is not listed. DEVPKEY_Device_Children is empty, no WinMM port exists.

Expected: UMP endpoint + WinMM ports. Actual: device invisible to all applications.

Issue 2 — rebound to usbaudio.sys, KSA send path dies under sustained load

1. Same machine. In Device Manager, update the device driver to "USB Audio Device" (wdma_usb.inf).
2. KSA endpoint and WinMM ports appear. Low-rate sends work.
3. Open the WinMM out port and send MIDI clock (0xF8) at ~50 msg/s via midiOutShortMsg (repro script below).
4. After ~88 messages (~2 s) every subsequent send permanently returns MMSYSERR_ERROR (1) — including after pauses. The handle later returns MMSYSERR_INVALHANDLE; MidiSrv re-enumerates the endpoint (WinMM port order changes).

Clock messages sent: 916, failed: 828
First error: code 1 at message #89 after 3.8s

5. Control: identical test against an iRig PRO DUO OUT (Thesycon vendor driver, same KSA transport): 950 messages / 30 s, zero errors.

$sig = @'
using System;
using System.Runtime.InteropServices;
public class MidiOut {
  [DllImport("winmm.dll")] public static extern int midiOutOpen(out IntPtr h, int id, IntPtr cb, IntPtr inst, int flags);
  [DllImport("winmm.dll")] public static extern int midiOutShortMsg(IntPtr h, int msg);
  [DllImport("winmm.dll")] public static extern int midiOutClose(IntPtr h);
}
'@
Add-Type -TypeDefinition $sig
$portId = 6  # adjust: WinMM out port index of the usbaudio-bound device
$h = [IntPtr]::Zero
[MidiOut]::midiOutOpen([ref]$h, $portId, [IntPtr]::Zero, [IntPtr]::Zero, 0)
$sent = 0; $firstErr = $null
$sw = [Diagnostics.Stopwatch]::StartNew()
while ($sw.Elapsed.TotalSeconds -lt 30) {
  $r = [MidiOut]::midiOutShortMsg($h, 0xF8)
  $sent++
  if ($r -ne 0 -and -not $firstErr) { $firstErr = "code $r at message #$sent after $([math]::Round($sw.Elapsed.TotalSeconds,1))s" }
  Start-Sleep -Milliseconds 20
}
[MidiOut]::midiOutClose($h)
"sent=$sent firstError=$firstErr"

Expected behavior

Both in-box driver paths should work for a class-compliant USB MIDI 1.0 device:

• USBMidi2-ACX binding: the KS transport should create a UMP endpoint from the driver's UMP pins, so the device appears in midi enumerate endpoints and gets WinMM/WinRT ports — as the kernel driver side already works (midiksinfo shows healthy In/Out pins).
• usbaudio.sys binding: the KSA send path should sustain continuous output indefinitely (~50 msg/s MIDI clock is normal DAW traffic). This exact combination ran for months before KB5101650 — sustained Bitwig clock included — so this is a regression, not a new limitation.

Additional notes

Timeline / root cause observation: setupapi.dev.log shows the rebind happening during the KB5101650 install (2026/07/16 00:52): devices previously reflected as USB\Class_01 [USBAudio] (logs from Dec 2025–Feb 2026) were reflected to USB\Class_01&SubClass_03&Prot_00 [USBMidi2Device]. The newly activated package usbmidi2.inf_amd64_a8d6f5e8e782632d (DriverVer 10.0.26100.8737) matches more specifically than wdma_usb.inf's generic USB\Class_01, so it wins driver ranking. An older package usbmidi2.inf_amd64_19049fd76cdd1d31 is still referenced in the driver index but its folder no longer exists in the FileRepository, so no rollback to the previous driver is possible.

Component versions (all stamped by the CU, 2026-07-14): midisrv.exe / wdmaud2.drv 10.0.26100.8875, Midi2.KSAggregateTransport.dll 1.0.16.1, Midi2.KSTransport.dll 1.0.15.0. GitHub SDK/Tools 1.0.16-rc.3.3, developer mode enabled. Drivers32: midi=wdmaud.drv, midi1=wdmaud2.drv, MidisrvTransferComplete=1.

Related issues (checked, not duplicates):

• #1043 — USBMidi2-ACX port failures on MIDI 1.0 devices with unequal in/out port counts. Different from Issue 1 here: the Polyend Play has symmetric ports (1 in / 1 out) and gets no endpoint at all rather than a partially working set. #1043 also predates KB5101650 (builds .8737/.8524) — this CU widened the blast radius by rebinding devices from usbaudio.sys to USBMidi2.
• #1041 — SysEx corruption on the receive path via KSA (driver 1.0.16.1). Issue 2 here is the send path over KSA + usbaudio.sys dying after ~88 messages — same transport version, different direction and failure mode.

No rollback path for affected users: KB5101650 is a checkpoint cumulative; wusa /uninstall fails with 0x800f0926.

Control device: iRig PRO DUO (Thesycon vendor driver) on the same KSA transport shows no send failures — the regression is specific to the in-box driver paths.

Full mididiag output attached.