Konfigurieren des EXDI-Debuggertransports

Artikel
11/01/2024

In diesem Thema wird beschrieben, wie Sie das Kernelmodusdebugging mit EXDI einrichten. Die Extended Debugging Interface (EXDI) ist eine Anpassungsebene zwischen einem Softwaredebugger und einem Debuggingziel.

Die Debuggingtools für Windows unterstützen das Kerneldebugging mit EXDI ab Windows Version 22000.
Die Benutzeroberfläche zum Konfigurieren von EXDI ist ab Version 1.2410.11001.0 im Debugger verfügbar.

EXDI kann verwendet werden, um eine Verbindung mit der virtuellen QEMU-Umgebung herzustellen. Weitere Informationen finden Sie unter Einrichten des QEMU-Kernelmodusdebuggings mit EXDI.

Hinweis

EXDI ist eine fortschrittliche, spezielle Form des Debuggings für bestimmte Umgebungen. Die Verwendung einer Standard-KDNET-Verbindung ist einfacher zu konfigurieren und wird empfohlen. Informationen zum automatischen Einrichten des Netzwerk-Debuggings finden Sie unter Automatisches Einrichten des KDNET-Netzwerk-Kernel-Debuggings.

EXDI COM-Serverübersicht

EXDI ist eine Schnittstelle, die WinDbg erweitert, indem Unterstützung für Hardwaredebugger hinzugefügt wird (z. B. JTAG-basiert oder GdbServer-basiert). Das folgende Diagramm veranschaulicht die Rolle von EXDI-GdbServer.

Stapeldiagramm, das die Rolle von EXDI-GdbServer mit WinDbg-DbgEng oben, einer EXDI-Schnittstelle und einem EXDI-COM-Server zeigt, der mit einem GDB-Server kommuniziert.

Ein COM-Server bezieht sich auf eine binäre Komponente, die eine COM-Schnittstelle implementiert. In diesem Fall wurde "exdi3.idl" von ExdiGdbSrv.dll für den Windows-Debuggerprotokollclient implementiert.

Die ExdiGdbsrv.dll selbst implementiert die Clientseite des GDB-RSP-Protokolls, die GDB-Serverseite (oder irgendwann als GDB-Server-Stub bezeichnet) vom QEMU GDB-Server (oder Trace32/OpenOCD/UEFI GDB-Server-Stub usw.) implementiert wird.

Da die EXDI-Verbindung keine Abhängigkeit von Windows oder dem Windows-Debugging-KDNET-Protokoll hat, das auf dem Ziel-PC geladen wird. Da diese Softwaredebuggerkomponenten nicht erforderlich sind, kann EXDI bei einem frühen Gerätestart und beim Debuggen von Betriebssystemstartproblemen hilfreich sein.

Wichtig

Da EXDI nicht das KDNET-Protokoll verwendet, verfügt der angeschlossene Debugger über deutlich weniger Informationen über das, was auf dem PC ausgeführt wird, und viele Befehle funktionieren anders oder möglicherweise gar nicht. Der Zugriff auf private Symbole für den zu debuggenden Code kann dem Debugger helfen, die Code-Ausführung des Zielsystems besser zu verstehen. Weitere Informationen finden Sie im Artikel zu öffentlichen und privaten Symbolen.

EXDI Kernel-Mode-Geräteanforderungen

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

Das Folgende ist erforderlich:

Auf dem Ziel- und Hostcomputer eine unterstützte Netzwerkkarte, die von der gewünschten Umgebung unterstützt wird, beispielsweise QEMU.
Eine Netzwerkverbindung zwischen Ziel und Host mit Verwendung von TCP/IP.
Windows 10 oder Windows 11, Version 22000 oder höher.

Begrenzungen

Wie oben beschrieben, da EXDI das KDNET-Protokoll nicht verwendet, weist der verbundene Debugger weniger Informationen zum Zielsystem auf und die Verwendung des Debuggers unterscheidet sich. Ohne Zugriff auf private Symbole für den Zielcode funktionieren viele Befehle nicht, die Symbole verwenden, um den Status des Zielsystems zu verstehen. In diesem Fall ist es möglich, Speicher anzuzeigen und Inhalte zu registrieren und Code zu zerlegen. Die Bestimmung des Speicherorts der Ausführung von Code oder das Ausführen anderer gängiger Debuggeraufgaben kann sehr schwierig und zeitaufwändig sein, ohne private Symbole.

