[BUG]: USB MIDI2-ACX Driver incoming SysEx dump corruption (SysEx Framing issue?) with MIDI Baby Gen4

[Psychlist1972]

Two issues with incoming SysEx found by customer (with Claude assistance) in issue #1040. Forking these out here because they are not the same as the original reported issue.

Note that this is more of a stress test than an real-world scenario. The customer is asking the device to send configuration dumps in a spammy fashion. We need to investigate to find out if the device itself is causing the issues (by not queueing up the responses and just overwriting its own buffers) or it's something in Windows. Regardless, the two issues below are issues Windows needs to handle.

F0 leaks into data, corrupting the SysEx

Discovered by Claude. Note message number 618 contains the SysEx 0xF0, which is not valid SysEx data. We'll need to see if the device is sending multiple SysEx End bytes, or something else is going on there.

      593 │ 30230909 09000000 │  1    │ SysEx 7-bit Continue                │ 09 09 09 -- -- --
      594 │ 30300000 00000000 │  1    │ SysEx 7-bit End                     │ -- -- -- -- -- --
      595 │ 30120002 00000000 │  1    │ SysEx 7-bit Start                   │ 00 02 -- -- -- --
      596 │ 3023170F 01000000 │  1    │ SysEx 7-bit Continue                │ 17 0F 01 -- -- --
      597 │ 30230100 00000000 │  1    │ SysEx 7-bit Continue                │ 01 00 00 -- -- --
      598 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      599 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      600 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      601 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      602 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      603 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      604 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      605 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      606 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      607 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      608 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      609 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      610 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      611 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      612 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      613 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      614 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      615 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      616 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      617 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      618 │ 3023F000 02000000 │  1    │ SysEx 7-bit Continue                │ F0 00 02 -- -- --
      619 │ 3023170F 01000000 │  1    │ SysEx 7-bit Continue                │ 17 0F 01 -- -- --
      620 │ 30230200 00000000 │  1    │ SysEx 7-bit Continue                │ 02 00 00 -- -- --
      621 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      622 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      623 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      624 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      625 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      626 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      627 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      628 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      629 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      630 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      631 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      632 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      633 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      634 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      635 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      636 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      637 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      638 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      639 │ 30230000 00000000 │  1    │ SysEx 7-bit Continue                │ 00 00 00 -- -- --
      640 │ 30230909 09000000 │  1    │ SysEx 7-bit Continue                │ 09 09 09 -- -- --
      641 │ 30230909 09000000 │  1    │ SysEx 7-bit Continue                │ 09 09 09 -- -- --
      642 │ 30230909 09000000 │  1    │ SysEx 7-bit Continue                │ 09 09 09 -- -- --
      643 │ 30310900 00000000 │  1    │ SysEx 7-bit End                     │ 09 -- -- -- -- --
      644 │ 30120002 00000000 │  1    │ SysEx 7-bit Start                   │ 00 02 -- -- -- --
      645 │ 3023170C 02000000 │  1    │ SysEx 7-bit Continue                │ 17 0C 02 -- -- --
      646 │ 30230020 00000000 │  1    │ SysEx 7-bit Continue                │ 00 20 00 -- -- --

Claude's analysis and additional info from the customer:

---

@Psychlist1972 — switched the MIDI Baby Gen4 to the KS transport (Device Manager →
usbmidi2-acx). Confirmed on KS via midi list endpoints: endpoint now
\?\swd#midisrv#midiu_ks_3718844848695588880_outpin.0_inpin.2#…. Re-ran the same
config-dump hammer and captured native UMP in midi.exe — 9 cycles, attached.

The KSA failure from this report does not reproduce on KS. When a block is framed
correctly it comes back byte-perfect. Block 0F 00 00 is byte-identical on 6 of 9
reads, with both non-default 0x40 parameter bytes intact, matching the Android
ground truth from the original report:
F0 00 02 17 0F 00 00 01 00 …00… 11 00 …00… 40 00 …00… 09×9 40 09×6 00 …00… 01 F7
No interior SysEx7 byte drops, no 0x40 loss, no abandoned messages of the KSA kind.
So moving off the KSA aggregation path resolves the corruption described here.

However, KS surfaces a different, clearly driver-side defect: SysEx message-boundary
framing. usbmidi2-acx fails to segment back-to-back SysEx messages. Instead of
End-ing block N and Start-ing block N+1, it leaks the next block's raw 0xF0 start
byte into the current message as a data byte and continues, welding adjacent blocks
into one oversized SysEx7 stream. Example — that same 0F 00 00 read balloons to 195
bytes because it's actually 0F 00 00 + 0F 00 01 + 0F 00 02 concatenated.

This is malformed UMP on the wire, not a reassembly artifact. Raw packet, capture
index 618:

3023F000 02000000  →  MT3, Group 1, SysEx7 Continue, count 3, data F0 00 02

A 0xF0 in a SysEx7 Continue data field isn't a valid 7-bit data byte, so this is
usbmidi2-acx producing invalid UMP irrespective of upstream USB timing — and the
device delimits cleanly (Android ground truth). Across the 9 cycles: 14/107
reassembled messages carry an interior 0xF0; 19 embedded F0 00 02 17 leaked-start
markers; the count of delimited messages per cycle swings 9–21 for an identical dump.

