[BUG]: WinMM input cannot release queued buffers after device removal, retaining a MIDI Services connection

[darmolian]

Summary

After an in-use MIDI input is physically disconnected, the WinMM client cannot complete its normal reset/close sequence. midiInReset and midiInStop return MMSYSERR_NODRIVER, while midiInClose repeatedly returns MIDIERR_STILLPLAYING. The client can open the reconnected endpoint and receive MIDI normally, but MIDI Services retains the old connection until the process exits.

MIDIERR_STILLPLAYING is expected while buffers remain queued. The issue is that the documented way to return those buffers, midiInReset, is rejected after the port has been invalidated, leaving the client without a successful cleanup path.

This reproduces with both a vendor-specific MIDI driver and Microsoft's class-compliant USB MIDI driver. It was also independently observed in Cubase 15.

AI Generated Content: This report and the public-source analysis were prepared with OpenAI Codex. I personally performed the hardware power-cycle tests and confirmed the application behavior described below.

Personal observation that led to this report

I became curious about why the connection instances reported for a WinMM session kept accumulating after a MIDI controller was powered off and back on. The controller reconnected and worked normally, but the session count increased instead of returning to one. We captured the session before and after a controlled power cycle, repeated the test with a second class-compliant USB-MIDI keyboard, and compared the behavior with Cubase 15. That testing is what led me to report the cleanup behavior.

Environment

• Windows 11 Pro 25H2, build 26200.9168
• midisrv.exe: 10.0.26100.7705
• wdmaud2.drv: 10.0.26100.7705
• Custom JUCE 9.0.0 application using WinMM MIDI input
• Devices tested:
  • Native Instruments Komplete Kontrol S88 mk2 using Native Instruments driver 5.0.0.57 (nikksm2midi.inf)
  • Class-compliant USB-MIDI device, VID 0F54, PID 0101, using Microsoft usbmidi2.inf 10.0.26100.9168

The official MIDI Diagnostics Tool is not installed on this machine. Session data was captured directly from the MIDI Services session tracker before and after each cycle; the relevant count was 1 before removal, 2 after successful reconnection, and remained 2 in a delayed snapshot.

Steps and observed results

1. Open a MIDI input through WinMM and start it. The MIDI Services session reports one instance for the endpoint.
2. Power the controller off and wait for its endpoint to disappear.
3. Power it back on and allow the application to reopen the returned endpoint.
4. Inspect the WinMM results while releasing the old handle:

midiInReset: 6 (MMSYSERR_NODRIVER)
midiInStop:  6 (MMSYSERR_NODRIVER)
midiInClose: 65 (MIDIERR_STILLPLAYING), unchanged across five attempts

5. The replacement midiInOpen and midiInStart both return success. MIDI from the reconnected keyboard reaches the loaded instrument and produces sound.
6. The MIDI Services session now reports two instances for the same endpoint. The count remains two in a delayed snapshot.
7. In the S88 test, exiting the client process removed the entire session, including the retained instance.

The same sequence and 1 -> 2 retained instance count reproduced with both devices listed above.

Independent application comparison

With Cubase 15 at its Hub and no project open, the S88 endpoint began with one instance. One S88 power cycle increased the same input endpoint to two instances. Several related S88/NI endpoints increased further, then stabilized. Exiting Cubase removed its entire session and all accumulated instances.

This comparison does not establish which close operations Cubase attempted, but it shows that retained instances after the same hot-plug event are not specific to the custom application.

Expected behavior

After surprise removal, WinMM should provide a cleanup path that returns queued input buffers and permits the obsolete handle and MIDI Services connection to close. Reopening the returned endpoint should leave only the replacement connection in the session.

Current public-source observation

Inspected at public main commit 3f16275e4ca10a084fc010a6b7c9a18c5976a504:

• Device removal marks an open WinMM port invalidated: MidiSrvPorts.cpp.
• Once invalidated, every input operation except MIDM_CLOSE returns MMSYSERR_NODRIVER, including MIDM_STOP and MIDM_RESET: MidiSrvPorts.cpp.
• CMidiPort::Reset is the local operation that completes and removes queued input buffers, while CMidiPort::Close returns MIDIERR_STILLPLAYING if those buffers remain: MidiSrvPort.cpp.
• Higher-level close and transport shutdown occur only after the port's close check succeeds: MidiSrvPorts.cpp.
• Service-side device removal invalidates the device pipe but does not destroy its client connections: MidiClientManager.cpp.

