Referenz zu Kernel-Livedumpcode
Dieser Abschnitt enthält Beschreibungen allgemeiner Kernel-Liveabbildcodes, die möglicherweise auftreten. Liveabbilder setzen das Betriebssystem nicht zurück, ermöglichen jedoch die Erfassung von Speicherinformationen für ungewöhnliche Situationen, in denen das Betriebssystem fortgesetzt werden kann.
Hinweis
Dieses Thema richtet sich an Programmierer. Wenn Sie ein Kunde sind, dessen System einen Bluescreen mit einem Fehlerprüfcode angezeigt hat, finden Sie weitere Informationen unter Behandeln von Bluescreenfehlern.
Kernel-Liveabbild im Vergleich zur Fehlerüberprüfung
Bei einer herkömmlichen Fehlerüberprüfung wird der PC zurückgesetzt, und die Arbeit des Benutzers wird unterbrochen. Das Ziel des Kernel-Liveabbilds besteht darin, Daten zu sammeln, um eine ungewöhnliche Situation zu beheben, aber dem Betriebssystem die Fortsetzung des Betriebs zu ermöglichen. Dies reduziert Ausfallzeiten im Vergleich zu einer Fehlerüberprüfung für "nicht tödliche", aber Ausfälle mit hohen Auswirkungen und Hängen. Kernel-Liveabbilder werden verwendet, wenn es möglich ist, das Betriebssystem in einen bekannten guten Zustand wiederherzustellen. Beispielsweise kann eine Hardwarezurücksetzung eines Subsystems, z. B. Video/Anzeige, USB3 oder Wi-Fi es diesen Systemen ermöglichen, in einen bekannten guten Zustand zurückzukehren, mit minimalen Auswirkungen auf den Benutzer.
Ein Kernel-Livedump erstellt eine konsistente Momentaufnahme des Kernelspeichers und speichert es in einer Dumpdatei für die zukünftige Analyse. Um die Auswirkungen auf die Leistung zu minimieren, werden Speicherkopiertechniken verwendet, um die Dumpdatei in kurzer Zeit zu erstellen. Darüber hinaus wird die Sammlung von Liveabbildern gedrosselt, sodass die Auswirkungen des Benutzers minimiert werden.
Ein Kernel-Livedump ist für eine Kategorie von Problemen wirksam, bei denen etwas lange dauert und dennoch nichts technisch fehlschlägt. Ein Watchdog-Timer kann initialisiert werden, wenn ein Vorgang gestartet wird. Wenn der Watchdog abläuft, bevor der Vorgang mit in der erwarteten Zeit abgeschlossen wird, kann ein Liveabbild des Systems erstellt werden. Anschließend kann das Dump analysiert werden, indem der Aufrufstapel und die zugehörige Wartekette für diesen Vorgang durchlaufen werden, um zu untersuchen, warum er nicht mit dem erwarteten Zeitrahmen abgeschlossen wird.
Systemprotokolle funktionieren gut, wenn etwas ausfällt und der Codebesitzer die Ursache des Fehlers aufgezeichnet hat und die Ursache identifizieren kann. Liveabbilder, die Watchdog-Timer verwenden, versuchen, Fehlerpfade abzufangen, die nicht erwartet und protokolliert wurden. Aber wie bei jedem Fehler können die Systemprotokolle andere Probleme identifizieren, die Hinweise auf die spezifische Grundursache des Fehlers geben können.
Inhalt der Kernel-Liveabbilddatei
Ähnlich wie normale Dumpdateien können Liveabbilddateien Minidumps (mit sekundären Daten) und vollständige Kernelabbilder enthalten, die auch Arbeitsspeicher im Benutzermodus enthalten können, ähnlich wie aktive Abbildbilder. Allgemeine Informationen zum Inhalt der Dumpdatei finden Sie unter Sorten von Kernel-Mode-Dumpdateien. Einige Livedumps versuchen nur, Minidumps zu erfassen, da sie für die Erfassung bestimmter hardwarebezogener Daten konzipiert sind, während andere versuchen, ein größeres Kernel-Liveabbild zu erfassen.
In Bezug auf Leistung, Dateigröße und Zuverlässigkeit von Dumperfassungen sind einige Informationen nicht enthalten, z. B. Seiten aus der Stand-by-Liste und Dateicaches.
Liveabbilddateien enthalten in der Regel Speicherseiten wie:
- KdDebuggerBlock
- Liste geladener Module
Für jeden Prozessor werden die folgenden Informationen in Kerneldumps erfasst:
- KiProcessorBlock
- PRCBs
- Aktueller Stapel
- Aktuelle Seitenverzeichnistabelle
- KI_USER_SHARED_DATA
- NTOS-Kernelimage
- HAL-Image
Weitere Informationen in Kerneldumps können sein:
- Thread-/Speicherzustand
- In-Memory-Protokollierung
Einige Liveabbilder können Prozessseiten im Benutzermodus enthalten.
Zusätzliche domänenspezifische Daten, z. B. USB-spezifische Daten für USB-Fehler, können für einige Liveabbilder enthalten sein.
Partielle Kernel-Liveabbilddatei
Eine partielle Kernel-Liveabbilddatei kann in Situationen generiert werden, in der das Liveabbild nicht zuverlässig alle beabsichtigten Speicherseiten erfassen kann. Die Informationen, die in einem Teilabbild erfasst werden, werden gefiltert und priorisiert, indem Seiten erfasst werden, die wichtige Daten enthalten, die zum Generieren eines gültigen Dumps vor anderen Seiten erforderlich sind. Für instance werden die Kernelseiten gegenüber Benutzerseiten priorisiert, wenn das Liveabbild Benutzerseiten enthält. In einigen Situationen sind nicht genügend Ressourcen verfügbar, um alle beabsichtigten optionalen Speicherseiten zu erfassen, sodass in der Dumpdatei möglicherweise Arbeitsspeicher fehlt. Die Dumpdatei sollte weiterhin vom WinDbg-Debugger erkannt werden, zeigt aber möglicherweise Fehler beim Versuch, Arbeitsspeicher abzuspeichern. Wenn der Debugger beim Versuch, Speicher an einer Adresse abzuspeichern, einen Fehler anzeigt, können Sie die Erweiterung !pte verwenden, um zu überprüfen, ob der PTE für eine Adresse gültig ist oder nicht. Dies kann helfen, zu ermitteln, ob die Speicheradresse wirklich ungültig ist oder ob die Seite gültig ist, aber einfach nicht in der Dumpdatei verfügbar ist.
Analysieren von Liveabbilddateien
Wenn ein Liveabbild auftritt, kann die Dumpdatei mit den gleichen Techniken analysiert werden, die für andere Speicherabbilddateien verwendet werden. Um den Inhalt des Arbeitsspeichers während eines Fehlers zu verstehen, sind Kenntnisse über Prozessorspeicherregister und Assemblyprogrammierung erforderlich.
Weitere Informationen finden Sie unter
Verwenden von WinDbg zum Anzeigen von Livedump-Stoppcodeinformationen
Wenn in diesem Thema kein bestimmter Liveabbildcode angezeigt wird, verwenden Sie die Erweiterung !analyze im Windows-Debugger (WinDbg) mit der folgenden Syntax (im Kernelmodus), und <code> ersetzen Sie durch einen Liveabbildcode:
!analyze -show <code>
Wenn Sie diesen Befehl eingeben, zeigt WinDbg Informationen zum angegebenen Liveabbildcode an. Wenn Ihre Standardnummernbasis (Radix) nicht 16 ist, wird das Präfix <code>0x verwendet.
Stellen Sie die Livedumpcodeparameter für den Befehl !analyze bereit, um alle verfügbaren Parameterinformationen anzuzeigen. Verwenden !analyze -show 0x144 0x3003 Sie z. B. wie hier gezeigt, um Informationen zur Fehlerüberprüfung 0x144 BUGCODE_USB3_DRIVER mit dem Parameter 1-Wert 0x3003 anzuzeigen.
0: kd> !analyze -show 0x144 0x3003
BUGCODE_USB3_DRIVER (144)
This bugcheck usually happens when the USB3 core stack detects an invalid
operation being performed by a USB client. This bugcheck may also occur
due to hardware failure on a USB Boot Device.
Arguments:
Arg1: 0000000000003003, USB3_WER_BUGCODE_USBHUB3_DEVICE_ENUMERATION_FAILURE
A USB device failed enumeration.
Arg2: 0000000000000000, USBHUB3_LIVEDUMP_CONTEXT
Arg3: 0000000000000000, 0
Arg4: 0000000000000000, 0
Informationen zum Herunterladen von WinDbg finden Sie unter Debuggen von Tools für Windows. Weitere Informationen zu den WinDbg-Entwicklungstools finden Sie unter Erste Schritte mit Windows-Debugging.
Speicherorte der Liveabbilddatei
Die Liveabbilder werden standardmäßig im Verzeichnis "C:\WINDOWS\LiveKernelReports" gespeichert.
Vollständige Dumps: %systemroot%\LiveKernelReports\*.dmp
Minidumps: %systemroot%\LiveKernelReports\<ComponentName>\*.dmp
Eine Verzeichnisstruktur wird verwendet, um Liveabbilder für verschiedene Komponenten zu speichern.
NDIS
PDCRevocation
PoW32kWatchdog
USBHUB3
WATCHDOG
Liveabbildregistrierungsschlüssel
Weitere Informationen zu Konfigurationsoptionen für vom System generierte Live-Kernelberichte finden Sie unter WER-Einstellungen.
Verwenden von PowerShell zum manuellen Auslösen eines Liveabbilds
Öffnen Und Administrator PowerShell-Eingabeaufforderung.
Rufen Sie den Anzeigenamen StorageSubsystem mithilfe des PowerShell-Befehls Get-StorageSubSystem ab .
C:\> Get-StorageSubSystem
FriendlyName HealthStatus OperationalStatus
------------ ------------ -----------------
Windows Storage on 10-2411-PC Healthy OK
- Verwenden Sie Get-StorageDiagnosticInfo, um ein Livedump für das obige Subsystem (zusammen mit anderen Diagnoseprotokollen) zu generieren. Weitere Informationen finden Sie unter Get-StorageDiagnosticInfo.
C:\> Get-StorageDiagnosticInfo -StorageSubSystemFriendlyName "Windows Storage on 10-2411-PC" -IncludeLiveDump -DestinationPath C:\destinationfolder
- Die Ausgabe gibt an, dass die angeforderten Informationen generiert werden.
Gathering storage subsystem diagnostic information
Running
[oooooooooooo ]
- Das Dump befindet sich in
[DestinationPath]\localhost.
C:\> dir C:\destinationfolder\localhost\*.dmp
Directory: C:\destinationfolder\localhost
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 5/5/2016 1:08 PM 867135488 LiveDump.dmp
- Wenn Sie den Debugger zum Ausführen von !analyze für die Dumpdatei verwenden, wird angegeben, dass es sich um einen Livedumpcode von LIVE_SYSTEM_DUMP (161) handelt.
Kernel-Liveabbildcodes
Die folgende Tabelle enthält Links zu Kernel-Livedumpcodes.
Diese Stoppcodes können für Liveabbilder oder zur Fehlerüberprüfung des Geräts verwendet werden.
| Code | Name |
|---|---|
| 0x00000124 | WHEA_UNCORRECTABLE_ERROR |
| 0x00000144 | BUGCODE_USB3_DRIVER |
| 0x00000164 | WIN32K_CRITICAL_FAILURE |
Weitere Informationen
Bug Check Code Reference (Referenz zu Fehlerüberprüfungscodes)
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