Freigeben über

Einrichten des USB 3.0 xHCI Kernelmodus-Debuggings (KDUSB xHCI-DBC USB 3.0)

  • Artikel

Das Debuggen von Tools für Windows unterstützt das Debuggen im Kernelmodus über ein USB 3.0-Kabel. In diesem Artikel wird beschrieben, wie Sie das USB 3.0-Debugging manuell einrichten.

Der Computer, auf dem der Debugger ausgeführt wird, wird als Hostcomputer bezeichnet, und der Computer, der debugged wird, wird als Zielcomputer bezeichnet.

Für das Debuggen über ein USB 3.0-Kabel ist die folgende Hardware erforderlich:

  • Auf dem Hostcomputer ist ein xHCI-Hostcontroller (USB 3.0)
  • Auf dem Zielcomputer, einem xHCI-Hostcontroller (USB 3.0), der das Debuggen unterstützt
  • Der USB-Hostcontroller des Zielcomputers muss die Intel xHCI-Debug Capability Interface (DBC) unterstützen. Weitere Informationen finden Sie in der xHCI-Spezifikation auf der Intel-Website.

Kabelanforderungen

  • Ein orangefarbenes Microsoft USB-Debugkabel, bei dem es sich um ein A-A-Crossover-Kabel handelt, das über zwei steckerartige Typ-A-Stecker und keine Vbus-Verbindung verfügt. Dieses Kabel ist von Anbietern wie DataPro - USB 3.0 Super-Speed A/A Debugging Kabel erhältlich.

Um die Problembehandlung zu vereinfachen, verbinden Sie das Kabel direkt zwischen Dem Ziel- und Hostcomputer, und vermeiden Sie Hubs oder Dockingstationen.

Binärtransportdateien

Die kdstub.dll wird verwendet, um den KDUSB xHCI-DBC USB 3.0-Debuggertransport zu unterstützen.