This appears to leave a cleanup dead-end when an invalidated input has queued MIDIHDR buffers: reset is rejected because the device is gone, while close is rejected because reset could not return the buffers. Allowing local stop/reset cleanup for an invalidated port, or returning its queued buffers during removal, may resolve the cycle.

The public source was inspected but not built or substituted for the installed Windows components. Unpublished Microsoft source may differ from both the public revision and the installed binaries.

Related issues

• [BUG Parent] In-use MIDI Device Disconnect Parent #1082 — in-use MIDI device disconnect parent
• [BUG] Endpoint does not work if reconnect the device while WinMM app using it. #463 — endpoint failure after WinMM device reconnect, marked fixed in the February 2026 Windows release
• [BUG] WinMM app stops receiving messages when open/close connection multiple times across several apps #564 — WinMM applications stop receiving after connections are opened and closed across applications
• [BUG]: Session context handles can collide after vector erase and slot reuse #1152 — separately reported session context-handle identity issue; not asserted to cause this behavior

[Psychlist1972]

Note that the session connection information is almost certainly a tracking/reporting error. It is not the case that the actual connection survived. It's that the session tracking wasn't properly updated.

Session tracker is not authoritative. It's second-order. This is a bug, but not exactly what was being assumed by Codex.

But the WinMM issue here seems real, and I will debug that.

Pete
Microsoft

[Psychlist1972]

Internal ADO issue 63888566

Pete
Microsoft

[Psychlist1972]

Claude Summary of problem and fix

KIR bug write-up

Problem

After an in-use MIDI input device is removed, a WinMM client has no way to complete its close sequence, and the port plus its MIDI Services connection leak for the life of the process. Reported as #1157 against wdmaud2.drv 10.0.26100.7705, seen with a JUCE application and independently with Cubase 15, on both a vendor driver and class-compliant USB MIDI.

Removal marks the port invalidated, and CMidiPorts::ForwardMidMessage then refuses every input message except MIDM_CLOSE with MMSYSERR_NODRIVER. midiInReset and midiInStop are the documented — and the only — way to return queued MIDIHDR buffers, so they are refused; CMidiPort::Close then returns MIDIERR_STILLPLAYING because those buffers are still queued. Neither side of the cycle can be broken by the application.

Measured on x64 by removing a loopback endpoint underneath an open handle with four buffers queued: midiInReset 6, midiInStop 6, midiInClose 65 on five consecutive attempts, buffers still MHDR_PREPARED|MHDR_INQUEUE. midiInUnprepareHeader also returns 65, from winmm's own MHDR_INQUEUE check. The MIDI output direction was tested the same way and does not have this problem: midiOutClose succeeds, because the STILLPLAYING check applies only to MidiFlowIn.

Fix

Behind Feature_Servicing_MIDI2WinMMCleanupAfterDeviceRemoval, contained entirely to wdmaud2.drv. ForwardMidMessage is unchanged. Net-new CMidiPorts::ForwardMidMessageAllowingCleanup forwards MIDM_STOP and MIDM_RESET to the port regardless of invalidation and delegates all other messages to ForwardMidMessage; the default: call site in CMidiPorts::MidMessage selects between the two under the KIR, with the original call preserved verbatim in the else. CMidiPort::Reset and CMidiPort::Stop touch only client-side state and the application's own buffers, so they remain correct with the device gone. MIDM_ADDBUFFER and MIDM_START continue to be refused, and close still returns MIDIERR_STILLPLAYING if the application never resets, both of which match the documented contract.

Verification

Create a loopback pair, open the A side as a WinMM MIDI input, prepare and queue buffers, midiInStart, then remove the pair by association id and wait for it to leave the WinMM device list. This drives the same device-interface-removal path as a surprise unplug.

• KIR on: midiInReset returns 0, the queued buffers come back as MHDR_DONE, midiInClose returns 0, and the session's connection for that endpoint is released without exiting the process.
• KIR off: midiInReset and midiInStop return 6, midiInClose returns 65 indefinitely, and the buffers stay MHDR_PREPARED|MHDR_INQUEUE.

Hardware equivalent: power-cycle a USB MIDI controller with an application holding its input open, and confirm the obsolete handle closes cleanly and only the replacement connection remains.

Regression check: normal open/start/stop/reset/close with the device still present is unaffected on both paths, and MIDI output behavior is untouched.