Note this isn't a version-parity comparison: KS transport DLL is 1.0.15.0 vs KSA
1.0.16.1 (SDK 1.0.17-rc.4.25 overall) — KS is the older build and still avoids the
interior-drop failure.

This boundary-framing behavior looks distinct from the KSA interior-drop this issue is
scoped to, and adjacent to #1025 (usbmidi2-acx framing/CIN). Happy to keep it here or
file it as a separate usbmidi2-acx issue with the capture — whichever you prefer for
triage. Capture attached: usbmidi2_acx_capture.txt.

---

This is the device in use
https://www.disasterareadesigns.com/shop/p/midi-baby

Steps to reproduce

1. Connect a class-compliant USB-MIDI 1.0 device (here: Disaster Area MIDI Baby Gen4, firmware v34). Move it to the USBMIDI2-ACX driver via device manager.
2. Monitor the endpoint in the Windows MIDI Services Console: midi.exe, message/UMP view, or directly via trace.
3. Trigger the device's full-configuration SysEx dump repeatedly. Here the dump was requested by the vendor's editor issuing config-read SysEx; each cycle begins with a Universal Identity Request/Reply (F0 7E … 06 02 …) followed by the config blocks.
4. Let it run several cycles (6-9 cycles)
5. Reassemble the MT3 SysEx7 packets per block and compare byte-for-byte across reads, and against the device's true output (attached android_midi_output.txt, same device on an Android USB-MIDI host in referenced bug [BUG]: MIDI Baby Gen 4 - USB-MIDI 1.0 inbound SysEx non-deterministically corrupted (bytes dropped / message abandoned) with usbaudio.sys MIDI 1 driver and KSA transport #1040 ).

Unknowns:

Is the data from the device well-formed? TBD. The customer shared Android output from the same dumps, but that doesn't mean the data itself is "correct" coming from the device. All operating systems have to have some level of affordance for bad MIDI data.

I've contacts the MIDI Baby folks about the device.

[kmarchiori]

Here's a monitor log of much more deliberate pacing on requests.

midi_endpoint_list_usbmidi2_acx_deliberate.txt

[Psychlist1972]

Here's a monitor log of much more deliberate pacing on requests.

midi_endpoint_list_usbmidi2_acx_deliberate.txt

Thanks. I see that one also has the F0 embedded as data.

The kind folks Disaster Area Designs are sending me a device to repro the issue with. Super helpful as I normally have to purchase these devices myself and it gets expensive over time :) .

Pete
Microsoft

[Psychlist1972]

Internal ADO Bug Reference: 63056880

[Psychlist1972]

Today I pointed Scout + Claude Opus 4.8 at this and a couple other seemingly related issues in this repo to see if it had ideas while I wait for the device to arrive. Documenting here for transparency.

Pete
Microsoft

---

Issue #1041 — KS / usbmidi2-acx leaked-F0 welded SysEx

Path: Device.cpp inbound completion loop (lines 2380–2413) → USBMIDI1ToUMP (line 3380), with per-cable state pDeviceContext->midi1IsInSysex[cbl_num] (line 2407).

Root cause — USBMIDI1ToUMP, case MIDI_CIN_SYSEX_START (lines 3457–3493):

if (!*pbIsInSysex) {
    if (pBuffer[1] != SYSEX_START) return false;   // start: requires F0
    ...
    *pbIsInSysex = true;
} else {
    firstByte = 1; lastByte = 4;                    // "continue": copy ALL 3 bytes
    umpPkt->umpData.umpBytes[1] = UMP_SYSEX7_CONTINUE | 3;
}

The else branch assumes any CIN-0x4 packet while already in-SysEx is a pure continuation and copies all three USB bytes as SysEx7 data with no check for 0xF0. So when the device emits a new SysEx Start (CIN 4, first byte 0xF0) while the previous SysEx was never closed with F7, the 0xF0 is written straight into a Continue packet's data field — producing exactly the captured 3023F000 02000000 (Continue, count 3, data F0 00 02) and welding adjacent blocks into one oversized stream. It never emits an End for block N or a Start for block N+1.

Related framing defect (same function): the channel-voice cases (line 3605) set *pbIsInSysex = false without emitting a SysEx7 End, truncating an open SysEx with no terminator ("abandoned" style). The various MIDI_CIN_SYSEX_END_* cases only close cleanly if state already matches.

Recommended fix: Make USBMIDI1ToUMP treat 0xF0 as authoritative regardless of pbIsInSysex: if a byte==0xF0 arrives while in-SysEx, first emit a synthetic End for the current message, then open a new Start — don't copy 0xF0 as data. More robustly, drive framing from the actual data bytes (F0/F7), not solely the USB CIN, since the device's CIN usage under stress is what triggers this. Also emit a proper End when a channel-voice/System message interrupts an open SysEx.

Secondary concern: the inbound completion routine uses static UMP_PACKET umpPacket / static … UMP_Packet_Struct / static wordsRemain (lines 2347–2355). Per-cable SysEx state is safely in device context, but these statics are shared across all pins/instances and are a real concurrency/corruption hazard under multiple simultaneous streams — make them per-request/per-context.