Gleichzeitiges EXDI- und KDNET-Debugging

In einigen komplexen Szenarien, z. B. bei einer frühen Geräteaufnahme, kann es hilfreich sein, zwei Verbindungen mit dem Zielgerät herzustellen. Ein EXDI und ein KDNET. Wenn es sich bei dem Ziel um ein Windows-Betriebssystem handelt, wird das Debuggen von KDNET-Software wie normalerweise konfiguriert, z. B. um eine Verbindung mit einem virtuellen Computer herzustellen. In dieser Konfiguration kann jeder der beiden gleichzeitig laufenden Debugger eingreifen, um Code auf der Zielmaschine zu debuggen.

WinDbg im Prozessserver

Die binäre EXDI-Komponente kann entweder aus dem Windbg-Prozess oder innerhalb des Windbg-Prozesses ausgeführt werden. Die Verwendung der EXDI-Benutzeroberfläche oder die Inproc=<EXDI COM server binary> erheblich verbesserte Zuverlässigkeit, indem COM-Startfehler reduziert werden. Daher wird immer empfohlen, die EXDI-Sitzung mit dem Inproc-Parameter auszuführen, der bei Verwendung der Benutzeroberfläche immer aktiviert ist.

Für den Befehlszeilenstart ist die Standardoption nicht mehr verarbeitet, aber "inprocess" sollte mit dem InProc=ExdiGdbDrv.dll Parameter aktiviert werden.

COM GDB Server-Client

In diesem Thema wird die Verwendung des EXDI COM GDB Server-Clients (ExdiGdbSrv.dll) beschrieben, der die EXDI COM-Debuggerschnittstelle implementiert. Es ist möglich, dieselbe COM-Schnittstelle zu verwenden, um andere Schnittstellen zu implementieren, z. B. einen EXDI COM-Server für JTAG-DCI.

Zusammenfassung des Prozesses zur Verwendung einer EXDI-Verbindung

Verwenden Sie diesen Vorgang, um eine EXDI-Verbindung mit WinDbg zu verwenden.

Laden Sie die Windows-Debugging-Tools herunter und installieren Sie sie auf dem Hostsystem.
Starten Sie WinDbg mithilfe der Benutzeroberfläche oder der Option -kx, um eine Verbindung mit dem EXDI-Server herzustellen.
Verwenden Sie WinDbg, um das Zielsystem mithilfe einer Teilgruppe verfügbarer Debuggerbefehle zu debuggen.

Ein Beispiel für ein EXDI-Verwendungsszenario finden Sie unter Einrichten des QEMU-Kernelmodusdebuggings mit EXDI.

Herunterladen und Installieren des Windows-Debugging-Tools

Installieren Sie die Windows-Debugging-Tools auf dem Hostsystem. Informationen zum Herunterladen und Installieren der Debugging-Tools finden Sie unter Debugging-Tools für Windows.

Starten Sie WinDbg, und stellen Sie eine Verbindung mit dem EXDI-Server her.

Die folgenden Optionen können in der EXDI-Kernelverbindungs-UI konfiguriert werden.

Windbg EXDI-Kernelverbindungs-UI mit angezeigten Verbindungsoptionen, einschließlich IP- und Portadresse.

Zieltyp [Trace32|BMC-OpenOCD|QEMU|VMWare|UEFI] Wählen Sie entsprechend dem Zieltyp aus, den Sie debuggen möchten. Die folgenden Zieltypen sind verfügbar.
- Trace32 : Lauterbach Trace32 HW Debugger GDB Serverkonfiguration
- BMC-OpenOCD: BMC-OpenOCD HW Debugger GDB Serverkonfiguration
- QEMU: QEMU SW Simulator GDB Serverkonfiguration
- VMWare: VMWare GDB-Serverkonfiguration
- UEFI: UEFI-Firmwaredebugging
Zielarchitektur [x86 | ARM64 | x64] – Zielprozessorarchitektur. Beachten Sie, dass alle Zieltypen möglicherweise nicht alle Zielarchitekturen unterstützen.
Zielbetriebssystem – Wählen Sie entsprechend dem Zielbetriebssystem [Windows|Linux] aus, das Sie debuggen möchten.
Heuristische Größe [None | 0xFE - PreNT |0xFFE - NT] des Bildscans – Wählen Sie eine der drei Optionen aus, um die heuristische Größe für die Bildüberprüfung zu bestimmen. Dieser Wert konfiguriert, wie das Debuggermodul Speicher überprüft, der nach der PE DOS-Signatur sucht, die zum Sammeln des Code-Execuitionszustands verwendet wird. Wenn der Attributwert nicht angegeben ist (oder "0"), verwendet das Debuggermodul nicht die schnelle Heuristik und fällt auf die Legacy-Heuristik zurück, die den gesamten Speicher überprüft, der nach der PE DOS-Signatur sucht. Der Standardwert wird für jeden Zieltyp ausgewählt und empfohlen.
Gdb-Server und -Port TargetIPAddress:TargetPortAddress – Legen Sie auf die Zeichenfolge fest, die die IPTargetAddress, einen Doppelpunkt und die ZielportAddress enthält. Beispiel: LocalHost:1234 oder 168.82.1.5:5555.
Bei Verbindungen [on|off] unterbrechen Aktivieren Sie das Kontrollkästchen, um nach dem Herstellen der Verbindung in das Ziel einzubrechen.
Erweiterte Optionen

