[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

[AmeNote-Michael]

I have spent the past day trying to determine where this hang is occurring. As far as I can tell from debugger, it is not inside the driver that it is getting locked up - agreed @Psychlist1972 there may be an error case to handle in a subsequent call to driver, but I have been unable to reproduce the crash error in a condition to be diagnosed.

First I wanted to see if all data is truly transmitted to and from the UM-One. Using Beagle, I can confirm the full dataset is transmitted to the UM-One and with loopback, all data is read back into the Windows USB stack.

Next I looked into the last processed information in the driver into the double buffer. The debug log excerpt below shows that the continuous reader and the driver does process the information and there is room in the double buffer to pass information to higher layers. I still need to determine if the data is subsequently read out of the double buffer. @garydan42 any suggestions on how to check this?

`64972: StreamEngine::FillReadStream - StreamEngine::FillReadStream Entry with m_IsRunning set to 1
64973: StreamEngine::FillReadStream - StreamEngine::FillReadStream MidiIn processing buffer, total processed: 4094
64974: StreamEngine::FillReadStream - StreamEngine::FillReadStream Exit
64975: USBMIDI2DriverEvtReadComplete - USBMIDI2DriverEvtReadComplete Exit
64976: USBMIDI2DriverEvtReadComplete - USBMIDI2DriverEvtReadComplete Entry, NumBytesTransferred 4, TotalBytesProcessed 16380
64977: USBMIDI2DriverEvtReadComplete - USBMIDI2DriverEvtReadComplete Data, Word Processed 0x4f7f9f09

64978: StreamEngine::FillReadStream - StreamEngine::FillReadStream Entry with m_IsRunning set to 1
64979: StreamEngine::FillReadStream - StreamEngine::FillReadStream MidiIn processing buffer, total processed: 4095
64980: StreamEngine::FillReadStream - StreamEngine::FillReadStream Exit
64981: USBMIDI2DriverEvtReadComplete - USBMIDI2DriverEvtReadComplete Exit
64982: USBMIDI2DriverEvtReadComplete - USBMIDI2DriverEvtReadComplete Entry, NumBytesTransferred 4, TotalBytesProcessed 16384
64983: USBMIDI2DriverEvtReadComplete - USBMIDI2DriverEvtReadComplete Data, Word Processed 0x4f7f8f08

64984: StreamEngine::FillReadStream - StreamEngine::FillReadStream Entry with m_IsRunning set to 1
64985: StreamEngine::FillReadStream - StreamEngine::FillReadStream MidiIn processing buffer, total processed: 4096
64986: StreamEngine::FillReadStream - StreamEngine::FillReadStream Exit
64987: USBMIDI2DriverEvtReadComplete - USBMIDI2DriverEvtReadComplete Exit
---- end of log ----`

[MusicMaker]

It seems PocketMIDI must have added MIDI 2.0 support.I have been trying to reproduce this with my custom MID 2.0 HW as a MIDI legacy loopback (not via MIDI but just an internal USB packet loopback) using midi.exe but could not. , By my experience PocketMIDI crashes in different situations and I am not sure sure if PocketMIDI closes the MIDI 2.0 connection correctly. By my experience the service became in unstable state when not doing it correctly (i.e using trhe tokens). I am going to simulate this again with transmit data provides using my custom MIDI 2 client app and custom device..

[m-komo]

@Psychlist1972 @AmeNote-Michael
The original issue, an app stops receiving MIDI messages and MidiSrv stops working, can be reproduced with the USB MIDI 1.0 driver (USBAUDIO.sys) and the Roland vendor specific driver, if an app uses the MidiSrv enumerated ports ("UM-ONE I-1" and "UM-ONE O-1").
It seems that the root cause of the issue is outside of the driver.
I think it would be better to investigate the green screen issue separately.

[AmeNote-Michael]

I have provided detailed logs using the CollectMidiLogs utility to @garydan42. He indicates that he will look at it tomorrow. This is using the USBMidi2.sys Driver.