Einrichten des QEMU-Kernel-Mode Debuggens mithilfe von EXDI
In diesem Thema wird beschrieben, wie Sie QEMU Kernel-Mode Debugging mithilfe von EXDI einrichten. Der Windows-Debugger unterstützt das Kerneldebuggen einer QEMU-Umgebung mithilfe von EXDI. In diesem Dokument werden die erforderlichen Schritte zum Einrichten einer GdbServer RSP-Sitzung zwischen dem ExdiGdbSrv.dll (GDB-Serverclient) und dem QEMU GDB-Server beschrieben.
Das beschriebene Szenario verwendet einen virtuellen Windows x64-Computer und einen QEMU-GDB-Server, der auch unter Windows ausgeführt wird.
Es ist möglich, eine Verbindung mit anderen Betriebssystemen herzustellen, die als Host dienen, z. B. Linux. QEMU, die Virtualisierungs- und Computeremulationssoftware, kann auf zahlreichen Architekturen wie x64 und Arm64 ausgeführt werden. Der ExdiGdb-Debugserver unterstützt auch andere Prozessoren, z. B. ist es möglich, WinDbg zum Debuggen von QEMU unter Arm64 zu verwenden. Dies bietet mehrere Optionen zum Debuggen einer Windows-VMs, sodass die Windows-VM über den verfügbaren QEMU GDB-Server, der mit dem Debuggerhost EXDI GDB-Serverclient verbunden ist, HW debuggt werden kann.
Allgemeine Informationen zum Einrichten und Behandeln von Problemen mit EXDI-Verbindungen finden Sie unter Konfigurieren des EXDI-Debuggertransports.
Hinweis
EXDI ist eine erweiterte, spezialisierte Form des Debuggens für bestimmte Umgebungen. Die Verwendung einer KDNET-Standardverbindung ist einfacher zu konfigurieren und wird empfohlen. Informationen zum automatischen Einrichten des Netzwerkdebuggens finden Sie unter Automatisches Debuggen des KDNET-Netzwerkkernels.
EXDI COM-Server
EXDI ist eine Schnittstelle, die die Erweiterung von WinDbg ermöglicht, 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.
Wichtig
Da EXDI das KDNET-Protokoll nicht verwendet, hat der verbundene Debugger deutlich weniger Informationen darüber, was auf dem PC ausgeführt wird, und viele Befehle funktionieren anders oder funktionieren möglicherweise gar nicht. Der Zugriff auf private Symbole für den zu debuggenden Code kann dem Debugger helfen, die Codeausführung des Zielsystems besser zu verstehen. Weitere Informationen finden Sie unter Öffentliche und private Symbole.
Einrichten einer Debuggerverbindung mit einem Windows-Image auf QEMU
In diesem Thema wird der Prozess zum Anfügen an ein virtuelles QEMU-Windows-Image beschrieben, das unter Windows ausgeführt wird.
- Laden Sie QEMU unter Windows herunter, und installieren Sie es.
- Konfigurieren Sie ein virtuelles QEMU-Windows-Zielimage für den Start mit den erforderlichen Netzwerk- und BIOS/UEFI-Einstellungen für das Debuggen.
- Starten Sie die QEMU-Umgebung mithilfe des konfigurierten Startskripts.
- Starten Sie den gdbserver in QEMU.
- Überprüfen Sie die Netzwerkkonnektivität, und suchen Und notieren Sie die IP-Adresse des Zielimages. (HOST-IP-Standardadresse 1.2.3.4).
- Laden Sie die Windows-Debugtools herunter, und installieren Sie sie auf dem Hostsystem.
- Laden Sie den EXDI-Server für QEMU auf GitHub herunter, erstellen, registrieren und konfigurieren Sie sie.
- Konfigurieren Sie den Debuggerhost (WinDbg), indem Sie die EXDI-Konfigurations-XML-Dateien bearbeiten.
- Starten Sie WinDbg über die Befehlszeile, um eine Verbindung mit dem EXDI-Server herzustellen.
- Verwenden Sie WinDbg, um das QEMU-Ziel-Windows-Image zu debuggen.
Herunterladen und Installieren von QEMU unter Windows
QEMU ist ein generischer und Open Source Computeremulator und Virtualisierer, der eine dynamische Übersetzung verursacht. Wenn QEMU als Computeremulator verwendet wird, können Betriebssystemen und Programme ausgeführt werden, die für einen Prozessor (z. B. arm64) auf einem anderen Computer (einem x64-PC) erstellt wurden. Es kann auch Vm-Images für verschiedene Betriebssysteme (Windows/Linux/Mac) ausführen bzw. hosten.
QEMU kann andere Hypervisoren wie KVM verwenden, um CPU-Erweiterungen (HVM) für die Virtualisierung zu verwenden. Wenn QEMU als Virtualisierer verwendet wird, erzielt QEMU nahezu native Leistung, indem der Gastcode direkt auf der Host-CPU ausgeführt wird. QEMU kann die Vorteile der Hypervisorfunktionen des Betriebssystems nutzen, um die CPU- und MMU-Emulation auf echte Hardware auszulagern.
Herunterladen und Installieren von QEMU
In dieser exemplarische Vorgehensweise wird QEMU für Windows x64 auf einem x64-PC installiert, auf dem der Windows-Debugger ebenfalls ausgeführt wird.
Laden Sie QEMU von der QEMU-Downloadseite herunter: https://www.qemu.org/download/
Informationen zur Installation von QEMU finden Sie in der QEMU-Dokumentation: https://www.qemu.org/documentation/
Konfigurieren eines virtuellen Zieldatenträgers
Suchen oder erstellen Sie ein Virtuelles Datenträgerimage mit der Software, die Sie debuggen möchten.
In diesem Beispiel wird ein Windows x64 VHDX-Datenträgerimage für virtuelle Computer verwendet. Weitere Informationen zu Windows-VM-Images finden Sie unter Erstellen eines virtuellen Computers mit Hyper-V auf Windows 10.
Einfügen der VirtIO-Treiber in das Windows-Image
Um Netzwerkfunktionen und eine angemessene Leistung des Speichergeräts zu ermöglichen, müssen Sie die VirtIO-Treiber entweder in das Windows-VM-Datenträgerimage einfügen oder installieren. Die VirtIo-Treiber sind hier verfügbar: https://github.com/virtio-win/kvm-guest-drivers-windows
VirtIO ist eine standardisierte Schnittstelle, die virtuellen Computern zugriff auf abstrahierte Hardware wie Blockgeräte, Netzwerkadapter und Konsolen ermöglicht. 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 ein natives QEMU-QCOW-Image anstelle einer VHDX verwendet wird.
Verwenden Sie den folgenden qemu-img.exe Befehl, um die vhdx zu konvertieren. Dieses Hilfsprogramm befindet sich an der Stelle, an der 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
Herunterladen der UEFI-Firmware
Um optimale Ergebnisse zu erzielen, laden Sie die UEFI-Firmwaredatei (OVMF.fd) herunter, oder kompilieren Sie sie. Die Firmware wird benötigt, da QEMU andernfalls standardmäßig ältere BIOS-Systeme emuliert.
Eine Quelle für die UEFI-Firmware ist das Open Clear Linux-Projekt: https://clearlinux.org/
Die UEFI-Beispieldatei OVMF.fd 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 aus 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 beispielsweise eine StartQEMUx64Windows.bat Datei im QEMU-Stammverzeichnis. Sehen Sie sich die folgende Beispieldatei an.
Verwenden des QEMU-Startskripts zum Starten von QEMU
Führen Sie das QEMU-Startskript aus, um QEMU zu starten.
c:\Program Files\qemu\StartQEMUx64Windows.bat
Wenn eine Firewall Defender-Eingabeaufforderung angezeigt wird, erteilen Sie der App alle Rechte für alle Netzwerktypen, um Windbg durch die Windows-Firewall für den Hostdebuggercomputer zu aktivieren.
Sobald der virtuelle Windows-Computer in der QEMU-Umgebung gestartet wurde, wird die QEMU-Benutzeroberfläche angezeigt.
Verwenden Sie STRG+ALT+ eine Zahlentastenkombination, um in die QEMU-Monitorkonsole zu wechseln. Dieser Monitor ist auch mit View-compatmonitor> verfügbar.
Geben Sie ein gdbserver , um den Front-End-GDB-Server auf QEMU zu starten.
QEMU sollte angezeigt werden Waiting for gdb connection on device ‘tcp::1234’
Kehren Sie mit der Tastenkombination STRG+ALT+1 zum Fenster Standard zurück.
Tipp: Das GDB-Konsolenfenster unterstützt den Befehl "system_reset", um die Emulation schnell neu zu starten. Geben Sie hilfe für eine Liste der GDB-Konsolenbefehle ein.
Beispiel für das QEMU x64-Skript zum Starten eines virtuellen Windows-Computers
Hier sehen Sie ein Beispiel für ein QEMU-Konfigurationsskript, das für AMD64-Virtual Machines verwendet werden kann. Ersetzen Sie die Links, die auf die DISK- und CDROM-Dateien verweisen, zu den Speicherorten 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 DEAMON=-daemonize"
%EXECUTABLE% %MACHINE% %CPU% %BIOS% %GFX% %USB_CTRL% %DRIVE0% %DISK0% %NETHOST% %NETGUEST%
Überprüfen Sie die Netzwerkverbindung.
Stellen Sie sicher, dass Sie die Windows-IP-Adresse abrufen (wenn sich die Debuggerhostsitzung nicht auf demselben Windows-Computer wie die QEMU-VM befindet).
Wenn der GDB-Server ordnungsgemäß gestartet wurde, wird die Portnummer angezeigt, an der der GDB-Server lauscht, und Sie müssen diesen Port verwenden, um den Hostdebugger (IP:Port-Paar) im exdiConfigData.xml einzurichten.
Wenn sich Ihr Hostdebugger auf demselben Computer befindet, auf dem der QEMU-Gast gehostet wird, wird der Localhost-Bezeichner im exdiconfigdata.xml als IP:Port-Paar verwendet (z. B. LocalHost:Port:1234). In diesem Beispiel werden mit dem Server und dem Hostdebugger auf demselben PC die Standardwerte verwendet.
Legen Sie den aktuellen Wert des Zielnamensattributs (CurrentTarget) in der ExdiConfigData.xml-Datei auf "QEMU" fest.
Wenn Sie auf einem Remote-PC arbeiten, legen Sie die QEMU-Ziel-IP fest <address> : Port <number> , an dem der GDB-Server lauscht:
- Suchen Sie das Tag-Element der QEMU-Komponente im exdiCondifgData.xml.
- Legen Sie die IP:Portnummer (LocalHost, wenn debugger auf demselben Host wie der QEMU-VM ausgeführt wird) für den QEMU-GDB-Server wie folgt fest:
- Speichern Sie die Änderungen an der exdiConfigdata.xml Datei, die sich unter dem von EXDI_GDBSRV_XML_CONFIG_FILE Umgebungsvariablen angegebenen Pfad befindet.
Weitere Informationen zu QEMU-Netzwerken finden Sie unter https://wiki.qemu.org/Documentation/Networking
Die folgenden Befehle können auf der QEMU-Konsole (compatmonitor0) ausgegeben werden, um Informationen zum Netzwerk und zur Verbindung status anzuzeigen.
info network
info usernet
Herunterladen und Installieren der Windows-Debugtools auf dem Hostsystem
Installieren Sie die Windows-Debugtools auf dem Hostsystem. Informationen zum Herunterladen und Installieren der Debuggertools finden Sie unter Debugtools für Windows.
Herunterladen, Erstellen und Registrieren der EXDI-Server-DLL
Laden Sie den entsprechenden Quellcode für ExdiGdbSrv.dll binär (EXDI COM-Serverclient) aus dem Microsoft/WinDbg-Samples, GitHub https://github.com/microsoft/WinDbg-Samples) herunter.
git clone https://github.com/microsoft/WinDbg-Samples
Erstellen Sie die VS-Lösung (ExdiGdbSrv.sln) gemäß der Architektur Ihrer Hostdebuggerinstallation in Exdi/exdigdbsrv.
Suchen Sie die vom Build erzeugte ExdiGdbSrv.dll.
Kopieren Sie den EXDI com-Server (ExdiGdbSrv.dll) auf den Hostcomputer in das Verzeichnis, das Ihren Debugger enthält, .g. C:\Program Files (x86)\Windows Kits\10\Debuggers\x64 oder C:\Debuggers)
Verwenden Sie regsvr32, um die DLL in einer Administratoreingabeaufforderung zu registrieren.
C:\Program Files (x86)\Windows Kits\10\Debuggers\x64>regsvr32 ExdiGdbSrv.dll
RegSvr32 sollte eine Meldung zurückgeben, die angibt, dass der DLLRegisterServer in ExdiGdbSrv.dll succeededangibt.
Dieser Schritt muss nur einmal ausgeführt werden, aber wenn Sie den Speicherort des ExdiGdbSrv.dll ändern, müssen Sie den COM-Server erneut registrieren.
Eine weitere 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 unter Konfigurieren des EXDI-Debuggertransports.
Konfigurieren des Debuggerhosts (WinDbg) durch Bearbeiten der EXDI-Konfigurations-XML-Dateien
Suchen Sie die beiden erforderlichen Konfigurationsdateien in WinDbg-Samples/Exdi/exdigdbsrv/ , und kopieren Sie sie in eine lokale Datei auf Ihrem Hostdebuggercomputer, auf dem der Debugger 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 zur SYSTEMregisterzuordnungsdatei für EXDI xml.
Allgemeine Informationen zur Einrichtung und Problembehandlung von EXDI-Verbindungen sowie zu den exdiConfigData.xml Tags und Attributen finden Sie unter Konfigurieren des EXDI-Debuggertransports.
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 ein SET , um zu bestätigen, dass der angegebene Pfad am Speicherort des ExdiGdbSrvSample.dll
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 ein dir env: , um zu bestätigen, dass der angegebene Pfad am Speicherort des ExdiGdbSrvSample.dll
Starten von WinDbg auf dem Hostsystem
Starten Sie die windbg-Sitzung über die exdi-Schnittstelle an derselben Eingabeaufforderung, in der Sie die Umgebungsvariablen (EXDI_GDBSRV_XML_CONFIG_FILE und EXDI_SYSTEM_REGISTERS_MAP_XML_FILE) festlegen.
c:\Debuggers> windbg.exe -v -kx exdi:CLSID={29f9906e-9dbe-4d4b-b0fb-6acf7fb6d014},Kd=Guess,DataBreaks=Exdi
Zum Anzeigen einer zusätzlichen Ausgabe kann die ausführliche Sitzung -v: verwendet werden. Allgemeine Informationen zu den WinDbg-Optionen finden Sie unter WinDbg Command-Line-Optionen.
Eine weitere 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 unter Konfigurieren des EXDI-Debuggertransports.
PS>.\Start-ExdiDebugger.ps1 -ExdiTarget "QEMU" -GdbPort 1234 -Architecture x64 -ExdiDropPath "C:\path\to\built\exdi\files"
Der Debugger sollte gestartet und eine Verbindung mit dem QEMU-GdbServer hergestellt werden.
Der Debugger zeigt die erfolgreiche EXDI-Transportinitialisierung 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 EXDIGdbServer-Konsolenpaketfenster kann auch Informationen über die status der EXDI-Verbindung anzeigen, wenn displayCommPackets="yes" in der exdiConfigData.xml-Datei festgelegt ist. Weitere Informationen finden Sie in den Informationen zur Problembehandlung unter Konfigurieren des EXDI-Debuggertransports.
Verwenden von WinDbg zum Debuggen des QEMU-Ziel-Windows-Images
Der dbgeng.dll verwendet einen heuristischen Algorithmus, um den Speicherort der NT-Basisladeadresse zum Zeitpunkt des Break-Befehls zu ermitteln. Wenn keine privaten Symbole verfügbar sind, schlägt dieser Prozess fehl.
Dies bedeutet, dass die Unterbrechung unter vielen Verbindungssequenzen nicht wie erwartet funktioniert. Wenn Sie manuell in den Code einbrechen, handelt es sich um einen zufälligen Speicherort, den Windows in diesem Moment ausgeführt hat. Da Symbole für den Zielcode möglicherweise nicht verfügbar sind, kann es schwierig sein, Haltepunkte mithilfe von Symbolen festzulegen.
Befehle wie die folgenden, die direkt auf den Arbeitsspeicher zugreifen, funktionieren.
k, kb, kc, kd, kp, kP, kv (Display Stack Backtrace)
d, da, db, dc, dd, dD, df, dp, dq, du, dw (Anzeigespeicher)
Außerdem können Sie Code schrittweise durchlaufen.
Es gibt auch Befehle, mit denen Versucht werden kann, Code zu finden, den Sie debuggen möchten.
Imgscan kann beim EDXI-Debuggen hilfreich sein, da im Gegensatz zum herkömmlichen KDNET-basierten Kerneldebuggen das Festlegen von Haltepunkten basierend auf Symbolen möglicherweise nicht verfügbar ist. Das Auffinden eines gewünschten Zielbilds kann die Verwendung des Speicherorts erleichtern, um einen Haltepunkt für den Speicherzugriff festzulegen.
.exdicmd (EXDI-Befehl)
Die EXDICMD sendet mithilfe der aktiven EXDI-Debugverbindung einen EXDI-Befehl 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) verwendet werden.
exdiConfigData.xml : Diese Datei enthält die Standard Konfigurationsdaten, die vom GDB-Serverclient benötigt werden, um eine erfolgreiche GDB-Sitzung mit dem GDB-Serverziel des HW-Debuggers einzurichten, sodass der GDB-Serverclient nicht ausgeführt wird, wenn der Dateispeicherort nicht von der umgebungsvariablen EXDI_GDBSRV_XML_CONFIG_FILE festgelegt wird. Jedes XML-Tag ermöglicht das Konfigurieren eines bestimmten Satzes der GDB-Serverfunktionalität. Unten finden Sie eine Liste der Attribute, die Sie im XML-Code ändern können, und beispiel-XML.
Systemregister.xml : Diese Datei enthält eine Zuordnung zwischen Systemregistern und ihrem Zugriffscode. 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 in den XML-Konfigurationsdateien definierten GDBServer-Tags und -Attribute finden Sie unter Konfigurieren des EXDI-Debuggertransports.
Problembehandlung
Weitere Informationen zur Problembehandlung finden Sie unter Konfigurieren des EXDI-Debuggertransports.
Weitere Informationen
Konfigurieren des EXDI-Debuggertransports
Automatisches Einrichten des Debuggens des KDNET-Netzwerkkernels
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