[BUG] MidiSrv gets stuck when MIDI messages are received through a MidiSrv enumerated port.

[m-komo]

Describe the bug
When an MME app is receiving MIDI messages via a MidiSrv enumerated port, it suddenly stops receiving MIDI messages. After that, the MME app hangs when I close the app.
If it occurs, all apps using MidiSrv stop working and restarting OS or terminating MidiSrv process is required to recover.

To Reproduce

1. Set the Roland UM-ONE mk2 to class-compliant mode (set the switch to "TAB") and short INPUPT and OUTPUT to loop back messages.
2. Attach the UM-ONE to PC.
3. Update the driver to the USB MIDI 2.0 driver (UsbMidi2.sys).
4. Open the Pocket MIDI 64bit and choose MidiSrv enumerated ports ("Roland UM-ONE I-1" and "Roland UM-ONE O-1") for Input and Output.
5. Open the MIDI In Monitor and the MIDI Out Monitor windows.
6. From the "Views" menu, open "System Exclusive" window.
7. Ot the System Exclusive window, click "Open" and choose attached "TestMIDI_Note.txt".
8. Click "Transmit" to send messages.

All sent messages are looped back and the app starts receiving those messages.
However, messages stop being received halfway and it cannot be closed.

Expected behavior
All sent messages are received and displayed in the MIDI In Monitor.
The app continues working and can be closed.

Installer Name or Version
Windows.MIDI.Services.In-Box.Service.-.1.0.1-preview.7.24305.1438-x64.exe

Desktop (please complete the following information):

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

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

• Roland UM-ONE mk2
• USB MIDI 2.0 class driver (USBMIDI2_10.0.1.7.x64.zip)

Application Information

• MORSON Pocket MIDI (64bit)
  https://www.morson.jp/pocketmidi-webpage/

Additional context
I am not sure if it relates to this issue though, I faced Green Screen once.
I will share the kernel memory dump file separately.

[MusicMaker]

FWIW, just installed pocketMIDI 1.7.0. using custom MIDI 2.0 USB device using the MIDI 2 rev 1.0.7 driver. The device sends UMP packets, (note on/off etc.. no sysex). Midi .exe receives them well , pocket MIDI receives some of the legacy packets after selecting the device and then freezes. Interestingly PocketMIDI seems to sees the UMP device, but MIDI-OX does not.

[Psychlist1972]

Crash dump indicates this is likely an issue in the USB MIDI 2.0 driver.

[AmeNote-Michael]

I have just completed a series of tests that to me points to the service or supportive applications in DP7, and not the driver.

Systems in test:
AmeNote Red: Intel Windows Surface running latest Insider Build.
Devel System: Intel Windows Mini PC running updated Windows 11 Pro
Macbook Pro: M2 Mac updated to latest OS.

Using the UM-One and testing with Pocket MIDI application on all platforms with the test file provided, here is my results:

1. AmeNote Red with DP7 loaded but UM-One using legacy driver - system does not complete transfer of the file, MIDI In Monitor did not observe all data sent out
2. Macbook Pro - full transfer occurred - conclusion, issue not UM-One
3. Devel System without DP7 loaded and UM-One using legacy driver - system completes full transfer - conclusion, not UM-One on Windows in general
4. AmeNote Red with DP7 unloaded and system rebooted - UM-One using legacy driver - system completes full transfer - conclusion, not likely related to driver, something about service or winMM bridging.

It is also important to note, I noticed latency in using the services in this testing. You can visually see that the MIDI In Monitor is lagging the Out Monitor with loopback. When services removed, hard to see any lag.

@Psychlist1972 please assign appropriately to have investigated further outside of driver. At this time I do not think it is a driver issue.

[AmeNote-Michael]

This image from AmeNote Red with DP7 installed, but UM-One is using the default usbdriver.sys. You will note that the messages just stop getting echoed back. I am going to try to connect through USB data logger to see if messages sent to USB and looped back at least.

[Psychlist1972]

I have just completed a series of tests that to me points to the service or supportive applications in DP7, and not the driver.

Systems in test: AmeNote Red: Intel Windows Surface running latest Insider Build. Devel System: Intel Windows Mini PC running updated Windows 11 Pro Macbook Pro: M2 Mac updated to latest OS.

Using the UM-One and testing with Pocket MIDI application on all platforms with the test file provided, here is my results:

1. AmeNote Red with DP7 loaded but UM-One using legacy driver - system does not complete transfer of the file, MIDI In Monitor did not observe all data sent out
2. Macbook Pro - full transfer occurred - conclusion, issue not UM-One
3. Devel System without DP7 loaded and UM-One using legacy driver - system completes full transfer - conclusion, not UM-One on Windows in general
4. AmeNote Red with DP7 unloaded and system rebooted - UM-One using legacy driver - system completes full transfer - conclusion, not likely related to driver, something about service or winMM bridging.

It is also important to note, I noticed latency in using the services in this testing. You can visually see that the MIDI In Monitor is lagging the Out Monitor with loopback. When services removed, hard to see any lag.

@Psychlist1972 please assign appropriately to have investigated further outside of driver. At this time I do not think it is a driver issue.

@AmeNote-Michael

There's a kernel bugchk in the stack dump reported as associated with this, that appears to be from a driver call. I pasted a screen shot. Root cause or not, the driver needs to be hardened to prevent that. That would come out from the fuzz testing anyway.

FWIW, #1 uses an entirely different code path so can't really be used for any sort of validation here. The translation happens in a different place, and the way the device is aggregated is different. At least for the bugchk, the conclusion that it is unrelated to the driver is not supported by the tests.

(Note: If you are using the latest Insider build, you may be running with mixed bits which can further complicate things.)

[Psychlist1972]

FWIW, just installed pocketMIDI 1.7.0. using custom MIDI 2.0 USB device using the MIDI 2 rev 1.0.7 driver. The device sends UMP packets, (note on/off etc.. no sysex). Midi .exe receives them well , pocket MIDI receives some of the legacy packets after selecting the device and then freezes. Interestingly PocketMIDI seems to sees the UMP device, but MIDI-OX does not.

MIDI-0X uses a 32 bit MIDI library that won't see anything from Windows MIDI Services until we install 32-bit MIDI interface bits in WOW64