Condividi tramite

Configurazione del debug in modalità kernel USB 3.0 xHCI (KDUSB xHCI-DBC USB 3.0)

  • Articolo

Gli strumenti di debug per Windows supportano il debug in modalità kernel su un cavo USB 3.0. Questo articolo descrive come configurare manualmente il debug USB 3.0.

Il computer che esegue il debugger viene chiamato computer host e il computer sottoposto a debug viene chiamato computer di destinazione.

Il debug su un cavo USB 3.0 richiede l'hardware seguente:

  • Nel computer host, un controller host xHCI (USB 3.0)
  • Nel computer di destinazione, un controller host xHCI (USB 3.0) che supporta il debug
  • Il controller host USB del computer di destinazione deve supportare l'interfaccia DBC (Intel xHCI-Debug Capability Interface). Per altre informazioni, vedere la specifica xHCI disponibile nel sito Web Intel.

Requisiti dei cavi

  • Un cavo di debug USB Microsoft arancione, che è un cavo crossover A-A che dispone di due plug di tipo A-A e nessuna connessione Vbus. Questo cavo è disponibile da fornitori come DataPro - USB 3.0 Super-Speed A/A Debugging Cable.

Per semplificare la risoluzione dei problemi, collegare il cavo direttamente tra il computer di destinazione e host, evitando hub o ancoraggi.

File di trasporto binario

Il kdstub.dll viene usato per supportare il trasporto del debugger USB 3.0 KDUSB xHCI-DBC.

Configurare il computer di destinazione

  1. Nel computer di destinazione avviare lo strumento UsbView . Lo strumento UsbView è incluso in Strumenti di debug per Windows. Per un sistema x64, UsbView si trova in C:\Programmi (x86)\Windows Kits\10\Tools\kitversion\x64\usbview.exe.

  2. In UsbView individuare tutti i controller host xHCI.

  3. In UsbView espandere i nodi dei controller host xHCI. Cercare un'indicazione che una porta nel controller host supporta il debug.

    [Port1]

Is Port User Connectable:         yes
Is Port Debug Capable:            yes
Companion Port Number:            3
Companion Hub Symbolic Link Name: USB#ROOT_HUB30#5&32bab638&0&0#{...}
Protocols Supported:
 USB 1.1:                         no
 USB 2.0:                         no
 USB 3.0:                         yes

  4. Prendere nota dei numeri di bus, dispositivo e funzione per il controller xHCI che si intende usare per il debug. UsbView visualizza questi numeri. Nell'esempio seguente il numero dell'autobus è 48, il numero del dispositivo è 0 e il numero di funzione è 0.

    USB xHCI Compliant Host Controller
...
DriverKey: {36fc9e60-c465-11cf-8056-444553540000}\0020
...
Bus.Device.Function (in decimal): 48.0.0

  5. Dopo aver identificato un controller xHCI che supporta il debug, il passaggio successivo consiste nell'individuare il connettore USB fisico associato a una porta nel controller xHCI. Per trovare il connettore fisico, collegare qualsiasi dispositivo USB 3.0 in qualsiasi connettore USB nel computer di destinazione. Aggiornare UsbView per vedere dove si trova il dispositivo. Se UsbView mostra il dispositivo connesso al controller host xHCI scelto, è stato trovato un connettore USB fisico che è possibile usare per il debug USB 3.0.

Importante

Prima di usare bcdedit per modificare le informazioni di avvio, potrebbe essere necessario sospendere temporaneamente le funzionalità di sicurezza di Windows, ad esempio BitLocker e Avvio protetto nel PC di test. Riabilitare queste funzionalità di sicurezza al termine dei test e gestire in modo appropriato il PC di test quando le funzionalità di sicurezza sono disabilitate.

  1. Nel computer di destinazione aprire una finestra del prompt dei comandi come amministratore e immettere questi comandi:

    bcdedit /debug on
