The USB MIDI 1.0 specification was released in the late 90s around the same time that PCs were starting to move from rectangular beige boxes to things like fake-silvered bulbous plastic shapes. At this point, some of the code in Windows to support USB MIDI 1.0 has become intergenerational – it’s certainly older than my teenagers here at home. There have been updates over the years, but the core has remained largely the same.
Currently, the WinMM / MME APIs that so many apps use rely on device enumeration (that is, discovery and listing of MIDI-capable devices) code in the Windows Audio Endpoint Builder service, and in the existing WinMM libraries.
As part of that enumeration process, there’s a very important registry key:
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32
That registry key contains, among other things, a number of values which control loading of drivers for MIDI-capable devices. That number of driver entries is limited to 10 for reasons which likely made sense at the time.
That doesn’t mean there’s a limit of 10 MIDI ports or MIDI devices on the system, just 10 driver entries. I’ve had dozens of MIDI devices connected to my PC here during testing. I even hit the point of maxing out the number of USB devices my controller will support (that number is different based on CPU), and they all worked.
When you use a MIDI device which requires a custom driver, it sometimes takes up a “slot” in the 10 available midi entries in the registry. Eventually, you can run out of valid entries.
Problems
The existing code in Windows only reads the first ten entries (midi, midi1, midi2…midi9) so if your driver ended up with an entry like midi12 it would never be read, and the driver would not be loaded. Similarly, if there’s a midi0 entry in there, it does not get read because the first entry should be midi not midi0.
If you are using a device where the driver had already been loaded due to a previous entry, then no issues. But that’s not always the case.
Problem 1: Too many entries
This is the common problem which results in customers using tools which cause the midi0 issue mentioned next.
We’ve only seen a handful of drivers which require entries in there, so many people never run into these problems. But if you need one of those drivers, then you’re likely familiar with the problems caused by being bumped off the end of the list.
But once a driver is in the list of valid 10 entries, any device which needs that driver will work.
Problem 2: Invalid midi0 entry
Some third-party tools used to rearrange or otherwise fix these entries create an invalid midi0 entry. I’ve let tools authors know when I see this behavior, but it doesn’t always get fixed.
The way the Windows code was set up, the first entry should be midi with no “0” at the added. The next is midi1 etc. midi0 is an invalid entry. If the driver you require for your device is assigned to midi0, it will not be loaded and your device will not work.
Solution Going Forward
In Windows MIDI Services, these are the only midiN entries which should be present:
midi : REG_SZ : wdmaud.drv
midi1: REG_SZ : wdmaud2.drv
(There is also the existing midimapper entry, and for the time-being, a MidisrvTransferComplete entry that will likely go away in the future.)
The first entry is wdmaud.drv which is the classic WinMM driver and is required for the in-box MIDI synth because the new MIDI Service does not yet handle the in-box synth.
The second entry is wdmaud2.drv which is the driver that turns everything else over to the new MIDI Service midisrv.exe. Because of this transfer, no other midi entries are required. Your device drivers, if they are Kernel Streaming (KS) drivers like most MIDI 1 drivers are, will be discovered and loaded by Midisrv. Gary on the team came up with this approach to forwarding the calls to the new service, and it has been working brilliantly because it required the least amount of plumbing changes inside the WinMM code.
Midisrvnow handles all enumeration of MIDI-capable devices, and uses a completely different way to find the connected Kernel Streaming drivers in the system, including our own MIDI 1.0 and MIDI 2.0 class drivers, as well as third-party KS MIDI drivers. Anything which is not a KS driver, must be implemented in another way. For example, our built-in loopback endpoints are handled completely in service code, as is the Network MIDI 2.0 preview implementation, and the Virtual Device implementation. We`ve built an infrastructure using classic COM to make it easier to write new transports without having to create kernel drivers, or mess with these registry entries.
Most third-party USB MIDI drivers are no longer required
On a PC with Windows MIDI Services, if your MIDI device is a class-compliant USB MIDI device (most are), there’s no need to install a third-party driver for them. The MIDI Service now handles multi-client use of all MIDI devices so that the ports enumerated by any existing driver, including our built-in drivers, can be used by multiple apps.
If the device is not class-compliant, or is not USB, then you will still want to install that third-party driver. However, it won’t require entries in the Drivers32 location in the registry.
We also recognize that customers may install third-party drivers just due to preference or habit, and that a subset of those drivers continue to make updates to the Drivers32 entries. Therefore, the Windows MIDI Services App SDK includes a tool midifixreg.exe which will reset the registry to the Windows MIDI Services default setup with just wdmaud.drv and wdmaud2.drv. Your devices will continue to work regardless of the KS driver they use because once wdmaud2.drv is loaded, all enumeration happens in the service.
C:\Users\Pete>midifixreg
================================================================================
This tool is part of the Windows MIDI Services SDK and tools
Copyright 2025- Microsoft Corporation.
Information, license, and source available at https://aka.ms/midi
================================================================================
- Found value 'midi' with value 'wdmaud.drv'
- Found value 'midimapper'. Leaving it alone.
- Found value 'midi1' with value 'wdmaud2.drv'
No incorrect values found.
C:\Users\Pete>
Net effect
So as we move forward and folks use versions of Windows with Windows MIDI Services installed starting in early 2026, we can look forward to a day when no one, regardless of the MIDI device they use, runs into this 10-driver limit.
And if you are using Windows MIDI Services, before you install a third-party USB MIDI driver, check to see if the device just works with our in-box driver. Even before Windows MIDI Services, almost all recent MIDI devices work just fine with our in-box class driver. The main reason third-party drivers were created was to get around the single-app limitation in Windows with the previous MIDI implementation.
Learn more about Windows MIDI Services, currently available in Windows Insider Canary releases
Great background!
Sorry to ask a stupid question, but if the registry key should always contain the same values, why not update the code that reads it to.. not read it? (and behave like those 2 entries are present).
Are there scenarios going forward where this key needs to be modified? Or are there 3rd party apps that rely on this key containing these values?
The code that reads it is quite old and complex and in the middle of a bunch of other code that has grown around it over the decades. It also handles more than MIDI, it handles a lot of the audio system in Windows. We don't want to crack open that code as it would eventually require us to rewrite a lot and deal with the inevitable backwards compatibility issues that introduces. We've already rewritten quite a bit, but not in that specific area, and that alone has taken us a couple years. (Most of the effort in the new...
> classic COM to make it easier
https://media.tenor.com/MbYXU2om01cAAAAM/fry-not-sure.gif
But seriously, thanks for this great article! I’m not a MIDI user (or device writer – anymore), but I love the inner working details!
Can you please say when new MIDI services will be available in Windows? I mean not in Preview versions but in regular ones. It’s long time passed since you announced this API and it still is not available as part of Windows regular builds. All new features you’re suggesting (MIDI 2.0, virtual devices) in new MIDI services are already exist many years in your competitors. Please give us the release date.
Yes, I provided some information on that at the bottom of the previous blog post. See “So what’s the status of MIDI 2.0 on Windows?”
https://devblogs.microsoft.com/windows-music-dev/troubleshooting-recent-midi-issues-in-windows-11/
Pete
Microsoft
Maxim:
Yes, the new service fixes all the names for WinRT MIDI 1.0. The names are the same ones used by WinMM MIDI 1.0 now.
Also, the user can rename their ports/endpoints using the tools we provide. They can also decide, at a per-device or global level, if they want to use WinMM-compatible names (ugly, but often hard-coded into apps or stored in project files), or new-style names that intelligently use the iJack value (in the case of USB) in combination with filter/device names like so many hardware companies have asked for.
WinRT MIDI 1.0 used the iJack values directly for everything, which...
Thanks for the detailed answer, Pete!
Yes, probably I missed the point when I could start to try new things. Unlike JUCE I'm just a single developer who creates a free library in my spare time... But yes, it's my responsibility to be prepared for new MIDI services.
Regarding WinRT: I've tried to integrate DryWetMIDI in UWP (as far as I know, it uses WinRT) by a user request five years ago and encountered a bug – names of devices are shown incorrectly. This bug is critical in my opinion so I've decided to abandon UWP support (and thus WinRT). BTW, has...
Hi Pete,
Thank you for your reply. Oh, so we need to wait until March 2026...
I'm developer of popular .NET library - DryWetMIDI, and the library provides ability to create virtual devices. But unfortunately it's possible for macOS only right now. The same situation with observing a device plugged/unplugged (many users asked about this). It's sad that Windows still lacks this functionality :-(
By the way, where can we ask different questions regarding how to write programs using new MIDI services? I have a couple of such questions to be prepared for MIDI services release.
Thanks for the feedback Maxim.
Preview builds have been available on Github repo over the past year, specifically so developers and advanced users could get a head start using the new SDK and tools on Insider builds. Windows MIDI Services in-box features (driver, backwards compatibility, etc.) have been in Windows Insider Canary builds. JUCE, among others, have used the previews to build their own MIDI 2 support for Windows.
SDK and tools Release Candidate will be coming within the next month, and adds a new multi-message send/receive feature which was lacking from preview 13. The in-box components (that are in Canary) will...
If only all the Windows divisions were as open and transparent! Thanks for the updates, Pete.