Absturzabbildunterstützung – Test (LOGO)
Mit diesem Test wird überprüft, ob der Miniporttreiber für den Speicher unter Windows die Erstellung einer Speicherabbilddatei unterstützt, nachdem ein Systembeendigungsfehler auftritt.
Testdetails
| Spezifikationen |
|
| Plattformen |
|
| Unterstützte Versionen |
|
| Voraussichtliche Laufzeit (in Minuten) | 45 |
| Kategorie | Szenario |
| Zeitüberschreitung (in Minuten) | 2700 |
| Neustart erforderlich | false |
| Erfordert eine spezielle Konfiguration | true |
| Typ | automatic |
Zusätzliche Dokumentation
Tests in diesem Funktionsbereich enthalten möglicherweise zusätzliche Dokumentation, einschließlich Informationen zu Voraussetzungen, Einrichtung und Fehlerbehebung, die in den folgenden Themen zu finden sind:
- Device.Storage – Zusätzliche Dokumentation
- System.Fundamentals – Zusätzliche Dokumentation
- System.Server – Zusätzliche Dokumentation
Ausführen des Tests
Bevor Sie den Test ausführen, schließen Sie die Testeinrichtung ab, die in den Testanforderungen für den Typ von Speichercontroller beschrieben sind, den Sie testen. Weitere Informationen finden Sie unter Testen von Speicheradaptern oder -controllern – Übersicht.
Für diesen Test ist zusätzliche Software und Hardware erforderlich:
Zu testendes Gerät
Festplatte mit mindestens 20 GB verfügbarem Speicherplatz auf Partition C:.
Bevor Sie den Test ausführen, müssen außerdem die folgenden Voraussetzungen erfüllt sein:
Wenn Ihr Testsystem über eine Internetverbindung verfügt, muss keine Aktion ausgeführt werden.
Wenn Ihr Testsystem nicht über eine Internetverbindung verfügt, erstellen Sie einen Ordner namens C:\Symbols, und installieren Sie Windows-Betriebssystemsymbole. Gehen Sie hierzu folgendermaßen vor:
Hinweis
Symbole sind erforderlich, um die Sicherungsdatei zu analysieren. Die häufigste Ursache für Probleme bei diesem Test ist die fehlende Installation der Symbole. Die Version der Symbole muss mit der Version des Betriebssystems übereinstimmen, das auf dem Testcomputer installiert ist. Daher muss es extern in das Kit heruntergeladen werden.
Laden Sie auf einem Computer mit einer Internetverbindung die Windows-Symbolpakete herunter. Weitere Informationen finden Sie unter Herunterladen von Windows-Symbolpaketen.
Kopieren Sie die Symboldateien auf den Testcomputer in den Ordner C:\Symbols. Da die Symbole groß sein können, müssen Sie nur die Dateien ntkrnlmp.pdb (für x64 oder Arm) bzw. ntkrpamp.pdb (für x86) kopieren.
Problembehandlung
Informationen zur allgemeinen Problembehandlung bei HLK-Testfehlern finden Sie unter Problembehandlung bei Windows HLK-Testfehlern.
Informationen zur Problembehandlung finden Sie unter Problembehandlung bei Device.Storage-Tests.
Fehlermeldung „Fehler beim Laden der richtigen Symbole“ in den Testprotokollen
Nach dem Neustart überprüft der Test die Sicherungsdatei auf Korrektheit. Dabei wird im Test (genauso wie von Entwickler*innen) der Kerneldebugger kd verwendet (siehe Herunterladen und Installieren von Debuggingtools für Windows). Um eine Sicherungsdatei zu analysieren, benötigt der Debugger Zugriff auf Symbole (siehe Symboldateien). Dies ist ein Wörterbuch für die Sicherung. Sie ermöglichen dem Debugger, den Inhalt des Arbeitsspeichers (oder eine Absturzsicherungsdatei) in einzelnen Modulen (ausführbare Dateien, Bibliotheken, Treiber usw.), Funktionen innerhalb dieser Module und Datenstrukturen zu analysieren. Ganz allgemein gilt: Wenn Sie die Sicherungsdatei nicht mithilfe des Kerneldebuggers untersuchen können, kann der Test nicht bestanden werden.
Damit der Test ordnungsgemäß funktioniert, muss er Symbole für den Debugger bereitstellen. Wenn er nicht über die richtigen Symbole verfügt, werden während der ersten Analysephase des Tests Warnungen protokolliert. Die derzeitige Vorgehensweise besteht darin, öffentliche Symbolpakete herunterzuladen (siehe Herunterladen von Windows-Symbolpaketen) und sie vor der Testausführung auf dem Testcomputer zu installieren. Wenn die Symbole nicht installiert sind oder nicht mit dem Betriebssystem übereinstimmen, kann im Testprotokoll die folgende Meldung angezeigt werden:
(x) Fehler beim Laden der richtigen Symbole.
(i) Weitere Informationen zum Installieren von Betriebssystemsymbolen finden Sie in der WDK-Dokumentation.
(i) Ihre Symbole könnten auch veraltet sein. Aktualisieren Sie die Symbole über den Microsoft-Symbolserver.
Diese Meldung führt nicht dazu, dass der Test Fehler generiert, da in einigen Fällen die Analyse der Sicherung mit teilweise übereinstimmenden Symbolen fortgesetzt werden kann. Wenn der Test fortgesetzt und mehr Testfälle mit Nachrichten wie Fehler beim Abrufen von Adressen von ... oder Fehler beim Abrufen von ... nicht bestanden werden, bedeutet dies, dass der Debugger die Sicherung aufgrund fehlender Symbole nicht analysieren kann. Eine Möglichkeit, einzelne Symbole zu umgehen, besteht darin, das lokal installierte Symbolpaket um Symbole zu ergänzen, die von einem Internetsymbolserver zwischengespeichert wurden. Führen Sie die folgenden Schritte aus, um die Symbole lokal zwischenzuspeichern:
Vergewissern Sie sich, dass Sie bereits ein Absturzabbild erstellt haben. Dies geht am einfachsten, indem Sie den Test einmal ausführen und mit einem Fehler beenden lassen.
Vergewissern Sie sich, dass die Debuggingtools installiert sind. Auch hier besteht die einfachste Möglichkeit darin, den Test einmal auszuführen. Dabei werden die Tools in C:\Debugger installiert.
Öffnen Sie eine Eingabeaufforderung mit erhöhten Rechten.
Geben Sie folgenden Befehl ein:
c:\Debuggers\kd -z c:\Windows\MEMORY.DMP -y SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols.Dadurch wird die Sicherung in den Kerneldebugger geladen, wobei die Symbole vom Remotesymbolspeicher von Microsoft im lokalen Verzeichnis C:\Symbols als Downstreamspeicher zwischengespeichert werden.
Stellen Sie sicher, dass Symbole durch Betriebssystemdateien wie NTOSKRNL und NTDLL gefunden werden können. Diese Dateien sind für die Analyse der Sicherung erforderlich. Fehler beim Laden von Symbolen für andere Module (z. B. Drittanbietertreiber) stellen kein Problem dar.
Jetzt sollte die Eingabeaufforderung 0: kd> angezeigt werden. Geben Sie an dieser Eingabeaufforderung den Befehl .reload /f ein. Dieser Befehl erzwingt das Laden und Zwischenspeichern aller Symbole für die in der Sicherung geladenen Module durch den Debugger.
Um den Debugger zu beenden, drücken Sie STRG+B und dann die EINGABETASTE.
Fehlermeldung „Auslagerungsdatei zu klein für vollständige Sicherung“ im Testprotokoll
Im Fall eines Absturzes gibt es keine Gewissheit darüber, welche Teile des Betriebssystems noch funktionsfähig sind. Die Netzwerk- oder Dateisystemtreiber haben möglicherweise den Absturz verursacht und verhindern damit z. B. den Zugriff auf Dateisystemstrukturen, die erforderlich sind, um eine Sicherungsdatei zu erstellen, oder auf ein Netzwerk, um die Datei remote zu speichern. Das Betriebssystem verwendet in diesem Fall eine Datei, die bereits vorhanden ist (die Auslagerungsdatei), und schreibt direkt in die logischen Blockerweiterungen dieser Datei auf dem Datenträger. Während der Abbildsicherung wird der Inhalt des physischen Arbeitsspeichers in die Auslagerungsdatei auf dem Systemdatenträger geschrieben (normalerweise C:\pagefile.sys). Die Auslagerungsdatei muss groß genug zum Speichern der Abbildsicherung sein. Die größte Sicherung ist eine vollständige Sicherung. Sie erfordert die Größe des physischen Arbeitsspeichers (z. B. 4.096) sowie ein zusätzliches Megabyte für die Kopfzeileninformationen. Für den Test müssen die Benutzer*innen die Auslagerungsdatei vorab mit einer entsprechenden Größe konfigurieren. Wenn die Größe der Auslagerungsdatei nicht ausreicht, wird beim Test während der Initialisierungsphase der folgende Fehler protokolliert:
(i) Überprüfen der Größe der Auslagerungsdatei.
(x) Die Auslagerungsdatei ist zu klein für eine vollständige Abbildsicherung.
(i) Größe der Auslagerungsdatei: 330989568
(i) Größe des physischen Speichers: 1073094656
(i) Konfigurieren Sie die Auslagerungsdatei mit einer Mindestgröße von Größe des physischen Speichers + 1 MB.
Ich sehe den Systembeendigungsfehler (blauer Bildschirm), aber der Fehlerprüfcode ist nicht E2.
Nachdem einige grundlegende Einstellungen überprüft wurden, installiert der Test einen Treiber, der dazu dient, das System zum Absturz zu bringen und neu zu starten. Nach dem Neustart ändert der Test die Absturzsteuerungseinstellungen (bei einer vollständigen Sicherung), löscht alle alten Sicherungsdateien und bringt das System zum Absturz. Zum Zeitpunkt des Absturzes zeigt das System einen Fehlerüberprüfungsbildschirm (blauer Bildschirm) mit Details zum Typ des Absturzes an. Der Fehlerüberprüfungstyp sollte MANUALLY_INITIATED_CRASH (e2) lauten. Wenn etwas anderes angezeigt wird, bedeutet dies, dass während des Schreibens der Sicherungsdatei eine zweite Fehlerüberprüfung aufgetreten ist. Dies sollte untersucht werden. Verbinden Sie dazu einen Kerneldebugger mit dem Testclient, und debuggen Sie den Speicheradaptertreiber.
Beim Test wird die Fehlermeldung „Sicherungsdatei wird von einem anderen Prozess verwendet. HRESULT: 0x80070020“
Nachdem die Sicherungsdatei geschrieben wurde, sollte der Testcomputer automatisch neu gestartet werden. Bei einem Neustart nach einem Absturz erkennt das Betriebssystem die Anwesenheit von Sicherungsinformationen in der Auslagerungsdatei und beginnt mit dem Schreiben einer Abbildsicherung. Dieser Prozess wird asynchron ausgeführt, während der Computer gestartet wird und auch noch nach der Anmeldung von Benutzer*innen. Sie können während dieses Prozesses den Fortschritt anzeigen, indem Sie die Größe der Sicherungsdatei (C:\windows\memory.dmp) überprüfen oder den Prozess im Task-Manager (werfault.exe) anzeigen. Der Test wird häufig gleichzeitig mit diesem Prozess ausgeführt und versucht dabei, auf dieselbe Sicherungsdatei zuzugreifen. Wenn dies auftritt, werden die folgenden Nachrichten im Protokoll angezeigt:
(i) Herstellen einer Verbindung mit Sicherungsdatei: C:\Windows\MEMORY. DMP
(i) Sicherungsdatei wird von einem anderen Prozess verwendet. HRESULT: 0x80070020
(i) In der Regel wird aufgrund eines großen RAM noch in memory.dmp geschrieben, wiederholen Sie den Vorgang nach 5 Minuten.
Der Test sollte dann erneut versuchen, auf die Datei zuzugreifen. Wenn der Fehlermeldungscode ein anderer ist oder sich ändert (z. B. 0x80070002: ERROR_FILE_NOT_FOUND), bedeutet dies, dass die Datei nicht auf den Datenträger geschrieben werden konnte. Der erste Ort, an dem Sie nach wichtigen Debuginformationen suchen sollten, ist das Systemereignisprotokoll. Um das Ereignisprotokoll anzuzeigen, klicken Sie auf Start und anschließend auf Ausführen, und geben Sie dann Compmgmt.msc ein. Wählen Sie im Computerverwaltungsfenster die Option Computerverwaltung\Systemtools\Ereignisanzeige\System aus. Durchsuchen Sie die Liste der Ereignisse nach einem Ereignis mit der Quelle BugCheck. Die häufigste Ursache für eine fehlende Sicherungsdatei ist nicht genügend freier Speicherplatz auf dem Datenträger. Der Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CrashControl\MachineCrash enthält Informationen zum letzten Absturz (vor einem Neustart), einschließlich der Teilsicherungsdatei, sofern eine erstellt wurde. Dies kann hilfreich sein, wenn Sie versuchen, andere Probleme durch fehlende Abbildsicherungen zu debuggen.
Weitere Informationen
Ein Absturzabbild stellt den Mechanismus dar, mit dem das Betriebssystem den Speicheradaptertreiber aufruft, um den Inhalt des Speichers nach einem Systembeendigungsfehler in eine Sicherungsdatei zu schreiben. Aufgrund des Ursachen von Systembeendigungsfehlern kann das Betriebssystem keine Annahmen über die Stabilität des Systems machen. Daher stehen dem Speichertreiber nur sehr wenige Systemdienste zur Verfügung. Mit dem Test auf Unterstützung von Absturzabbildern wird überprüft, ob der Speicheradaptertreiber weiterhin unter diesen eingeschränkten Umgebungen funktioniert und die E/A-Vorgänge ausführen kann, um erfolgreich in die Sicherung zu schreiben.
Das Windows-Betriebssystem ermöglicht die Generation von drei verschiedenen Typen von Speicherabbilddateien:
Vollständig
Kernel
Mini
Bei diesem Test werden die Sicherungsdateitypen Kernel und Mini getestet. Weitere Informationen zu diesen Sicherungsdateitypen finden Sie unter Sicherungsdateien im Kernelmodus.
Bei diesem Test wird die folgende Abfolge von Vorgängen ausgeführt:
Installieren der Debuggingtools für Windows im Verzeichnis %SystemDrive%\Debuggers und Initialisieren des Systems
Installieren des Testtreibers, um einen Absturz zu simulieren
Festlegen der Größe der Auslagerungsdatei
Simulieren von Systembeendigungsfehlern (Bluescreen) mit Fehlerprüfcode 0x000000E2
Neustarten des Systems und automatisches Starten des Tests
Überprüfen Sie den vorherigen Absturz, indem Sie die Speicherabbilddatei über den Kerneldebugger analysieren und überprüfen, ob die Sicherung ordnungsgemäß geschrieben wurde.
Wiederholen Sie die Schritte 4–6 für jeden Sicherungsdateityp.
Befehlssyntax
| Befehl | Beschreibung |
|---|---|
Crashdumptest.exe -c |
Löscht alle früheren Fehler. |
crashdumptest.exe -dtm -y [SymbolsDirectory] -ypass |
Initialisiert den Test. |
crashdumptest.exe -autorun -y [SymbolsDirectory] -dtm" |
Führt den Test aus. |
Dateiliste
| Befehlsoption | Beschreibung |
|---|---|
Crashdumptest.exe |
[TestBinRoot]\nttest\driverstest\storage\wdk\ |
BugCheck.sys |
[TestBinRoot]\nttest\driverstest\storage\wdk\ |
Parameter
| Parametername | Parameterbeschreibung |
|---|---|
| DebuggerDirectory | Verzeichnis, in dem Debugger installiert werden. |
| SymbolsDirectory | Verzeichnis, in dem bereits Symbole installiert sind. |
| LLU_LclAdminUsr | Benutzerkonto zum Ausführen des Tests. |
| LLU_NetAccessOnly | Benutzerkonto für den Zugriff auf die Testdateifreigabe. |
| PagefileSize | Größe der Auslagerungsdatei in MB (unterstützt mem+N-Format) |