Case study: risoluzione dei problemi relativi a un dispositivo USB sconosciuto tramite ETW e Netmon

Questo argomento fornisce un esempio di 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 ed è apparso come un dispositivo sconosciuto in Gestione dispositivi e altre parti dell'interfaccia utente. L'ID hardware era USB\UNKNOWN. Per diagnosticare ulteriormente, abbiamo scollegato il dispositivo, iniziato una traccia ETW e ricollegato il dispositivo. Dopo che il dispositivo è apparso come dispositivo sconosciuto, abbiamo interrotto la traccia.

Informazioni sul problema sconosciuto del dispositivo

Per eseguire il debug di un problema sconosciuto del dispositivo USB, aiuta a capire 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 il sistema USB enumera un dispositivo?

In genere, quando lo stack di driver USB non riesce ad enumerare un dispositivo, il driver hub segnala ancora l'arrivo del dispositivo a Windows e il dispositivo USB è contrassegnato come un 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 da parte del driver dell'hub USB come dispositivo sconosciuto:

• Durante l'enumerazione, la richiesta di reimpostazione della porta è scaduta.
• La richiesta Imposta indirizzo per il dispositivo USB non è riuscita.
• La richiesta per il descrittore del dispositivo USB non è riuscita.
• Il descrittore del dispositivo USB non è valido e la convalida non è riuscita.
• La richiesta per il descrittore di configurazione non è riuscita.
• Il descrittore di configurazione USB non è valido e la convalida non è riuscita.

In Windows 7, i dispositivi sconosciuti che non riescono nell'enumerazione sono contrassegnati con il Codice 43 in Gestione dispositivi.

Se un dispositivo è contrassegnato con codice di errore 28 in Gestione dispositivi, il dispositivo è enumerato 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 un INF corrispondente per il dispositivo per installare un driver.

Avvio dell'analisi della traccia degli 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

1. Avviare Netmon, fare clic su File -> Apri -> Rilevamento e quindi selezionare il file.

2. Selezionare il primo evento nel riquadro Riepilogo frame con la descrizione SystemTrace. Questa immagine mostra l'aspetto della schermata quando si seleziona il primo evento.

   

3. Per personalizzare le colonne visualizzate da Netmon, fare clic con il pulsante destro del mouse su un nome di colonna e scegliere Scegli colonne.

4. 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 dei dispositivi USB

L'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 eventi di riepilogo. Analogamente al 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 un evento che si verifica sul bus, le interazioni con i driver client o il sistema o le modifiche dello stato interno.

I driver dell'hub USB e della porta USB registrano entrambi gli eventi di riepilogo. 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 di eventi 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 di 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 qualsiasi evento dell'hub USB è probabilmente il primo evento non di riepilogo. La figura 3 nella pagina seguente mostra il primo evento non di 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 dell'evento e Payload dei dati

Nel log di esempio il primo evento dopo gli eventi di riepilogo del dispositivo è un evento IRP Completed di riattivazione dell'hub USB. Abbiamo collegato un dispositivo, e un controller host o un hub si sta riattivando in risposta. Per determinare quale componente viene riattivato, esaminare i dati dell'evento. I dati si trovano nel riquadro Dettagli della cornice, visualizzato in una struttura ad albero in circa il seguente formato:

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 IRP Completed di riattivazione attesa dell'hub USB e verrà visualizzata una struttura ETW denominata fid_USBHUB_Hub. Il nome della struttura ha 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.
Resto della stringa	Nome dell'oggetto descritto dai dati della struttura. Per questo evento, si tratta di 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 ed è possibile identificare l'hub specifico usando il contenuto della struttura. La figura 4 mostra il riquadro Dettagli del Frame, con la struttura fid_USBHUB_Hub espansa per visualizzare i relativi campi.

La struttura dell'hub è molto simile a due altre strutture comunemente visualizzate negli eventi ETW USB: fid_USBHUB_Device e fid_USBPORT_Device. I campi importanti seguenti 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	L'elenco dei numeri di porta dell'hub a base uno attraverso cui è collegato un dispositivo USB. Il numero di numeri di porta nell'elenco è contenuto nel campo PortPathDepth . Per i dispositivi dell'hub radice, questo elenco è composto interamente da zeri. 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 zeri. Per esempio:

