Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# Kernel-Debugging für Windows-Instanzen über das Netzwerk
Das KDNET Extensibility Module for Elastic Network Adapter (ENA) ist eine Schicht zur Unterstützung von Hardwaretreibern, die das Windows-Kernel-Debugging über das Netzwerk über ENA auf Amazon Elastic Compute Cloud-Instances ermöglicht. Sie können das Erweiterbarkeitsmodul mit dem Windows Debugger (WinDbg) verwenden, um Debugging auf Kernelebene auf EC2-Instances durchzuführen, auf denen Windows ausgeführt wird.
Mit dem Kernel-Debugging können Sie grundlegende Betriebssystemprobleme wie Bluescreen-Fehler (BSODs), Treiberfehler und Startprobleme auf Ihren EC2-Windows-Instances diagnostizieren und beheben.
**Topics**
+ [Voraussetzungen](#kdnet-prerequisites)
+ [Schritt 1: Installieren Sie die Windows-Debugging-Tools auf dem Debug-Host](#kdnet-step1-install-debugging-tools)
+ [Schritt 2: Richten Sie das Debug-Ziel ein](#kdnet-step2-setup-debug-target)
+ [Schritt 3: Starten Sie die Debugging-Sitzung auf dem Debug-Host](#kdnet-step3-start-debugging-session)
+ [Schritt 4: Starten Sie das Debug-Ziel neu](#kdnet-step4-reboot-debug-target)
+ [Bereinigen Sie die Debug-Einstellungen nach dem Debuggen](#kdnet-clean-up)
+ [Einschränkungen](#kdnet-limitations)
+ [Weitere Hinweise](#kdnet-additional-notes)
## Voraussetzungen
Stellen Sie vor dem Beginn sicher, dass Sie über das Folgende verfügen:
Zwei EC2-Windows-Instances im selben Subnetz:
+ Eine **Debug-Host-Instance** — führt den Windows-Debugger aus (). WinDbg
+ Eine **Debug-Zielinstanz** — die Instanz, die Sie debuggen möchten.
Weitere Informationen zum Starten von Instances finden Sie unter. [Erste Schritte mit Amazon EC2](EC2_GetStarted.md)
Sicherheitsgruppen für die Host- und Ziel-Instances müssen eingehenden und ausgehenden UDP-Verkehr auf dem Port zulassen, der für das KDNET-Debugging verwendet wird (empfohlener Bereich: 50000—50039). Die einfachste Methode, dies einzurichten, besteht darin, eine Sicherheitsgruppe mit einer eingehenden Regel zu erstellen, die UDP-Verkehr von sich selbst als Quelle zulässt, und diese Sicherheitsgruppe dann beiden Instanzen zuzuordnen. Weitere Informationen finden Sie unter [Sicherheitsgruppenregeln](https://docs.aws.amazon.com/vpc/latest/userguide/security-group-rules.html) im *Benutzerhandbuch für Amazon VPC*.
Auf der Debug-Zielinstanz muss eine der folgenden Windows-Versionen (oder höher) ausgeführt werden:
+ Windows Server 2025 mit der Buildnummer 26100.7462 (Patch vom Dezember 2025)
+ Windows 11 24H2 mit der Buildnummer 26100.7309
+ Windows 11 25H2 mit der Buildnummer 26200.7309
**Anmerkung**
Das KDNET-Erweiterungsmodul für ENA wird als Teil von Windows vertrieben und kann nur über monatliche kumulative Windows-Updates aktualisiert werden. Wir empfehlen, die neueste Windows-KB-Version auf dem Debug-Ziel zu installieren, um sicherzustellen, dass Sie über die neueste Version verfügen.
Um zu überprüfen, ob das Modul auf dem Debug-Ziel vorhanden ist, führen Sie den folgenden Befehl in einer Sitzung mit erhöhten Rechten PowerShell aus:
```
Test-Path C:\Windows\system32\kd_02_1d0f.dll
```
Wenn der Befehl zurückkehrt`True`, ist das Modul verfügbar.
## Schritt 1: Installieren Sie die Windows-Debugging-Tools auf dem Debug-Host
Installieren Sie die Windows-Debugging-Tools auf der Debug-Host-Instanz, indem Sie den folgenden Befehl in einer Sitzung ausführen: PowerShell
```
winget install microsoft.windbg
```
Ausführliche Installationsanweisungen finden [Sie in der Microsoft-Dokumentation unter Installieren des Windows-Debuggers](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/).
Stellen Sie nach der Installation sicher, dass der Debugger funktioniert, indem Sie den folgenden Befehl in einer PowerShell Sitzung ausführen:
```
windbgx
```
Das WinDbg Fenster sollte sich öffnen. Ist dies der Fall, war die Installation erfolgreich und Sie können das Fenster schließen.
## Schritt 2: Richten Sie das Debug-Ziel ein
**Anmerkung**
Wenn das Kernel-Debugging aktiv ist, ist das ENA-Gerät, das für die Debugging-Sitzung verwendet wird, nur für den Debugger-Verkehr vorgesehen. Wenn Sie während des Debuggings den Internetzugang auf der Debug-Ziel-Instance aufrechterhalten müssen, fügen Sie der Instance eine zweite ENA hinzu, bevor Sie beginnen.
Öffnen Sie auf dem Debug-Ziel eine PowerShell Sitzung mit erhöhten Rechten und konfigurieren Sie das Kernel-Debugging mithilfe der folgenden Schritte.
Führen Sie den folgenden Befehl aus, um die Bus-, Geräte- und Funktionsnummer des ENA-Adapters aufzulisten, der an die Instanz angeschlossen ist:
```
Get-NetAdapter -Physical |
Where-Object -Property PnPDeviceID -Match -Value '^PCI\\VEN_1D0F&DEV_EC2[01]&' |
Get-NetAdapterHardwareInfo |
Select-Object InterfaceDescription, BusNumber, DeviceNumber, FunctionNumber |
Format-List
```
### Wenn mehrere ENA-Adapter an die Instanz angeschlossen sind
Wenn mehrere ENA-Adapter an die Instanz angeschlossen sind, verwenden Sie den folgenden Befehl, um jeden physischen Adapter seiner privaten IP-Adresse zuzuordnen. Sie können diese Details AWS-Managementkonsole unter **EC2 → Instances → [Instance-ID] → Networking → Network** Interfaces miteinander vergleichen. Auf diese Weise können Sie bestimmte Netzwerkschnittstellen- IDs, private und Sicherheitsgruppen mit dem Adapter auf Betriebssystemebene korrelieren IPs, um gezieltes Debuggen zu ermöglichen.
```
Get-NetAdapter -Physical |
Where-Object PnPDeviceID -Match '^PCI\\VEN_1D0F&DEV_EC2[01]&' |
ForEach-Object {
$adapter = $_
$hwInfo = $adapter | Get-NetAdapterHardwareInfo
$ipInfo = Get-NetIPAddress -InterfaceIndex $adapter.InterfaceIndex -AddressFamily IPv4
[PSCustomObject]@{
InterfaceDescription = $adapter.InterfaceDescription
IPAddress = $ipInfo.IPAddress
BusNumber = $hwInfo.BusNumber
DeviceNumber = $hwInfo.DeviceNumber
FunctionNumber = $hwInfo.FunctionNumber
}
} | Format-List
```
Notieren Sie sich die `FunctionNumber` Werte `BusNumber``DeviceNumber`, und des ENA-Adapters, der für das Debuggen von der Ausgabe aus verwendet werden soll.
Führen Sie die folgenden Befehle aus, um das Kernel-Debugging zu konfigurieren. Ersetzen Sie die Platzhalterwerte durch Ihre spezifische Konfiguration:
```
bcdedit /debug on
bcdedit /set loadoptions FORCEHVTONOTSHAREDEBUGDEVICE
bcdedit /dbgsettings net hostip:host-private-ip port:port-number key:encryption-key busparams:b.d.f
```
**Anmerkung**
Prüfen Sie, ob vorhanden ist, `loadoptions` indem Sie den folgenden Befehl ausführen. Wenn ein Wert zurückgegeben wird, kopieren Sie diese Zeichenfolge und fügen Sie sie `;FORCEHVTONOTSHAREDEBUGDEVICE` an.
```
(bcdedit /enum) -match "loadoptions"
```
Wobei Folgendes gilt:
+ *host-private-ip*— Die private IPv4 Adresse der Debug-Host-Instanz. Wenn Ihre Instances IPv6 nur in einem Subnetz gestartet werden, finden Sie IPv6 in der Microsoft-Dokumentation unter [KDNET einrichten mit](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-network-debugging-connection#ipv6) weitere Informationen zur Verwendung IPv6 mit KDNET.
+ *port-number*— Der Port, der für die Debugging-Sitzung verwendet werden soll. Der empfohlene Bereich liegt zwischen 50000 und 50039 (z. B.). `50000`
+ *encryption-key*— Ein 256-Bit-Schlüssel, der zur Verschlüsselung der Debugging-Verbindung verwendet wird. Er wird als vier 64-Bit-Werte angegeben, die durch Punkte getrennt sind. Jeder 64-Bit-Wert kann bis zu 13 Zeichen lang sein, wobei nur die Kleinbuchstaben a—z und die Ziffern 0—9 verwendet werden. Sonderzeichen sind nicht zulässig. Beispiel für einen Verschlüsselungsschlüssel:. `1kdnet2keys3.4kdnet5keys6.7kdnet8keys9.10kdnet11ke`
+ *b.d.f*— Die Bus-, Geräte- und Funktionsnummern für das ENA-Gerät, formatiert als `bus.device.function` (z. B.`0.3.0`), die für das Debuggen verwendet werden.
**Tipp**
Führen Sie außerdem den folgenden Befehl aus, um den Windows-Startvorgang zu debuggen:
```
bcdedit /bootdebug on
```
## Schritt 3: Starten Sie die Debugging-Sitzung auf dem Debug-Host
Um das Debuggen von Datenverkehr auf dem Host zu ermöglichen, können Sie eine Firewallregel entweder für die WinDbg Anwendung oder einen bestimmten UDP-Port erstellen.
**Option 1: Die WinDbg Anwendung zulassen**
Führen Sie die folgenden Befehle aus, um die WinDbg ausführbare Datei zu autorisieren:
```
$WinDbgxPath = "$env:LocalAppData\Microsoft\WindowsApps\WinDbgX.exe"
New-NetFirewallRule -DisplayName "Allow Inbound KDNET Connection" -Action Allow -Program $WinDbgxPath
```
**Option 2: Erlauben Sie einen bestimmten UDP-Port**
Alternativ können Sie eingehenden UDP-Verkehr zu dem für das Kernel-Debugging konfigurierten Port zulassen. Ersetzen Sie *port-number* durch den ausgewählten KDNET-Port:
```
$DebugPort = port-number
New-NetFirewallRule -DisplayName "Allow Inbound KDNET Connection" -Direction Inbound -LocalPort $DebugPort -Protocol UDP -Action Allow
```
**Anmerkung**
Firewallkonfigurationen können durch die Domain Group Policy (GPO) eingeschränkt werden oder erfordern erhöhte Administratorrechte. Wenn der Befehl fehlschlägt, wenden Sie sich an Ihren Netzwerkadministrator.
Beginnen Sie WinDbg mit dem Port und dem Schlüssel, die der Debug-Zielkonfiguration entsprechen. Sie können je nach Anwendungsfall zusätzliche Kernel-Debugging-Optionen angeben, die in der [WinDbg Microsoft-Befehlszeilenreferenz](https://learn.microsoft.com/en-us/windows-hardware/drivers/debuggercmds/windbg-command-line-preview#kernel-options) dokumentiert sind.
```
windbgx -k net:port=port-number,key=encryption-key
```
WinDbg öffnet und wartet darauf, dass das Debug-Ziel eine Verbindung herstellt.
## Schritt 4: Starten Sie das Debug-Ziel neu
Starten Sie die Instanz auf dem Debug-Ziel neu, um die Debugging-Verbindung zu initiieren:
```
shutdown -r -t 0
```
Nach dem Neustart des Debug-Ziels stellt der Debug-Host automatisch eine Verbindung zum Ziel her. WinDbg Sie können es jetzt verwenden WinDbg , um den Kernelstatus zu überprüfen, Breakpoints zu setzen und Probleme zu diagnostizieren.
## Bereinigen Sie die Debug-Einstellungen nach dem Debuggen
**Auf dem Debug-Ziel**
Wenn Sie mit dem Debuggen fertig sind, entfernen Sie die Kernel-Debugging-Konfiguration aus dem Debug-Ziel, um das normale Startverhalten wiederherzustellen. Öffnen Sie auf dem Debug-Ziel eine PowerShell Sitzung mit erhöhten Rechten und führen Sie die folgenden Befehle aus:
```
bcdedit /debug off
bcdedit /dbgsettings LOCAL
bcdedit /deletevalue loadoptions
```
Wenn Sie bereits `loadoptions` andere als haben`FORCEHVTONOTSHAREDEBUGDEVICE`, sollten Sie die Einstellung wiederherstellen, indem Sie `bcdedit /set loadoptions` mit dem Original `loadoptions` arbeiten.
Wenn Sie das Boot-Debugging aktiviert haben, führen Sie außerdem Folgendes aus:
```
bcdedit /bootdebug off
```
Starten Sie die Instanz neu, damit die Änderungen wirksam werden.
**Auf dem Debug-Host**
Entfernen Sie die Firewallregel, indem Sie Folgendes ausführen:
```
Remove-NetFirewallRule -DisplayName "Allow Inbound KDNET Connection"
```
## Einschränkungen
Das KDNET-Erweiterbarkeitsmodul für ENA unterstützt derzeit nicht:
+ Nichtmetallische x86\$164-Instance-Typen der 8. Generation (zum Beispiel) `m8a.xlarge`
+ 48xlarge-x86\$164-Instance-Typen der 7. Generation (z. B.) `m7a.48xlarge`
+ u7i-Instanztypen
Das Modul unterstützt derzeit keine Instanzen mit aktiviertem Secure Boot. Sie können den Status überprüfen, indem Sie eine PowerShell Sitzung mit erhöhten Rechten ausführen`Confirm-SecureBootUEFI`. Wenn die Ausgabe lautet`True`, ist Secure Boot aktiv. Beachten Sie, dass für alle von Amazon bereitgestellten Images mit einem „TPM“ -Präfix Secure Boot standardmäßig aktiviert ist.
## Weitere Hinweise
Wenn beim Verbinden des Debuggers mit der Ziel-Instance Probleme auftreten, überprüfen Sie Folgendes:
+ Alle in diesem Handbuch aufgeführten Voraussetzungen sind erfüllt, einschließlich der erforderlichen Windows Server-Buildversion und des Vorhandenseins des Erweiterbarkeitsmoduls.
+ Die Sicherheitsgruppen, die beiden Instanzen zugeordnet sind, sind korrekt konfiguriert, sodass der Datenverkehr zwischen ihnen über den konfigurierten Debugging-Port möglich ist.
+ Die Windows-Firewallregeln auf den Hostinstanzen blockieren den Netzwerkverkehr zwischen den beiden Instanzen am konfigurierten Port nicht.
Weitere Hinweise finden Sie in der [Microsoft-Dokumentation unter Manuelles Einrichten des KDNET-Netzwerkkernel-Debuggings](https://learn.microsoft.com/en-us/windows-hardware/drivers/debugger/setting-up-a-network-debugging-connection).