bcdedit /dbgsettings usb targetname:<TargetName>

    TargetName è un nome creato per il computer di destinazione. Si noti che TargetName non deve essere il nome ufficiale del computer di destinazione. Può trattarsi di qualsiasi stringa creata, purché soddisfi queste restrizioni:

    • La stringa non deve contenere "debug" in qualsiasi punto di TargetName in qualsiasi combinazione di maiuscole o minuscole. Ad esempio, se si usa "DeBuG" o "DEBUG" in qualsiasi punto del nome di destinazione, il debug non funziona correttamente.
    • Gli unici caratteri nella stringa sono il trattino (-), il carattere di sottolineatura(_), le cifre da 0 a 9 e le lettere da A a Z (maiuscole o minuscole).
    • La lunghezza massima della stringa è di 24 caratteri.

  2. In Gestione dispositivi individuare il controller USB che si intende usare per il debug. In Posizione nella scheda Generale vengono visualizzati il bus, il dispositivo e i numeri di funzione. Immettere questo comando:

    bcdedit /set "{dbgsettings}" busparams <b.d.f>

    B, d e f sono i numeri di bus, dispositivo e funzione per il controller host USB. I numeri di bus, dispositivo e funzione devono essere in formato decimale.

    Esempio:

    bcdedit /set "{dbgsettings}" busparams 48.0.0

  3. Riavviare il computer di destinazione.

Disabilitare il risparmio energia

In alcuni casi, le transizioni di alimentazione possono interferire con il debug tramite USB 3.0. Per evitare questi problemi, disabilitare la sospensione selettiva per il controller host xHCI e il relativo hub radice, che si sta usando per il debug.

  1. In Gestione dispositivi passare al nodo per il controller host xHCI. Fare clic con il pulsante destro del mouse sul nodo e scegliere Proprietà. Se è presente una scheda Risparmio energia, aprire la scheda e deselezionare la casella di controllo Consenti al computer di spegnere il dispositivo per risparmiare energia .

  2. In Gestione dispositivi passare al nodo per l'hub radice del controller host xHCI. Fare clic con il pulsante destro del mouse sul nodo e scegliere Proprietà. Se è presente una scheda Risparmio energia, aprire la scheda e deselezionare la casella di controllo Consenti al computer di spegnere il dispositivo per risparmiare energia .

Al termine dell'uso del controller host xHCI per il debug, riabilitare la sospensione selettiva per il controller host xHCI.

Avviare una sessione di debug per la prima volta

  1. Connettere un cavo di debug USB 3.0 alle porte USB 3.0 scelte per il debug nei computer host e di destinazione.
  2. Determinare il bitness (32 bit o 64 bit) di Windows in esecuzione nel computer host.
  3. Nel computer host aprire una versione di WinDbg (come amministratore) che corrisponda al bit di Windows in esecuzione nel computer host. Ad esempio, se il computer host esegue una versione a 64 bit di Windows, aprire la versione a 64 bit di WinDbg come amministratore.
  4. Scegliere Debug kernel dal menu File. Nella finestra di dialogo Debug kernel aprire la scheda USB . Immettere il nome di destinazione creato durante la configurazione del computer di destinazione. Fare clic su OK.

A questo punto, il driver di debug USB viene installato nel computer host, motivo per cui è importante associare la velocità di bit di WinDbg al bit di Windows. Dopo aver installato il driver di debug USB, è possibile usare la versione a 32 bit o a 64 bit di WinDbg per le sessioni di debug successive.

Avviare una sessione di debug

Uso di WinDbg

Nel computer host aprire WinDbg. Scegliere Debug kernel dal menu File. Nella finestra di dialogo Debug kernel aprire la scheda USB . Immettere il nome di destinazione creato durante la configurazione del computer di destinazione. Seleziona OK.

È anche possibile avviare una sessione con WinDbg immettendo il comando seguente in una finestra del prompt dei comandi, in cui TargetName è il nome di destinazione creato durante la configurazione del computer di destinazione:

windbg /k usb:targetname=<TargetName>

