[BUG] Sending MT3 messages to UM-ONE running with the USBMidi2.sys causes Green Screen.

[m-komo]

Describe the bug
Sending MT3 messages to UM-ONE running with the USBMidi2.sys causes Green Screen.

This issue only occurs if I call the 'send-file' command via the Windows batch file.

To Reproduce

1. Set the Roland UM-ONE to class-compliant mode (set the switch to "TAB") and attach it to PC.
2. Update the driver to the USB MIDI 2.0 driver (UsbMidi2.sys).
3. Run 'midi.exe enum ep' and put the endpoint name of the UM-ONE into the attached batch file(Send_MT3-file.bat).
4. Double click the batch file to run.

Green screen occurs.

Expected behavior
No green screen issue occurs.

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.2702 (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

• midi.exe

Additional context

• If I run the send-file command manually, this issue never occurs.
• This issue never occurs with the USB MIDI 1.0 driver (USBAUDIO.sys).

[Psychlist1972]

I have validated that this green screens on the February Canary

Sending the file to the UM-One through the Windows MIDI 1.0 Class driver: no problem.
Sending the file to the UM-One using the MIDI 2 class driver: green screen.

I did not need to run a batch file, just pasting the command on the command line was sufficient.

What was strange to me is the green screen it caused was not in the MIDI driver, but it was in DirectX. (dxgmms2.sys)

SYMBOL_NAME:  dxgmms2!VidSchiUnwaitNodeHwQueueProgress+d4

MODULE_NAME: dxgmms2

IMAGE_NAME:  dxgmms2.sys

IMAGE_VERSION:  10.0.27788.1000

STACK_COMMAND:  .process /r /p 0xffff968f1f694080; .thread 0xffff968f1ef04080 ; kb

BUCKET_ID_FUNC_OFFSET:  d4

FAILURE_BUCKET_ID:  AV_R_dxgmms2!VidSchiUnwaitNodeHwQueueProgress

OS_VERSION:  10.0.27788.1000

[Psychlist1972]

Tried with my iConnectivity mio and also reproduced the green screen. Works fine with midi 1.0 class driver, but green screens when assigned the MIDI 2.0 class driver.

Both my mio and my um-one have out connected to in with a physical DIN joiner.

This time, the green screen was shown to be in wdf01000.sys and reported in usbmidi2.sys. So this smells like memory corruption to me.

SYMBOL_NAME:  USBMidi2!USBMIDI2DriverEvtRequestWriteCompletionRoutineDelete+d0

MODULE_NAME: USBMidi2

IMAGE_NAME:  USBMidi2.sys

STACK_COMMAND:  .process /r /p 0xffffd2080e9e40c0; .thread 0xffffd20806ed8080 ; kb

BUCKET_ID_FUNC_OFFSET:  d0

FAILURE_BUCKET_ID:  AV_R_USBMidi2!USBMIDI2DriverEvtRequestWriteCompletionRoutineDelete

OS_VERSION:  10.0.27788.1000

BUILDLAB_STR:  rs_prerelease

OSPLATFORM_TYPE:  x64

OSNAME:  Windows 10

FAILURE_ID_HASH:  {c4e07962-03a1-f1aa-1aa8-b8b9cd7e77f5}

Tagging @AmeNote-Michael

[Psychlist1972]

Tagging @AmeNote-Michael

[AmeNote-Michael]

@Psychlist1972 @garydan42 it is interesting when using kernel debugger, it seems that the midi.exe command in batch file is given opportunity to complete the task at hand, but something in cleanup causes crash. See following picture:

I have also attached a txt file of analyzer and wdflogdump from the kernel debugger for any insights. There does appear to be an error in driver, but this is after it has gone idle from activity. Not sure what error is telling me, need to research further - but if anyone has ideas it would be appreciated.

Issue472-DebuggerAnalysis.txt

Note that after gathering kernel debugger data I then continue execution and get green screen.

[AmeNote-Michael]

Note that I am getting random locations of crash - wonder if same issue as #435 which we still are investigating cause.

[AmeNote-Michael]

Resolved in PR #580

@Psychlist1972

[m-komo]

@Psychlist1972 @AmeNote-Michael
The issue seems to be resolved with this driver(250302-USBMidi2-x64-TestSigned.zip).