[BUG]: WinMM app stops working if it works with the vendor custom driver.

[m-komo]

Windows Version

27813.rs_prerelease.250307-1407

Service Installation Method

GitHub

SDK version, if appropriate

1.0.3-preview-11.250228-237

Location

Application using WinMM MIDI 1.0 (Classic API)

Type of bug

Application not working as expected

Steps to reproduce

After sending/receiving several MIDI messages with the WinMM app to/from a USB MIDI 1.0 device which works with a vendor custom driver, the app stops working and cannot be terminated.
Restarting OS is necessary to recover from this condition.

1. Download and install the UM-ONE Driver for Windows 11.
2. Set the TAB-COMP switch on the UM-ONE to [COMP] (vendor mode) and attache it to the PC
3. Restart OS or MidiSrv as a workaround for the #483.
4. Open the Pocket MIDI and choose the "UM-ONE" as an InputPort and an OutputPort.
5. Open the System Exclusive window and load the attached "TestMIDI_Note.txt".
6. Click the "Transmit" buttons to send messages.
7. Make sure the OUT indicator on the UM-ONE stops blinking, then open the Keyboard window and click several keys.

No messages are sent out.
You can confirm this by checking that the OUT indicator on the UM-ONE does not blink.

Then try to quit Pocket MIDI.
The application window closes but the application process remains.
Unable to terminate Pocket MIDI process.

After that, restarting OS is necessary to recover from this condition.

Expected behavior

WinMM app continues to work and can be terminated.

Additional notes

No response

[Psychlist1972]

My guess is this overruns the buffer on the UM-ONE. We're seeing a number of cases where we're sending messages much faster than these MIDI 1.0 devices can handle them, and because there's no throttling, the devices end up failing. I'll look into this.

[m-komo]

I checked the USB log, only the part of messages sent from the application were transferred to USB out.
So, I added a log to the driver's IMiniportMidiStream::Write method, I found that the method was called only halfway through the message sent by the application, just like the USB log.
The cause of the issue seems to be in the layer above the driver.

[Psychlist1972]

@m-komo does this only happen with WinMM clients, or can you repro this also with the MIDI console using UMP messages?

[m-komo]

@Psychlist1972 this never happned with the MIDI console.

I verified with following steps several times.

1. Set the TAB-COMP switch on the UM-ONE to [COMP] (vendor mode) and attache it to the PC.
2. Restart OS or MidiSrv as a workaround for the #483.
3. Open midi.exe in two windows.
4. From one, monitor the UM-ONE.
5. From the other, run 'midi ep send-file TestMT2_Note.txt -p 0'.

• The attached test file contains same Note On/Off messages in MT2 format.

[sat-okada]

I connected Yamaha UX-16 with Early Customer Preview 3. (GitHub Preview)
(1.0.3-preview-12.250322-1519)
(This device only works with Yamaha USB-MIDI Driver.)
I could not reproduce this with midi.exe, but with Pocket MIDI.

[Psychlist1972]

I checked the USB log, only the part of messages sent from the application were transferred to USB out. So, I added a log to the driver's IMiniportMidiStream::Write method, I found that the method was called only halfway through the message sent by the application, just like the USB log. The cause of the issue seems to be in the layer above the driver.

When you say "halfway through the message" do you mean only the first 2000(apx) UMP messages were sent, or only the last? I see the file has 4097 MIDI 2.0 channel voice messages, which would be 12,291 MIDI 1.0 bytes. But it would be more than that in cross-process buffer usage from client.

I connected Yamaha UX-16 with Early Customer Preview 3. (GitHub Preview) (1.0.3-preview-12.250322-1519) (This device only works with Yamaha USB-MIDI Driver.) I could not reproduce this with midi.exe, but with Pocket MIDI.

When you reproduced this with Pocket MIDI, can you tell me what behavior you saw? Did Pocket MIDI also hang for you?

[sat-okada]

When reproduced, the behaviour was as follows.

1. Pocket MIDI displayed "Failed to transmit message".
2. Closed Pocket MIDI window.
3. The Pocket MIDI process was still running when Pocket MIDI window was closed,so terminated Pocket MIDI from task manager.
4. Run midi service status
   Displayed "Service MidiSrv is runnning."
5. Restart MidiSrv as messages could not be sent or received in midi.exe.
   midi service restart
   Displayed "Unable to restart service. Service is not currently runnning."
6. Looking on Task Manager, MidiSrv.exe was found to be running.

[m-komo]

@Psychlist1972

When you say "halfway through the message" do you mean only the first 2000(apx) UMP messages were sent, or only the last?

Only the first 3,450 messages were sent.
To be more specific, "8D 3C 4D" in the TestMIDI_Note.txt was sent, but "9D 3D 4D" was not.