[TODO]: Default CircuitPython install (and Arduino usbmidi setup) advertises non-functional MIDI endpoints which lock the service until unplugged

[Psychlist1972]

Discussion here:
https://ptb.discord.com/channels/980245825202552942/1530573182355116215

Ordered Adafruit RP2350 Metro
Installed Circuit Python 10.2.1

Upon device reboot, the device advertises MIDI endpoints

Those endpoints are also in the USB descriptors (although the descriptors are malformed)

RP2350 Descriptor Dump

Information for device Metro RP2350 (VID=0x239A PID=0x814E):

*** ERROR: Descriptor has errors! ***

------------------------------
Connection Information:
------------------------------
Device current bus speed: FullSpeed
Device supports USB 1.1 specification
Device supports USB 2.0 specification
Device address: 0x0028
Current configuration value: 0x01
Number of open pipes: 9


------------------------------
Device Descriptor:
------------------------------
0x12	bLength
0x01	bDescriptorType
0x0200	bcdUSB
0x00	bDeviceClass      
0x00	bDeviceSubClass   
0x00	bDeviceProtocol   
0x40	bMaxPacketSize0   (64 bytes)
0x239A	idVendor
0x814E	idProduct
0x0100	bcdDevice
0x01	iManufacturer   "Adafruit"
0x02	iProduct        "Metro RP2350"
0x03	iSerialNumber   "08F3BB49F57C4292"
0x01	bNumConfigurations


-------------------------
Configuration Descriptor:
-------------------------
0x09	bLength
0x02	bDescriptorType
0x00DA	wTotalLength   (218 bytes)
0x06	bNumInterfaces
0x01	bConfigurationValue
0x00	iConfiguration
0xA0	bmAttributes   (Bus-powered Device, Remote-Wakeup)
0x32	bMaxPower      (100 mA)

Interface Association Descriptor:
------------------------------
0x08	bLength
0x0B	bDescriptorType
0x00	bFirstInterface
0x02	bInterfaceCount
0x02	bFunctionClass      (Communication Device Class)
0x02	bFunctionSubClass   (Abstract Control Model - ACM)
0x00	bFunctionProtocol   
0x00	iFunction

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x00	bInterfaceNumber
0x00	bAlternateSetting
0x01	bNumEndPoints
0x02	bInterfaceClass      (Communication Device Class)
0x02	bInterfaceSubClass   (Abstract Control Model - ACM)
0x00	bInterfaceProtocol   
0x04	iInterface   "CircuitPython CDC control"

CDC Header Functional Descriptor:
------------------------------
0x05	bFunctionalLength
0x24	bDescriptorType
0x00	bDescriptorSubtype
0x0110	bcdCDC

CDC Call Management Functional Descriptor:
------------------------------
0x05	bFunctionalLength
0x24	bDescriptorType
0x01	bDescriptorSubtype
0x01	bmCapabilities
0x01	bDataInterface

CDC Abstract Control Management Functional Descriptor:
------------------------------
0x04	bFunctionalLength
0x24	bDescriptorType
0x02	bDescriptorSubtype
0x02	bmCapabilities

CDC Union Functional Descriptor:
------------------------------
0x05	bFunctionalLength
0x24	bDescriptorType
0x06	bDescriptorSubtype
0x00	bControlInterface
0x01	bSubordinateInterface(0)

Endpoint Descriptor:
------------------------------
0x07	bLength
0x05	bDescriptorType
0x81	bEndpointAddress  (IN endpoint 1)
0x03	bmAttributes      (Transfer: Interrupt / Synch: None / Usage: Data)
0x0040	wMaxPacketSize    (1 x 64 bytes)
0x10	bInterval         (16 frames)

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x01	bInterfaceNumber
0x00	bAlternateSetting
0x02	bNumEndPoints
0x0A	bInterfaceClass      (CDC Data)
0x00	bInterfaceSubClass   
0x00	bInterfaceProtocol   
0x05	iInterface   "CircuitPython CDC data"

Endpoint Descriptor:
------------------------------
0x07	bLength
0x05	bDescriptorType
0x02	bEndpointAddress  (OUT endpoint 2)
0x02	bmAttributes      (Transfer: Bulk / Synch: None / Usage: Data)
0x0040	wMaxPacketSize    (64 bytes)
0x00	bInterval         

