This is just a quick post here to assist users with known bigger issues or workarounds, in the interest of remaining transparent on this project. The full list of known issues is on our github repo at https://aka.ms/midirepoissues
Main Windows MIDI Services Announcement blog post
The issues and workarounds here apply only to the new Windows MIDI Services rollout in Windows 11 retail 24h2 and 25h2. This does not apply to older versions of Windows. Insider builds get different releases on a different schedule so this information may or may not apply to a Windows Insider Canary/Dev/Beta release.
We performed a ton of testing with customers, partners, and our own equipment over the development cycle for Windows MIDI Services, but some bugs have made it through, as is known to happen with software development. We’re working on them in priority order, but I wanted to ensure the most impactful ones have more detail here.
Overview of found issues so far
We’ve found a few classes of issues now that Windows MIDI Services is out in the broader population. Some are our bugs, and some are app bugs or anti-patterns which worked on the older and slower API. Where we have bugs, we are fixing them. Where we can put in mitigations for apps, we will. Here are some of the interesting ones we’re watching for:
- Dynamically Added Ports (loopMIDI, some AKAI and other devices, some DJ controllers) are not visible due to them being created after the service has already started. This has more detail below.
- MIDI 1.0 ports are created slightly after the service has started, so some apps do not see them if the service was not already running before the app started. This same type of app would never see devices that are plugged in after the app was started, even under the old MIDI stack, but it becomes more of an issue here. This is separate from the above issue, but the mitigation is similar. The MIDI Settings app offers an option to start the MIDI Service to auto-start with Windows, and that will help in these situations.
- Some apps are relying on the old lack of multi-client support. This is a tough one. The apps are continuously opening ports on the system, using the fact that the old API would return an error if the port was already in-use. Multi-client (multiple apps being able to use the same MIDI ports) is our top-requested feature, so we don’t want to turn this off, especially not system-wide like this pattern would require. The pattern the apps were following is not a particularly good one. The only thing we can do there is report this to the app owners, and if they are still maintaining the apps, suggest they provide a fix.
- Some apps are relying on the slow speed of the old API and are allocating SysEx buffers after they are needed. This worked in the slower API, but not in the new one. We have some retry logic in place in an upcoming update to help work around this problematic code.
- There are some older .NET MIDI libraries which use an incorrect (too-small) MIDI Header structure definition. We now guard against that in the new stack, which is how we found out about these apps. It causes them to break messages like “An invalid parameter was passed to a system function”. We’re evaluating next steps here, because the guard is there to prevent writing to memory that we don’t have access to, and thereby crashing the app.
- inMusic drivers (old m-audio / midiman, current m-audio, AKAI, RANE) are preventing apps like Cubase from starting up due to locking the MIDI service. Additionally, we’ve finding issues with some third-party drivers besides m-audio. The issue is in the third-party driver. In the meantime, almost no third-party MIDI drivers are required anymore for modern class-compliant hardware.
Full issue list and updates for bugs may be found on our GitHub Repo
Info: How do I know if the new Windows MIDI Services Stack is enabled?
Windows MIDI Services is part of a Phased Rollout. This means that after you install the KB which contains the Windows MIDI Services binaries, you will get the new feature enabled at some point in the next month. Who gets enabled depends on the algorithms that control the rollout phases.
To see if your PC has the new Windows MIDI Services feature enabled, go to https://aka.ms/midi and download the checker tool there. It will be up until the next SDK release, where it will be included as part of the SDK and Tools package. Run this checker and pay attention to the output. It will tell you if the new stack has been enabled on your PC as part of the phased rollout. If it says it has not been enabled, then you are still running the older Windows MIDI stack, and any issues are unrelated to this release of Windows MIDI Services.
There is no way for customers to force enablement of the Windows MIDI Services stack. Everyone who has installed the KB update will be enabled by the end of February as part of the phased rollout. Uninstalling the KB update(s) is the only way to disable the new MIDI stack.
Info: MIDI unreliable on Insider builds.
Windows Insider Dev/Beta especially have an older partial rollout where only 50% of users will ever receive the new bits. Canary is behind as well. Please use retail 24h2 or 25h2 if you want to use the new Windows MIDI Services.
Issues
Bug: Dynamic ports (loopMIDI, loopBE, virtualTE / teVirtualMIDI / rtpMIDI) are not always visible.
Problem: Third-party drivers which dynamically create MIDI ports in Windows do not work as before. Unless the ports were created before the service was started, they are not visible. Additionally, if you have more than 16 loopback ports defined in either loopBE or loopMIDI, only 16 will be available, and the names may be messed up.
Known to affect:
- loopMIDI
- loopBE / loopBE30
- teVirtualMIDI (used by loopMIDI and rtpMIDI as well)
- Sonic Core software-defined MIDI ports
- te rtpMIDI
Possibly impacts
- SSL 360 link
- MPC Live III
- Possibly other AKAI apps
The problem is that the devices create the ports after midisrv has already started, and we don’t currently detect new ports added to an existing device. So what the next workaround is doing is trying to get the dynamic ports created before midisrv asks for them, and before you start your MIDI-using apps.
The MIDI Service today detects only when new devices are created, not when existing devices create new ports. This will be fixed. (Currently expected for 4th week of March release 3D)
Workaround 1: For basic loopback, use our in-box preview
We have a preview of MIDI 1.0 basic loopback support for Windows MIDI Services on GitHub here.
Just follow the installations instructions in the release post. We will ship this in Windows later this year. There are no practical limits to the number of ports you can create, and they are natively implemented in the MIDI Service.
Workaround 2: Install the KSA Preview Transport from our Discord server
The Discord Server has an #early-preview-releases channel. In that is the updated KSA Transport which no longer requires restarting the service, and has support for endpoints added after the service has started, as well as support for > 16 virtual ports.
Bug: WinRT MIDI 1.0 Timestamps are in the future, so no messages received.
This impacts Cakewalk Sonar and Steinberg Cubase when set to use WinRT MIDI, and also djay pro. The fix will be in Windows in a few months. In the meantime, a patch is available here.
Issue: inMusic-branded companies’ drivers locking up the MIDI Service (M-Audio/Midisport, AKAI, RANE, and possibly others)
This seems to impact all the inMusic drivers including the m-audio drivers, AKAI drivers, RANE, and others, regardless of device. Most of the newer MIDI devices are class-compliant and so work quite well if you do not download and install the vendor-provided driver.
Update March 4, 2026: We validated today that this driver crashes apps on Windows without Windows MIDI Services installed, but it wasn’t always obvious to the user that the MIDI connection had crashed, and it was possible to fix it by unplugging and replugging the device. The driver itself has an issue we cannot work around in the MIDI stack. We’ll work with inMusic to get this resolved, but it may take some time.
The service lockup happens when we try to close the driver. Other third-party drivers are fine, but these drivers (new and old, regardless of device) all lock up when asked to stop.
Workaround:
If you have one of the later Midisport devices which is class compliant (it works on other operating systems without a driver, this includes some of the older devices) then unplug the Midisport, completely uninstall the M-Audio driver from Windows, and then reboot and plug it back in. At that point, if the uninstall worked correctly, it will use our in-box MIDI 1.0 driver.
In the past, when these drivers crashed or had errors, it would only impact the single app using them. Because we have a service now, the impact can be wider. Note that we’re not seeing this with every PC. The driver fails only on a percentage of PCs, even with the same OS. It may be related to the type of USB port in use.
We do not have a workaround for the older devices which are not class-compliant. We are investigating the startup failures.
Bug: Apps using the WinMM MIDI 1.0 API may not see newly plugged-in devices. (fix rolling out starting end of February)
If you connect or power on a USB MIDI device after you’ve already started an app using the older WinMM MIDI 1.0 API, the device may not be visible.
This can also be true of browser-based MIDI apps.
The fix for this started releasing to the public in the February 2026 update the week of February 23. It takes up to 30 days for everyone to get it enabled. Ensure Windows is up-to-date
Workaround 1: Plug in your MIDI device early
Plug in the MIDI device and ensure it has fully booted up before starting the app.
Workaround 2: Use more than one MIDI device
If you plug in multiple MIDI devices, apps will receive the notification that new devices have been added.
Workaround 3: Restart the MIDI Service
Exit the application, plug in the device, and restart the MIDI service as described in the first issue. This level of restart is not normally required unless there are custom drivers in use which dynamically create MIDI ports.
Bug: Apps using the WinMM MIDI 1.0 API may crash if you disconnect or power down a plugged-in device (fix rolling out starting end of February)
If you disconnect, power down, or otherwise restart a USB MIDI device while an app is using it, that application may crash, depending upon how it has opened the device. This may also required a reboot to clear, depending upon the application.
The fix for this started releasing to the public in the February 2026 update the week of February 23. It takes up to 30 days for everyone to get it enabled. Ensure Windows is up-to-date
Workaround:
Wait until the app has exited before unplugging or powering down a device. This also applies to dynamically-created devices that are not physical USB devices.
Issue: VirtualDJ Not able to communicate with controller (Fixed by VirtualDJ, Windows workaround going out at the end of March)
We have worked with VirtualDJ on this, and would like to thank them for their cooperation and quick response.
The new MIDI stack is much faster than the old one, so we’re finding that some apps are running into errors that they hadn’t previously run into. In the case of VirtualDJ, this results in the UI freezing up.
We’ll have a broader fix in Windows. In the meantime, VirtualDJ have released their Build 9005 with a fix for this. You can download it from their main download page, or let your copy of VirtualDJ update itself.
If that doesn’t fix it for you, you can uninstall the KB update.
Issue: Korg USB devices using a .DRV winmm-style driver are not recognized
The new Windows MIDI Services stack does not recognize the older-style .DRV WinMM drivers and this may cause the device to not appear, or in some cases, apps using MIDI to take a very long time to list devices, appearing to hang. Luckily, there’s very little need for those old-style drivers anymore as the new stack is fully multi-client and supports class-compliant USB MIDI devices.
There is no plan to change this behavior.
Fix (only if Windows MIDI Services is already enabled on your PC)
Completely uninstall and remove the driver. This can be tricky with the Korg drivers in-particular because they tend to cause issues in the registry. A full article is coming on this and will be linked here when ready.
- Uninstall the Korg driver
- Physically disconnect the MIDI device
- In Device Manager (you can find the device manager by right-clicking the start button and selecting it), in the view menu, choose “Show hidden devices”
- Go down to “Sound, video and game controllers, find the device
- Right-click the grayed-out device you just found. Choose “uninstall device”
- If prompted to completely remove the driver, select the option to do so.
- Reboot
After the reboot, the device should be reassigned to our in-box MIDI driver. However, the uninstaller run earlier may have messed up the registry. In that case, download the latest SDK Runtime and Tools package (and only that package) and install it. Once installed, open an Administrator command prompt or terminal window and type midifixreg. Follow the prompts if any. If any changes were made, you will need to reboot again.
These are the only required registry entries for Windows MIDI Services.
Issue: Korg devices using the Korg BLE driver may not show up.
Instructions
We will eventually have a first-class BLE MIDI 1.0 transport in Windows MIDI Services. Today, you can continue to use the Korg driver for BLE MIDI (we do not recommend using their drivers for USB MIDI as those conflict with the USB MIDI Support in the MIDI Service).
Because the Korg BLE MIDI driver is an older style WinMM driver, it needs to be loaded in addition to the new Windows MIDI Services wdmaud2.drv. Because of this, it will not appear in any of the tools provided with Windows MIDI Services and will not be multi-client.
After installing the latest Korg BLE MIDI driver, the registry should have the following entries
Open regedit and paste this location into the address bar at the top of the app
Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32
You should see these entries:
- midi REG_SZ wdmaud.drv
- midi1 REG_SZ wdmaud2.drv
- midi2 REG_SZ korgbm64.drv
Here’s the explanation of what those entries do
- wdmaud.drv provides the in-box MIDI 1.0 synthesizer
- wdmaud2.drv provides the Windows MIDI Service and all USB devices, loopbacks, and more.
- korgbm64.drv provides the Korg BLE MIDI 1.0 devices
With those entries in place, all your devices should be working. There should be no other Korg .drv files in that list. Also note that “midi0” is not a valid entry. That entry needs to be named “midi”.
Issue: Spin Rhythm XD Appears to lock up if MIDI is enabled
This is the first app we’ve found which broke with the new multi-client support. As a result, it just keeps sending messages to all the ports because none of them ever fail.
Multi-client is the key feature in the new stack, and the #1 request from customers. We do not plan to disable this in any way.
Fix
The Spin Rhythm XD team quickly put out a patch for the game. Please see their Discord server for details.
Issue: Some apps may connect to the wrong device if you have multiple identical MIDI devices
The old WinMM API doesn’t really have any way for apps to find ports other than the name, and the new code doesn’t go out of its way to ensure there are no duplicate port names in the system. This is something we’re working to fix.
Workaround 1
If the app allows it (like Cubase), select the option to use the WinRT MIDI API instead of the original WinMM/”Windows MIDI” API
Workaround 2
Using the MIDI Settings app, in the App SDK and tools download, rename the MIDI 1 ports to make the names unique. This requires that the devices either have unique serial numbers, or they stay plugged into the same USB ports.
Workaround 3
If the device is class-compliant and is currently using our in-box MIDI 1 driver only: In Device Manager in Windows, set one of the MIDI devices (if you have two) to use the new usbmidi2-acx driver. (Right-click the device, update driver, browse my computer for drivers > let me pick from available drivers on the system, select USBMidi2-ACX. Like the above workaround, this requires that the devices either have serial numbers or stay plugged into the same USB port so that the USB IDs are not regenerated.
How to uninstall the update if needed
The first KB update containing the new Windows MIDI Services stack started rolling out during the last week of January, as the January 2026 Feature Update Preview (KBKB5074105). If you need to uninstall that, look for it in Settings > Windows Update > Update History > Uninstall Update
Future updates may also include this feature and so will need to be handled separately.
Additional information on our Discord Server in the #start-here section.
Other Important Notes
Do not use the Korg Driver Uninstaller or any other tool which works to change the ordering of midi…midi9 entries in the registry. Windows MIDI Services requires only that midi is set to wdmaud.drv and midi1 is set to wdmaud2.drv. If those two entries are not present, Windows MIDI Services will not work on your system. The SDK runtime and tools includes a tool midifixreg which will ensure these two settings exist, in case you’ve already run one of these tools on your system.
How to File Bugs or Report Issues
Please do not comment on this post with issues/bugs/questions.
Questions/Discussion, and for customers without access to GitHub, issue reporting: https://aka.ms/mididiscord
Developers and anyone else with access to GitHub can file issues here: https://aka.ms/midirepoissues
Is there any planned release for aggregate devices in Windows? My most wanted feature that has been discussed in one of your past blogs.
I assume you’re talking about audio (this blog post is about MIDI). As stated in the past, it’s under consideration for audio, but there are no immediate plans, and it will not be in the UAC2/ASIO driver 1.0 release.
Pete
Microsoft