[BUG]: MidiSrv's lazy-loading causes music applications to hang on first use

[sagamusix]

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

Windows 11 25H2

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

• 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 API (sometimes referred to as 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.sys)
• Windows MIDI 1.0 Class Driver (usbaudio.sys)
• Vendor-provided MIDI driver (please provide details below)
• Other or Unsure (please indicate in additional notes section below)

Application Name and Version

OpenMPT

MIDI Device

n/a

Vendor Driver

n/a

Output from the MIDI Diagnostics Tool

n/a

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

Your personal observation that led to the bug report

It appears that as of recently, Windows 11 runs a MIDI service component (MidiSrv) only on-demand, i.e. when an application first calls any of the MIDI API functions, such as midiInGetNumDevs(). Even on a Windows 11 system that has no MIDI devices at all attached (i.e. the only MIDI device listed by MMSYSTEM is the GM wavetable synth), the MIDI API call in question hangs for about ten seconds. Often, as is the case in OpenMPT, MIDI devices are enumerated on the GUI thread, to present a list of available MIDI devices. So this inevitably leads to a GUI hang, or the requested information not being available in the GUI.
If the application in question also suppports MME audio devices, any interaction with MME audio APIs such as enumerating audio devices appears to access the same internal structures as the MIDI device code, so even if you move your MIDI device enumeration code to a separate thread, the audio device code will still be blocked for the same duration if it happens to run at the same time (e.g. because the application enumerates available audio and MIDI devices on startup).

Steps to reproduce

See description above.

Additional notes

I fully understand that the MIDI component is not important to every Windows 11 user, so it is not started automatically to keep startup times lean for such users. However, this comes at the expense of music producers who now either have an inevitable hang, or have their MIDI devices being unavailable on first use. I wonder if the MIDI service could instead be started with a delay and low priority, so that it does not affect Windows 11 startup time for regular users, but doesn't block MIDI device enumeration and other API calls by the time a user is likely to use these APIs for the first time.

I tried to see if I can request the service to be started programmatically when launching OpenMPT, but it appears that this is a privileged operation that a non-admin Windows user cannot invoke. So my only workaround right now is to call midiInGetNumDevs() on a separate thread while OpenMPT starts up, and then hope that the user doesn't do anything that would require MME audio or MIDI devices to be enumerated, otherwise the GUI will just freeze.

[Psychlist1972]

One of the restrictions we had to live with to get the new MIDI Service and APIs in box is that it has to be demand-started only by default. With the increased work to reduce the default memory and CPU footprint of Windows, that is unlikely to change. It has been demand-start-only since January, but until around April or so, any call to WinMM, even for audio from the shell, was starting the service. That was a bug we fixed, so that may be why this seems like a recent change.

We have an option in the MIDI Settings app https://aka.ms/midi to auto-start the service, but the user needs to set that. If they complete the first-run setup of the MIDI Settings app, that change is selected by default. Unfortunately, some Windows Updates can also reset that to trigger-start. That's a bug we're looking into (internal ADO bug id: 63310511).

It can also be set after the fact in the MIDI Settings app here:

The user doesn't themselves need to be an administrator to make that change, but they do need to be able to elevate to an administrator account (and provide those credentials) when it is run.

In addition, other musician-focused services and apps often demand-start midisrv right after boot: NI Integration services, rtpMIDI, loopMIDI, and others.

Can you share with me specs of the system that's taking 10 seconds to start up MIDI without any MIDI devices or drivers in use? That's longer than I would expect in that situation.

Pete
Microsoft

[sagamusix]

It can also be set after the fact in the MIDI Settings app here

Yeah, I'm aware that users can generally change it, but it seems strange to me that now every music production software's manual would need to explain to users how to change a windows setting for the software to become as responsive as they expect it to be. It really seems like an application should be able to somehow signal to the system that it may require MIDI to operate properly, so that the service is started just in time before it's needed.

Can you share with me specs of the system that's taking 10 seconds to start up MIDI without any MIDI devices or drivers in use? That's longer than I would expect in that situation.

I've seen this both on an older ThinkPad with 8th-gen i7 and 32GB RAM, as well as a desktop with a pretty beefy AMD Ryzen 9 (I would need to double-check the exact model number but I doubt it's relevant; it's a very powerful CPU not older than two years) with 64GB of RAM.

[Psychlist1972]

It really seems like an application should be able to somehow signal to the system that it may require MIDI to operate properly, so that the service is started just in time before it's needed.

Yes. The new API, which is going in-box over the next few months, has exactly that. MidiApi::EnsureServiceAvailable(); https://microsoft.github.io/MIDI/sdk-reference/MidiApi/

We cannot modify the API surface area for the older APIs, however, so calling midiIn/OutGetNumDevs, is your closest analog.

Thanks for the information on the PCs showing a 10 second delay. That's longer than I would have expected to see when there are no MIDI devices present.

Pete
Microsoft

[sagamusix]

We cannot modify the API surface area for the older APIs, however, so calling midiIn/OutGetNumDevs, is your closest analog.

I plan to do this now in a background thread, but it also has to be placed carefully because as mentioned above, it seems to share an internal lock with MME device enumeration.

That's longer than I would have expected to see when there are no MIDI devices present.

Is there any way we could debug why this is happening?