Endpoint Descriptor:
------------------------------
0x07	bLength
0x05	bDescriptorType
0x82	bEndpointAddress  (IN endpoint 2)
0x02	bmAttributes      (Transfer: Bulk / Synch: None / Usage: Data)
0x0040	wMaxPacketSize    (64 bytes)
0x00	bInterval         

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x02	bInterfaceNumber
0x00	bAlternateSetting
0x02	bNumEndPoints
0x08	bInterfaceClass      (Mass Storage Device Class)
0x06	bInterfaceSubClass   (Transparent SCSI subclass)
0x50	bInterfaceProtocol   (Bulk only transport)
0x06	iInterface   "CircuitPython Mass Storage"

Endpoint Descriptor:
------------------------------
0x07	bLength
0x05	bDescriptorType
0x83	bEndpointAddress  (IN endpoint 3)
0x02	bmAttributes      (Transfer: Bulk / Synch: None / Usage: Data)
0x0040	wMaxPacketSize    (64 bytes)
0x00	bInterval         

Endpoint Descriptor:
------------------------------
0x07	bLength
0x05	bDescriptorType
0x03	bEndpointAddress  (OUT endpoint 3)
0x02	bmAttributes      (Transfer: Bulk / Synch: None / Usage: Data)
0x0040	wMaxPacketSize    (64 bytes)
0x00	bInterval         

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x03	bInterfaceNumber
0x00	bAlternateSetting
0x02	bNumEndPoints
0x03	bInterfaceClass      (Human Interface Device Class)
0x00	bInterfaceSubClass   
0x00	bInterfaceProtocol   
0x07	iInterface   "CircuitPython HID"

HID Descriptor:
------------------------------
0x09	bLength
0x21	bDescriptorType
0x0111	bcdHID
0x00	bCountryCode
0x01	bNumDescriptors
0x22	bDescriptorType   (Report descriptor)
0x009C	bDescriptorLength

Endpoint Descriptor:
------------------------------
0x07	bLength
0x05	bDescriptorType
0x84	bEndpointAddress  (IN endpoint 4)
0x03	bmAttributes      (Transfer: Interrupt / Synch: None / Usage: Data)
0x0040	wMaxPacketSize    (1 x 64 bytes)
0x08	bInterval         (8 frames)

Endpoint Descriptor:
------------------------------
0x07	bLength
0x05	bDescriptorType
0x04	bEndpointAddress  (OUT endpoint 4)
0x03	bmAttributes      (Transfer: Interrupt / Synch: None / Usage: Data)
0x0040	wMaxPacketSize    (1 x 64 bytes)
0x08	bInterval         (8 frames)

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x04	bInterfaceNumber
0x00	bAlternateSetting
0x00	bNumEndPoints
0x01	bInterfaceClass      (Audio Device Class)
0x01	bInterfaceSubClass   (Audio Control Interface)
0x00	bInterfaceProtocol   (Audio Protocol undefined)
0x09	iInterface   "CircuitPython Audio"

AC Interface Header Descriptor:
------------------------------
0x09	bLength
0x24	bDescriptorType
0x01	bDescriptorSubtype
0x0100	bcdADC
0x0009	wTotalLength   (9 bytes)
0x01	bInCollection
0x05	baInterfaceNr(1)

Interface Descriptor:
------------------------------
0x09	bLength
0x04	bDescriptorType
0x05	bInterfaceNumber
0x00	bAlternateSetting
0x02	bNumEndPoints
0x01	bInterfaceClass      (Audio Device Class)
0x03	bInterfaceSubClass   (MIDI Streaming Interface)
0x00	bInterfaceProtocol   (Audio Protocol undefined)
0x08	iInterface   "CircuitPython MIDI"

MS Interface Header Descriptor:
------------------------------
0x07	bLength
0x24	bDescriptorType
0x01	bDescriptorSubtype
0x0100	bcdMSC
0x0025	wTotalLength   (37 bytes)

MS MIDI IN Jack Descriptor:
------------------------------
0x06	bLength
0x24	bDescriptorType
0x02	bDescriptorSubtype
0x01	bJackType
0x01	bJackID
0x0A	iJack   "CircuitPython usb_midi.ports[0]"

MS MIDI IN Jack Descriptor:
------------------------------
0x06	bLength
0x24	bDescriptorType
0x02	bDescriptorSubtype
0x02	bJackType
0x02	bJackID
0x00	iJack

