Filing this against myself for future investigation. Came up while finishing up BLE today.
Claude Summary:
Summary
net stop midisrv (or stopping the service from the Services MMC) fails with "Windows could not stop the Windows MIDI Service service on Local Computer. The service did not return an error." when a MIDI Services management app is open. A second stop attempt usually succeeds.
The suspected cause is that midisrv requires its clients to release their references before it can complete shutdown, rather than tearing down and letting outstanding client calls fail.
Observed behavior
- With the Bluetooth MIDI Setup app open, stopping the service reliably fails.
- With the app closed, the service stops normally.
- The failure is fast — it is not a long timeout waiting on transport teardown.
- A second stop attempt succeeds, so nothing is permanently hung.
Why this is suspected
Each refresh in a setup app reaches the service through MidiServiceTransportPluginConfigManager::InternalSendConfigJsonAndGetResponse, which performs a fresh out-of-process COM activation on every poll:
auto serviceTransport = winrt::create_instance<IMidiTransport>(__uuidof(Midi2MidiSrvTransport), CLSCTX_ALL);
The Bluetooth Setup app's refresh timer defaults to 2 seconds (DefaultRefreshIntervalSeconds, clamped 1–60). At that cadence there is nearly always either a live reference to the service-hosted COM object or a call in flight.
This is not specific to Bluetooth. network-midi-setup, loopback-setup and bluetooth-midi-setup all use the same refresh timer and the same configuration manager path, so any of them should reproduce it.
Likely related: WinMM clients
The same class of problem has been observed when a WinMM app has a MIDI port open — the service will not stop until the app releases the port. If both share a root cause, this is one defect with two visible symptoms rather than two separate issues, which raises its priority.
This link has not been verified. It is included because the symptom shape matches.
What has not been proven
The causal step — that midisrv's stop path actually blocks on outstanding client references — has not been traced. The evidence is behavioral (stop fails with a client attached, succeeds without) plus the known activation pattern and polling cadence. It is plausible but circumstantial, and an alternative explanation inside the service stop sequence has not been ruled out.
Suggested confirmation steps
- Reproduce with the Network MIDI Setup app instead of the Bluetooth one. Same failure confirms the problem is general rather than transport-specific.
- Reproduce with a WinMM app holding a port open, with no management app running. Same failure supports the shared-root-cause theory.
- Instrument the service stop path to identify what it waits on, and whether outstanding COM references or client sessions gate it.
Possible directions
- Service side (durable): allow midisrv to tear down and let outstanding client calls fail, rather than requiring clients to disappear first. This is the fix that would cover both symptoms.
- App side (mitigation only): pause refresh timers when a management window is not in the foreground, and consider a longer default interval. This narrows the window but cannot close it, since a poll can always land during the stop.
Impact
Low for end users — stopping the service while a management app is open is an unusual action, it fails quickly, and retrying works. Higher for developers and support, where service restarts are routine and this makes them unreliable.
Likely related
#1016
Filing this against myself for future investigation. Came up while finishing up BLE today.
Claude Summary:
Summary
net stop midisrv(or stopping the service from the Services MMC) fails with "Windows could not stop the Windows MIDI Service service on Local Computer. The service did not return an error." when a MIDI Services management app is open. A second stop attempt usually succeeds.The suspected cause is that midisrv requires its clients to release their references before it can complete shutdown, rather than tearing down and letting outstanding client calls fail.
Observed behavior
Why this is suspected
Each refresh in a setup app reaches the service through
MidiServiceTransportPluginConfigManager::InternalSendConfigJsonAndGetResponse, which performs a fresh out-of-process COM activation on every poll:The Bluetooth Setup app's refresh timer defaults to 2 seconds (
DefaultRefreshIntervalSeconds, clamped 1–60). At that cadence there is nearly always either a live reference to the service-hosted COM object or a call in flight.This is not specific to Bluetooth.
network-midi-setup,loopback-setupandbluetooth-midi-setupall use the same refresh timer and the same configuration manager path, so any of them should reproduce it.Likely related: WinMM clients
The same class of problem has been observed when a WinMM app has a MIDI port open — the service will not stop until the app releases the port. If both share a root cause, this is one defect with two visible symptoms rather than two separate issues, which raises its priority.
This link has not been verified. It is included because the symptom shape matches.
What has not been proven
The causal step — that midisrv's stop path actually blocks on outstanding client references — has not been traced. The evidence is behavioral (stop fails with a client attached, succeeds without) plus the known activation pattern and polling cadence. It is plausible but circumstantial, and an alternative explanation inside the service stop sequence has not been ruled out.
Suggested confirmation steps
Possible directions
Impact
Low for end users — stopping the service while a management app is open is an unusual action, it fails quickly, and retrying works. Higher for developers and support, where service restarts are routine and this makes them unreliable.
Likely related
#1016