Valore di esempio	Descrizione
[0, 0, 0, 0, 0, 0]	L'evento fa riferimento a un hub radice (una porta nel 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 di un hub radice.
[3, 1, 0, 0, 0, 0]	Un hub viene 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 delle porte 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 a cui il dispositivo è collegato.

Nel log di esempio, l'evento Wait Wake Completion ha un percorso di porta con sei zeri. L'evento indica un'azione Wait Wake in un hub principale. Questo è logico a causa delle nostre azioni: il dispositivo è stato collegato a una porta dell'hub radice, quindi l'hub radice viene riattivato.

Filtri USB Netmon

È possibile esaminare ogni evento in un log in ordine cronologico, se si ha l'ora. Anche con esperienza, è difficile identificare rapidamente gli eventi importanti analizzando l'elenco delle descrizioni degli eventi. Per trovare la causa del dispositivo sconosciuto più rapidamente, è possibile usare la funzionalità di filtro Netmon.

Filtro degli errori USB

Per attivare il filtro degli errori USB in Netmon, fare clic su Filtro - Filtro visualizzato -> Filtro di carico ->> Filtri standard - USB ->> Errori dell'hub USB e quindi fare clic su Applica nel riquadro Filtro di visualizzazione.

Il filtro degli errori USB restringe l'elenco degli eventi solo a quelli che soddisfano i criteri illustrati nella tabella seguente.

Filtrare il testo	Descrizione
(USBPort_MicrosoftWindowsUSBUSBPORT AND Netevent.Header.Descriptor.Opcode == 34)	Gli eventi di porta USB con opcode 34 sono errori di porta.
(USBHub_MicrosoftWindowsUSBUSBHUB AND Netevent.Header.Descriptor.Opcode == 11)	Gli eventi dell'hub USB con codice operativo 11 sono errori dell'hub.
(NetEvent.Header.Descriptor.Level == 0x2)	Gli eventi con livello 0x2 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 codici di stato.

Questa immagine mostra il set più piccolo di eventi visualizzati nel riquadro Riepilogo frame dopo aver applicato il filtro di errore 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 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 campo dati fid_DebugText 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 è simile a 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	Conto risorse
fid_NtStatus	Consultare Valori NTSTATUS.
Campo di stato di un blocco di richiesta USB (URB) o fid_UsbdStatus	Trova il valore di "USBD_STATUS" in inc\api\usb.h nel 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 a ritroso dagli eventi problematici

Gli eventi registrati prima degli eventi di errore potrebbero fornire indizi 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 degli errori USB è abilitato e quindi fare clic su Rimuovi nel riquadro Filtro di visualizzazione . Il filtro di errore USB viene ancora visualizzato nel riquadro Filtro di visualizzazione ed è possibile riapplicarlo 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 il Dispatch e il Complete di un trasferimento di controllo USB. Il campo percorso della porta fid_USBPORT_Device è zero per entrambi gli eventi, il 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 prossimi eventi sono il quarto (e ultimo) evento Create Device Failed e la quarta (e ultima) eccezione 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 su cui abbiamo eseguito la traccia include solo controller host (hub radice) più il dispositivo che stavamo connettendo, 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.

Il più recente evento precedente è stato un trasferimento di controllo USB completato. I dati dell'evento indicano 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 dall'USB. Lo stato URB è 0xC0000004. Poiché lo stato non è zero, il trasferimento probabilmente non è riuscito. Per altre informazioni su questo valore USBD_STATUS, vedere usb.h e Understanding Error Events and Status Codes (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 di stallo. Quale richiesta è stata bloccata dall'endpoint? Gli altri dati registrati per l'evento indicano che la richiesta era 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 (DEVICE) e determinare che la richiesta è stata get-device descrittore.

Per continuare l'enumerazione USB, il dispositivo deve aver risposto a questa richiesta con il descrittore del dispositivo. Al contrario, il dispositivo bloccava la richiesta, causando l'esito negativo dell'enumerazione. Di conseguenza, 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.

Argomenti correlati

• Utilizzo di USB ETW
• Tracciamento degli eventi USB per Windows