Festlegen von QEMU-Kernel-Mode Debugging mit EXDI
Dieses Thema beschreibt, wie Sie das QEMU-Kernel-Mode-Debugging mit EXDI festlegen. Der Windows-Debugger unterstützt das Debuggen des Kernels in einer QEMU-Umgebung mit EXDI. Dieses Dokument beschreibt die erforderlichen Schritte zum Aufbau einer GdbServer RSP-Sitzung zwischen der ExdiGdbSrv.dll (GDB-Server-Client) und dem QEMU-GDB-Server.
Das beschriebene Szenario verwendet eine virtuelle Maschine mit Windows x64 und einen QEMU-GDB-Server, der ebenfalls unter Windows ausgeführt wird.
Es ist möglich, sich mit anderen Betriebssystemen zu verbinden, die als Host dienen, wie z. B. Linux. QEMU, die Software zur Virtualisierung und Emulation von Computern, kann auf zahlreichen Architekturen ausgeführt werden, z. B. x64 und Arm64. Der ExdiGdb-Debugging-Server unterstützt auch andere Prozessoren, so ist es z. B. möglich, WinDbg zum Debuggen von QEMU, das auf Arm64 ausgeführt wird, zu verwenden. Dies bietet mehrere Optionen, um eine Windows-VM zu debuggen, sodass die Windows-VM über den verfügbaren QEMU-GDB-Server, der mit dem Debugger Host EXDI-GDB-Server-Client verbunden ist, HW-debuggt werden kann.
Allgemeine Informationen zum Festlegen, Konfigurieren und zur Fehlerbehebung von EXDI-Verbindungen finden Sie unter Konfigurieren des EXDI-Debugger-Transports.
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. Um das Networking-Debugging automatisch einzurichten, siehe KDNET-Network-Kernel-Debugging automatisch einrichten.
EXDI COM Server
EXDI ist eine Schnittstelle, die die Möglichkeit bietet, WinDbg um den Support für Hardware-Debugger (z. B. JTAG-basiert oder GdbServer-basiert) zu erweitern. Das folgende Diagramm veranschaulicht die Rolle von EXDI-GdbServer.
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 unter Öffentliche und private Symbole.
Einrichtung einer Debugger-Verbindung zu einem Windows-Image unter QEMU
In diesem Thema beschreiben wir, wie Sie eine Verbindung zu einem QEMU-Virtual-Windows-Image herstellen, das unter Windows ausgeführt wird.
- Laden Sie QEMU herunter, und installieren Sie es auf Windows.
- Konfigurieren Sie ein QEMU-Virtual-Windows-Image, um es mit den erforderlichen Netzwerk- und BIOS/UEFI-Einstellungen für das Debugging zu starten.
- Starten Sie die QEMU-Umgebung unter Verwendung des konfigurierten Startskripts.
- Starten Sie den gdbserver auf QEMU.
- Überprüfen Sie die Netzwerkkonnektivität, und lokalisieren und notieren Sie die IP-Adresse des Ziel-Images. (HOST-IP-Standardadresse von 1.2.3.4).
- Laden Sie die Windows-Debugging-Tools herunter, und installieren Sie sie auf dem Host-System.
- Laden Sie den EXDI-Server für QEMU auf GitHub herunter, erstellen, registrieren und konfigurieren Sie ihn.
- Konfigurieren Sie den Debugger-Host (WinDbg), indem Sie die EXDI-Konfigurations-XML-Dateien bearbeiten.
- Starten Sie WinDbg über die Kommandozeile, um sich mit dem EXDI-Server zu verbinden.
- Verwenden Sie WinDbg, um das Ziel-QEMU-Windows-Image zu debuggen.
Herunterladen und Installieren von QEMU unter Windows
QEMU ist ein generischer und Open-Source Computer-Emulator und Virtualisierer, der eine dynamische Übersetzung bewirkt. Wenn QEMU als Computer-Emulator verwendet wird, kann es Betriebssysteme und Programme, die für einen Prozessor (z. B. Arm64) entwickelt wurden, auf einem anderen Computer (einem x64-PC) ausführen. Er kann auch Images virtueller Maschinen für verschiedene Betriebssysteme (Windows/Linux/Mac) ausführen/hosten.
QEMU kann andere Hypervisors wie KVM verwenden, um CPU-Erweiterungen (HVM) für die Virtualisierung zu nutzen. Wenn QEMU als Virtualisierer verwendet wird, erzielt QEMU nahezu native Leistungen, indem es den Code des Gastes direkt auf der Host-CPU ausführt. QEMU kann die Funktionen des Betriebssystem-Hypervisors nutzen, um die CPU- und MMU-Emulation auf echte Hardware auszulagern.
Herunterladen und Installieren von QEMU
In dieser Anleitung wird QEMU für Windows x64 auf einem x64-PC installiert, auf dem auch der Windows-Debugger ausgeführt wird.
Laden Sie QEMU von der QEMU-Download-Seite herunter: https://www.qemu.org/download/
In der QEMU-Dokumentation finden Sie Informationen zur Installation von QEMU: https://www.qemu.org/documentation/
Konfigurieren eines virtuellen Datenträgers als Ziel
Suchen oder erstellen Sie ein Image eines virtuellen Datenträgers, der die Software enthält, die Sie debuggen möchten.
In diesem Beispiel wird ein Image eines virtuellen Computers unter Windows x64 VHDX verwendet. Um mehr über die Images virtueller Maschinen unter Windows zu erfahren, lesen Sie Virtuelle Maschine mit Hyper-V unter Windows 10 erstellen.
VirtIO-Treiber in das Windows-Image einfügen
Um Netzwerkfunktionen und eine angemessene Leistung der Datenträger zuzulassen, injizieren oder installieren Sie die VirtIO-Treiber in das Image der virtuellen Maschine unter Windows. Die VirtIo-Treiber sind hier erhältlich: https://github.com/virtio-win/kvm-guest-drivers-windows
VirtIO ist eine standardisierte Schnittstelle, die virtuellen Maschinen die Möglichkeit bietet, auf abstrahierte Hardware zuzugreifen, wie z. B. Blockgeräte, Netzwerkadapter und Konsolen. Virtio dient als Abstraktionsschicht für Hardwaregeräte in einer virtualisierten Umgebung wie QEMU.
Konvertieren von VHDX in QEMU
Dieser Schritt ist nicht erforderlich, wird aber empfohlen, da eine bessere Leistung erzielt wird, wenn Sie ein natives QEMU-QCOW-Image anstelle einer VHDX verwenden.
Verwenden Sie den Befehl qemu-img.exe, um die VHDX zu konvertieren. Dieses Dienstprogramm finden Sie dort, wo Sie QEMU installiert haben, z. B. C:\Program Files\qemu.
C:\Program Files\qemu> qemu-img convert -c -p -O qcow2 MyVHDXFile.vhdx MyQEMUFile.qcow2
UEFI-Firmware herunterladen
Die besten Ergebnisse erzielen Sie, wenn Sie die UEFI-Firmware-Datei (OVMF.fd) herunterladen oder kompilieren. Die Firmware wird benötigt, da QEMU sonst standardmäßig ältere BIOS-Systeme emuliert.
Eine Quelle für UEFI-Firmware ist das Open-Source-Linux-Projekt: https://clearlinux.org/
Die UEFI OVMF.fd Beispieldatei ist hier verfügbar: https://github.com/clearlinux/common/blob/master/OVMF.fd
Extrahieren Sie den Inhalt der heruntergeladenen Datei in C:\Program Files\qemu\Firmware.
Für andere Plattformen als Intel AMD64 sollten Sie die Firmware mit dem EDK2 kompilieren. Weitere Informationen finden Sie unter https://github.com/tianocore/tianocore.github.io/wiki/How-to-build-OVMF.
Konfigurieren des QEMU-Startskripts
Erstellen Sie Ihre Konfigurationsdatei in QEMU. Erstellen Sie zum Beispiel eine StartQEMUx64Windows.bat-Datei unter dem QEMU-Root-Verzeichnis. Siehe die Beispielsdatei unten.
QEMU mit dem QEMU-Startskript starten
Führen Sie das QEMU-Startskript aus, um QEMU zu starten.
c:\Program Files\qemu\StartQEMUx64Windows.bat
Wenn eine Defender-Firewall-Meldung erscheint, gewähren Sie der App alle Rechte für alle Arten von Netzwerken, um Windbg durch die Windows Firewall für den Host-Debugger-Computer zu aktivieren.
Sobald der virtuelle Windows-Computer in der QEMU-Umgebung gestartet ist, erscheint die QEMU-Benutzeroberfläche.
Verwenden Sie die Tastenkombination STRG+ALT+ eine Zifferntaste, um die QEMU-Monitor-Konsole aufzurufen. Dieser Monitor ist auch über View->Compatmonitor verfügbar.
Geben Sie gdbserver ein, um den Front-End GDB-Server auf QEMU zu starten.
QEMU sollte Waiting for gdb connection on device ‘tcp::1234’ anzeigen.
Kehren Sie mit der Tastenkombination STRG+ALT+1 zum Hauptfenster zurück.
Tipp: Das GDB-Konsolenfenster unterstützt den Befehl „system_reset“ zum schnellen Neustart der Emulation. Geben Sie help ein, um eine Liste der GDB-Konsolenbefehle zu erhalten.
Beispiel für ein Skript zum Starten einer QEMU-x64-Windows-VM
Hier finden Sie ein Beispiel für ein QEMU-Konfigurationsskript, das für virtuelle AMD64-Maschinen verwendet werden kann. Ersetzen Sie die Links, die auf die DISK- und CDROM-Dateien verweisen, durch die entsprechenden Speicherorte auf Ihrem PC.
REM
REM This script is used to run a Windows x64 VM on QEMU that is hosted by a Windows x64 host system
REM The Host system is a PC with Intel(R) Xeon(R) CPU.
REM
set EXECUTABLE=qemu-system-x86_64
set MACHINE=-m 6G -smp 4
REM No acceleration
REM generic cpu emulation.
REM to find out which CPU types are supported by the QEMU version on your system, then run:
REM qemu-system-x86_64.exe -cpu help
REM the see if your host system CPU is listed
REM
set CPU=-machine q35
REM Enables x64 UEFI-BIOS that will be used by QEMU :
set BIOS=-bios D:\temp\firmware\OVMF.fd
REM Use regular GFX simulation
set GFX=-device ramfb -device VGA
set USB_CTRL=-device usb-ehci,id=usbctrl
set KEYB_MOUSE=-device usb-kbd -device usb-tablet
REM # The following line enable the full-speed HD controller (requires separate driver)
REM # Following line uses the AHCI controller for the Virtual Hard Disk:
set DRIVE0=-device ahci,id=ahci -device ide-hd,drive=disk,bus=ahci.0
REM
REM This will set the Windows VM x64 disk image that will be launched by QEMU
REM The disk image is in the qcow2 format accepted by QEMU.
REM You get the .qcow2 image, once you get the VHDX Windows VM x64 image
REM and apply the script to inject the virtio x64 drivers and then run the
REM the QEMU tool to convert the .VHDX image to .qcow2 format
REM i.e.
REM qemu-img convert -c -p -O qcow2 Windows_VM_VHDX_with_injected_drivers_file.vhdx file.qcow2
REM file : points to the specified qcow2 image path.
REM
set DISK0=-drive id=disk,file=D:\temp\x64_image_qcow2_for_windows\basex64Client.qcow2,if=none
REM
REM for kdnet on, then best option:
REM NETWORK0="-netdev user,id=net0,hostfwd=tcp::53389-:3389,hostfwd=tcp::50001-:50001 -device virtio-net,netdev=net0,disable-legacy=on"
REM
set NETHOST=-netdev user,id=net0,hostfwd=tcp::3589-:3389
set NETGUEST=-device e1000,netdev=net0
REM # The following line should enable the Daemon (instead of interactive)
set DAEMON=-daemonize"
%EXECUTABLE% %MACHINE% %CPU% %BIOS% %GFX% %USB_CTRL% %DRIVE0% %DISK0% %NETHOST% %NETGUEST%
Netzwerkverbindung überprüfen
Vergewissern Sie sich, dass Sie die IP-Adresse von Windows erhalten (wenn sich der Host des Debuggers nicht auf demselben Windows-Computer befindet wie die QEMU-VM).
Wenn der GDB-Server ordnungsgemäß gestartet wurde, sehen Sie die Nummer des Ports, an dem der GDB-Server lauscht, und Sie müssen diesen Port für die Einrichtung des Host-Debuggers (IP:Port-Paar) in der exdiConfigData.xml verwenden.
Wenn sich Ihr Host-Debugger auf demselben Computer befindet, auf dem auch der QEMU-Gast gehostet wird, dann wird die ID Localhost in der exdiconfigdata.xml als IP:Port-Paar verwendet (z. B. LocalHost:Port:1234). In diesem Beispiel, bei dem sich der Server und der Host-Debugger auf demselben PC befinden, werden die Standardwerte verwendet.
Legen Sie in der Datei ExdiConfigData.xml den Wert des Attributs für den aktuellen Zielnamen (CurrentTarget) auf „QEMU“ fest.
Wenn Sie auf einem Remote-PC arbeiten, legen Sie das Ziel QEMU IP <address> : Port <number> fest, unter dem der GDB-Server lauscht:
- Finden Sie das Tag-Element der QEMU-Komponente in der Datei exdiCondifgData.xml.
- Legen Sie die IP:Port-Nummer (LocalHost, wenn der Debugger auf demselben Host wie die QEMU-VM ausgeführt wird) für den QEMU-GDB-Server fest:
- Speichern Sie die Änderungen in der Datei exdiConfigdata.xml, die sich unter dem in der Umgebungsvariablen EXDI_GDBSRV_XML_CONFIG_FILE angegebenen Pfad befindet.
Weitere Informationen zum QEMU-Networking finden Sie unter https://wiki.qemu.org/Documentation/Networking
Die folgenden Befehle können in der QEMU-Konsole (compatmonitor0) genutzt werden, um Informationen über das Netzwerk und den Verbindungsstatus anzuzeigen.
info network
info usernet
Downloaden und Installieren der Windows-Debugging-Tools auf dem Host-System
Installieren Sie die Windows-Debugging-Tools auf dem Host-System. Informationen zum Herunterladen und Installieren der Debugging-Tools finden Sie unter Debugging-Tools für Windows.
EXDI-Server-DLL herunterladen, kompilieren und registrieren
Herunterladen des entsprechenden ExdiGdbSrv.dll Binarys (EXDI-COM-Server-Client) aus dem Quellcode von microsoft/WinDbg-Samples, GitHub https://github.com/microsoft/WinDbg-Samples)
git clone https://github.com/microsoft/WinDbg-Samples
Erstellen Sie die VS-Lösung (ExdiGdbSrv.sln) entsprechend der Architektur Ihrer Host-Debugger-Installation, die sich in Exdi/exdigdbsrv befindet.
Sichern Sie die ExdiGdbSrv.dll, die durch den Build erzeugt wurde.
Kopieren Sie den EXDI-COM-Server (ExdiGdbSrv.dll) auf den Host-Computer, in das Verzeichnis, das Ihren Debugger enthält, z. B. C:\Program Files (x86)\Windows Kits\10\Debuggers\x64 oder C:\Debuggers)
Verwenden Sie regsvr32, um die DLL in einer administrativen Eingabeaufforderung zu registrieren.
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64>regsvr32 ExdiGdbSrv.dll
RegSvr32 sollte eine Nachricht zurückgeben, die besagt, das die DLLRegisterServer in ExdiGdbSrv.dll succeeded.
Dieser Schritt muss nur einmal ausgeführt werden, aber wenn Sie den Speicherort der ExdiGdbSrv.dll ändern, müssen Sie den COM-Server erneut registrieren.
Eine andere Möglichkeit besteht darin, das PowerShell-Beispielskript zu verwenden, um die EXDI-DLL zu installieren und den Debugger beim ersten Mal zu starten. Weitere Informationen finden Sie unter Beispiel EXDI PowerShell-Skript in Konfiguration des EXDI-Debugger-Transports.
Konfigurieren des Hosts des Debuggers (WinDbg), indem Sie die XML-Dateien der EXDI-Konfiguration bearbeiten
Suchen Sie die beiden benötigten Konfigurationsdateien in WinDbg-Samples/Exdi/exdigdbsrv/, und kopieren Sie sie lokal auf den Computer, auf dem der Debugger-Host installiert ist.
exdiConfigData.xmlsystemregisters.xml
EXDI_GDBSRV_XML_CONFIG_FILE – Beschreibt den vollständigen Pfad zur EXDI-XML-Konfigurationsdatei.
EXDI_SYSTEM_REGISTERS_MAP_XML_FILE – Beschreibt den vollständigen Pfad zu der EXDI-XML-Systemregister-Map-Datei.
Allgemeine Informationen zum Festlegen der Konfiguration und Fehlerbehebung von EXDI-Verbindungen sowie zu den Tags und Attributen von exdiConfigData.xml finden Sie unter Konfiguration des EXDI-Debugger-Transports.
Legen Sie die Umgebungsvariable EXDI_GDBSRV_XML_CONFIG_FILE und EXDI_SYSTEM_REGISTERS_MAP_XML_FILE fest, um den vollständigen Pfad zur EXDI-XML-Konfigurationsdatei zu beschreiben.
Eingabeaufforderung
Öffnen Sie eine Eingabeaufforderung, und legen Sie die folgenden Umgebungsvariablen fest.
set EXDI_GDBSRV_XML_CONFIG_FILE="C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\exdiConfigData.xml"
set EXDI_SYSTEM_REGISTERS_MAP_XML_FILE="C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\systemregisters.xml"
Geben Sie SET ein, um zu bestätigen, dass der angegebene Pfad am Speicherort der ExdiGdbSrvSample.dll verfügbar ist
PowerShell
Öffnen Sie eine PowerShell-Eingabeaufforderung, und legen Sie die folgenden Umgebungsvariablen fest:
$env:EXDI_GDBSRV_XML_CONFIG_FILE = 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\exdiConfigData.xml'
$env:EXDI_SYSTEM_REGISTERS_MAP_XML_FILE = 'C:\Program Files (x86)\Windows Kits\10\Debuggers\x64\systemregisters.xml'
Geben Sie dir env: ein, um zu bestätigen, dass der angegebene Pfad vom Speicherort der ExdiGdbSrvSample.dll aus verfügbar ist.
WinDbg auf dem Host-System starten
Starten Sie die windbg-Sitzung über die EXDI-Schnittstelle in derselben Eingabeaufforderung, in der Sie die Umgebungsvariablen festgelegt haben (EXDI_GDBSRV_XML_CONFIG_FILE und EXDI_SYSTEM_REGISTERS_MAP_XML_FILE).
c:\Debuggers> windbg.exe -v -kx exdi:CLSID={29f9906e-9dbe-4d4b-b0fb-6acf7fb6d014},Kd=Guess,DataBreaks=Exdi
Um zusätzliche Ausgaben anzuzeigen, können Sie die -v: verbose session verwenden. Allgemeine Informationen zu den WinDbg-Optionen finden Sie unter WinDbg Kommandozeilen-Optionen.
Eine andere Möglichkeit besteht darin, das PowerShell-Beispielskript zu verwenden, um die EXDI-DLL zu installieren und den Debugger beim ersten Mal zu starten. Weitere Informationen finden Sie unter Beispiel EXDI PowerShell-Skript, in Konfigurieren des EXDI-Debugger-Transports.
PS>.\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64 -ExdiDropPath "C:\path\to\built\exdi\files"
Der Debugger sollte starten und sich mit dem QEMU-GdbServer verbinden.
Der Debugger zeigt die erfolgreiche Initialisierung des EXDI-Transports an.
EXDI: DbgCoInitialize returned 0x00000001
EXDI: CoCreateInstance() returned 0x00000000
EXDI: QueryInterface(IExdiServer3) returned 0x00000000
Target command response: QEMU
exdiCmd: The function: 'ExdiDbgType' was completed.
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
Das Fenster EXDIGdbServer Console Packets kann auch Informationen über den Status der EXDI-Verbindung anzeigen, wenn displayCommPackets="yes" in der Datei exdiConfigData.xml festgelegt ist. Weitere Informationen finden Sie in der Fehlerbehebung unter Konfigurieren des EXDI-Debugger-Transports.
Verwenden von WinDbg zum Debuggen des Ziel-QEMU-Windows-Images
Die dbgeng.dll verwendet einen heuristischen Algorithmus, um die NT-Basisadresse zu dem Zeitpunkt zu finden, als der Break-Befehl erfolgte. 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.
Befehle wie die folgenden, die direkt auf den Speicher zugreifen, funktionieren.
k, kb, kc, kd, kp, kP, kv (Stack Backtrace anzeigen)
d, da, db, dc, dd, dD, df, dp, dq, du, dw (Display-Speicher)
Und Sie können Schritt für Schritt durch den Code gehen.
Es gibt auch Befehle, mit denen Sie versuchen können, den Code zu finden, den Sie debuggen möchten.
.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-Befehl).
EXDI-XML-Konfigurationsdateien
Es gibt zwei erforderliche xml-Dateien, die vom EXDI GDB COM-Server (ExdiGdbSrv.dll) genutzt werden.
exdiConfigData.xml – Diese Datei enthält die wichtigsten Konfigurationsdaten, die der GDB-Server-Client benötigt, um eine erfolgreiche GDB-Sitzung mit dem HW-Debugger GDB-Server-Ziel aufzubauen. Der GDB-Server-Client wird also nicht ausgeführt, wenn der Ort der Datei nicht durch die Umgebungsvariable EXDI_GDBSRV_XML_CONFIG_FILE festgelegt ist. Jedes XML-Tag bietet die Möglichkeit, bestimmte Funktionen des GDB-Servers festzulegen. Im Folgenden finden Sie eine Liste der Attribute, die Sie in der XML-Datei ändern können, sowie ein XML-Beispiel.
Systemregister.xml – Diese Datei enthält eine Zuordnung zwischen Systemregistern und ihrem Code für den Zugriff. Dies ist erforderlich, da der Zugriffscode nicht vom GDB-Server in der XML-Datei bereitgestellt wird und der Debugger über den Zugriffscode auf jedes Systemregister zugreift.
Weitere Informationen und eine Beschreibung der GDBServer-Tags und -Attribute, die in den XML-Konfigurationsdateien definiert sind, finden Sie unter Konfiguration des EXDI-Debugger-Transports.
Problembehandlung
Beachten Sie die Informationen zur Fehlerbehebung in Konfiguration des EXDI-Debugger-Transports.
Weitere Informationen
EXDI-Debugger-Transport konfigurieren
Automatisches Einrichten des KDNET-Netzwerkkernel-Debuggings
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für