[BUG] MIDI Service does not enumerate MIDI 1.0 devices when plugged in or changed driver after service startup.

[m-komo]

Describe the bug
If I attach the Roland UM-ONE which is set to the vendor mode, MidiSrv does not enumerate it.
To enumerate, restarting MidiSrv is necessary.

To Reproduce

1. Set the TAB-COMP switch on UM-ONE to [COMP] (vendor mode).
2. Attache UM-ONE to PC.
3. Run 'midi.exe enum ep'.

UM-ONE does not show up.

Expected behavior
It shows up.

Installer Name or Version

• Windows.MIDI.Services.In-Box.Service.1.0.2-preview-8.241219-1336-x64.exe

Desktop (please complete the following information):

• OS: Windows 11 24H2 build 26120.2705 (Insider Dev channel)

Device information, if this is with an external MIDI device:

• Roland UM-ONE
• UM-ONE Driver Ver.1.0.1 for Windows 10/11

Additional context
If UM-ONE is running with the in-box USB MIDI 1.0 driver (USBAUDIO.sys), the MidiSrv enumerates it.

[Psychlist1972]

I'm wondering if this is related to the Windows bug with the old MIDI 1 driver, where it doesn't release property. The way to test it would be:

1. Put the UM-ONE in class-compliant mode
2. Plug into Windows and verify it enumerates.
3. Unplug the device and put it into COMP mode
4. Without plugging it back in, reboot Windows
5. After reboot, plug in the UM-ONE
6. If the UM-ONE enumerates, then this is likely related to the old driver, which is fixed in upcoming Windows builds, not a midisrv issue.

[m-komo]

@Psychlist1972

The issue was reproducible not only with UM-ONE TAB mode (w/vendor driver) but also any USB MIDI 1.0 devices working with the USBAUDIO.sys.

Steps to reproduce

1. Detach any USB MIDI 1.0 devices and reboot Windows.
2. After reboot, open terminal and run 'midi service status' to ensure the MidiSrv is running.
3. Attach the UM-ONE and run 'midi enum ep'.

No endpoints found.

4. Keep connecting the UM-ONE and restart MidiSrv. Then run 'midi enum ep' again.

Endpoint for UM-ONE found.

Installer Name or Version

• Windows.MIDI.Services.In-Box.Service.1.0.2-preview-9.250112-2036-x64.exe (DP9 NAMM Preview 2)

Desktop

OS: Windows 11 24H2 build 26120.2705 (Insider Dev channel)

[Psychlist1972]

@Psychlist1972

The issue was reproducible not only with UM-ONE TAB mode (w/vendor driver) but also any USB MIDI 1.0 devices working with the USBAUDIO.sys.

Steps to reproduce

1. Detach any USB MIDI 1.0 devices and reboot Windows.
2. After reboot, open terminal and run 'midi service status' to ensure the MidiSrv is running.
3. Attach the UM-ONE and run 'midi enum ep'.

No endpoints found.

4. Keep connecting the UM-ONE and restart MidiSrv. Then run 'midi enum ep' again.

Endpoint for UM-ONE found.

Installer Name or Version

• Windows.MIDI.Services.In-Box.Service.1.0.2-preview-9.250112-2036-x64.exe (DP9 NAMM Preview 2)

Desktop

OS: Windows 11 24H2 build 26120.2705 (Insider Dev channel)

Thanks. I will look into this.

[Psychlist1972]

Further data

Just plugged in a MIDI 1.0 device (Korg nanoKONTROL 2 using our in-box driver) after the service had started, and it would not enumerate. There's a regression here I need to fix that seems broader than just when devices change drivers.

midiksinfo shows the device, so this is likely a problem in the transport, not the USB stack

[Psychlist1972]

This should be fixed for the next DP9 NAMM preview, likely to be released tonight.

[Psychlist1972]

Please re-test with DP9-NAMM-3
https://github.com/microsoft/MIDI/releases/tag/dev-preview-9-namm-3

[sat-okada]

I tested with DP9-NAMM-3 and the result did not improve.
Using midiksinfo before restarting MidiSrv I could see the device information, but not in enum.

midiksinfo

midi enum ep

Desktop
OS: Windows 11 Pro Insider Preview Build 27774.rs_prerelease.250111-1221

MIDI device: Roland UM-ONE mk2 (TAB mode, working with the USBAUDIO.sys)

[sat-okada]

Sorry, I had not updated wdmaud2.drv.
After update, the results improved.

[m-komo]

@Psychlist1972
I re-tested with DP9-NAMM-4.
But the issue persists.

[Psychlist1972]

This bug is still present in Customer Preview 1 (Canary). Looking into it.

[Psychlist1972]

Further data

Just plugged in a MIDI 1.0 device (Korg nanoKONTROL 2 using our in-box driver) after the service had started, and it would not enumerate. There's a regression here I need to fix that seems broader than just when devices change drivers.

midiksinfo shows the device, so this is likely a problem in the transport, not the USB stack

Quick update on that one: The Korg devices like that one end up enumerating under the new MIDI 2 class driver.

[Psychlist1972]

After the latest set of fixes I put in over the weekend to handle function blocks and some device naming stuff, I can no longer reproduce this behavior with any of the MIDI 1.0 devices (including UM-ONE) that I have been testing with, when connecting and disconnecting.

I was able to still repro it when moving a device from the MIDI 1 driver to the MIDI 2 driver, so testing that now.

[Psychlist1972]

From testing, I see why this is happening when you change the assigned driver.

It comes through as a Device Information Update, rather than as an add/remove. I'll need to experiment a bit more to see exactly which properties end up updated.

Edit: Well, except any further changes, which come through as add/update. It may be that we have to tell the customer to unplug/replug the device after they change which driver it is assigned to. I'm debugging further and looking into options.