Closed m-komo closed 14 hours ago
This is a tough one Michael, as it's garbage data. MIDI Services passes it along because it fits the UMP message type and size, and we don't validate beyond that.
If translation to valid byte stream message fails, I would just abort translating that UMP and discard it.
@AmeNote-Michael I suppose you could just convert this case to empty sysex F0/F7 with no data in between. That would presumably be better than just dropping the message.
@Psychlist1972 this will be resolved with new SYSEX handling in driver using AM Lib.
Next attestation signed driver.
The driver did not previous handle empty SYSEX message. Driver now handles empty SYSEX message F0 F7 in both directions: UMP <-> USB MIDI 1.0. and this is resolved in upcoming pull request.
I have confirmed that this issue is resolved with the latest version of the driver (23.1.50.504) and dp6.
I have confirmed that the issue has been solved.
Describe the bug If I send a zero length System Exclusive message (F0 F7) in MT3 format, MIDI Service gets stuck. If this happens, MidiSrv cannot be stopped and restarting OS is required.
This issue only occurs if I send a message to the USB MIDI 1.0 device running with the USB MIDI 2.0 driver (USBMidi2.sys). If I send a same message to the USB MIDI 1.0 device running with the USB MIDI 1.0 driver (USBAUDIO.sys) or the USB MIDI 2.0 device running with the USB MIDI 2.0 driver (USBMidi2.sys), this issue never happens.
To Reproduce
Expected behavior The message '0x30000000 0x00000000' is looped back and MIDI Service and midi console continue to work.
Installer Name or Version Windows.MIDI.Services.Developer.Preview.5.x64.1.0.24066.2126.exe
Desktop (please complete the following information):
Device information, if this is with an external MIDI device:
Application Information midi.exe console app.