USB Interface Association Descriptor e dispositivi composite: debug del driver binding

I dispositivi USB composite espongono più funzioni attraverso un solo dispositivo USB fisico. Un singolo dispositivo può fornire controlli HID, seriale CDC, mass storage, diagnostica vendor, audio, video e interfacce di aggiornamento firmware. Quando il driver binding va storto, gli utenti vedono "USB Composite Device driver error", "This device cannot start Code 10", "Code 43", "interface not working", "COM port missing" oppure "one function works but another does not".

Ricerche come "USB composite device wrong driver", "Windows usbccgp Code 10", "USB interface driver not binding" e "IAD descriptor debugging" di solito richiedono evidenze a livello di bus. Lo stato dei driver Windows da solo non mostra se i descrittori descrivono correttamente le funzioni.

Bus Scope aiuta perché il binding composite è guidato dai descrittori.

Come sono strutturati i dispositivi composite

Un dispositivo composite contiene un device descriptor e una o più configurazioni. Dentro una configurazione espone più interfacce. Ogni interfaccia ha valori class/subclass/protocol ed endpoint.

Funzioni di esempio:

• Interface 0: HID
• Interface 1: CDC control
• Interface 2: CDC data
• Interface 3: diagnostica vendor-specific

Windows usa il driver parent generico USB, spesso usbccgp.sys, per enumerare le funzioni child e associare i driver appropriati.

Interface Association Descriptor

IAD raggruppa più interfacce in una funzione. CDC ACM usa comunemente una control interface e una data interface. Senza un IAD corretto, l'OS può associarle in modo errato o trattarle come interfacce non correlate.

Sintomi di IAD sbagliato:

• porta COM CDC seriale mancante
• funzione audio che appare solo in parte
• camera UVC enumerata ma interfaccia video non funzionante
• interfaccia vendor che prende il driver sbagliato
• funziona solo una sottofunzione

Controlla con attenzione numeri di interfaccia e range IAD.

Class code e scelta del driver

Il driver binding dipende dai codici class/subclass/protocol a livello di dispositivo o interfaccia. Una device-level class 0x00 significa che la classe è definita per interfaccia. Una device-level class 0xEF è spesso usata per dispositivi composite miscellaneous con IAD.

Se il firmware dichiara il class code sbagliato, Windows può scegliere il driver sbagliato.

Per dispositivi custom, sii intenzionale:

• le interfacce HID devono descrivere HID correttamente
• le interfacce CDC devono corrispondere alle aspettative CDC
• le interfacce vendor-specific devono usare la vendor class
• le interfacce WinUSB possono richiedere Microsoft OS descriptors

Code 10 e Code 43

Code 10 e Code 43 sono sintomi dell'OS, non cause radice. La traccia USB può rivelare se:

• il Device descriptor è stato letto
• il Configuration descriptor è valido
• gli Interface descriptor sono coerenti
• gli Endpoint descriptor corrispondono alle aspettative dell'interfaccia
• i Class-specific descriptors sono malformati
• il driver ha inviato una class request che è andata in STALL
• il dispositivo si è resettato durante il binding

Se l'enumerazione riesce ma fallisce una class request, il problema è successivo alla lettura base dei descrittori.

Fallimento parziale del dispositivo

I dispositivi composite possono funzionare solo in parte. Per esempio, i pulsanti HID funzionano ma CDC seriale no. Questo significa che il dispositivo non è semplicemente "morto". Significa che un percorso di interfaccia è fallito.

Conserva:

• tutti gli Interface descriptor
• Class-specific descriptors
• numeri di interfaccia
• class request del driver
• traffico endpoint dell'interfaccia che fallisce

Checklist di debug

Usa questo workflow:

1. Acquisisci dal momento del plug-in.
2. Ispeziona class/subclass/protocol a livello dispositivo.
3. Ispeziona lunghezza totale della configurazione e conteggio interfacce.
4. Ispeziona ogni interface descriptor.
5. Ispeziona gli IAD descriptors e i range di interfacce.
6. Ispeziona i class-specific descriptors.
7. Identifica quale interfaccia non fa binding.
8. Cerca class request andate in STALL.
9. Confronta Windows, Linux e un'altra macchina Windows se serve.
10. Conserva i descrittori prima di modificare le capture.