MS MIDI OUT Jack Descriptor:
------------------------------
0x09	bLength
0x24	bDescriptorType
0x03	bDescriptorSubtype
0x01	bJackType
0x03	bJackID
0x01	bNrInputPins
0x02	baSourceID(1)
0x01	baSourcePin(1)
0x0B	iJack   "CircuitPython usb_midi.ports[0]"

MS MIDI OUT Jack Descriptor:
------------------------------
0x09	bLength
0x24	bDescriptorType
0x03	bDescriptorSubtype
0x02	bJackType
0x04	bJackID
0x01	bNrInputPins
0x01	baSourceID(1)
0x01	baSourcePin(1)
0x00	iJack

Endpoint Descriptor (Audio/MIDI 1.0):
------------------------------
0x07	bLength
0x05	bDescriptorType
*** ERROR: Invalid descriptor length 0x07 for Audio/MIDI 1.0 endpoint (9 bytes expected)
Hex dump: 
0x07 0x05 0x05 0x02 0x40 0x00 0x00 

MS Bulk Data Endpoint Descriptor:
------------------------------
0x05	bLength
0x25	bDescriptorType
0x01	bDescriptorSubtype
0x01	bNumEmbMIDIJack
0x01	baAssocJackID(1)

Endpoint Descriptor (Audio/MIDI 1.0):
------------------------------
0x07	bLength
0x05	bDescriptorType
*** ERROR: Invalid descriptor length 0x07 for Audio/MIDI 1.0 endpoint (9 bytes expected)
Hex dump: 
0x07 0x05 0x85 0x02 0x40 0x00 0x00 

MS Bulk Data Endpoint Descriptor:
------------------------------
0x05	bLength
0x25	bDescriptorType
0x01	bDescriptorSubtype
0x01	bNumEmbMIDIJack
0x03	baAssocJackID(1)

Microsoft OS Descriptor is not available. Error code: 0x0000001F


--------------------------------
String Descriptor Table
--------------------------------
Index  LANGID  String
0x00   0x0000  0x0409 
0x01   0x0409  "Adafruit"
0x02   0x0409  "Metro RP2350"
0x03   0x0409  "08F3BB49F57C4292"
0x04   0x0409  "CircuitPython CDC control"
0x05   0x0409  "CircuitPython CDC data"
0x06   0x0409  "CircuitPython Mass Storage"
0x07   0x0409  "CircuitPython HID"
0x08   0x0409  "CircuitPython MIDI"
0x09   0x0409  "CircuitPython Audio"
0x0A   0x0409  "CircuitPython usb_midi.ports[0]"
0x0B   0x0409  "CircuitPython usb_midi.ports[0]"

------------------------------

Connection path for device: 
USB xHCI Compliant Host Controller
Root Hub
Generic USB Hub
Generic USB Hub
Metro RP2350 (VID=0x239A PID=0x814E) Port: 1

Running on: Windows 10 or greater (Build Version 29617)

Brought to you by TDD v2.19.0, Dec  5 2023, 12:08:38

Windows MIDI Services properly enumerates the MIDI interface and creates the appropriate endpoint and ports

