simpel1970
Lötkolbengott/-göttin
Nachdem ich bereits ein Mini-HowTo (schön versteckt in einem Thread) erstellt und hin und wieder gepflegt habe (BlueScreen wie jetzt weiter), wollte ich nun endlich mal ein etwas ausführlicheres HowTo anbieten, um euch eine detailliertere Hilfestellung für die Problemanalyse an die Hand zu geben. Für Anregungen bin ich dankbar, ein Diskussionsthread zu diesem HowTo ist ebenfalls vorhanden ([HowTo] Bluescreen auswerten - Diskussionsthread).
Inhaltsverzeichnis:
-Vorbereitung: Erweiterte Systemeinstellungen
-Das Handwerkszeug: Was brauche ich für die Auswertung
-Erste Schritte zur Auswertung
-Deutung der Bluescreens
-Hilfreiche Webseiten
-Alternative Auswertungstools
-Eigenen Problem-Thread erstellen
-Dump Dateien hochladen
-Terminologie
-Nützliche Debugging Befehle
-Auswertungsbeispiele
-Auswertungsbeispiele aus der Community
Vorbereitung: Erweiterte Systemeinstellungen
Bei Bluescreens werden -je nach Einstellung in den erweiterten Systemeinstellungen- Dump Dateien geschrieben.
Diese können mittels den Debugging Tools von Microsoft ausgewertet werden. Wenn der/die Bluescreen(s) durch Treiberprobleme verursacht wurden, ist die Auswertung mit dem Debugger eine gute Möglichkeit dem Problem auf die Schliche zu kommen.
Die "erweiterten Systemeinstellungen" findet ihr über die Systemsteuerung -> System und Sicherheit -> System -> Erweiterte Systemeinstellungen. Ein Klick auf die "Erweiterte Systemeinstellungen" öffnet das Fenster mit den Systemeigenschaften. Das Fenster hat mehrere Registerkarte und man befindet sich direkt auf der Registerkarte "Erweitert". Diese Registerkarte ist in drei Bereiche aufgeteilt. Im unteren Bereich "Starten und Wiederherstellen" auf den Button "Einstellungen" klicken.
Nun befindet ihr Euch dort, wo dem Betriebssystem mitgeteilt werden kann, was es bei Systemfehlern machen soll. Es gibt zwei Optionskästchen:
- Ereignis in das Systemprotokoll eintragen (damit ist das Ereignisprotokoll gemeint; dieses Kästchen sollte markiert sein)
- Automatischen Neustart durchführen (dieses Kästchen sollte deaktiviert sein, wenn man den Bluescreen auch mal zu Gesicht bekommen will).
Weiter unten befindet sich die wichtigere Einstellung, nämlich ob, wie und wo die Dumps gespeichert werden sollen.
Unter "Debuginformationen speichern" stehen verschiedene Einstellungen zur Verfügung (je nach Betriebssystem können auch weitere "Misch-Einstellungen" daneben stehen):
a. "Kein" (es wird keine Dump gespeichert; somit steht uns auch keine Dump für eine Auswertung zur Verfügung)
b. "kleines Speicherabbild" (das ist die Minidump. Diese beinhaltet die geladenen Treiber, Module und den Stack-Verlauf, der für die Auswertung von Bedeutung ist. Die Minidump ist, wie der Name bereits andeutet nur wenige hundert kb groß und ist für die meisten Auswertungen ausreichend)
c. "Kernelspeicherabbild" (das Kernelspeicherabbild enthält den vom Kernel belegten Speicher während des Absturzes. Das Kernelspeicherabbild ist für Auswertungen grundsätzlich geeigneter als das kleine Speicherabbild und auch deutlich kleiner als das vollständige Speicherabbild. Das Kernelspeicherabbild kann eine größe von ~150MB bis 2GB haben.)
d. "vollständiges Speicherabbild" (das ist alles drin, was ein Programmierer zum auffinden von Problemen seines Programms/Treibers benötigt. Wir (Normaluser/Anwender) benötigen aber die meisten darin enthaltenen Informationen nicht. Zudem wird in die vollständigen Dump der komplette Arbeitsspeicher geschrieben und kann somit mehrere GB groß werden)
e. "automatisches Speicherabbild" (ab Windows 8: https://msdn.microsoft.com/en-us/library/windows/hardware/dn383663(v=vs.85).aspx)
Wir wählen also b. das "kleine Speicherabbild" aus. In den Fällen, in denen die Minidump nicht ausreicht, bzw. optimaler Weise wählen wir c. das "Kernelspeicherbbild" aus.
Hier noch eine Übersicht über die verschiedenen Speicherabbilder: https://support.microsoft.com/de-de/kb/254649/de
Eine Zeile darunter finden wir den Ort, an dem Windows die Dumps abspeichert. Die Einstellung wird automatisch - je nach Einstellung - verändert. So ist bei dem "kleinen Speicherabbild" der Speicherpfad C:\Windows\Minidumps (%SystemRoot%Minidump) und beim Kernelspeicherabbild oder vollständigen Speicherabbild automatisch C:\Windows (%SystemRoot%MEMORY.DMP) hinterlegt. Dies kann grundsätzlich auch so belassen werden.
Das Verzeichnis C:\Windows\Minidump wird vom System automatisch angelegt, sobald eine Minidump geschrieben wird.
Bei Kernelspeicherabbilder oder vollständigen Speicherabbildern kann es ratsam sein (insbes. wenn diese nicht beim nächsten Absturz überschrieben werden sollen), dass man einen anderen Speicherort (auf einer größeren Festplatte) wählt.
Damit kommen wir auch zum letzten Punkt, nämlich zum Optionskästchen "vorhandene Datei überschreiben". Während beim Minidump diese Option ausgegraut ist, ist für das Kernelspeicherabbild und das vollständige Speicherabbild die Option verfügbar. Wenn ihr euch die Dumps auf eine größere Festplatte kopiert (oder direkt dort anlegen lässt), macht es Sinn -zumindest solange das Problem nicht gelöst ist- die Dateien nicht überschreiben zu lassen. Insofern sollte der Haken rausgemacht werden. Beachtet aber, dass bei wenig freien Speicher, die Festplatte schnell voll sein kann.
Mehr muss nicht eingestellt werden.
Falls trotz dieser Einstellungen keine Dumps geschrieben werden, solltet ihr nachsehen, ob die Auslagerungsdatei (Pagefile.sys) aktiviert ist und vom System verwaltet wird.
Solltet ihr nicht wissen, wo man das einstellt: Windows 7 - Größe der Auslagerungsdatei unter Windows 7 einstellen (im letzten Schritt natürlich die Option "Größe wird vom System verwaltet" aktivieren).
(Darstellung kann je nach Betriebssystem abweichen)
Das Handwerkszeug - Was brauche ich für die Auswertung
Um die Dumps auszuwerten, braucht man zunächst die Debugging Tools für Windows, welche im SDK Paket enthalten sind: Debugging Tools for Windows 10 (->Download the Installer). Die Version gilt für Win7 bis Win10
Während der Installation in der Komponentenauswahl nur die Debugging tools auswählen (siehe Bild). Mehr Tools sind für die Auswertung grundsätzlich nicht erforderlich. Je nach dem benötigt man mit Win7/Win8 Betriebssystemen (für die SDK Installation) noch das .net Framework 4.5.
(Darstellung kann je nach Betriebssystem abweichen)
Nach der Installation findet man im Programmverzeichnis (Programme -> Windows Kits) die Debugging Tools sowohl in der 32-bit, als auch in der 64-bit Version vor.
Unter Win8.x kann auch im ModernUI ("Metro"), bzw. unter Win10 im Startmenü "windbg" eingegeben werden, worauf als Suchergebnis die x86 und die x64 Versionen angezeigt werden. Entsprechend des Betriebssystems (32- oder 64-bit) auf dem die Dumps ausgewertet werden, startet man nun die entsprechende Version des Debuggers. Die windbg.exe muss mit Administrator-Rechten ausgeführt werden (am besten generell den Debugger mit der rechten Maustaste anklicken und im Kontext Menü "...als Administrator ausführen" auswählen).
Erste Schritte zur Auswertung
Sobald der Debugger gestartet wurde zeigt er sich zunächst mit einer unscheinbaren Grafikoberfläche:
Als nächstes ist es für die Auswertung wichtig, dass der Debugger Informationen über die installierten Treiber sammeln kann (die Informationen werden "Symbole" genannt).
Der nächste Schritt vor der eigentlichen Auswertung ist daher unter dem Menüpunkt "Files" -> "Symbol File Path" dem Debugger zu sagen, wo er die Symbole (Treiberinformationen) herbekommt. Eine praktische Lösung ist es den Debugger nur die Symbole (automatisch) zukommen zu lassen, die für diese Debugging Sitzung notwendig sind. Dazu einfach beim "Symbol File Path" in das kleine Fenster folgenden Befehl eingeben (paste©):
"SRV*C:\symbols*https://msdl.microsoft.com/download/symbols" (ohne "")
und OK drücken. Jetzt können alle notwendigen Informationen zum Debuggen direkt vom Microsoft Symbolserver geladen werden, das geschieht automatisch, benötigt aber eine bestehende Internet-Verbindung (alternativ können auch die kompletten Symbol-Dateien heruntergeladen werden: Herunterladen von Windows-Symbolpaketen. Die Einstellung im Symbol File Path muss dann entsprechend dem Ordnerpfad eingestellt werden in dem die Symbole entpackt werden (z.B. "C:\Symbols"). Um den Symbolpfad nicht bei jedem Start des Debuggers erneut eingeben zu müssen nochmals auf "Files" klicken und anschließend "Save Workspace" auswählen.
Anschließend über Files, das Speicherabbild für den Debugger öffnen: Files -> Open Crash Dump (Tastankombination: STRG + D)
Die Dump Datei auswählen und öffnen.
Hierbei ist entscheidend, welche Art von Debuginformationen in den erweiterten Systemeinstellungen hinterlegt sind.
Speicherpfad der dmp Datei (Kernelspeicherabbild, oder vollständiges Kernelspeicherabbild) ist C:\Windows -> "MEMORY.dmp".
Speicherpfad der Minidumps ist C:\Windows\Minidump -> "Minixxxxxx-xx.dmp"
Bei einer Abfrage ob die Informationen für die "Workspace" gespeichert werden sollen, merkt sich in diesem Schritt der Debugger (falls ihr "ja" auswählt) den Speicherpfad der Dump Datei. Beim nächsten arbeiten mit dem Debugger wählt er als Speicherpfad den eben gewählten Zielpfad aus. Sofern diese Abfrage nicht erscheint und ihr den Speicherpfad dennoch dauerhaft abspeichern möchtet, könnt ihr das über "Files" -> "Save Workspace" machen. (Hintergrund: Bei jedem Start lädt der Debugger eine "Default Workspace". Diese beinhaltet insbes. Einstellungen für den Symbolpfad, Imagepfad, Logfile Einstellungen, des weiteren noch Verbindungseinstellungen für Remote Debugging Sessins, etc. Über "Save Workspace" könnt ihr diese "Default"-Einstellungen anpassen.)
Nach dem die Dump geladen wurde sammelt der Debugger zunächst verschiedene Informationen über installierte Patches, SPs, Treiber, etc. Dies macht der Debugger eigenständig...einfach warten. Nachdem dieser Schritt erledigt wurde zeigt sich dieses Bild:
Im oberen Bereich (Markierung 1) kann man Informationen über die Debugger Version, Speicherpfad der Dump Datei, Symbolpfad und die Betriebssystemversion entnehmen.
Im mittleren Bereich (Markierung 2) ist eine erste Darstellung des Bluescreens (Bugcheckcode und mögliche Fehlerursache). Diese Informationen werden auch durch andere Tools (Bluescreenview, etc.) angezeigt. Im Gegensatz zu diesen Tools steigen wir mit dem Debugger nun aber jetzt erst richtig in die Auswertung ein.
Im unteren Bereich (Markierung 3) ist die Kommandozeile. Hier werden spezielle Debuggingbefehle eingegeben.
Für eine normale Auswertung reicht hier regelmäßig der Befehl "!analyze –v". Diesen können wir (ohne "") in die Kommandozeile eingeben und anschließend die ENTER Taste drücken. "Können" deswegen, da man sich dies auch sparen kann. Im Markierten Bereich 2 ist dieser Befehl bereits vorgegeben. Ich brauche also nur auf das mit blauer Schrift und unterstrichene !analyze -v klicken und der Debugger übernimmt den Befehl.
Der Debugger werkelt dann etwas (manchmal auch etwas länger - solange in der Kommandozeile "Busy" zu lesen ist einfach abwarten) und nach kurzer Zeit wird als Ausgabe u.a. eine Zuweisung der Datei, die den Bluescreens hervorgerufen hat, gegeben.
Dies sieht dann z.B. so aus:
Die Bereiche, an denen man den für den Absturz verantwortlichen Treiber erkennt, habe ich Fett markiert. Zunächst sind das die Zeilen "IMAGE_NAME" und "FAILURE_BUCKET_ID".
Ein ebenso wichtiger Bereich ist der Stack Verlauf "STACK_TEXT", da hier der Absturzverlauf angezeigt wird (in diesem Beispiel ist nur ein Eintrag vorhanden, hier können aber mehrere Zeilen dargestellt werden). Im Stack Verlauf kann schrittweise nachvollzogen werden, wie der Fehler aufgetreten ist und welche Treiber oder Systemprozesse möglicherweise den Absturz mit beeinflusst haben.
Im oben gezeigten Beispiel wurde der Bluescreen durch den Grafikkartentreiber (atikmdag.sys) ausgelöst.
Sitzung des Debuggers beenden: Gebt in die Kommandozeile "q" (ohne "") ein, um die Sitzung zu beenden und bevor ihr eine andere Dump in den Debugger laden wollt.
Diesen Auswertungstext könnt ihr für Euren eigenen Problemthread benutzen (siehe "Eigenen Problem-Thread" erstellen).
Um den Text aus dem Debugger kopieren zu können, müsst ihr zunächst den entsprechenden Textbereich markieren und anschließend mit der Tastenkombination STRG + C in die Zwischenablage kopieren (das Kontextmenü ist im Debugger nicht vorhanden). Anschließend kann der kopierte Text in den Thread eingefügt werden.
Deutung der Bluescreens
An welchen Stellen der Auswertung der fehlerhafte Treiber ausgemacht werden kann, habe ich ja bereits im letzten Absatz erläutert. Hier sind aber mitunter ein paar Dinge zu beachten:
1. Werden Microsoft eigene Treiber als Absturzursache benannt, liegt das Problem in den seltensten Fällen tatsächlich an einem Treiberproblem. Ein Hardwareproblem wäre in diesem Fall wahrscheinlicher. Um die Systemintegrität der Windows-Treiber zu überprüfen kann aber dennoch das Tool sfc.exe gesartet weren (Eingabeaufforderung als Admin starten und "sfc /scannow" (ohne "") eingeben.
2. Man sollte sich nie auf nur eine Dump Auswertung verlassen. Nur die Auswertung mehrerer Dumps zeigt, ob sich das Problem wiederholt, oder ob bei jeder Dump ein anderer BugCheckCode angezeigt wird und auch die Absturzursachen variieren. Bei einem solchen Szenario ist das Problem regelmäßig bei der Hardware zu suchen.
3. Ganz wichtig ist natürlich auch das System ohne Übertaktung laufen zu lassen. Die Auswertung einer Dump, die durch fehlerhafte bzw. nicht stabile Übertaktung hervorgerufen wurde ist kurz gesagt verschwendete Zeit. Dennoch kann man auch bei einer instabilen Übertaktung aus den Stopfehlercodes die ungefähre Ursache deuten: Common BSOD Error Code List for Overclocking - Overclock.net Community
4. Der NT STATUS Code: Der Stopfehlercode des Bluescreens besteht nicht nur aus Bug Check Code allein, sondern es werden zusätzlich Parameter (Arguments) angezeigt. Das sind bei einem Bluescreen die Werte, die in den Klammern stehen. In der oben geposteten Auswertung werden die Arguments separat aufgelistet:
Arg1 (0xC0000005) steht in diesem Beispiel für ein NT STATUS Code, nämlich "STATUS_ACCESS_VIOLATION". In der weiter unten verlinkten Liste der NT STATUS Codes werden diese Codes noch etwas umschrieben: "The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s." Der Code 0xC0000005 beschreibt also eine Speicherzugriffsverletzung.
Bei welchen Stopfehlercodes NT STATUS Codes (und an welcher Stelle) angezeigt werden, könnt ihr dem jeweiligen Stopfehlercode aus der unten verlinkten Übersicht (siehe hilfreiche Webseiten -> Microsoft Übersicht Stopfehlercodes) entnehmen.
Noch ein Beispiel dazu: 0x7A: KERNEL_DATA_INPAGE_ERROR. Der NT Status Code (error status) wird im 2. Parameter (Argument) angezeigt.
Für gewöhnlich treten bei diesem Stopfehlercode folgende NT Status Codes auf:
Anhand der Erläuterungen kann die Absturzursache durch die NT STATUS Codes weiter eingegrenzt, oder sogar zielgenau identifiziert werden.
5. Den Stack-Verlauf (Stack_Text) immer mit berücksichtigen. Der Stack-Verlauf ist mit das Wichtigste bei der Bluescreenauswertung und kann für die Fehlerfindung sehr hilfreich sein. Die zeitliche Reihenfolge des Verlaufs ist absteigend (der oberste Eintrag ist das zeitlich letzte Ereignis, der Unterste das erste Ereignis im Ablauf).
Bei den Auswertungsbeispielen habe ich einen Fall (Stop 0x7F, 0x08) dokumentiert, bei dem dies gut veranschaulicht wird.
6. Auch das Debugging Tool kann keine Wunder vollbringen, sprich in jedem Fall zu einer befriedigenden Lösung beitragen. Insbes. bei hardwarebedingten Fehlern (z.B. Kompatibilitätsprobleme, Hardwaredefekte) kommt das Tool an seine Grenzen.
Auch ist die Dump Datei nur eine Momentaufnahme des Absturzhergangs. Es kann in Einzelfällen durchaus vorkommen, dass auch bei vorliegenden Treiberproblemen, diese durch die Auswertung nicht nachvollziehbar sind. Um ein Treiberproblem in solchen Fällen ausschließen zu können, bietet das Betriebssystem das Tool "Driver Verifier". Der Driver Verifier ist kurz gesagt ein Stresstest um fehlerhafte Treiber ausfindig zu machen. Wird ein fehlerhaft arbeitender Treiber von Verifier erkannt, wird umgehend ein Bluescreen (Stop 0xC4 Fehler) ausgegeben und eine Dump Datei angelegt. Hier kommt nun wieder der Debugger zum Einsatz, mit dem man den Treiber genannt bekommt (auch hier ist aber Ziff. 2 dieses Kapitels zu beachten: mehrere Dumps auswerten).
Mit diesem Tool sollte grundsätzlich vorsichtig umgegangen werden, da es das Betriebssystem lahm legen, bzw. im ungünstigsten Fall nicht mehr gebootet werden kann. In diesem "Worst Case" muss der Driver Verifier im abgesicherten Modus deaktivert werden; zur Sicherheit ist es aber ratsam vor der Aktivierung des Verifiers einen Wiederherstellungspunkt zu erstellen. Näheres über die Anwendung des Verifiers kann hier nachgelesen werden: Driver Verifier (Windows Drivers)
Wenn die Arbeit des Verifiers nicht mehr benötigt wird, ist dieser wieder manuell zu deaktivieren, da er auch nach einem Neustart immer noch aktiv ist. Zum deaktivieren reicht es in die Eingabeaufforderung "verifier.exe /reset" einzugeben (ohne "").
Eigenen Problem-Thread erstellen
Eins vorweg... falls ihr meine Hilfe benötigt, könnt ihr mich gerne über PN (persönliche Nachrichten, etc) kontaktieren; Hilfestellung und Beratung erfolgt aber ausschließlich über Threads. Hier im Forum gibt es reihenweise versierte Nutzer, die Euch bei Problemen helfen können. Viele sind auf bestimmte Bereiche spezialisiert. Es ist daher -für Euch selbst- enorm hilfreich, wenn ihr einen eigenen Thread aufmacht, um das Wissen der gesamten Community abfragen zu können.
Wenn ihr nun alles gemacht habt und mit den Resultaten dennoch nicht klar kommt, oder sich das Problem nicht lösen lässt, oder euch der Weg über den Debugger zu umständlich ist, erstellt bitte euren eigenen Thread. Hierfür gibt es bei PCGH zwei Bereiche (Unterforen), die sich anbieten:
- Komplette Rechner: Praxisprobleme, oder
- Windows 7, Windows 8, Windows allgemein
In dem erstellten Thread postet ihr erst mal die komplette Hardware, die sich in oder an eurem PC befindet. Des weiteren könnt ihr Screenshots hinzufügen von Tools, die weitere Auskünfte über eure Hardware bieten. Diese sind insbes.:
Verliert auch noch ein paar Worte, ob euch bei den Abstürzen Regelmäßigkeiten aufgefallen sind. Ob die Bluescreens bei bestimmten Aktionen auftreten (nur beim Spielen, nur bei Flash-Videos, nach dem Standby, etc).
Insbes. auch, ob die Probleme schon seit bestehen des Computers auftreten, oder sich erst seit Kurzem bemerkbar gemacht haben. In diesem Fall auch benennen, was ihr am System verändert habt (andere Hardware, neue Treiber, neue Software, etc).
Habt ihr den Thread erstellt, könnt ihr mir über PN gerne einen Link zu dem Thread schicken, wenn ihr meine Hilfe bei der Auswertung benötigt.
Dump Dateien hochladen
Insbesondere, wenn ihr euch das ganze Tutorial nicht antun möchtet, oder aber mit der Auswertung nicht klarkommt, könnt ihr die Auswertung der Community überlassen. Hierfür müsst ihr jedoch auch die Dump Dateien zur Verfügung stellen. Ihr habt dabei mehrere Möglichkeiten dies zu tun.
Bei Minidumps: Wechselt in das Minidump-Verzeichnis und kopiert die Dump Dateien auf den Desktop (anderes Verzeichnis ist auch möglich, Hauptsache nicht in dem Windows Systemordner belassen).
Die kopierten Dateien nun im ZIP Format einpacken (z.B. mit WinZIP oder 7-ZIP). Sind die Dateien noch in einem Windows Systemordner kann hierbei nun ein Zugriffsproblem auftreten (deswegen vorher in ein Nicht-Windows-Verzeichnis kopieren).
Die gezippten Dateien können nun hier im Forum wie ein Bild hochgeladen werden: [How To] Bilderupload im Forum - Version 2.1
Bei vollständigen Dump-Dateien (MEMORY.DMP): Diese sind zu groß, um sie direkt hier im Forum einbinden zu können. Darum können diese nur über Filehoster (bzw. einem Link dorthin) der Community angeboten werden.
Meine große Bitte ist, dass ihr nicht irgendwelche Werbeverseuchten 08/15 Filehoster auswählt, sondern solche Anbieter wählt, bei denen man einfach und schnell die Dateien herunterladen kann. Dazu gehören insbes. Anbieter wie Dropbox, OneDrive, GoogleDrive, etc.
Terminologie
BSOD = Bluescreen of Death
BugCheckCode = Stopfehlercode des Bluescreens (z.B. STOP 0x0000000A: IRQL_NOT_LESS_OR_EQUAL).
Dump Datei = hierbei handelt es sich um den (absturzrelevanten) Inhalt des Arbeitsspeichers, der auf die Systemplatte geschrieben wird (in der Dump werden keine vertraulichen Daten, Bilder, Passwörter, etc. gespeichert!).
Debugging Tools = Werkzeug (Tool) zum Diagnostizieren und Auffinden von Fehlern.
Symbole (Debugsymbols) = Informationen über Dateien (Treiber, DLLs, etc.) wie z. B. Variablennamen, Namen von Prozeduren und Funktionen.
(wird noch ergänzt)
Zum Schluß möchte ich noch ein Dankeschön an PCGH_Stephan aussprechen; ohne seine Anregung wäre dieses HowTo vermutlich nie entstanden.
Änderungen im HowTo:
30.09.2014: [HowTo] Bluescreen auswerten - Diskussionsthread
16.06.2015: Auswahl Debuginformationen aktualisiert
30.08.2015: Infos für Win10 ergänzt
23.02.1016: Links im Kapitel "Das Handwerkszeug" angepasst
17.03.2016: Download Links im Kapitel "Eigenen Thread erstellen" angepasst
21.03.2016: Links im Kapitel "hilfreiche Webseiten" ergänzt
06.11.2016: Adresse Symbol-Server aktualisiert
18-09-2018: Links im Kapitel"Das Handwerkszeug..." angepasst
Inhaltsverzeichnis:
-Vorbereitung: Erweiterte Systemeinstellungen
-Das Handwerkszeug: Was brauche ich für die Auswertung
-Erste Schritte zur Auswertung
-Deutung der Bluescreens
-Hilfreiche Webseiten
-Alternative Auswertungstools
-Eigenen Problem-Thread erstellen
-Dump Dateien hochladen
-Terminologie
-Nützliche Debugging Befehle
-Auswertungsbeispiele
-Auswertungsbeispiele aus der Community
Vorbereitung: Erweiterte Systemeinstellungen
Bei Bluescreens werden -je nach Einstellung in den erweiterten Systemeinstellungen- Dump Dateien geschrieben.
Diese können mittels den Debugging Tools von Microsoft ausgewertet werden. Wenn der/die Bluescreen(s) durch Treiberprobleme verursacht wurden, ist die Auswertung mit dem Debugger eine gute Möglichkeit dem Problem auf die Schliche zu kommen.
Die "erweiterten Systemeinstellungen" findet ihr über die Systemsteuerung -> System und Sicherheit -> System -> Erweiterte Systemeinstellungen. Ein Klick auf die "Erweiterte Systemeinstellungen" öffnet das Fenster mit den Systemeigenschaften. Das Fenster hat mehrere Registerkarte und man befindet sich direkt auf der Registerkarte "Erweitert". Diese Registerkarte ist in drei Bereiche aufgeteilt. Im unteren Bereich "Starten und Wiederherstellen" auf den Button "Einstellungen" klicken.
Nun befindet ihr Euch dort, wo dem Betriebssystem mitgeteilt werden kann, was es bei Systemfehlern machen soll. Es gibt zwei Optionskästchen:
- Ereignis in das Systemprotokoll eintragen (damit ist das Ereignisprotokoll gemeint; dieses Kästchen sollte markiert sein)
- Automatischen Neustart durchführen (dieses Kästchen sollte deaktiviert sein, wenn man den Bluescreen auch mal zu Gesicht bekommen will).
Weiter unten befindet sich die wichtigere Einstellung, nämlich ob, wie und wo die Dumps gespeichert werden sollen.
Unter "Debuginformationen speichern" stehen verschiedene Einstellungen zur Verfügung (je nach Betriebssystem können auch weitere "Misch-Einstellungen" daneben stehen):
a. "Kein" (es wird keine Dump gespeichert; somit steht uns auch keine Dump für eine Auswertung zur Verfügung)
b. "kleines Speicherabbild" (das ist die Minidump. Diese beinhaltet die geladenen Treiber, Module und den Stack-Verlauf, der für die Auswertung von Bedeutung ist. Die Minidump ist, wie der Name bereits andeutet nur wenige hundert kb groß und ist für die meisten Auswertungen ausreichend)
c. "Kernelspeicherabbild" (das Kernelspeicherabbild enthält den vom Kernel belegten Speicher während des Absturzes. Das Kernelspeicherabbild ist für Auswertungen grundsätzlich geeigneter als das kleine Speicherabbild und auch deutlich kleiner als das vollständige Speicherabbild. Das Kernelspeicherabbild kann eine größe von ~150MB bis 2GB haben.)
d. "vollständiges Speicherabbild" (das ist alles drin, was ein Programmierer zum auffinden von Problemen seines Programms/Treibers benötigt. Wir (Normaluser/Anwender) benötigen aber die meisten darin enthaltenen Informationen nicht. Zudem wird in die vollständigen Dump der komplette Arbeitsspeicher geschrieben und kann somit mehrere GB groß werden)
e. "automatisches Speicherabbild" (ab Windows 8: https://msdn.microsoft.com/en-us/library/windows/hardware/dn383663(v=vs.85).aspx)
Wir wählen also b. das "kleine Speicherabbild" aus. In den Fällen, in denen die Minidump nicht ausreicht, bzw. optimaler Weise wählen wir c. das "Kernelspeicherbbild" aus.
Hier noch eine Übersicht über die verschiedenen Speicherabbilder: https://support.microsoft.com/de-de/kb/254649/de
Eine Zeile darunter finden wir den Ort, an dem Windows die Dumps abspeichert. Die Einstellung wird automatisch - je nach Einstellung - verändert. So ist bei dem "kleinen Speicherabbild" der Speicherpfad C:\Windows\Minidumps (%SystemRoot%Minidump) und beim Kernelspeicherabbild oder vollständigen Speicherabbild automatisch C:\Windows (%SystemRoot%MEMORY.DMP) hinterlegt. Dies kann grundsätzlich auch so belassen werden.
Das Verzeichnis C:\Windows\Minidump wird vom System automatisch angelegt, sobald eine Minidump geschrieben wird.
Bei Kernelspeicherabbilder oder vollständigen Speicherabbildern kann es ratsam sein (insbes. wenn diese nicht beim nächsten Absturz überschrieben werden sollen), dass man einen anderen Speicherort (auf einer größeren Festplatte) wählt.
Damit kommen wir auch zum letzten Punkt, nämlich zum Optionskästchen "vorhandene Datei überschreiben". Während beim Minidump diese Option ausgegraut ist, ist für das Kernelspeicherabbild und das vollständige Speicherabbild die Option verfügbar. Wenn ihr euch die Dumps auf eine größere Festplatte kopiert (oder direkt dort anlegen lässt), macht es Sinn -zumindest solange das Problem nicht gelöst ist- die Dateien nicht überschreiben zu lassen. Insofern sollte der Haken rausgemacht werden. Beachtet aber, dass bei wenig freien Speicher, die Festplatte schnell voll sein kann.
Mehr muss nicht eingestellt werden.
Falls trotz dieser Einstellungen keine Dumps geschrieben werden, solltet ihr nachsehen, ob die Auslagerungsdatei (Pagefile.sys) aktiviert ist und vom System verwaltet wird.
Solltet ihr nicht wissen, wo man das einstellt: Windows 7 - Größe der Auslagerungsdatei unter Windows 7 einstellen (im letzten Schritt natürlich die Option "Größe wird vom System verwaltet" aktivieren).
Das Handwerkszeug - Was brauche ich für die Auswertung
Um die Dumps auszuwerten, braucht man zunächst die Debugging Tools für Windows, welche im SDK Paket enthalten sind: Debugging Tools for Windows 10 (->Download the Installer). Die Version gilt für Win7 bis Win10
Während der Installation in der Komponentenauswahl nur die Debugging tools auswählen (siehe Bild). Mehr Tools sind für die Auswertung grundsätzlich nicht erforderlich. Je nach dem benötigt man mit Win7/Win8 Betriebssystemen (für die SDK Installation) noch das .net Framework 4.5.
(Darstellung kann je nach Betriebssystem abweichen)Nach der Installation findet man im Programmverzeichnis (Programme -> Windows Kits) die Debugging Tools sowohl in der 32-bit, als auch in der 64-bit Version vor.
Unter Win8.x kann auch im ModernUI ("Metro"), bzw. unter Win10 im Startmenü "windbg" eingegeben werden, worauf als Suchergebnis die x86 und die x64 Versionen angezeigt werden. Entsprechend des Betriebssystems (32- oder 64-bit) auf dem die Dumps ausgewertet werden, startet man nun die entsprechende Version des Debuggers. Die windbg.exe muss mit Administrator-Rechten ausgeführt werden (am besten generell den Debugger mit der rechten Maustaste anklicken und im Kontext Menü "...als Administrator ausführen" auswählen).
Erste Schritte zur Auswertung
Sobald der Debugger gestartet wurde zeigt er sich zunächst mit einer unscheinbaren Grafikoberfläche:
Als nächstes ist es für die Auswertung wichtig, dass der Debugger Informationen über die installierten Treiber sammeln kann (die Informationen werden "Symbole" genannt).
Der nächste Schritt vor der eigentlichen Auswertung ist daher unter dem Menüpunkt "Files" -> "Symbol File Path" dem Debugger zu sagen, wo er die Symbole (Treiberinformationen) herbekommt. Eine praktische Lösung ist es den Debugger nur die Symbole (automatisch) zukommen zu lassen, die für diese Debugging Sitzung notwendig sind. Dazu einfach beim "Symbol File Path" in das kleine Fenster folgenden Befehl eingeben (paste©):
"SRV*C:\symbols*https://msdl.microsoft.com/download/symbols" (ohne "")
und OK drücken. Jetzt können alle notwendigen Informationen zum Debuggen direkt vom Microsoft Symbolserver geladen werden, das geschieht automatisch, benötigt aber eine bestehende Internet-Verbindung (alternativ können auch die kompletten Symbol-Dateien heruntergeladen werden: Herunterladen von Windows-Symbolpaketen. Die Einstellung im Symbol File Path muss dann entsprechend dem Ordnerpfad eingestellt werden in dem die Symbole entpackt werden (z.B. "C:\Symbols"). Um den Symbolpfad nicht bei jedem Start des Debuggers erneut eingeben zu müssen nochmals auf "Files" klicken und anschließend "Save Workspace" auswählen.
Anschließend über Files, das Speicherabbild für den Debugger öffnen: Files -> Open Crash Dump (Tastankombination: STRG + D)
Die Dump Datei auswählen und öffnen.
Hierbei ist entscheidend, welche Art von Debuginformationen in den erweiterten Systemeinstellungen hinterlegt sind.
Speicherpfad der dmp Datei (Kernelspeicherabbild, oder vollständiges Kernelspeicherabbild) ist C:\Windows -> "MEMORY.dmp".
Speicherpfad der Minidumps ist C:\Windows\Minidump -> "Minixxxxxx-xx.dmp"
Bei einer Abfrage ob die Informationen für die "Workspace" gespeichert werden sollen, merkt sich in diesem Schritt der Debugger (falls ihr "ja" auswählt) den Speicherpfad der Dump Datei. Beim nächsten arbeiten mit dem Debugger wählt er als Speicherpfad den eben gewählten Zielpfad aus. Sofern diese Abfrage nicht erscheint und ihr den Speicherpfad dennoch dauerhaft abspeichern möchtet, könnt ihr das über "Files" -> "Save Workspace" machen. (Hintergrund: Bei jedem Start lädt der Debugger eine "Default Workspace". Diese beinhaltet insbes. Einstellungen für den Symbolpfad, Imagepfad, Logfile Einstellungen, des weiteren noch Verbindungseinstellungen für Remote Debugging Sessins, etc. Über "Save Workspace" könnt ihr diese "Default"-Einstellungen anpassen.)
Nach dem die Dump geladen wurde sammelt der Debugger zunächst verschiedene Informationen über installierte Patches, SPs, Treiber, etc. Dies macht der Debugger eigenständig...einfach warten. Nachdem dieser Schritt erledigt wurde zeigt sich dieses Bild:
Im oberen Bereich (Markierung 1) kann man Informationen über die Debugger Version, Speicherpfad der Dump Datei, Symbolpfad und die Betriebssystemversion entnehmen.
Im mittleren Bereich (Markierung 2) ist eine erste Darstellung des Bluescreens (Bugcheckcode und mögliche Fehlerursache). Diese Informationen werden auch durch andere Tools (Bluescreenview, etc.) angezeigt. Im Gegensatz zu diesen Tools steigen wir mit dem Debugger nun aber jetzt erst richtig in die Auswertung ein.
Im unteren Bereich (Markierung 3) ist die Kommandozeile. Hier werden spezielle Debuggingbefehle eingegeben.
Für eine normale Auswertung reicht hier regelmäßig der Befehl "!analyze –v". Diesen können wir (ohne "") in die Kommandozeile eingeben und anschließend die ENTER Taste drücken. "Können" deswegen, da man sich dies auch sparen kann. Im Markierten Bereich 2 ist dieser Befehl bereits vorgegeben. Ich brauche also nur auf das mit blauer Schrift und unterstrichene !analyze -v klicken und der Debugger übernimmt den Befehl.
Der Debugger werkelt dann etwas (manchmal auch etwas länger - solange in der Kommandozeile "Busy" zu lesen ist einfach abwarten) und nach kurzer Zeit wird als Ausgabe u.a. eine Zuweisung der Datei, die den Bluescreens hervorgerufen hat, gegeben.
Dies sieht dann z.B. so aus:
Die Bereiche, an denen man den für den Absturz verantwortlichen Treiber erkennt, habe ich Fett markiert. Zunächst sind das die Zeilen "IMAGE_NAME" und "FAILURE_BUCKET_ID".
Ein ebenso wichtiger Bereich ist der Stack Verlauf "STACK_TEXT", da hier der Absturzverlauf angezeigt wird (in diesem Beispiel ist nur ein Eintrag vorhanden, hier können aber mehrere Zeilen dargestellt werden). Im Stack Verlauf kann schrittweise nachvollzogen werden, wie der Fehler aufgetreten ist und welche Treiber oder Systemprozesse möglicherweise den Absturz mit beeinflusst haben.
Im oben gezeigten Beispiel wurde der Bluescreen durch den Grafikkartentreiber (atikmdag.sys) ausgelöst.
Sitzung des Debuggers beenden: Gebt in die Kommandozeile "q" (ohne "") ein, um die Sitzung zu beenden und bevor ihr eine andere Dump in den Debugger laden wollt.
Diesen Auswertungstext könnt ihr für Euren eigenen Problemthread benutzen (siehe "Eigenen Problem-Thread" erstellen).
Um den Text aus dem Debugger kopieren zu können, müsst ihr zunächst den entsprechenden Textbereich markieren und anschließend mit der Tastenkombination STRG + C in die Zwischenablage kopieren (das Kontextmenü ist im Debugger nicht vorhanden). Anschließend kann der kopierte Text in den Thread eingefügt werden.
Deutung der Bluescreens
An welchen Stellen der Auswertung der fehlerhafte Treiber ausgemacht werden kann, habe ich ja bereits im letzten Absatz erläutert. Hier sind aber mitunter ein paar Dinge zu beachten:
1. Werden Microsoft eigene Treiber als Absturzursache benannt, liegt das Problem in den seltensten Fällen tatsächlich an einem Treiberproblem. Ein Hardwareproblem wäre in diesem Fall wahrscheinlicher. Um die Systemintegrität der Windows-Treiber zu überprüfen kann aber dennoch das Tool sfc.exe gesartet weren (Eingabeaufforderung als Admin starten und "sfc /scannow" (ohne "") eingeben.
2. Man sollte sich nie auf nur eine Dump Auswertung verlassen. Nur die Auswertung mehrerer Dumps zeigt, ob sich das Problem wiederholt, oder ob bei jeder Dump ein anderer BugCheckCode angezeigt wird und auch die Absturzursachen variieren. Bei einem solchen Szenario ist das Problem regelmäßig bei der Hardware zu suchen.
3. Ganz wichtig ist natürlich auch das System ohne Übertaktung laufen zu lassen. Die Auswertung einer Dump, die durch fehlerhafte bzw. nicht stabile Übertaktung hervorgerufen wurde ist kurz gesagt verschwendete Zeit. Dennoch kann man auch bei einer instabilen Übertaktung aus den Stopfehlercodes die ungefähre Ursache deuten: Common BSOD Error Code List for Overclocking - Overclock.net Community
4. Der NT STATUS Code: Der Stopfehlercode des Bluescreens besteht nicht nur aus Bug Check Code allein, sondern es werden zusätzlich Parameter (Arguments) angezeigt. Das sind bei einem Bluescreen die Werte, die in den Klammern stehen. In der oben geposteten Auswertung werden die Arguments separat aufgelistet:
Arg1 (0xC0000005) steht in diesem Beispiel für ein NT STATUS Code, nämlich "STATUS_ACCESS_VIOLATION". In der weiter unten verlinkten Liste der NT STATUS Codes werden diese Codes noch etwas umschrieben: "The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s." Der Code 0xC0000005 beschreibt also eine Speicherzugriffsverletzung.
Bei welchen Stopfehlercodes NT STATUS Codes (und an welcher Stelle) angezeigt werden, könnt ihr dem jeweiligen Stopfehlercode aus der unten verlinkten Übersicht (siehe hilfreiche Webseiten -> Microsoft Übersicht Stopfehlercodes) entnehmen.
Noch ein Beispiel dazu: 0x7A: KERNEL_DATA_INPAGE_ERROR. Der NT Status Code (error status) wird im 2. Parameter (Argument) angezeigt.
Für gewöhnlich treten bei diesem Stopfehlercode folgende NT Status Codes auf:
Anhand der Erläuterungen kann die Absturzursache durch die NT STATUS Codes weiter eingegrenzt, oder sogar zielgenau identifiziert werden.
5. Den Stack-Verlauf (Stack_Text) immer mit berücksichtigen. Der Stack-Verlauf ist mit das Wichtigste bei der Bluescreenauswertung und kann für die Fehlerfindung sehr hilfreich sein. Die zeitliche Reihenfolge des Verlaufs ist absteigend (der oberste Eintrag ist das zeitlich letzte Ereignis, der Unterste das erste Ereignis im Ablauf).
Bei den Auswertungsbeispielen habe ich einen Fall (Stop 0x7F, 0x08) dokumentiert, bei dem dies gut veranschaulicht wird.
6. Auch das Debugging Tool kann keine Wunder vollbringen, sprich in jedem Fall zu einer befriedigenden Lösung beitragen. Insbes. bei hardwarebedingten Fehlern (z.B. Kompatibilitätsprobleme, Hardwaredefekte) kommt das Tool an seine Grenzen.
Auch ist die Dump Datei nur eine Momentaufnahme des Absturzhergangs. Es kann in Einzelfällen durchaus vorkommen, dass auch bei vorliegenden Treiberproblemen, diese durch die Auswertung nicht nachvollziehbar sind. Um ein Treiberproblem in solchen Fällen ausschließen zu können, bietet das Betriebssystem das Tool "Driver Verifier". Der Driver Verifier ist kurz gesagt ein Stresstest um fehlerhafte Treiber ausfindig zu machen. Wird ein fehlerhaft arbeitender Treiber von Verifier erkannt, wird umgehend ein Bluescreen (Stop 0xC4 Fehler) ausgegeben und eine Dump Datei angelegt. Hier kommt nun wieder der Debugger zum Einsatz, mit dem man den Treiber genannt bekommt (auch hier ist aber Ziff. 2 dieses Kapitels zu beachten: mehrere Dumps auswerten).
Mit diesem Tool sollte grundsätzlich vorsichtig umgegangen werden, da es das Betriebssystem lahm legen, bzw. im ungünstigsten Fall nicht mehr gebootet werden kann. In diesem "Worst Case" muss der Driver Verifier im abgesicherten Modus deaktivert werden; zur Sicherheit ist es aber ratsam vor der Aktivierung des Verifiers einen Wiederherstellungspunkt zu erstellen. Näheres über die Anwendung des Verifiers kann hier nachgelesen werden: Driver Verifier (Windows Drivers)
Wenn die Arbeit des Verifiers nicht mehr benötigt wird, ist dieser wieder manuell zu deaktivieren, da er auch nach einem Neustart immer noch aktiv ist. Zum deaktivieren reicht es in die Eingabeaufforderung "verifier.exe /reset" einzugeben (ohne "").
Hilfreiche Webseiten
Die Microsoft eigene Übersicht über die Stopfehlercodes kann auch als erste Anlaufstelle recht hilfreich sein: Bug Check Code Reference (Windows Debuggers)
NT Status Codes: 2.3.1 NTSTATUS values
Sehr bequem ist auch der Dienst auf dieser Seite, auf der man seine Dump-Dateien hochladen kann und die Auswertung (analyze -v) automatisiert abläuft: Instant Online Crash Analysis
Eine hilfreiche Webseite für den Einstieg in die Auswertung und für weitergehende Fehlersuche ist ebenfalls die Homepage von John Carrona: BSOD Index. Hier findet man umfangreiches Infomaterial, Erläuterungen zu Stopfehlercodes, Links zu Hotfixes, ein Nachschlagewerk für Treiber, etc.
Bei Problemen, die nicht durch Treiber hervorgerufen werden, hat der User riedochs hier eine tolle Checkliste bereitgestellt: Erste Schritte bei Problemen
In diesem Zusammenhang darf auch die Nullmethode von HisN nicht fehlen: http://www.computerbase.de/forum/showthread.php?t=1550968. Dank dieser Methode kann man bei einem Totalausfall mit einfachen Mitteln herausfinden, warum der Rechner nicht mehr starten will.
(hier gibt es zu dieser Methode noch die Erläuterung der Bios Töne: http://www.biosflash.com/bios-pieptoene.htm)
Alternative Auswertungstools
Eigentlich gibt es keine Alternative zu den Debugging Tools von Microsoft. Auch die unten genannten Tools sind für eine genauere Analyse nicht geeignet.
Warum die Tools dennoch Beachtung finden sollten, liegt daran, dass mit ein paar Klicks eine Übersicht aller aufgetretenen Stopfehlercodes (incl. Parameter) erstellt werden kann. Diese Übersicht kann für eine erste Einschätzung sehr hilfreich sein.
Insbesondere wenn hier variierende Stopfehlercodes zu sehen sind, macht eine Analyse mit den Debugging Tools i.d.R. wenig Sinn, da die Wahrscheinlichkeit eines Treiberproblems gegen Null geht. (siehe auch "Deutung der Bluescreens" - Ziffer 2)
Des weiteren kann man z.B. mit Bluescreenview schnell und einfach die Aktualität der Treiber überprüfen. Auch dies ist bei der Fehlersuche hilfreich.
Im Bereich 1 stehen die Stopfehlercodes (incl. Arguments) der Minidump Dateien. Im Bereich 2 sind die Treiber zu sehen, die sich über das Feld "Time String" nach Datum sortieren lassen (funktioniert nur mit Minidumps). Veraltete Treiber sind hiermit einfach und schnell auszumachen.
Das Beispiel veranschaulicht auch deutlich, warum diese Tools keine echte Alternative zu den Debugging Tools für die Auswertung darstellen. Bei dem im Bluescreenview-Screenshot zu sehende erste Absturz wird der Treiber "csc.sys" als Absturzursache ("Caused by Driver") genannt. Die Minidump ist die gleiche, die ich unter "Erste Schritte zur Auswertung" exemplarisch ausgwertet habe. Wie mit dem Debugger ermittlet, war jedoch der Grafikkartentreiber die tatsächliche Absturzursache. Mit Bluescreenview allein hätten wir das nicht herausgefunden.
Bei dem Tool "WhoCrashed" ist noch erwähnenswert, dass man damit sein System "kontrolliert" mit einem Bluescreen (0xDEADDEAD) abstürzen lassen kann (Crash Dump Test). Dies ist insbes. nützlich, um zu überprüfen, ob die Einstellungen zum Schreiben der Dumps korrekt vorgenommen wurden und auch funktionieren. Die Dumps können natürlich auch für erste Debug Versuche genutzt werden.
Bluescreenview: Blue screen of death (STOP error) information in dump files.
WhoCrashed: Resplendence Software - WhoCrashed, automatic crash dump analyzer
Die Microsoft eigene Übersicht über die Stopfehlercodes kann auch als erste Anlaufstelle recht hilfreich sein: Bug Check Code Reference (Windows Debuggers)
NT Status Codes: 2.3.1 NTSTATUS values
Sehr bequem ist auch der Dienst auf dieser Seite, auf der man seine Dump-Dateien hochladen kann und die Auswertung (analyze -v) automatisiert abläuft: Instant Online Crash Analysis
Eine hilfreiche Webseite für den Einstieg in die Auswertung und für weitergehende Fehlersuche ist ebenfalls die Homepage von John Carrona: BSOD Index. Hier findet man umfangreiches Infomaterial, Erläuterungen zu Stopfehlercodes, Links zu Hotfixes, ein Nachschlagewerk für Treiber, etc.
Bei Problemen, die nicht durch Treiber hervorgerufen werden, hat der User riedochs hier eine tolle Checkliste bereitgestellt: Erste Schritte bei Problemen
In diesem Zusammenhang darf auch die Nullmethode von HisN nicht fehlen: http://www.computerbase.de/forum/showthread.php?t=1550968. Dank dieser Methode kann man bei einem Totalausfall mit einfachen Mitteln herausfinden, warum der Rechner nicht mehr starten will.
(hier gibt es zu dieser Methode noch die Erläuterung der Bios Töne: http://www.biosflash.com/bios-pieptoene.htm)
Alternative Auswertungstools
Eigentlich gibt es keine Alternative zu den Debugging Tools von Microsoft. Auch die unten genannten Tools sind für eine genauere Analyse nicht geeignet.
Warum die Tools dennoch Beachtung finden sollten, liegt daran, dass mit ein paar Klicks eine Übersicht aller aufgetretenen Stopfehlercodes (incl. Parameter) erstellt werden kann. Diese Übersicht kann für eine erste Einschätzung sehr hilfreich sein.
Insbesondere wenn hier variierende Stopfehlercodes zu sehen sind, macht eine Analyse mit den Debugging Tools i.d.R. wenig Sinn, da die Wahrscheinlichkeit eines Treiberproblems gegen Null geht. (siehe auch "Deutung der Bluescreens" - Ziffer 2)
Des weiteren kann man z.B. mit Bluescreenview schnell und einfach die Aktualität der Treiber überprüfen. Auch dies ist bei der Fehlersuche hilfreich.
Im Bereich 1 stehen die Stopfehlercodes (incl. Arguments) der Minidump Dateien. Im Bereich 2 sind die Treiber zu sehen, die sich über das Feld "Time String" nach Datum sortieren lassen (funktioniert nur mit Minidumps). Veraltete Treiber sind hiermit einfach und schnell auszumachen.
Das Beispiel veranschaulicht auch deutlich, warum diese Tools keine echte Alternative zu den Debugging Tools für die Auswertung darstellen. Bei dem im Bluescreenview-Screenshot zu sehende erste Absturz wird der Treiber "csc.sys" als Absturzursache ("Caused by Driver") genannt. Die Minidump ist die gleiche, die ich unter "Erste Schritte zur Auswertung" exemplarisch ausgwertet habe. Wie mit dem Debugger ermittlet, war jedoch der Grafikkartentreiber die tatsächliche Absturzursache. Mit Bluescreenview allein hätten wir das nicht herausgefunden.
Bei dem Tool "WhoCrashed" ist noch erwähnenswert, dass man damit sein System "kontrolliert" mit einem Bluescreen (0xDEADDEAD) abstürzen lassen kann (Crash Dump Test). Dies ist insbes. nützlich, um zu überprüfen, ob die Einstellungen zum Schreiben der Dumps korrekt vorgenommen wurden und auch funktionieren. Die Dumps können natürlich auch für erste Debug Versuche genutzt werden.
Bluescreenview: Blue screen of death (STOP error) information in dump files.
WhoCrashed: Resplendence Software - WhoCrashed, automatic crash dump analyzer
Eigenen Problem-Thread erstellen
Eins vorweg... falls ihr meine Hilfe benötigt, könnt ihr mich gerne über PN (persönliche Nachrichten, etc) kontaktieren; Hilfestellung und Beratung erfolgt aber ausschließlich über Threads. Hier im Forum gibt es reihenweise versierte Nutzer, die Euch bei Problemen helfen können. Viele sind auf bestimmte Bereiche spezialisiert. Es ist daher -für Euch selbst- enorm hilfreich, wenn ihr einen eigenen Thread aufmacht, um das Wissen der gesamten Community abfragen zu können.
Wenn ihr nun alles gemacht habt und mit den Resultaten dennoch nicht klar kommt, oder sich das Problem nicht lösen lässt, oder euch der Weg über den Debugger zu umständlich ist, erstellt bitte euren eigenen Thread. Hierfür gibt es bei PCGH zwei Bereiche (Unterforen), die sich anbieten:
- Komplette Rechner: Praxisprobleme, oder
- Windows 7, Windows 8, Windows allgemein
In dem erstellten Thread postet ihr erst mal die komplette Hardware, die sich in oder an eurem PC befindet. Des weiteren könnt ihr Screenshots hinzufügen von Tools, die weitere Auskünfte über eure Hardware bieten. Diese sind insbes.:
- CPU-Z (Informationen über CPU, Mainboard, RAM -> einfach von jedem Reiter einen Screenshot machen)
- GPU-Z (Informationen über die Grafikkarte)
- CrystalDiskInfo (SMART Werte der Festplatten(n), hiermit lässt sich auch die Firmware (insbes. bei SSDs) auslesen). Wichtig! Beim Einsatz von CrystalDiskInfo die Portable Version nehmen, damit nicht unnötig Adware installiert wird: http://www.computerbase.de/downloads/systemtools/festplatten/crystaldiskinfo/
- Einen Screenshot von Bluescreenview beilegen (siehe alternative Auswertungstools), um eine Übersicht über die aufgetretenen Stopfehlercodes zu erhalten.
- Die Minidumps dem Thread anhängen (siehe nächstes Kapitel "Dump Dateien hochladen")
- Gerade bei variierenden Stopfehlercodes bietet es sich zudem an die RAM mit Memtest86+ auf Fehler zu überprüfen (die Prüfung sollte außerhalb von Windows mind. 4-6 Std. laufen; bei Fehlern die Prüfung für jeden RAM Riegel wiederholen, hierfür immer nur den zu prüfenden RAM Riegel einbauen).
Anleitung für Memtest86+: RAM - Test with Memtest86+ - Windows 7 Help Forums
Verliert auch noch ein paar Worte, ob euch bei den Abstürzen Regelmäßigkeiten aufgefallen sind. Ob die Bluescreens bei bestimmten Aktionen auftreten (nur beim Spielen, nur bei Flash-Videos, nach dem Standby, etc).
Insbes. auch, ob die Probleme schon seit bestehen des Computers auftreten, oder sich erst seit Kurzem bemerkbar gemacht haben. In diesem Fall auch benennen, was ihr am System verändert habt (andere Hardware, neue Treiber, neue Software, etc).
Habt ihr den Thread erstellt, könnt ihr mir über PN gerne einen Link zu dem Thread schicken, wenn ihr meine Hilfe bei der Auswertung benötigt.
Dump Dateien hochladen
Insbesondere, wenn ihr euch das ganze Tutorial nicht antun möchtet, oder aber mit der Auswertung nicht klarkommt, könnt ihr die Auswertung der Community überlassen. Hierfür müsst ihr jedoch auch die Dump Dateien zur Verfügung stellen. Ihr habt dabei mehrere Möglichkeiten dies zu tun.
Bei Minidumps: Wechselt in das Minidump-Verzeichnis und kopiert die Dump Dateien auf den Desktop (anderes Verzeichnis ist auch möglich, Hauptsache nicht in dem Windows Systemordner belassen).
Die kopierten Dateien nun im ZIP Format einpacken (z.B. mit WinZIP oder 7-ZIP). Sind die Dateien noch in einem Windows Systemordner kann hierbei nun ein Zugriffsproblem auftreten (deswegen vorher in ein Nicht-Windows-Verzeichnis kopieren).
Die gezippten Dateien können nun hier im Forum wie ein Bild hochgeladen werden: [How To] Bilderupload im Forum - Version 2.1
Bei vollständigen Dump-Dateien (MEMORY.DMP): Diese sind zu groß, um sie direkt hier im Forum einbinden zu können. Darum können diese nur über Filehoster (bzw. einem Link dorthin) der Community angeboten werden.
Meine große Bitte ist, dass ihr nicht irgendwelche Werbeverseuchten 08/15 Filehoster auswählt, sondern solche Anbieter wählt, bei denen man einfach und schnell die Dateien herunterladen kann. Dazu gehören insbes. Anbieter wie Dropbox, OneDrive, GoogleDrive, etc.
Terminologie
BSOD = Bluescreen of Death
BugCheckCode = Stopfehlercode des Bluescreens (z.B. STOP 0x0000000A: IRQL_NOT_LESS_OR_EQUAL).
Dump Datei = hierbei handelt es sich um den (absturzrelevanten) Inhalt des Arbeitsspeichers, der auf die Systemplatte geschrieben wird (in der Dump werden keine vertraulichen Daten, Bilder, Passwörter, etc. gespeichert!).
Debugging Tools = Werkzeug (Tool) zum Diagnostizieren und Auffinden von Fehlern.
Symbole (Debugsymbols) = Informationen über Dateien (Treiber, DLLs, etc.) wie z. B. Variablennamen, Namen von Prozeduren und Funktionen.
(wird noch ergänzt)
Zum Schluß möchte ich noch ein Dankeschön an PCGH_Stephan aussprechen; ohne seine Anregung wäre dieses HowTo vermutlich nie entstanden.
Änderungen im HowTo:
30.09.2014: [HowTo] Bluescreen auswerten - Diskussionsthread
16.06.2015: Auswahl Debuginformationen aktualisiert
30.08.2015: Infos für Win10 ergänzt
23.02.1016: Links im Kapitel "Das Handwerkszeug" angepasst
17.03.2016: Download Links im Kapitel "Eigenen Thread erstellen" angepasst
21.03.2016: Links im Kapitel "hilfreiche Webseiten" ergänzt
06.11.2016: Adresse Symbol-Server aktualisiert
18-09-2018: Links im Kapitel"Das Handwerkszeug..." angepasst
Anhänge
Zuletzt bearbeitet:
Das war eine Menge Arbeit, die du da für die Community geleistet hast.