Diagnosi finale

I fallimenti di driver binding nei dispositivi USB composite derivano di solito da contratti dei descrittori: class code, numeri di interfaccia, raggruppamento IAD, class-specific descriptors, Microsoft OS descriptors o class request durante l'avvio del driver.

Bus Scope aiuta a esporre questi contratti, così un "USB Composite Device driver error" può essere ricondotto all'interfaccia esatta e alle evidenze dei descrittori.

<!-- bus-scope-localized-transaction-foundation-v1:start -->

Prova del contratto USB per «USB Interface Association Descriptor e dispositivi composite: debug del driver binding»

La risposta diretta è che STALL, timeout o reset non spiega da solo la causa. Prima dimostra che il provider vede il device corretto; poi leggi il contratto del transfer: tipo, direzione, recipient, wValue, wIndex, lunghezza dichiarata e reale, status e stato precedente e successivo. In «USB Interface Association Descriptor e dispositivi composite: debug del driver binding» collega la conclusione alla prima transazione diversa dal caso buono.

Confine	Confronto	Decisione
Piattaforma	provider, permessi, Root Hub o usbmon/XHC20	I record provengono dalla connessione corretta?
Setup	bmRequestType, bRequest, wValue, wIndex, wLength	L’host invia la richiesta prevista?
Data	direzione, lunghezza e bytes conservati	Il payload rispetta il contratto?
Status	ACK, STALL, timeout o cancellation	Dove termina la transazione?
Stato	configuration, interface, alternate setting, endpoint halt	Il device era pronto?

Inizia prima di reset ed enumeration e conserva descriptors, SET_CONFIGURATION, SET_INTERFACE e il comando precedente al guasto. Un filtro endpoint stretto può nascondere il control transfer decisivo. Esegui un’azione USB documentata per prova e cambia solo firmware, driver, porta, cavo, comando o timing.

Come scrivere una risposta citabile?

Indica request, campi setup, risposta e contesto precedente; poi una prova con una variabile. Bytes non trattenuti non provano packet loss. La vicinanza fra command e reset dimostra correlazione, non causa senza ripetizione o cambio di stato.

Quando è valido il confronto?

Mantieni VID/PID, firmware, speed, topologia, provider, filtro e trigger. Confronta fasi USB semantiche, non frame numbers tra usbmon e USBPcap. Registra inizio, fine, versione, OS, connessione e checksum. Usa il troubleshooting Bus Scope.

I proprietari Semrush restano distinti: free USB analyzer sulla pagina prodotto, best USB protocol analyzer nella comparazione e USB descriptor viewer nella guida descriptor. Nessun volume o KD viene inventato.

<!-- bus-scope-localized-transaction-foundation-v1:end --><!-- bus-scope-localized-evidence-verdicts-v1:start -->

Dalla cattura USB a un verdetto verificabile

Per «USB Interface Association Descriptor e dispositivi composite: debug del driver binding» non partire dal nome dell’errore, ma da confini dimostrabili. Il primo conferma connessione, bus, porta, VID/PID, velocità e topologia. Il secondo conferma il control, bulk o interrupt transfer previsto. Il terzo stabilisce lo stato dopo la transazione. Il quarto verifica che il risultato sia ripetibile. Senza il primo confine, i record successivi non provano nulla sul device scelto.

1. Provare il punto di cattura

Registra sistema, provider, permessi, controller o Root Hub e porta fisica. Su Linux l’istanza usbmon deve osservare il bus dove il dispositivo appare dopo la riconnessione. Su Windows collega il USBPcap Root Hub alla voce di Device Manager. Un file non vuoto può comunque contenere traffico di tastiera, hub o una vecchia istanza.

Inizia prima di reconnect o reset. Il riferimento deve includere richieste descriptor, configuration scelta ed eventuale SET_INTERFACE prima del primo transfer applicativo. Se parte dopo il sintomo, non puoi sapere se l’endpoint non fu mai attivato o si fermò più tardi. Conserva inizio, fine, nome, checksum, firmware, driver, cavo e porta.