(Note: if "new style names" are selected, the name displayed will be the cleaned up version of what's in iJack. However, because we clean off the indexes that are in brackets, the name looks a little different from the USB decsriptor

Problem

The problem is, these ports are not wired up. And devices are shipping with only one of them enabled (the three fader box type devices, for example). We're seeing the same thing with the Leonardo MIDI where those fader boxes, which are sold to customers, just come with a note saying not to enable the MIDI Out in your DAW.

Prior to Windows MIDI Services, this non-functional port would lock up only a single application. However, now it locks up the Windows Service.

Need to find a way to work around these broken devices.

If you are the author of these devices, please go in and customize the USB MIDI library (Leonardo) or the Circuit Python MIDI setup (Circuit Python) to only expose the ports you actually implement.

Pete
Microsoft

[Psychlist1972]

Example of an older (pre-Windows MIDI Services) post showing how this would hang an individual application.

After closing Cubase 13.0.41 a midi device shows still ‘owned’ by Cubase when I open VST Live I get the message, that the device is still in use by Cubase. The device was not actively used in Cubase project, but connected.
The message pops up for one device, even more are typically connected.
PC needs restart to get all working in VST Live.
When I switch apps the other way around (VSTLive close, open Cubase afterward) there is no issue - so looks VSTLive handles the device ‘closing’ correctly.
Device: Arduino Leonardo (GNU midi library C++, controller software in C++ ), via USB and respective drivers.
f.y.i. the device is about 7 years on market, so may be it is a ‘legacy’ issue for a niche thing. Maybe you can help me to understand why it happens from Cubase to VSTLive and the other direction works. Not a big deal, maybe just an information.

https://forums.steinberg.net/t/midi-devices-not-released-for-vstlive-after-closing-cubase/927487

Another from before Windows MIDI Services:

"Arduino kills Cubase 13?!"

Hello! I have a midi controller programmed on an Arduino Leonardo. I recently updated Cubase to version 13. Now when I launch Cubase 13, all my projects started crashing because of this controller. After Cubase 13 crashed, when I started it again, everything worked. The controller is connected via USB, updating the controller driver for Windows did not fix the problem. If you disable the midi controller, then everything works without failures. Is there any solution to this problem?

https://forums.steinberg.net/t/arduino-kills-cubase-13/907654

Pete
Microsoft

[Psychlist1972]

In CircuitPython, if you just put in your run loop the statement midi_in.receive() (if midi_in is your input) and ignore the results, the device becomes completely responsive.

Of course, not advertising unused endpoints is the better solution, but I could find no way to configure this in boot.py, so it likely requires customization of Circuit Python itself, which seems silly for something so basic and common.

Pete
Microsoft

[Psychlist1972]

Just PR'd to main a workaround for this.

This will cause some small memory leaks until the device is disconnected, but it stops the service from hanging due to the broken device.

Info from Claude's analysis after multiple hours of trying to find ways around this problem:

Excellent — that confirms the whole chain.

Let me record the non-obvious findings so this doesn't have to be re-derived.

Great result — and worth noting the fix only landed once the dump replaced guesswork. The ETL kept pointing me at plausible-but-wrong culprits; the thread stacks plus mapping m_ThreadHandle through !handle proved it in one step.

Final state, all behind Feature_Servicing_MIDI2KSOutputWriteHang:

• MidiKs.cpp — bounded, payload-scaled write timeout; abandon leaks the buffers, closes the handle, retires the pin
• MidiXProc.cpp — bounded join, S_FALSE on abandon
• MidiClientPipe.cpp — release() on S_FALSE
• Midi2.KSAggregateMidiOutProxy.cpp — failure + slow-write telemetry

Shared SyncIoctl and KsHandleWrapper::Execute were reverted to original, so the input path and all property calls are untouched.

Three things still open, in rough priority:

1. m_ClientManagerLock scope — DestroyMidiClient still holds it across pipe shutdown. You're now isolated to a ~10s stall instead of forever, but one bad device still briefly gates every client. This is the real resilience fix and still needs your sign-off.
2. PinSetState with INFINITE — your separate shutdown-IRP bug. Same hang class, different path; this change doesn't cover it.
3. Timeout constants — 4000ms + 1ms/byte was reasoned, not measured. The slow-write telemetry (>250ms) will give you real numbers from your device zoo, including whether drivers complete on accept rather than transmit, which would change the model.

Worth remembering that the Leonardo itself is genuinely defective here — it ignores both cancel and cleanup. The service is now resilient to that class of device rather than cured of it.

[Psychlist1972]

Worth explicitly noting a couple things here

• These implementations are broken and need to be fixed. The situation they create is not healthy. There is no guarantee they will continue to work in the future. If the devices simply drain their input queue, thereby responding properly per the USB MIDI contract, then this goes away.
• This is a workaround to keep apps which do open the MIDI Out from hanging when they do so. So when Cubase sends out the SysEx Identity request when starting up, it doesn't hang.
• **The MIDI Service cannot be restarted until the device is unplugged.(( Only at that point will the thread become unblocked and the resources freed. You can stop the service, but the process stays zombied due to the thread locked up with this device's MIDI Destination pin.

Recommendation: when you run across this with your devices, report it to the device manufacturer as a bug and ask them to fix it. Point them to this bug for the details.

In addition, disable the MIDI Out to the device in your DAW if that is possible. :)

Pete
Microsoft