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\Drivers32That 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.ProblemsThe 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 entriesThis 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 entrySome 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 ForwardIn Windows MIDI Services, these are the only midiN entries which should be present:midi : REG_SZ : wdmaud.drvmidi1: 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. Midisrv now 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 requiredOn 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.Net effectSo 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