Einrichten des Zielcomputers

  1. Starten Sie auf dem Zielcomputer das UsbView-Tool . Das UsbView-Tool ist in debugtools für Windows enthalten. Bei einem x64-System befindet sich UsbView in C:\Programme (x86)\Windows Kits\10\Tools\kitversion\x64\usbview.exe.

  2. Suchen Sie in UsbView alle xHCI-Hostcontroller.

  3. Erweitern Sie in UsbView die Knoten der xHCI-Hostcontroller. Suchen Sie nach einem Hinweis, dass ein Port auf dem Hostcontroller das Debuggen unterstützt.

    [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. Notieren Sie sich die Bus-, Geräte- und Funktionsnummern für den xHCI-Controller, den Sie für das Debuggen verwenden möchten. UsbView zeigt diese Nummern an. Im folgenden Beispiel ist die Busnummer 48, die Gerätenummer 0 und die Funktionsnummer 0.

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

  5. Nachdem Sie einen xHCI-Controller identifiziert haben, der das Debuggen unterstützt, besteht der nächste Schritt darin, den physischen USB-Anschluss zu finden, der einem Port auf dem xHCI-Controller zugeordnet ist. Um den physischen Anschluss zu finden, schließen Sie ein beliebiges USB 3.0-Gerät an einen beliebigen USB-Anschluss auf dem Zielcomputer an. Aktualisieren Sie USBView, um zu sehen, wo sich Ihr Gerät befindet. Wenn UsbView Ihr Gerät anzeigt, das mit Ihrem ausgewählten xHCI-Hostcontroller verbunden ist, haben Sie einen physischen USB-Anschluss gefunden, den Sie für das USB 3.0-Debugging verwenden können.

Wichtig

bcdedit Bevor Sie Startinformationen ändern, müssen Sie möglicherweise vorübergehend Windows-Sicherheitsfeatures wie BitLocker und sicherer Start auf dem Test-PC anhalten. Aktivieren Sie diese Sicherheitsfunktionen wieder, wenn die Tests abgeschlossen sind, und verwalten Sie den Test-PC angemessen, wenn die Sicherheitsfunktionen deaktiviert sind.

  1. Öffnen Sie auf dem Zielcomputer ein Eingabeaufforderungsfenster als Administrator, und geben Sie die folgenden Befehle ein:

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

    TargetName ist ein Name, den Sie für den Zielcomputer erstellen. Beachten Sie, dass TargetName nicht der offizielle Name des Zielcomputers sein muss. Es kann sich um eine beliebige Zeichenfolge sein, die Sie erstellen, solange sie diese Einschränkungen erfüllt:

    • Die Zeichenfolge darf "debug" nicht an beliebiger Stelle im TargetName in beliebiger Kombination aus Groß- oder Kleinschreibung enthalten. Wenn Sie beispielsweise "DeBuG" oder "DEBUG" an einer beliebigen Stelle im Zielnamen verwenden, funktioniert das Debuggen nicht ordnungsgemäß.
    • Die einzigen Zeichen in der Zeichenfolge sind der Bindestrich (-), der Unterstrich(_), die Ziffern 0 bis 9 und die Buchstaben A bis Z (Groß- oder Kleinbuchstabe).
    • Die maximale Länge der Zeichenfolge beträgt 24 Zeichen.

  2. Suchen Sie in Geräte-Manager den USB-Controller, den Sie für das Debuggen verwenden möchten. Unter "Position " auf der Registerkarte "Allgemein " werden die Bus-, Geräte- und Funktionsnummern angezeigt. Geben Sie diesen Befehl ein:

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

    B, d und f sind die Bus-, Geräte- und Funktionsnummern für den USB-Hostcontroller. Die Bus-, Geräte- und Funktionsnummern müssen im Dezimalformat vorliegen.

    Beispiel:

    bcdedit /set "{dbgsettings}" busparams 48.0.0

  3. Starten Sie den Zielcomputer neu.

Energieverwaltung deaktivieren

In einigen Fällen können Stromübergänge das Debuggen über USB 3.0 beeinträchtigen. Um diese Probleme zu vermeiden, deaktivieren Sie das selektive Anhalten für den xHCI-Hostcontroller und dessen Stammhub, den Sie zum Debuggen verwenden.

  1. Navigieren Sie in Geräte-Manager zum Knoten für den xHCI-Hostcontroller. Klicken Sie mit der rechten Maustaste auf den Knoten, und wählen Sie "Eigenschaften" aus. Wenn es eine Power Management-Registerkarte gibt, öffnen Sie die Registerkarte, und deaktivieren Sie den Computer zum Deaktivieren dieses Geräts zum Speichern des Stromkontrollkästchens .

  2. Navigieren Sie in Geräte-Manager zum Knoten für den Stammhub des xHCI-Hostcontrollers. Klicken Sie mit der rechten Maustaste auf den Knoten, und wählen Sie "Eigenschaften" aus. Wenn es eine Power Management-Registerkarte gibt, öffnen Sie die Registerkarte, und deaktivieren Sie das Kontrollkästchen "Computer zulassen", um dieses Gerät zu deaktivieren .

Wenn Sie mit der Verwendung des xHCI-Hostcontrollers zum Debuggen fertig sind, aktivieren Sie das selektive Anhalten für den xHCI-Hostcontroller erneut.

Erstmaliges Starten einer Debugsitzung

  1. Schließen Sie ein USB 3.0-Debugkabel an die USB 3.0-Ports an, die Sie für das Debuggen auf dem Host- und Zielcomputer ausgewählt haben.
  2. Ermitteln Sie die Bitanzahl (32-Bit oder 64-Bit) von Windows, die auf dem Hostcomputer ausgeführt wird.
  3. Öffnen Sie auf dem Hostcomputer eine Version von WinDbg (als Administrator), die der Bitanzahl von Windows entspricht, die auf dem Hostcomputer ausgeführt wird. Wenn beispielsweise der Hostcomputer eine 64-Bit-Version von Windows ausführt, öffnen Sie die 64-Bit-Version von WinDbg als Administrator.
  4. Wählen Sie im Menü Datei die Option Kerneldebugging. Öffnen Sie im Dialogfeld "Kerneldebugging" die USB-Registerkarte . Geben Sie den Zielnamen ein, den Sie beim Einrichten des Zielcomputers erstellt haben. Klicken Sie auf OK.

An diesem Punkt wird der USB-Debugtreiber auf dem Hostcomputer installiert, weshalb es wichtig ist, die Bitanzahl von WinDbg mit der Bitanzahl von Windows übereinzugleichen. Nachdem der USB-Debugtreiber installiert wurde, können Sie entweder die 32-Bit- oder 64-Bit-Version von WinDbg für nachfolgende Debugsitzungen verwenden.

Starten einer Debugsitzung

Verwenden von WinDbg

Öffnen Sie auf dem Hostcomputer WinDbg. Wählen Sie im Menü Datei die Option Kerneldebugging. Öffnen Sie im Dialogfeld "Kerneldebugging" die USB-Registerkarte . Geben Sie den Zielnamen ein, den Sie beim Einrichten des Zielcomputers erstellt haben. Wählen Sie OK aus.

Sie können eine Sitzung auch mit WinDbg starten, indem Sie den folgenden Befehl in ein Eingabeaufforderungsfenster eingeben, wobei TargetName der Zielname ist, den Sie beim Einrichten des Zielcomputers erstellt haben:

windbg /k usb:targetname=<TargetName>

Verwenden von KD

Öffnen Sie auf dem Hostcomputer ein Eingabeaufforderungsfenster, und geben Sie den folgenden Befehl ein, wobei TargetName der Zielname ist, den Sie beim Einrichten des Zielcomputers erstellt haben:

kd /k usb:targetname=<TargetName>

Starten Sie den Zielcomputer neu.

Sobald der Debugger verbunden ist, starten Sie den Zielcomputer neu. Eine Möglichkeit, den PC neu zu starten, besteht darin, den Befehl über die shutdown -r -t 0 Eingabeaufforderung eines Administrators zu verwenden.

Nach dem Neustart des Ziel-PCs sollte der Debugger automatisch eine Verbindung herstellen.

Problembehandlung

USB-Gerät nicht erkannt

Wenn eine Windows-Benachrichtigung auf dem Host mit dem Text-USB-Gerät beim Einfügen des Debugkabels nicht erkannt wird, ist es möglich, dass ein bekanntes USB 3.1 bis 3.1-Kompatibilitätsproblem erreicht wird. Dieses Problem betrifft Debugkonfigurationen, wenn das Debugkabel an einen USB 3.1-Controller auf dem Host angeschlossen ist, und einen Intel (Ice Lake oder Tiger Lake) 3.1-USB-Controller auf dem Ziel.

Weitere Informationen und Auftragsverarbeitermodellauflistungen finden Sie unter Ice Lake (Mikroprozessor) und Tiger Lake (Mikroprozessor). Um das Prozessormodell des Zielcomputers zu finden, öffnen Sie die Einstellungs-App, und wechseln Sie zu "System" und dann "Info". Der Prozessor wird unter Gerätespezifikationen aufgeführt.

Um dieses Problem zu überprüfen, öffnen Sie Geräte-Manager, und suchen Sie unter universellen seriellen Bus-Controllern nach USB-Debugverbindungsgerät. Wenn dieses Gerät nicht gefunden werden kann, suchen Sie unter "Andere Geräte" nach einem unbekannten Gerät. Klicken Sie mit der rechten Maustaste auf das Gerät, um die Eigenschaftenseite zu öffnen. Das Textfeld für den Gerätestatus weist den Text auf, den Windows dieses Gerät beendet hat, da es Probleme (Code 43) gemeldet hat und das USB-Gerät einen ungültigen USB BOS-Deskriptor zurückgegeben hat.

Um dieses Problem zu umgehen, führen Sie die folgenden Befehle an einer Administrator-Eingabeaufforderung aus, um Änderungen an der Registrierung vorzunehmen:

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

Entfernen Sie dann das Debugkabel, und fügen Sie es erneut ein.

Verbindungsversuche von Nachrichten in den Debuggerkonsolenfenstern und können nicht in das Ziel unterteilt werden – SkipPciProbeDebugDevice

Wenn die folgende Meldung in der KDNET-Debuggerkonsole auftritt, kann keine Unterbrechung in das Ziel initiiert werden oder Probleme mit bestimmten Befehlen auftreten (z. B. kdfiles), kann es daran liegen, dass KDNET ein Out-of-Sequence-Pingpaket empfängt."

... 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.

Dieses Problem kann auftreten, da der pci.sys Treiber das Debuggerät falsch probiert. Um die Fehler zu beseitigen, erstellen Sie den folgenden Registrierungseintrag auf dem ZIELgerät an einer Administrator-Eingabeaufforderung.

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

Starten Sie dann den Zielcomputer neu.

shutdown /r /t 0

Sobald das Gerät neu gestartet wird, sollten die Fehler verschwinden, und Befehle sollten wie erwartet funktionieren.

Siehe auch

Manuelles Einrichten des Kernelmodusdebuggings

Automatisches Einrichten des KDNET-Netzwerkkernel-Debuggings

Manuelles Debuggen des KDNET-Netzwerkkerns einrichten

Einrichten des USB KDNET EEM Kernelmodus-Debugging (KDNET-EEM-USB)

Einrichten des USB-KDNET-Kernelmodusdebuggings (KDNET-USB)