Kommunikationspaketprotokoll [on|off] anzeigen – Aktivieren Sie das Kontrollkästchen, um in Hexwerten das unformatierte GDBServer-Kommunikationspaketprotokoll zum Debuggen und Zur Problembehandlung anzuzeigen.

Nachdem die gewünschten Optionen ausgewählt wurden, wählen Sie "OK " aus, um eine Verbindung herzustellen.

Konfigurieren erweiterter Optionen mithilfe der EXDI-Konfigurations-XML-Dateien

Die meisten erforderlichen Optionen sind in der in diesem Thema beschriebenen Benutzeroberfläche verfügbar. Informationen zum Konfigurieren erweiterter Optionen mithilfe der EXDI-Konfigurations-XML-Dateien finden Sie unter EXDI XML-Konfigurationsdateien.

Beispiel für die WinDbg-Befehlszeile EXDI

Verwenden Sie diese Optionen, um die Windbg-Sitzung zu starten, die die EXDI-Schnittstelle an der Eingabeaufforderung verwendet.

c:\Debuggers> windbg.exe -v -kx exdi:CLSID={29f9906e-9dbe-4d4b-b0fb-6acf7fb6d014},Kd=Guess,InProc=ExdiGdbDrv.dll,DataBreaks=Exdi

Um zusätzliche Ausgabe für Diagnosezwecke anzuzeigen, kann die -v: ausführliche Sitzung verwendet werden. Allgemeine Informationen zu den WinDbg-Optionen finden Sie unter WinDbg-Befehlszeilenoptionen. Weitere Informationen finden Sie weiter unten unter EXDI WinDbg-Ladeparameter .

Die Debuggerkonsole zeigt die EXDI-Transportinitialisierung an.

EXDI: DbgCoInitialize returned 0x00000001
EXDI: CoCreateInstance() returned 0x00000000
EXDI: QueryInterface(IExdiServer3) returned 0x00000000
EXDI: Server::GetTargetInfo() returned 0x00000000
EXDI: Server::SetKeepaliveInterface() returned 0x00000000
EXDI: Server::GetNbCodeBpAvail() returned 0x00000000
EXDI: ExdiNotifyRunChange::Initialize() returned 0x00000000
EXDI: LiveKernelTargetInfo::Initialize() returned 0x00000000
EXDI: Target initialization succeeded
Kernel Debugger connection established

WinDbg-Hauptsitzung mit EXDI CLSID im Fenstertitel.

Das Konsolenfenster EXDIGdbServer kann auch Informationen zum Status der EXDI-Verbindung anzeigen. Weitere Informationen über die Konsole finden Sie unter Problembehandlung.

EXDI WinDbg-Ladeparameter

Die folgenden Parameter werden mit WinDbg verwendet, um eine EXDI-Kernelsitzung zu starten.

-kx EXDI:Options

Die folgenden EXDI-Optionen sind mit der Option -kx verfügbar. Jede Option sollte durch ein Komma getrennt werden.

Parameter	Beschreibung
CLSID	Klassen-ID, die dem LiveExdiGdbSrvServer zugewiesen ist (wie in der Datei "ExdiGdbSrv.idl" definiert).
Kd=Guess -or- NtBaseAddr	Das Debuggermodul verwendet einen allgemeinen heuristischen Mechanismus – oder suchen Sie nach der NT-Basisadresse.
ForceX86	Erzwingt das Debuggermodul, die IeXdiX86Context3-Schnittstelle zum Abrufen/Festlegen des CPU-Kontexts zu verwenden.
DataBreaks=Exdi	Verwendung von Datenhaltepunkten zulassen.
Inproc	Verwendung eines inproc Exdi-Servers zulassen. Diese Option wird empfohlen – InProc=ExdiGdbDrv.dll
PathToSrvCfgFiles	Der Pfad zu den XML-Konfigurationsdateien für EXDI.

