Case Study: Risoluzione dei problemi relativi a un dispositivo USB sconosciuto tramite ETW e Netmon
Questo argomento illustra come usare USB ETW e Netmon per risolvere i problemi relativi a un dispositivo USB non riconosciuto da Windows.
Per questo esempio, è stato collegato un dispositivo e è apparso come dispositivo sconosciuto in Gestione dispositivi e altre parti dell'interfaccia utente. L'ID hardware era USB\UNKNOWN. Per diagnosticare ulteriormente, il dispositivo è stato scollegato, ha iniziato una traccia ETW e collegato di nuovo al dispositivo. Dopo che il dispositivo è apparso come dispositivo sconosciuto, è stata arrestata la traccia.
Informazioni sul problema del dispositivo sconosciuto
Per eseguire il debug di un problema di dispositivo USB sconosciuto, consente di comprendere cosa fa lo stack di driver USB per enumerare un dispositivo quando un utente lo collega al sistema. Per informazioni sull'enumerazione USB, vedere il post di blog intitolato Come enumera uno stack USB?
In genere quando lo stack di driver USB non riesce ad enumerare un dispositivo, il driver dell'hub segnala comunque l'arrivo del dispositivo a Windows e il dispositivo USB viene contrassegnato come dispositivo sconosciuto in Gestione dispositivi. Il dispositivo ha un ID dispositivo USB\VID_0000&PID_0000 e un ID hardware e un ID compatibile di USB\UNKNOWN. Gli eventi seguenti causano l'enumerazione di un dispositivo USB come dispositivo sconosciuto:
- Timeout della richiesta di reimpostazione della porta durante l'enumerazione.
- La richiesta Imposta indirizzo per il dispositivo USB non è riuscita.
- La richiesta per il descrittore dispositivo USB non è riuscita.
- Il descrittore del dispositivo USB è stato non valido e non è stato convalidato.
- La richiesta per il descrittore di configurazione non è riuscita.
- Il descrittore di configurazione USB è stato non valido e non è stato convalidato.
In Windows 7 i dispositivi sconosciuti che non riescono nell'enumerazione sono contrassegnati con codice di errore 43 in Gestione dispositivi.
Se un dispositivo è contrassegnato con codice di errore 28 in Gestione dispositivi, il dispositivo enumera correttamente, ma è ancora un dispositivo sconosciuto. Questo codice di errore indica che il dispositivo non ha fornito una stringa ID prodotto durante l'enumerazione e Windows non è riuscito a trovare una corrispondenza INF per il dispositivo per installare un driver.
Avvio dell'analisi della traccia eventi
Poiché si tratta di un errore del dispositivo, è consigliabile usare Netmon con il parser USB per analizzare il file di log.
Per visualizzare il log di traccia eventi
Eseguire Netmon, fare clic su File - Apri ->> Acquisizione e quindi selezionare il file.
Selezionare il primo evento nel riquadro Riepilogo fotogrammi , con la descrizione SystemTrace. Questa immagine mostra l'aspetto dello schermo quando si seleziona il primo evento.
Per personalizzare le colonne visualizzate da Netmon, fare clic con il pulsante destro del mouse su un nome di colonna e scegliere Scegli colonne.
Il primo evento, identificato come tipo SystemTrace, contiene informazioni generali sul log. È possibile espandere l'albero delle informazioni nel riquadro Dettagli frame per visualizzare informazioni quali il numero di eventi persi e l'ora di inizio della traccia.
Eventi di riepilogo del dispositivo USB
Evento 2 è il primo evento USB nel log. Questo e diversi eventi successivi descrivono i controller host USB, gli hub e i dispositivi connessi al sistema al momento dell'avvio della traccia. È possibile chiamare questo gruppo di eventi gli eventi di riepilogo del dispositivo o semplicemente gli eventi di riepilogo. Come il primo evento, gli eventi di riepilogo non descrivono l'attività del driver. Gli eventi di riepilogo registrano lo stato dei dispositivi all'inizio di una sessione di registrazione. Altri eventi rappresentano qualcosa che accade sul bus, interazioni con i driver client o il sistema o modifiche dello stato interno.
I driver di riepilogo della porta USB e dell'hub USB. Il driver che ha registrato un evento viene identificato nella colonna Nome protocollo. Ad esempio, un evento registrato dal driver della porta USB ha il nome del protocollo USBPort_MicrosoftWindowsUSBPORT. Una traccia evento USB contiene in genere una sequenza di eventi di riepilogo delle porte, seguita da una sequenza di eventi di riepilogo dell'hub. Molti degli eventi di riepilogo della porta USB e dell'hub USB hanno le parole "Information" o "Attributes" nella relativa descrizione.
Come è possibile identificare la fine degli eventi di riepilogo? Se si verifica un'interruzione significativa nel modello timestamp tra gli eventi dell'hub USB all'inizio del log, l'interruzione è probabilmente la fine del riepilogo del dispositivo. In caso contrario, il primo evento di porta USB dopo gli eventi dell'hub USB è probabile che il primo evento non riepilogo. La figura 3 nella pagina seguente mostra il primo evento non riepilogo in questa traccia di esempio.
In questo esempio il dispositivo di interesse non è stato connesso al sistema quando è stata avviata la traccia, quindi è possibile ignorare gli eventi di riepilogo del dispositivo per il momento.
Descrizione eventi e payload dei dati
Nel log di esempio, il primo evento dopo gli eventi di riepilogo del dispositivo è un evento di attesa dell'hub USB Wake IRP Complete. È stato collegato un dispositivo e un controller host o un hub viene riattivato in risposta. Per determinare quale componente viene riattivato, esaminare i dati dell'evento. I dati si trovano nel riquadro Dettagli cornice, che viene mostrato in una struttura ad albero in circa il formato seguente:
Frame information
ETW event header information
ETW event descriptor (Constant information about the event ID such
as error level)
Event payload (Data logged at the time of the event)
Name of a USB-specific structure
Structure members and their values (Types: numbers, strings,
or arrays)
...
Espandere i dati del payload per l'evento Wait IRP Completed dell'hub USB e verrà visualizzata una struttura ETW denominata fid_USBHUB_Hub. Il nome della struttura include i componenti seguenti:
| Termine | Descrizione |
|---|---|
| Fid_ | Prefisso tipico per una struttura USB ETW. |
| USBHUB_ | Indicazione che il driver dell'hub USB ha registrato l'evento. |
| Il resto della stringa | Nome dell'oggetto descritto dai dati della struttura. Per questo evento, è un oggetto Hub. |
Il driver dell'hub USB usa la struttura fid_USBHUB_Hub per descrivere un hub USB. Gli eventi con questa struttura hub nel payload dei dati fanno riferimento a un hub e possiamo identificare l'hub specifico usando il contenuto della struttura. La figura 4 mostra il riquadro Dettagli cornice, con la struttura fid_USBHUB_Hub espansa per visualizzarne i campi.
La struttura dell'hub è molto simile a due altre strutture che vengono comunemente visualizzate negli eventi ETW USB:fid_USBHUB_Device e fid_USBPORT_Device. I seguenti campi importanti sono comuni a tutte e tre le strutture:
| Campo | Descrizione |
|---|---|
| fid_idVendor | ID fornitore USB (VID) del dispositivo |
| fid_idProduct | ID prodotto USB (PID) del dispositivo |
| fid_PortPath | Elenco di numeri di porta hub basati su uno tramite il quale è collegato un dispositivo USB. Il numero di numeri di porta nell'elenco è contenuto nel campo PortPathDepth . Per i dispositivi dell'hub radice, questo elenco è tutti zero. Per un dispositivo USB connesso direttamente a una porta dell'hub radice, il valore in PortPath[0] è il numero di porta dell'hub radice della porta a cui è collegato il dispositivo. |
Per un dispositivo USB connesso tramite uno o più hub USB aggiuntivi, l'elenco dei numeri di porta hub inizia con la porta dell'hub radice e continua con gli hub aggiuntivi (in ordine di distanza dall'hub radice). Ignorare gli zero. Ad esempio:
| Valore di esempio | Descrizione |
|---|---|
| [0, 0, 0, 0, 0, 0] | L'evento fa riferimento a un hub radice (una porta sul PC, controllata direttamente da un controller host USB). |
| [3, 0, 0, 0, 0, 0] | L'evento fa riferimento a un hub o a un dispositivo collegato al numero di porta 3 dell'hub radice. |
| [3, 1, 0, 0, 0, 0] | Un hub è collegato alla porta 3 di un hub radice. L'evento fa riferimento a un hub o a un dispositivo collegato alla porta 1 dell'hub esterno. |
È consigliabile monitorare i percorsi di porta di qualsiasi dispositivo di interesse. Quando un dispositivo viene enumerato, il VID e il PID sono sconosciuti e registrati come 0. Il VID e il PID non vengono visualizzati durante alcune richieste di dispositivo di basso livello, ad esempio la reimpostazione e la sospensione. Queste richieste vengono inviate all'hub in cui il dispositivo è collegato.
Nel log di esempio l'evento Wait Wake completion ha un percorso di porta con sei zere. L'evento indica un'azione Wait Wake in un hub radice. Questo è logico a causa delle nostre azioni: il dispositivo è stato collegato a una porta hub radice, quindi l'hub radice si sta svegliando.
Filtri USB Netmon
È possibile esaminare ogni evento in un log in ordine cronologico, se si dispone del tempo. Anche con esperienza, è difficile identificare rapidamente gli eventi importanti analizzando l'elenco delle descrizioni degli eventi. Per trovare più rapidamente la causa del dispositivo sconosciuto, è possibile usare la funzionalità di filtro Netmon.
Filtro errori USB
Per attivare il filtro degli errori USB in Netmon, fare clic su Filtro -> Filtro visualizzato -> Filtro di caricamento -> Filtri standard - USB ->> Errori dell'hub USB e quindi fare clic su Applica nel riquadro Filtro schermo.
Il filtro degli errori USB restringe l'elenco degli eventi solo a quelli che soddisfano i criteri indicati nella tabella seguente.
| Filtrare il testo | Descrizione |
|---|---|
| (USBPort_MicrosoftWindowsUSBUSBPORT AND Netevent.Header.Descriptor.Opcode == 34) | Gli eventi della porta USB con opcode 34 sono errori di porta. |
| (USBHub_MicrosoftWindowsUSBUSBHUB AND Netevent.Header.Descriptor.Opcode == 11) | Gli eventi dell'hub USB con opcode 11 sono errori dell'hub. |
| (NetEvent.Header.Descriptor.Level == 0x2) | Gli eventi con 0x2 di livello sono in genere errori. |
| (USBHub_MicrosoftWindowsUSBUSBHUB AND NetEvent.Header.Descriptor.Id == 210) | Gli eventi dell'hub USB con ID 210 sono eventi "Usb Hub Exception Logged". Per altre informazioni, vedere Informazioni sugli eventi di errore e sui codici di stato. |
Questa immagine mostra il set più piccolo di eventi visualizzati nel riquadro Riepilogo fotogrammi dopo aver applicato il filtro errori USB al log di traccia di esempio.
Per visualizzare una panoramica della sequenza di errori, è possibile visualizzare brevemente ogni evento di errore. I campi importanti da osservare includono fid_NtStatus, fid_UsbdStatus e fid_DebugText. Per altre informazioni, vedere Informazioni sugli eventi di errore e sui codici di stato. Per disattivare un filtro, fare clic sul pulsante Rimuovi nel riquadro Visualizza filtro .
Filtri Netmon personalizzati
È possibile creare filtri personalizzati in Netmon. Il metodo più semplice consiste nel creare un filtro dai dati sullo schermo in uno dei modi seguenti:
- Fare clic con il pulsante destro del mouse su un campo nel riquadro Dettagli cornice e scegliere Aggiungi valore selezionato per visualizzare il filtro.
- Fare clic con il pulsante destro del mouse su un campo nel riquadro Riepilogo frame e scegliere Aggiungi [nome campo] a Visualizza filtro.
È possibile modificare gli operatori (ad esempio OR, AND e ==) e i valori del filtro per compilare le espressioni di filtro appropriate.
Informazioni sugli eventi di errore e sui codici di stato
Nell'esempio di dispositivo sconosciuto, la maggior parte delle eccezioni dell'hub USB ha un fid_DebugText dati di CreateDeviceFailure. Non è chiaro quanto sia grave l'eccezione, ma il testo di debug fornisce un suggerimento per la causa: un'operazione correlata al nuovo dispositivo non è riuscita. Per il momento, si supponga che gli eventi Create Device Failed adiacenti siano ridondanti. Le ultime due eccezioni sono CreateDeviceFailure_Popup e GenErr_UserIoctlFailed. L'eccezione popup sembra un errore esposto all'utente, ma tutti questi errori potrebbero essere correlati al problema sconosciuto del dispositivo.
Gli eventi di errore USB e altri eventi hanno valori di stato nei dati che forniscono informazioni preziose sul problema. È possibile trovare informazioni sui valori di stato usando le risorse nella tabella seguente.
| Tipo di stato | Risorsa |
|---|---|
| fid_NtStatus | Vedere valori NTSTATUS. |
| Campo di stato di un blocco di richieste USB o fid_UsbdStatus | Cercare il valore come USBD_STATUS in inc\api\usb.h in Windows Driver Kit (WDK). È anche possibile usare il USBD_STATUS. In questo argomento vengono elencati i nomi simbolici e i significati dei valori USBD_STATUS. |
Lettura indietro da eventi di problema
Gli eventi registrati prima degli eventi di errore potrebbero fornire indicazioni importanti sulla causa dell'errore. È consigliabile esaminare gli eventi registrati prima degli errori per provare a determinare la causa radice del dispositivo sconosciuto. In questo esempio, iniziare a guardare indietro dall'evento CreateDeviceFailure_Popup, l'eccezione da seconda a ultima. Selezionare questo evento mentre il filtro errori USB è abilitato e quindi fare clic su Rimuovi nel riquadro Filtro di visualizzazione . Il filtro di errore USB viene comunque visualizzato nel riquadro Filtro di visualizzazione ed è possibile applicarlo di nuovo in un secondo momento. Ma ora il filtro è disabilitato e il riquadro Riepilogo frame visualizza tutti gli eventi, come illustrato in questa immagine.
I due eventi registrati poco prima dell'evento CreateDeviceFailure_Popup sono Dispatch e Complete di un trasferimento di controllo USB. Il campo fid_USBPORT_Device percorso porta è zero per entrambi gli eventi, che indica che la destinazione del trasferimento è l'hub radice. Nella struttura fid_USBPORT_URB_CONTROL_TRANSFER dell'evento di completamento lo stato è zero (USBD_STATUS_SUCCESS), che indica che il trasferimento è riuscito. Continuare a esaminare gli eventi precedenti.
I due eventi precedenti successivi sono il quarto evento (finale) Create Device Failed e la quarta eccezione (finale) CreateDeviceFailure, esaminata in precedenza.
L'evento precedente successivo è Endpoint Close. Questo evento significa che un endpoint non è più utilizzabile. I dati dell'evento descrivono sia il dispositivo che l'endpoint nel dispositivo. Il percorso della porta del dispositivo è [1, 0, 0, 0, 0, 0]. Il sistema in cui è stata eseguita la traccia include solo controller host (hub radice) più il dispositivo che ci si connette, quindi questo percorso della porta non descrive un hub. L'endpoint chiuso deve trovarsi nel singolo dispositivo collegato e ora sappiamo che il percorso del dispositivo è 1. È probabile che i driver rendevano inaccessibile l'endpoint del dispositivo a causa di un problema riscontrato in precedenza. Continuare a esaminare gli eventi precedenti.
L'evento precedente successivo è un trasferimento di controllo USB completato. I dati dell'evento mostrano che la destinazione del trasferimento è il dispositivo (il percorso della porta è 1). La struttura fid_USBPORT_Endpoint_Descriptor indica che l'indirizzo dell'endpoint è 0, quindi questo è l'endpoint di controllo predefinito definito da USB. Lo stato DELL'OGGETTO è 0xC0000004. Poiché lo stato non è zero, il trasferimento probabilmente non è riuscito. Per altre informazioni su questo valore USBD_STATUS, vedere usb.h e Informazioni sugli eventi di errore e codici di stato.
#define USBD_STATUS_STALL_PID ((USBD_STATUS)0xC0000004L)
Significato: il dispositivo ha restituito un identificatore di pacchetto stall. Quale richiesta è stata bloccata dall'endpoint? Gli altri dati registrati per l'evento indicano che la richiesta è una richiesta di controllo del dispositivo standard. Ecco la richiesta analizzata:
Frame: Number = 184, Captured Frame Length = 252, MediaType = NetEvent
+ NetEvent:
- MicrosoftWindowsUSBUSBPORT: Complete Internal URB_FUNCTION_CONTROL_TRANSFER
- USBPORT_ETW_EVENT_COMPLETE_INTERNAL_URB_FUNCTION_CONTROL_TRANSFER: Complete Internal URB_FUNCTION_CONTROL_TRANSFER
+ fid_USBPORT_HC:
+ fid_USBPORT_Device:
+ fid_USBPORT_Endpoint:
+ fid_USBPORT_Endpoint_Descriptor:
+ fid_URB_Ptr: 0x84539008
- ControlTransfer:
+ Urb: Status = 0xc0000004, Flags 0x3, Length = 0
- SetupPacket: GET_DESCRIPTOR
+ bmRequestType: (Standard request) 0x80
bRequest: (6) GET_DESCRIPTOR
Value_DescriptorIndex: 0 (0x0)
Value_DescriptorType: (1) DEVICE
_wIndex: 0 (0x0)
wLength: 64 (0x40)
Combinare bRequest (GET_DESCRIPTOR) con il Value_DescriptorType (DISPOSITIVO) ed è possibile determinare che la richiesta è stata get-device descrittore.
Affinché l'enumerazione USB continui, il dispositivo deve aver risposto a questa richiesta con il descrittore del dispositivo. Al contrario, il dispositivo ha bloccato la richiesta, che ha causato l'esito negativo dell'enumerazione. Pertanto, tutti e quattro gli errori di creazione del dispositivo sono stati causati da richieste bloccate per il descrittore del dispositivo. È stato determinato che il dispositivo è sconosciuto perché l'enumerazione non è riuscita e l'enumerazione non è riuscita perché il dispositivo non ha completato la richiesta per il descrittore del dispositivo.