[BUG]: WinRT MIDI 1.0 MidiInPort silently dead after USB replug on 25H2

Windows Version

26200.7922

Service Installation Method

Other (please indicate below)

SDK version, if appropriate

No response

Location

Application using WinRT MIDI 1.0 (Windows 10 MIDI)

Type of bug

Cannot receive messages from MIDI 1.0 device

Steps to reproduce

1. Open a USB MIDI 1.0 class-compliant device's input port via MidiInPort.FromIdAsync
2. Confirm MessageReceived callback fires normally during use
3. Physically unplug the USB device
4. DeviceWatcher fires removeDevice for both input and output ports (expected)
5. Physically replug the USB device
6. DeviceWatcher fires addDevice — same device paths and GUIDs as before
7. Open the input port again via MidiInPort.FromIdAsync — returns S_OK, valid COM pointer
8. Register MessageReceived callback via add_MessageReceived — returns S_OK
9. Send MIDI data from the device — MessageReceived never fires

Expected behavior

MessageReceived callback fires when the device sends MIDI data after replug, as it does on Windows 11 24H2.

Additional notes

Tested on build 26200.7922 (2026-02 Preview cumulative update KB5074105), which includes the February 2026 "surprise removal" fix (#831). That fix addressed WinMM hangs on device disconnect but does not resolve this WinRT issue.

Debugger session confirmed every WinRT API call succeeds after replug:

• FromIdAsync: S_OK
• GetResults: S_OK, valid COM pointer
• add_MessageReceived: S_OK

Yet the callback is never invoked. The port object passes all validation but is silently dead.

Additional observations:

• Device paths are identical before and after replug (same KSA ID, same GUIDs)
• DeviceWatcher fires duplicate removeDevice for the input port on unplug (input removed 2x, output 1x)
• Output port's SendBuffer executes without error, but the device never responds — output may also be dead
• Not related to #847 (timestamp corruption) — this is callbacks never firing at all

Tested via JUCE 8.0.8 with JUCE_USE_WINRT_MIDI=1. Setting JUCE_USE_WINRT_MIDI=0 (falls back to WinMM) resolves the issue — USB replug recovery works correctly through the WinMM path on 25H2.

Both WinMM and WinRT are replumbed through midisrv. The February 2026 fix hardened the WinMM path but appears to have left the WinRT reconnection path broken.

Verified with a fresh app restart: after replug, add_MessageReceived is called and returns S_OK (callback re-registered on the new COM port), but MessageReceived still never fires. This rules out stale application state as a cause.

Service installation: Retail Windows 11 25H2 (not Insider, not GitHub install). MIDI service came in-box with the OS.

Attached below is a document with more specific debugger output and details:

WinRTIssueSubmission.md