Steuern der heuristischen Suche und heuristischen Größe

Wie bereits beschrieben, verwendet der Debugger einen heuristischen Algorithmus, um die NT-Basisadresse zu finden. Führen Sie die folgenden Schritte aus, um die heuristische Suche abzubrechen, wenn Sie WinDbg über die Befehlszeile starten.

Legen Sie die HeuristicScanSize auf 0 in der exdiconfigdata.xml-Datei für den Zielserver fest, an den Sie angefügt werden.
Verwenden Sie den kd=NtBaseAddr heuristischen Typ in der Befehlszeile "Windbg".

Weitere Informationen zum Arbeiten mit XML-Konfigurationsdateien finden Sie unter EXDI XML-Konfigurationsdateien.

Verwenden von WinDbg zum Debuggen des Zielsystems – Haltepunkte

Die dbgeng.dll verwendet einen heuristischen Algorithmus, um die Position der NT-Basisladeadresse zum Zeitpunkt des Auftretens des Unterbrechungsbefehls zu ermitteln. Wenn keine privaten Symbole verfügbar sind, schlägt dieser Prozess fehl.

Das bedeutet, dass die Unterbrechung bei vielen Sequenzen von Verbindungen nicht wie erwartet funktionieren wird. Wenn Sie manuell in den Code eingreifen, wird es sich um eine zufällige Stelle handeln, die Windows zufällig in diesem Moment ausgeführt hat. Da Symbole für den Ziel-Code möglicherweise nicht verfügbar sind, kann es schwierig sein, Haltepunkte mit Hilfe von Symbolen festzulegen.

Debuggerbefehle

Befehle wie die folgenden, die direkt auf den Speicher zugreifen, funktionieren.

k, kb, kc, kd, kp, kP, kv (Stack Backtrace anzeigen)

r (Register)

d, da, db, dc, dd, dD, df, dp, dq, du, dw (Display-Speicher)

u (Unassemble)

Und Sie können Code mithilfe von p (Step) schrittweise durchlaufen.

Es gibt auch Befehle, die verwendet werden können, um Code zu finden, den Sie debuggen möchten.

s (Speicher durchsuchen)

.imgscan (Bildkopfzeilen suchen)

Imgscan kann beim Debuggen von EDXI hilfreich sein, da das Festlegen von Haltepunkten auf der Basis von Symbolen im Gegensatz zum traditionellen KDNET-basierten Debuggen des Kernels nicht möglich ist. Das Auffinden eines gewünschten Ziel-Images kann das Festlegen eines Haltepunkts für den Zugriff auf den Speicher erleichtern.

.exdicmd (EXDI-Befehl)

.exdicmd sendet einen EXDI-Befehl über die aktive EXDI-Debugging-Verbindung an das Zielsystem. Weitere Informationen finden Sie unter .exdicmd (EXDI Command).

Problembehandlung

Verwenden Sie die Ausgabe aus dem ExdiGdbServer-Fenster, um die Verbindungssequenz zu überwachen.

ExdiGdbServer-Textfenster mit langen hexadezimalen Zahlen.

Problem: Fehler: Es kann keine Verbindung mit dem GbDServer hergestellt werden. Überprüfen der Verbindungszeichenfolge <hostname/ip>:portnumber

Dieses Problem kann folgende Ursachen haben:

Die ExdiGdbSrv.dll kann keine Verbindung mit dem Ziel-GDB-Server herstellen.
Der GDB-Server wird noch nicht am Ziel ausgeführt.
Firewallprobleme, stellen Sie sicher, dass beide IP-Adressen erreichbar sind, indem Sie Ping, Tracert oder ein anderes Tool verwenden, um zu überprüfen, ob der GDB-Datenverkehr die Firewall durchlaufen kann.

Problem: Fehlerszenario mit dem Zielsystem ist nicht verfügbar - DbgCoInitialize gibt 0x00000001 zurück

Die folgende Ausgabe kann zurückgegeben werden, wenn das Zielsystem nicht geladen oder anderweitig nicht verfügbar ist.