Uso di KD

Nel computer host aprire una finestra del prompt dei comandi e immettere il comando seguente, dove TargetName è il nome di destinazione creato durante la configurazione del computer di destinazione:

kd /k usb:targetname=<TargetName>

Riavviare il computer di destinazione

Una volta connesso il debugger, riavviare il computer di destinazione. Un modo per riavviare il PC consiste nell'usare il shutdown -r -t 0 comando dal prompt dei comandi di un amministratore.

Dopo il riavvio del PC di destinazione, il debugger dovrebbe connettersi automaticamente.

Risoluzione dei problemi

Dispositivo USB non riconosciuto

Se nell'host viene visualizzata una notifica di Windows con il dispositivo USB di testo non riconosciuto quando si inserisce il cavo di debug, è possibile che si verifichi un problema di compatibilità USB 3.1 da 3.1 a 3.1 noto. Questo problema influisce sulle configurazioni di debug quando il cavo di debug è connesso a un controller USB 3.1 nell'host e un controller USB Intel (Ice Lake o Tiger Lake) 3.1 sulla destinazione.

Per altre informazioni e elenchi di modelli di processore, vedere Ice Lake (microprocessore) e Tiger Lake (microprocessore). Per trovare il modello di processore del computer di destinazione, aprire l'app Impostazioni e passare a Sistema e quindi Informazioni su. Il processore è elencato in Specifiche del dispositivo.

Per verificare questo problema, aprire Gestione dispositivi e cercare Usb Debug Connection Device in Universal Serial Bus Controllers (Controller universali del bus seriale). Se il dispositivo non è stato trovato, verificare la presenza di un dispositivo sconosciuto in Altri dispositivi. Fare clic con il pulsante destro del mouse sul dispositivo per aprire la relativa pagina delle proprietà. La casella di testo stato del dispositivo avrà il testo Windows ha arrestato questo dispositivo perché ha segnalato problemi (Codice 43) e Il dispositivo USB ha restituito un descrittore USB BOS non valido.

Per risolvere questo problema, eseguire questi comandi da un prompt dei comandi dell'amministratore per apportare modifiche al Registro di sistema:

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\349500E00000 /v SkipBOSDescriptorQuery /t REG_DWORD /d 1 /f
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\usbflags\045E06560000 /v SkipBOSDescriptorQuery /t REG_DWORD /d 1 /f

Rimuovere e reinserire quindi il cavo di debug.

La connessione ritenta i messaggi nelle finestre della console del debugger e non può accedere alla destinazione - SkipPciProbeDebugDevice

Se viene visualizzato il messaggio seguente nella console del debugger KDNET, non è possibile avviare un'interruzione nella destinazione o riscontrare problemi con determinati comandi (ad esempio, kdfile), potrebbe essere dovuto alla ricezione di un pacchetto ping out-of-sequence da parte di KDNET".

... Retry sending the same data packet for 128 times.

The transport connection between host kernel debugger and target Windows seems lost.
please try resync with target, recycle the host debugger, or reboot the target Windows.

Questo problema può verificarsi perché il driver pci.sys esegue erroneamente il probe del dispositivo di debug. Per eliminare gli errori, creare la voce del Registro di sistema seguente nel dispositivo TARGET al prompt dei comandi dell'amministratore.

reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\SERVICES\kdnet /v SkipPciProbeDebugDevice /t REG_DWORD /d 1 /f

Riavviare quindi il computer di destinazione.

shutdown /r /t 0

Dopo il riavvio del dispositivo, gli errori dovrebbero scomparire e i comandi dovrebbero funzionare come previsto.

Vedi anche

Configurare manualmente il debug in modalità kernel

Configurazione automatica del debug del kernel di rete KDNET

Configurazione manuale del debug del kernel di rete KDNET

Configurazione del debug in modalità kernel KDNET USB KDNET (KDNET-EEM-USB)

Configurazione del debug in modalità kernel USB KDNET (KDNET-USB)