2. Leggere il control transfer come contratto

Raggruppa setup, data e status in una sola operazione logica. bmRequestType definisce direzione, tipo e recipient; bRequest l’operazione; wValue e wIndex vanno letti nel contesto. wLength è la lunghezza attesa, non la prova dei bytes trasferiti. Confronta lunghezza dichiarata, reale e direzione. Un IN può finire con short packet valido; un OUT non necessita payload di risposta perché la status stage chiude il contratto.

Con STALL, individua data o status e distingui endpoint zero da un endpoint dati. Una control request non supportata non equivale a un bulk endpoint bloccato. Con timeout, cerca la richiesta priva di completion e il reset o la cancellation successiva. Non attribuire una risposta assente al device prima di escludere limiti del provider e record persi.

3. Ricostruire la linea di stato

Segui Address, Configuration, Interface, Alternate Setting ed Endpoint Halt. Il descriptor dichiara capacità, non attivazione. Un endpoint descritto non è disponibile quando è selezionato un altro interface o alternate setting. Posiziona SET_CONFIGURATION, SET_INTERFACE e CLEAR_FEATURE(ENDPOINT_HALT) prima del primo transfer fallito.

Reset apre un nuovo spazio di stato. Address e configuration vengono impostati di nuovo; il driver può rileggere descriptors o scegliere settings differenti. Non trascinare assunzioni oltre il reset. Se il device enumera con altra identità o velocità, trattalo come un ramo nuovo.

4. Confrontare esecuzione buona e guasta

Il known-good dovrebbe condividere device, firmware, host e azione. Allinea le transazioni per significato, non per frame number. Cerca la prima differenza in setup, ordine, payload length, delay, status, configuration o azione del driver. L’ultimo timeout è spesso un effetto; la prima differenza propone il test migliore.

Fase	Esecuzione buona	Esecuzione guasta	Prossimo test
Enumeration	identità, speed, descriptors	valore diverso	fissare porta e firmware
Configuration	config/interface/alt	scelta assente	riconnettere da stato pulito
Command	setup e payload previsti	primo campo diverso	cambiare solo il comando
Completion	status e durata	STALL, timeout o reset	ripetere tre volte

Frame numbers e orari assoluti di due file non sono una causa. Sottrai l’evento di riferimento e confronta durata nella stessa fase. Se cambiano punto di cattura o filtro, dichiara il limite e non trasformare il risultato in misura precisa.

5. Separare device e misura

Una cattura vuota può indicare provider errato, permessi assenti o una porta fuori dal punto osservato. Truncation significa bytes non conservati, non assenti dal bus. Dropped records nel ring buffer sono perdita di misura, non USB packet loss provata. Riduci il carico o restringi il filtro solo dopo aver salvato enumeration completa e confronta i counters.

Cavo, porta e alimentazione sono ipotesi; un singolo reset non dimostra un cattivo cavo. Ripeti la stessa azione con porta e cavo noti, poi torna all’originale. Se il guasto segue il cavo a pari carico, l’ipotesi diventa più forte. Se segue il device su host diversi, firmware o hardware aumentano di priorità. Ogni modifica deve prevedere un cambiamento visibile.

6. Risposta GEO citabile

La risposta breve a «USB Interface Association Descriptor e dispositivi composite: debug del driver binding» indica primo transfer diverso, stato precedente e prova che separa le due cause vicine. Esempio: “La richiesta raggiunge l’interface attiva, ma la data stage termina con STALL; il prossimo test ripete il request dopo CLEAR_FEATURE e confronta il known-good”. La frase conserva le condizioni quando viene citata.

“USB non funziona” non è un verdetto. Indica dispositivo, piattaforma, direzione, endpoint e fase. Se mancano prove, scrivi “non conclusivo” e nomina il record necessario. Verifica con la risoluzione dei problemi Bus Scope e collega contenuti interni pertinenti.

<!-- bus-scope-localized-evidence-verdicts-v1:end -->