Microsoft (R) Windows Debugger Version 10.0.20317.1 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.

EXDI: DbgCoInitialize returned 0x00000001

Dies ist ein häufiger Fehler, wenn der ExdiGdbSrv.dll COM-Server keine Verbindung mit dem QEMU GDServer herstellen konnte, sodass dies zu einem Fehler führen kann:

Die vorherige Sitzung des ExdiGdbSrv.dll wird weiterhin von einem dllhost.exe Prozess gehostet, sodass Sie den dllhost.exe Prozess beenden müssen. Verwenden Sie TaskList an einer Eingabeaufforderung, um die PID von dllhost.exe zu finden, die die ExdiGdbSrv.dll hosten. Verwenden und töten Sie TaskKill /PID <PID ID> /f die zugeordnete PID. Weitere Informationen zum Arbeiten mit PIDs finden Sie unter Suchen der Prozess-ID.
Der QEMU gdbserver wurde noch nicht gestartet, oder die Datei exdiconfigdata.xml enthält ungültige IP:Port-Werte. Wenn die WinDbg-Sitzung auf demselben Host-PC wie die Windows-VM QEMU gestartet wird, dann die IP=LocalHost.
Fehler beim Starten des EXDI-COM-Servers (ExdiGDbSrv.dll) über den dllhost.exe-Prozess (COM-bezogen). Um dies zu beheben, starten Sie den Hostdebugger-PC neu oder melden Sie sich erneut bei Windows ab, und melden Sie sich erneut an. Wenn dies nicht funktioniert, registrieren Sie den EXDI COM-Server nach dem Neustart/erneuten Anmelden erneut.
- regsvr32.exe <full path to the ExdiGdbSrv.dll)

Problem: Die Debugsitzung konnte nicht gestartet werden: FAILURE HR=0x80004005:Failed to AttachKernel.

Dieses Problem kann folgende Ursachen haben:

Wie oben beschrieben, ist es möglich, dass die vorherige Sitzung der ExdiGdbSrv.dll noch aktiv ist. Suchen und beenden Sie den zugeordneten DLL-Host wie oben beschrieben.

WinDbg-Dialogfeld, in dem Fehler mit HR-0x80004005 angezeigt werden.

Problem: Das Kerneldebugging mit EXDI konnte nicht gestartet werden.

Dieses Problem kann folgende Ursachen haben:

Es gibt eine weitere Instanz des ExdiGdbSrv.dll (gehostet von dllhost.exe) auf dem Hostdebuggercomputer.
Beenden Sie die zusätzliche Instanz des COM-Diensts, der die ExdiGdbSrv.dll hostet.
- Führen Sie zunächst die Prozesse unter Verwendung des Dienstprogramms TList auf dem Host-PC auf. Der DLLHost, der die ExdiGdbSrv.dll hostet, zeigt ExdiGdbServer an.
  
  tlist 261928 dllhost.exe ExdiGdbServer
- Verwenden Sie kill -f XXXXX an der Debugger-Eingabeaufforderung, um den Prozess mithilfe der Prozessnummer zu beenden.

Problem: Fehler: GdbServer-Sitzung kann nicht konfiguriert werden.

Dieses Problem kann folgende Ursachen haben:

Fehler beim Auffinden der Sitzungsinformationen, z. B. des Pfads zu den XML-Konfigurationsdateien.

Problem: Fehler: EXDI_GDBSRV_XML_CONFIG_FILE Umgebungsvariable ist nicht definiert.

Dieses Problem kann folgende Ursachen haben:

ExdiGdbSrv.dll Umgebungsvariablen sind in der Umgebung nicht festgelegt oder anderweitig nicht verfügbar.

Problem: Fehler: Die EXDI_GDBSRV_XML_CONFIG_FILE Umgebungsvariable ist nicht definiert. Das Beispiel "Exdi-GdbServer" wird zu diesem Zeitpunkt nicht fortgesetzt. Legen Sie den vollständigen Pfad zur Exdi XML-Konfigurationsdatei fest.

Dieses Problem kann folgende Ursachen haben:

Die EXDI_GDBSRV_XML_CONFIG_FILE Umgebungsvariable ist nicht festgelegt. In manchen Situationen funktioniert ExdiGDbSrv.dll weiterhin, wenn Sie auf die Schaltfläche „OK“ klicken, aber die Abfrage der Systemregister durch windbg.exe (z. B. über die Funktionen rdmsr/wrmsr) schlägt fehl.