How-To Bluescreen auswerten

How-To-Threads

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.

761237-howto-bluescreen-auswerten-erweiterte-systemeinstellungen.jpg


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).


761251-howto-bluescreen-auswerten-auslagerungsdatei.jpg
(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.

762580-howto-bluescreen-auswerten-installation-sdk.jpg
Installation SDK_2.jpg (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:

761266-howto-bluescreen-auswerten-debugger1.jpg


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&copy):

"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.

761268-howto-bluescreen-auswerten-debugger2.jpg
761269-howto-bluescreen-auswerten-debugger3.jpg


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:

761271-howto-bluescreen-auswerten-debugger4.jpg


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:

2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_THREAD_EXCEPTION_NOT_HANDLED_M (1000007e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Some common problems are exception code 0x80000003. This means a hard
coded breakpoint or assertion was hit, but this system was booted
/NODEBUG. This is not supposed to happen as developers should never have
hardcoded breakpoints in retail code, but ...
If this happens, make sure a debugger gets connected, and the
system is booted /DEBUG. This will let us see why this breakpoint is
happening.
Arguments:
Arg1: ffffffffc0000005, The exception code that was not handled
Arg2: fffff80084da2dbb, The address that the exception occurred at
Arg3: ffffd0002071f128, Exception Record Address
Arg4: ffffd0002071e930, Context Record Address

Debugging Details:
------------------


EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

FAULTING_IP:
atikmdag+c7dbb
fffff800`84da2dbb 488b83a8060000 mov rax,qword ptr [rbx+6A8h]

EXCEPTION_RECORD: ffffd0002071f128 -- (.exr 0xffffd0002071f128)
ExceptionAddress: fffff80084da2dbb (atikmdag+0x00000000000c7dbb)
ExceptionCode: c0000005 (Access violation)
ExceptionFlags: 00000000
NumberParameters: 2
Parameter[0]: 0000000000000000
Parameter[1]: 00000000000006a8
Attempt to read from address 00000000000006a8

CONTEXT: ffffd0002071e930 -- (.cxr 0xffffd0002071e930)
rax=0000000000000000 rbx=0000000000000000 rcx=0000000000000000
rdx=0000000000000000 rsi=0000000000310000 rdi=0000000000000002
rip=fffff80084da2dbb rsp=ffffd0002071f360 rbp=ffffe0000c7c1860
r8=0000000000000002 r9=000000f41f7f4000 r10=0000000000000000
r11=fffff80084832587 r12=ffffe00009986400 r13=ffffe0000bb5d040
r14=ffffe000132c2010 r15=fffff80084cdb000
iopl=0 nv up ei pl zr na po nc
cs=0010 ss=0018 ds=002b es=002b fs=0053 gs=002b efl=00010246
atikmdag+0xc7dbb:
fffff800`84da2dbb 488b83a8060000 mov rax,qword ptr [rbx+6A8h] ds:002b:00000000`000006a8=????????????????
Resetting default scope

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

ERROR_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 00000000000006a8

READ_ADDRESS: fffff803a34d5ce0: Unable to get special pool info
fffff803a34d5ce0: Unable to get special pool info
unable to get nt!MmNonPagedPoolStart
unable to get nt!MmSizeOfNonPagedPoolInBytes
00000000000006a8

FOLLOWUP_IP:
atikmdag+c7dbb
fffff800`84da2dbb 488b83a8060000 mov rax,qword ptr [rbx+6A8h]

BUGCHECK_STR: AV

LAST_CONTROL_TRANSFER: from 0000000000000000 to fffff80084da2dbb

STACK_TEXT:
ffffd000`2071f360 00000000`00000000 : ffffd000`2071f3a9 00000000`00000000 00000000`00311007 ffffe000`132c2010 : atikmdag+0xc7dbb


SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: atikmdag+c7dbb

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: atikmdag

IMAGE_NAME: atikmdag.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 53508a3c

STACK_COMMAND: .cxr 0xffffd0002071e930 ; kb

FAILURE_BUCKET_ID: AV_atikmdag+c7dbb

BUCKET_ID: AV_atikmdag+c7dbb

Followup: MachineOwner

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: ffffffffc0000005, The exception code that was not handled
Arg2: fffff80084da2dbb, The address that the exception occurred at
Arg3: ffffd0002071f128, Exception Record Address
Arg4: ffffd0002071e930, Context Record Address

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:

0xC000009A, or STATUS_INSUFFICIENT_RESOURCES, indicates a lack of nonpaged pool resources.
0xC000009C, or STATUS_DEVICE_DATA_ERROR, typically indicates bad blocks (sectors) on the hard disk.
0xC000009D, or STATUS_DEVICE_NOT_CONNECTED, indicates defective or loose cabling, termination, or that the controller does not see the hard disk.
0xC000016A, or STATUS_DISK_OPERATION_FAILED, indicates bad blocks (sectors) on the hard disk.
0xC0000185, or STATUS_IO_DEVICE_ERROR, indicates improper termination or defective cabling on SCSI devices or that two devices are trying to use the same IRQ.
0xC000000E, or STATUS_NO_SUCH_DEVICE, indicates a hardware failure or an incorrect drive configuration. Check your cables and check the drive with the diagnostic utility available from your drive manufacturer. If you are using older PATA (IDE) drives, this status code can indicate an incorrect master/subordinate drive configuration.

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.

762514-howto-bluescreen-auswerten-bluescreenview.jpg


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.:


  1. CPU-Z (Informationen über CPU, Mainboard, RAM -> einfach von jedem Reiter einen Screenshot machen)
  2. GPU-Z (Informationen über die Grafikkarte)
  3. 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/
  4. Einen Screenshot von Bluescreenview beilegen (siehe alternative Auswertungstools), um eine Übersicht über die aufgetretenen Stopfehlercodes zu erhalten.
  5. Die Minidumps dem Thread anhängen (siehe nächstes Kapitel "Dump Dateien hochladen")
  6. 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
TIPP: Screenshots mit Windows-Boardmitteln (Vista/Win7/Win8) erstellen: Verwenden des Snipping Tools zum Erfassen von Bildschirmfotos - Windows-Hilfe

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

  • erweiterte Systemeinstellungen.jpg
    erweiterte Systemeinstellungen.jpg
    62,6 KB · Aufrufe: 6.009
  • Auslagerungsdatei.jpg
    Auslagerungsdatei.jpg
    33,7 KB · Aufrufe: 4.127
  • Debugger1.jpg
    Debugger1.jpg
    45,5 KB · Aufrufe: 3.925
  • Debugger2.jpg
    Debugger2.jpg
    137,1 KB · Aufrufe: 3.639
  • Debugger3.jpg
    Debugger3.jpg
    27,2 KB · Aufrufe: 3.658
  • Debugger4.jpg
    Debugger4.jpg
    151,5 KB · Aufrufe: 4.580
  • Bluescreenview.jpg
    Bluescreenview.jpg
    205 KB · Aufrufe: 3.345
  • Installation SDK.jpg
    Installation SDK.jpg
    39,5 KB · Aufrufe: 4.403
Zuletzt bearbeitet:
Nützliche Debugging Befehle:

Allgemein:

Der Befehl "q" beendet die Debugging Sitzung (nicht den Debugger). Der Befehl ist notwendig, wenn ihr eine weitere Dump in den Debugger laden und auswerten möchtet.

Mit "?" könnt ihr euch eine kleine Übersicht über Debugging Befehle im Debugger anzeigen lassen. Eine detailliertere Übersicht findet ihr in der Datei "debugger.chm". Die Datei lässt sich am bequemsten im Debugger über das Menü "Help" -> "Index" öffnen. Eine Stichwortsuche ist über "Help" -> "Search" möglich.

Treiber:

Habt ihr über die Auswertung einen Treiber (wie oben zu sehen z.B. den Grafikkartentreiber) entlarvt und wollt noch etwas näheres über den Treiber wissen, könnt ihr mit dem Befehl: "lmvm [Modul_Name]" weitere Details aufrufen:

2: kd> lmvm atikmdag
start end module name
fffff800`84cdb000 fffff800`85beb000 atikmdag (no symbols)
Loaded symbol image file: atikmdag.sys
Image path: \SystemRoot\system32\DRIVERS\atikmdag.sys
Image name: atikmdag.sys
Timestamp: Fri Apr 18 04:13:16 2014 (53508A3C)
CheckSum: 00EAEEE6
ImageSize: 00F10000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

Um ggf. auch veraltete Treiber aufzuspüren könnt ihr mittels "lmntsm" alle geladenen Module (sortiert nach Namen) mit Datum aufrufen (dies Dauert eine Weile):

2: kd> lmntsm
start end module name
fffff800`83023000 fffff800`830ad000 ACPI ACPI.sys Sat Feb 22 13:13:57 2014 (53089485)
fffff800`83000000 fffff800`83018000 acpiex acpiex.sys Thu Aug 22 13:37:47 2013 (5215F80B)
fffff800`8719c000 fffff800`871f8000 afcdp afcdp.sys Wed Jul 20 16:46:03 2011 (4E26EA2B)
fffff800`84930000 fffff800`849c2000 afd afd.sys Thu Apr 03 04:23:08 2014 (533CC60C)
fffff800`84675000 fffff800`8468c000 ahcache ahcache.sys Thu Aug 22 13:39:54 2013 (5215F88A)
fffff800`863d3000 fffff800`863fa000 AMDACPKSL AMDACPKSL.SYS Wed Mar 12 00:49:44 2014 (531FA118)
fffff800`86398000 fffff800`863d3000 AtihdWB6 AtihdWB6.sys Wed Mar 12 00:50:02 2014 (531FA12A)
fffff800`84cdb000 fffff800`85beb000 atikmdag atikmdag.sys Fri Apr 18 04:13:16 2014 (53508A3C)
fffff800`84aa4000 fffff800`84b47000 atikmpag atikmpag.sys Fri Apr 18 03:07:07 2014 (53507ABB)
...
(Liste gekürtzt)

Über die am Zeilenende stehende Datumssignatur könnt ihr die veralteten Treiber ausmachen.

Im Windows10 Debugger (Vers. 10.0.x) sind die Treibernamen der Liste nun blau unterlegt und mit hyperlinks versehen. Ein Klick auf den Treibernamen ruft die Details auf.

end module namefffff800`0a400000 fffff800`0a48a000 ACPI ACPI.sys Sat Feb 22 13:13:57 2014 (53089485)
fffff800`0a5db000 fffff800`0a5f3000 acpiex acpiex.sys Thu Aug 22 13:37:47 2013 (5215F80B)
fffff800`0be44000 fffff800`0bed6000 afd afd.sys Fri May 30 05:03:01 2014 (5387F4E5)
fffff800`0c0f9000 fffff800`0c110000 ahcache ahcache.sys Thu Aug 22 13:39:54 2013 (5215F88A)
fffff800`0cf0b000 fffff800`0cf0cf80 AiChargerPlus AiChargerPlus.sys Thu Apr 19 03:17:35 2012 (4F8F67AF)
fffff800`0c0f3000 fffff800`0c0f9000 AsIO AsIO.sys Wed Aug 22 11:54:47 2012 (5034AC67)
fffff800`0d8cd000 fffff800`0d8f2000 asmthub3 asmthub3.sys Thu Jan 09 10:16:42 2014 (52CE68FA)
fffff800`0d2f0000 fffff800`0d2f9000 asmtufdriver asmtufdriver.sys Fri Jun 13 05:22:50 2014 (539A6E8A)

....

0: kd> lmDvmACPI
Browse full module list
start end module name
fffff800`0a400000 fffff800`0a48a000 ACPI (pdb symbols) c:\symbols\acpi.pdb\D94860249B214FD4B988A7E1E3A0E7B62\acpi.pdb
Loaded symbol image file: ACPI.sys
Mapped memory image file: c:\symbols\ACPI.sys\530894858a000\ACPI.sys
Image path: \SystemRoot\System32\drivers\ACPI.sys
Image name: ACPI.sys
Browse all global symbols functions data
Timestamp: Sat Feb 22 13:13:57 2014 (53089485)
CheckSum: 00090936
ImageSize: 0008A000
File version: 6.3.9600.17031
Product version: 6.3.9600.17031
File flags: 0 (Mask 3F)
File OS: 40004 NT Win32
File type: 3.7 Driver
File date: 00000000.00000000
Translations: 0409.04b0
CompanyName: Microsoft Corporation
ProductName: Microsoft® Windows® Operating System
InternalName: ACPI.sys
OriginalFilename: ACPI.sys
ProductVersion: 6.3.9600.17031
FileVersion: 6.3.9600.17031 (winblue_gdr.140221-1952)
FileDescription: ACPI Driver for NT
LegalCopyright: © Microsoft Corporation. All rights reserved.



System:

Der Dump können ebenfalls wichtige Systeminformationen (Motherboard, Bios Version, RAM Belegung, CPU Speed, etc.) entnommen werden:

2: kd> !sysinfo
!sysinfo [ cpuinfo | cpumicrocode | cpuspeed | gbl | machineid | registers | smbios ] [-csv | -noheaders]

Mit dem Kommande "!sysinfo" stehen euch mehrere Bereiche zur Verfügung. Z.B. smbios. Die Befehlsfolge lautet dann:
!sysinfo smbios

1: kd> !sysinfo smbios
[SMBIOS Data Tables v2.7]
[DMI Version - 39]
[2.0 Calling Convention - No]
[Table Size - 2709 bytes]

[BIOS Information (Type 0) - Length 24 - Handle 0000h]
Vendor Intel Corp.
BIOS Version GAZ7711H.86A.0066.2013.0521.1509
BIOS Starting Address Segment f000
BIOS Release Date 05/21/2013
BIOS ROM Size 810000
BIOS Characteristics
07: - PCI Supported
11: - Upgradeable FLASH BIOS
12: - BIOS Shadowing Supported
15: - CD-Boot Supported
16: - Selectable Boot Supported
17: - BIOS ROM Socketed
19: - EDD Supported
23: - 1.2MB Floppy Supported
24: - 720KB Floppy Supported
25: - 2.88MB Floppy Supported
26: - Print Screen Device Supported
27: - Keyboard Services Supported
28: - Serial Services Supported
29: - Printer Services Supported
32: - BIOS Vendor Reserved
BIOS Characteristic Extensions
00: - ACPI Supported
01: - USB Legacy Supported
08: - BIOS Boot Specification Supported
10: - Specification Reserved
11: - Specification Reserved
BIOS Major Revision 4
BIOS Minor Revision 6
EC Firmware Major Revision 255
EC Firmware Minor Revision 255

[System Information (Type 1) - Length 27 - Handle 0001h]
Manufacturer
Product Name
Version
Serial Number
UUID 00000000-0000-0000-0000-000000000000
Wakeup Type Power Switch
SKUNumber To be filled by O.E.M.
Family To be filled by O.E.M.

[BaseBoard Information (Type 2) - Length 15 - Handle 0002h]
Manufacturer Intel Corporation
Product DZ77GA-70K
Version AAG39009-402
Serial Number
Asset Tag
Feature Flags 09h
666115552: - (null)
666115600: - (null)
Location [String Not Specified]
Chassis Handle 0003h
Board Type 0ah - Processor/Memory Module
Number of Child Handles 0

[System Enclosure (Type 3) - Length 22 - Handle 0003h]
Manufacturer
Chassis Type Desktop
Version
Serial Number
Asset Tag Number
Bootup State Safe
Power Supply State Safe
Thermal State Safe
Security Status None
OEM Defined 0
Height 0U
Number of Power Cords 1
Number of Contained Elements 0
Contained Element Size 0

[Cache Information (Type 7) - Length 19 - Handle 0004h]
Socket Designation CPU Internal L1
Cache Configuration 0080h - WT Enabled Int NonSocketed L1
Maximum Cache Size 0100h - 256K
Installed Size 0100h - 256K
Supported SRAM Type 0002h - Unknown
Current SRAM Type 0002h - Unknown
Cache Speed 0ns
Error Correction Type ParitySingle-Bit ECC
System Cache Type Data
Associativity 8-way Set-Associative

[Cache Information (Type 7) - Length 19 - Handle 0005h]
Socket Designation CPU Internal L2
Cache Configuration 0081h - WT Enabled Int NonSocketed L2
Maximum Cache Size 0400h - 1024K
Installed Size 0400h - 1024K
Supported SRAM Type 0002h - Unknown
Current SRAM Type 0002h - Unknown
Cache Speed 0ns
Error Correction Type Specification Reserved
System Cache Type Unified
Associativity 8-way Set-Associative

[Cache Information (Type 7) - Length 19 - Handle 0006h]
Socket Designation CPU Internal L3
Cache Configuration 0182h - WB Enabled Int NonSocketed L3
Maximum Cache Size 1800h - 6144K
Installed Size 1800h - 6144K
Supported SRAM Type 0002h - Unknown
Current SRAM Type 0002h - Unknown
Cache Speed 0ns
Error Correction Type Specification Reserved
System Cache Type Unified
Associativity Specification Reserved

[Physical Memory Array (Type 16) - Length 23 - Handle 0007h]
Location 03h - SystemBoard/Motherboard
Use 03h - System Memory
Memory Error Correction 03h - None
Maximum Capacity 33554432KB
Memory Error Inf Handle [Not Provided]
Number of Memory Devices 4

[Onboard Devices Information (Type 10) - Length 12 - Handle 0020h]
Number of Devices 4
01: Type Video [disabled]
01: Description Intel(R) HD Graphics Device
02: Type Ethernet [enabled]
02: Description Intel(R) 82579V Gigabit Network Device
03: Type Ethernet [enabled]
03: Description Intel(R) 82574L Gigabit Network Device
04: Type Sound [enabled]
04: Description Intel High Definition Audio Device

[OEM Strings (Type 11) - Length 5 - Handle 0021h]
Number of Strings 1
1 To Be Filled By O.E.M.

[System Configuration Options (Type 12) - Length 5 - Handle 0022h]

[Memory Device (Type 17) - Length 34 - Handle 0028h]
Physical Memory Array Handle 0007h
Memory Error Info Handle [Not Provided]
Total Width 64 bits
Data Width 64 bits
Size 4096MB
Form Factor 09h - DIMM
Device Set [None]
Device Locator DIMM3
Bank Locator CHANNEL A DIMM0
Memory Type 18h - Specification Reserved
Type Detail 0080h - Synchronous
Speed 1333MHz
Manufacturer 8394
Serial Number
Asset Tag Number
Part Number 991770

[Memory Device Mapped Address (Type 20) - Length 35 - Handle 0029h]
Starting Address 00000000h
Ending Address 003fffffh
Memory Device Handle 0028h
Mem Array Mapped Adr Handle 0031h
Partition Row Position [Unknown]
Interleave Position 01
Interleave Data Depth 02

[Memory Device (Type 17) - Length 34 - Handle 002ah]
Physical Memory Array Handle 0007h
Memory Error Info Handle [Not Provided]
Total Width 64 bits
Data Width 64 bits
Size 4096MB
Form Factor 09h - DIMM
Device Set [None]
Device Locator DIMM1
Bank Locator CHANNEL A DIMM1
Memory Type 18h - Specification Reserved
Type Detail 0080h - Synchronous
Speed 1333MHz
Manufacturer 8394
Serial Number
Asset Tag Number
Part Number 991770

[Processor Information (Type 4) - Length 42 - Handle 002bh]
Socket Designation CPU 1
Processor Type Central Processor
Processor Family cdh - Specification Reserved
Processor Manufacturer Intel(R) Corporation
Processor ID a7060200fffbebbf
Processor Version Intel(R) Core(TM) i5-2500K CPU @ 3.30GHz
Processor Voltage 49h - 5V
External Clock 100MHz
Max Speed 3800MHz
Current Speed 3300MHz
Status Enabled Populated
Processor Upgrade Specification Reserved
L1 Cache Handle 0004h
L2 Cache Handle 0005h
L3 Cache Handle 0006h
Serial Number [String Not Specified]
Asset Tag Number
Part Number Fill By OEM

[Memory Device Mapped Address (Type 20) - Length 35 - Handle 002ch]
Starting Address 00800000h
Ending Address 00bfffffh
Memory Device Handle 002ah
Mem Array Mapped Adr Handle 0031h
Partition Row Position [Unknown]
Interleave Position 01
Interleave Data Depth 02

[Memory Device (Type 17) - Length 34 - Handle 002dh]
Physical Memory Array Handle 0007h
Memory Error Info Handle [Not Provided]
Total Width 64 bits
Data Width 64 bits
Size 4096MB
Form Factor 09h - DIMM
Device Set [None]
Device Locator DIMM4
Bank Locator CHANNEL B DIMM0
Memory Type 18h - Specification Reserved
Type Detail 0080h - Synchronous
Speed 1333MHz
Manufacturer 8394
Serial Number
Asset Tag Number
Part Number 991770

[Memory Device Mapped Address (Type 20) - Length 35 - Handle 002eh]
Starting Address 00400000h
Ending Address 007fffffh
Memory Device Handle 002dh
Mem Array Mapped Adr Handle 0031h
Partition Row Position [Unknown]
Interleave Position 02
Interleave Data Depth 02

[Memory Device (Type 17) - Length 34 - Handle 002fh]
Physical Memory Array Handle 0007h
Memory Error Info Handle [Not Provided]
Total Width 64 bits
Data Width 64 bits
Size 4096MB
Form Factor 09h - DIMM
Device Set [None]
Device Locator DIMM2
Bank Locator CHANNEL B DIMM1
Memory Type 18h - Specification Reserved
Type Detail 0080h - Synchronous
Speed 1333MHz
Manufacturer 8394
Serial Number
Asset Tag Number
Part Number 991770

[Memory Device Mapped Address (Type 20) - Length 35 - Handle 0030h]
Starting Address 00c00000h
Ending Address 00ffffffh
Memory Device Handle 002fh
Mem Array Mapped Adr Handle 0031h
Partition Row Position [Unknown]
Interleave Position 02
Interleave Data Depth 02

[Memory Array Mapped Address (Type 19) - Length 31 - Handle 0031h]
Starting Address 00000000h
Ending Address 00ffffffh
Memory Array Handle 0007h
Partition Width 04

Mit der Debugger Version 10.0.X wurden ein paar Neuerungen aufgenommen. So werde mittels "!analayze -v" diverse Systeminformationen gleich mit ausgegeben:
0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************


DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: ffffe001a7c95ca0, Physical Device Object of the stack
Arg3: fffff80261a6f960, nt!TRIAGE_9F_POWER on Win7 and higher, otherwise the Functional Device Object of the stack
Arg4: ffffe001a2919790, The blocked IRP


Debugging Details:
------------------


SYSTEM_SKU: All
SYSTEM_VERSION: System Version
BIOS_DATE: 09/22/2014
BASEBOARD_PRODUCT: X99-DELUXE
BASEBOARD_VERSION: Rev 1.xx


BUGCHECK_P1: 3
BUGCHECK_P2: ffffe001a7c95ca0
BUGCHECK_P3: fffff80261a6f960
BUGCHECK_P4: ffffe001a2919790
DRVPOWERSTATE_SUBCODE: 3
IMAGE_NAME: UsbHub3.sys
DEBUG_FLR_IMAGE_TIMESTAMP: 53d0f163
MODULE_NAME: UsbHub3
FAULTING_MODULE: fffff8000d32d000 UsbHub3

CPU_COUNT: c
CPU_MHZ: b54
CPU_VENDOR: GenuineIntel
CPU_FAMILY: 6
CPU_MODEL: 3f
CPU_STEPPING: 2

CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT
BUGCHECK_STR: 0x9F
PROCESS_NAME: System
CURRENT_IRQL: 2
ANALYSIS_VERSION: 10.0.10240.9 amd64fre

(weitere Befehle folgen)


Änderungen:

30.08.2015: Neuerungen in Debugger Version 10.0.x hinzugefügt
 
Zuletzt bearbeitet:
Auswertungsbeispiele:

(spezielle Debugging Befehle für spezielle Stopfehler)

Während die meisten Treiberprobleme mittels "!analyze -v" aufgedeckt werden können, gibt es bestimmte Bluescreens, bei denen man etwas mehr nachforschen muss, um den Problem auf die Schliche zu kommen.




Bluescreens nach Standby, der 0x9F (driver_power_state_failure) - 1. Arg: 0x03.

Der Stop 0x9F Fehler wird regelmäßig durch fehlerhafte Treiber ausgelöst. Bei der Auswertung dieses Bluescreens steht man aber oft vor dem Problem, dass die Auswertung mittes !analyze -v keine befriedigende Zuweisung des fehlerhaften Treibers ausgibt. Selbst im Stack Verlauf ist nichts handfestes dabei:

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time (usually 10 minutes).
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: fffffa800a970060, Physical Device Object of the stack
Arg3: fffff800045df748, nt!TRIAGE_9F_POWER on Win7, otherwise the Functional Device Object of the stack
Arg4: fffffa800fb1eb40, The blocked IRP

Debugging Details:
------------------

DRVPOWERSTATE_SUBCODE: 3

DRIVER_OBJECT: fffffa800838f840

IMAGE_NAME: usbhub.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 52954dd0

MODULE_NAME: usbhub

FAULTING_MODULE: fffff88004523000 usbhub

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0x9F

PROCESS_NAME: ALCKRESI.exe

CURRENT_IRQL: 2

TAG_NOT_DEFINED_c000000f: FFFFF800045DFFB0

STACK_TEXT:
fffff800`045df6f8 fffff800`02f388d2 : 00000000`0000009f 00000000`00000003 fffffa80`0a970060 fffff800`045df748 : nt!KeBugCheckEx
fffff800`045df700 fffff800`02ed385c : fffff800`045df830 fffff800`045df830 00000000`00000000 00000000`00000001 : nt! ?? ::FNODOBFM::`string'+0x33af0
fffff800`045df7a0 fffff800`02ed36f6 : fffff880`03524a40 fffff880`03524a40 00000000`00000000 00000000`00000000 : nt!KiProcessTimerDpcTable+0x6c
fffff800`045df810 fffff800`02ed35de : 00000006`cad40909 fffff800`045dfe88 00000000`0002da7b fffff800`030471e8 : nt!KiProcessExpiredTimerList+0xc6
fffff800`045dfe60 fffff800`02ed33c7 : fffffa80`08d54ec2 00000000`0002da7b 00000000`00000000 00000000`0000007b : nt!KiTimerExpiration+0x1be
fffff800`045dff00 fffff800`02ecbd15 : 00000000`00000000 fffffa80`0aac2060 00000000`00000000 fffff880`016db800 : nt!KiRetireDpcList+0x277
fffff800`045dffb0 fffff800`02ecbb2c : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxRetireDpcList+0x5
fffff880`09ba92f0 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiDispatchInterruptContinue


STACK_COMMAND: kb

FOLLOWUP_NAME: MachineOwner

FAILURE_BUCKET_ID: X64_0x9F_3_IMAGE_usbhub.sys

BUCKET_ID: X64_0x9F_3_IMAGE_usbhub.sys

Followup: MachineOwner
---------


Auch die Auflösung nach dem DRIVER_OBJECT: fffffa800838f840 - (wird im Debugger als Link dargestellt, man braucht also nur draufklicken):

0: kd> !drvobj fffffa800838f840 f
fffff80003079010: Unable to get value of ObpRootDirectoryObject
fffff80003079010: Unable to get value of ObpRootDirectoryObject
Driver object (fffffa800838f840) is for:
\Driver\usbhub
Driver Extension List: (id , addr)

Device Object list:
fffffa800a970060 fffffa80099bc060: Could not read device object


DriverEntry: fffff88004570064 usbhub!GsDriverEntry
DriverStartIo: 00000000
DriverUnload: fffff880045496d4 usbhub!UsbhDriverUnload
AddDevice: 00000000

Dispatch routines:
[00] IRP_MJ_CREATE fffff88004524f60 usbhub!UsbhGenDispatch
[01] IRP_MJ_CREATE_NAMED_PIPE fffff80002eadb30 nt!IopInvalidDeviceRequest
[02] IRP_MJ_CLOSE fffff88004524f60 usbhub!UsbhGenDispatch
[03] IRP_MJ_READ fffff80002eadb30 nt!IopInvalidDeviceRequest
[04] IRP_MJ_WRITE fffff80002eadb30 nt!IopInvalidDeviceRequest
[05] IRP_MJ_QUERY_INFORMATION fffff80002eadb30 nt!IopInvalidDeviceRequest
[06] IRP_MJ_SET_INFORMATION fffff80002eadb30 nt!IopInvalidDeviceRequest
[07] IRP_MJ_QUERY_EA fffff80002eadb30 nt!IopInvalidDeviceRequest
[08] IRP_MJ_SET_EA fffff80002eadb30 nt!IopInvalidDeviceRequest
[09] IRP_MJ_FLUSH_BUFFERS fffff80002eadb30 nt!IopInvalidDeviceRequest
[0a] IRP_MJ_QUERY_VOLUME_INFORMATION fffff80002eadb30 nt!IopInvalidDeviceRequest
[0b] IRP_MJ_SET_VOLUME_INFORMATION fffff80002eadb30 nt!IopInvalidDeviceRequest
[0c] IRP_MJ_DIRECTORY_CONTROL fffff80002eadb30 nt!IopInvalidDeviceRequest
[0d] IRP_MJ_FILE_SYSTEM_CONTROL fffff80002eadb30 nt!IopInvalidDeviceRequest
[0e] IRP_MJ_DEVICE_CONTROL fffff88004524f60 usbhub!UsbhGenDispatch
[0f] IRP_MJ_INTERNAL_DEVICE_CONTROL fffff88004524f60 usbhub!UsbhGenDispatch
[10] IRP_MJ_SHUTDOWN fffff8800454a53c usbhub!UsbhDeviceShutdown
[11] IRP_MJ_LOCK_CONTROL fffff80002eadb30 nt!IopInvalidDeviceRequest
[12] IRP_MJ_CLEANUP fffff80002eadb30 nt!IopInvalidDeviceRequest
[13] IRP_MJ_CREATE_MAILSLOT fffff80002eadb30 nt!IopInvalidDeviceRequest
[14] IRP_MJ_QUERY_SECURITY fffff80002eadb30 nt!IopInvalidDeviceRequest
[15] IRP_MJ_SET_SECURITY fffff80002eadb30 nt!IopInvalidDeviceRequest
[16] IRP_MJ_POWER fffff88004524f60 usbhub!UsbhGenDispatch
[17] IRP_MJ_SYSTEM_CONTROL fffff88004524f60 usbhub!UsbhGenDispatch
[18] IRP_MJ_DEVICE_CHANGE fffff80002eadb30 nt!IopInvalidDeviceRequest
[19] IRP_MJ_QUERY_QUOTA fffff80002eadb30 nt!IopInvalidDeviceRequest
[1a] IRP_MJ_SET_QUOTA fffff80002eadb30 nt!IopInvalidDeviceRequest
[1b] IRP_MJ_PNP fffff88004524f60 usbhub!UsbhGenDispatch

bringt nichts wirklich brauchbares. Das einzige was man hieraus schließen könnte, wäre dass der usbhub Treiber Probleme macht. Folglich wäre die Installation der aktuellsten Chipsatztreiber vorzunehmen.

Im Stopfehlercode werden aber in den Arguments wichtige Adressen dargestellt, mittels denen etwas über die tatsächliche (versteckte) Absturzursache herausgefunden werden kann:

Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: fffffa800a970060, Physical Device Object of the stack
Arg3: fffff800045df748, nt!TRIAGE_9F_POWER on Win7, otherwise the Functional Device Object of the stack
Arg4: fffffa800fb1eb40, The blocked IRP

Argument 4 gibt Auskunft über die Adresse des Treibers, der nicht innerhalb der vom Betriebssystem vorgegebenen Zeit reagiert hat. Was hinter der Adresse steckt erhält man durch den Befehl !irp <Adresse>:

0: kd> !irp fffffa800fb1eb40
Irp is active with 10 stacks 7 is current (= 0xfffffa800fb1edc0)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
>[ 16, 2] 0 e0 fffffa800a970060 00000000 fffff88000f7a57c-fffff88000f7a3c4 Success Error Cancel
\Driver\usbhub ACPI!ACPIDeviceIrpDeviceFilterRequest
Args: 00000000 00000001 00000003 00000000
[ 16, 2] 0 1 fffffa80099b7920 00000000 00000000-00000000 pending
\Driver\ACPI
Args: 00000000 00000001 00000003 00000000
[ 16, 2] 0 e1 fffffa800a997070 00000000 00000000-00000000 pending
Unable to load image \SystemRoot\system32\DRIVERS\Mbm3CBus.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for Mbm3CBus.sys
*** ERROR: Module load completed but symbols could not be loaded for Mbm3CBus.sys
\Driver\Mbm3CBus
Args: 00000000 00000001 00000003 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-fffffa800b0c6790

Args: 00000000 00000000 00000000 00000000

Der (von mir) in Fettdruck dargestellte Stack beinhaltet den für den Absturz verantwortlichen Treiber: Mbm3CBus.sys

Eine Überprüfung über das 2. Argument mittels !devstack <Adresse> bestätigt dies:

0: kd> !devstack fffffa800a970060
!DevObj !DrvObj !DevExt ObjectName
fffffa800a997070 \Driver\Mbm3CBus fffffa800a9971c0 InfoMask field not found for _OBJECT_HEADER at fffffa800a997040

fffffa80099b7920 \Driver\ACPI fffffa80069cd7d0 InfoMask field not found for _OBJECT_HEADER at fffffa80099b78f0

> fffffa800a970060 \Driver\usbhub fffffa800a9701b0 Cannot read info offset from nt!ObpInfoMaskToOffset

!DevNode fffffa8009326d90 :
DeviceInst is "USB\VID_0BDB&PID_1911\6B014EC3F6E4CCF0"
ServiceName is "Mbm3CBus"

Und gibt gleich noch Auskunft über die VID (Vendor ID).

Wollt/müsst ihr herausfinden, was das für ein Treiber ist, hilft die Webeseite von John Carrona als erste Anlaufstelle: Driver Reference Table (DRT)

Genaueres über das Gerät, das hinter die VID steht findet ihr hier heraus: PCI Vendor and Device Lists





Stop 0x9F (Arg. 1: 0x04) "The power transition timed out waiting to synchronize with the Pnp subsystem."
(hier wurde ein vollständiges Speicherabbild genutzt - mind. erforderlich ist bei diesem Fehlertyp ein Kernelspeicherabbild)


Auch hier besteht oft das Problem, dass mit der Auswertung mittels !analyze -v der Treiber, der für den "Time Out" verantwortlich ist nicht herausgefunden werden kann:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 9F, {4, 258, fffffa800fdfd730, fffff80000b9c3d0}

Implicit thread is now fffffa80`0fdfd730
Probably caused by : ntkrnlmp.exe ( nt!KiSwapContext+7a )

Followup: MachineOwner
---------

0: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time.
Arguments:
Arg1: 0000000000000004, The power transition timed out waiting to synchronize with the Pnp
subsystem.
Arg2: 0000000000000258, Timeout in seconds.
Arg3: fffffa800fdfd730, The thread currently holding on to the Pnp lock.
Arg4: fffff80000b9c3d0, nt!TRIAGE_9F_PNP on Win7 and higher

Debugging Details:
------------------

Implicit thread is now fffffa80`0fdfd730

DRVPOWERSTATE_SUBCODE: 4

FAULTING_THREAD: fffffa800fdfd730

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

BUGCHECK_STR: 0x9F

PROCESS_NAME: System

CURRENT_IRQL: 2

ANALYSIS_VERSION: 6.3.9600.17237 (debuggers(dbg).140716-0327) amd64fre

LAST_CONTROL_TRANSFER: from fffff8000346d5f2 to fffff8000347aa8a

STACK_TEXT:
fffff880`03762750 fffff800`0346d5f2 : fffffa80`0fdfd730 fffffa80`0fdfd730 00000000`00000000 00000000`00000004 : nt!KiSwapContext+0x7a
fffff880`03762890 fffff800`0347e99f : 00000000`00000000 00000000`00000000 00000000`000000f6 00000000`00000000 : nt!KiCommitThreadWait+0x1d2
fffff880`03762920 fffff800`03457b4e : 00000000`00000000 fffff800`0000001b 00000000`00000000 fffff880`009b3100 : nt!KeWaitForSingleObject+0x19f
fffff880`037629c0 fffff800`0347cdbc : ffffffff`fd9da600 fffffa80`1169b9f0 fffff800`0367bda0 fffff880`000006b1 : nt!ExpWaitForResource+0xae
fffff880`03762a30 fffff800`037b4602 : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`00000000 : nt!ExAcquireResourceExclusiveLite+0x14f
fffff880`03762aa0 fffff800`0357a540 : 00000000`00000000 fffff800`0361d2d8 00000000`00000001 00000000`00000000 : nt! ?? ::NNGAKEGL::`string'+0x1b83c
fffff880`03762ad0 fffff800`03481261 : fffff800`0357a500 fffff800`0376ec01 fffffa80`0fdfd700 00000000`00000000 : nt!PnpDeviceActionWorker+0x40
fffff880`03762b70 fffff800`0371373a : 00000000`00000000 fffffa80`0fdfd730 00000000`00000080 fffffa80`0fcf3b30 : nt!ExpWorkerThread+0x111
fffff880`03762c00 fffff800`034688e6 : fffff880`0356d180 fffffa80`0fdfd730 fffff880`035780c0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`03762c40 00000000`00000000 : fffff880`03763000 fffff880`0375d000 fffff880`037628a0 00000000`00000000 : nt!KxStartSystemThread+0x16


STACK_COMMAND: .thread 0xfffffa800fdfd730 ; kb

FOLLOWUP_IP:
nt!KiSwapContext+7a
fffff800`0347aa8a 488d8c2400010000 lea rcx,[rsp+100h]

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: nt!KiSwapContext+7a

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: nt

IMAGE_NAME: ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 531590fb

IMAGE_VERSION: 6.1.7601.18409

FAILURE_BUCKET_ID: X64_0x9F_4_nt!KiSwapContext+7a

BUCKET_ID: X64_0x9F_4_nt!KiSwapContext+7a

ANALYSIS_SOURCE: KM

FAILURE_ID_HASH_STRING: km:x64_0x9f_4_nt!kiswapcontext+7a

FAILURE_ID_HASH: {988e0922-fc98-5cf6-5921-ee45c15cab37}

Followup: MachineOwner

Die "ntkrnlmp.exe", ein Bestandteil des Betriebssystems, ist -wie bereits erwähnt- in den seltensten Fällen für das Problem verantwortlich.

Wir müssen also weiter nachforschen, welcher Treiber den Time-Out verursacht. Mit !locks extension können wir zunächst alle locks aufrufen, die durch Threads gehalten werden:

0: kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks..

Resource @ nt!IopDeviceTreeLock (0xfffff8000367bea0) Shared 1 owning threads
Contention Count = 1
Threads: fffffa800fdf6660-01<*>
KD: Scanning for held locks.

Resource @ nt!PiEngineLock (0xfffff8000367bda0) Exclusively owned
Contention Count = 15
NumberOfExclusiveWaiters = 3
Threads: fffffa800fdf6660-01<*>
Threads Waiting On Exclusive Access:
fffffa800fd6e040 fffffa800fdfd730 fffffa800fd84b50

KD: Scanning for held locks
95036 total locks, 2 locks currently held

Nun wissen wir welcher Thread hierfür verantwortlich ist: Thread fffffa800fdf6660

Als letzten Schritt nun den Stack für diesen Thread auflösen:

0: kd> !thread fffffa800fdf6660
THREAD fffffa800fdf6660 Cid 0004.0040 Teb: 0000000000000000 Win32Thread: 0000000000000000 WAIT: (DelayExecution) KernelMode Non-Alertable
fffffa8014097690 NotificationEvent
Not impersonating
DeviceMap fffff8a0000086f0
Owning Process fffffa800fcf3b30 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 2654032 Ticks: 0
Context Switch Count 3822211 IdealProcessor: 4 NoStackSwap
UserTime 00:00:00.000
KernelTime 00:00:13.119
Win32 Start Address nt!ExpWorkerThread (0xfffff80003481150)
Stack Init fffff8800377ec70 Current fffff8800377e490
Base fffff8800377f000 Limit fffff88003779000 Call 0
Priority 12 BasePriority 12 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
*** ERROR: Module load completed but symbols could not be loaded for btwampfl.sys

Child-SP RetAddr : Args to Child : Call Site
fffff880`0377e4d0 fffff800`0346d5f2 : fffffa80`0fdf6660 fffffa80`0fdf6660 00000000`00000000 00000000`00000008 : nt!KiSwapContext+0x7a
fffff880`0377e610 fffff800`0347d992 : 00000000`00000000 00000000`00000018 00000000`00000050 00000000`00000018 : nt!KiCommitThreadWait+0x1d2
fffff880`0377e6a0 fffff880`0b283a2a : fffffa80`14527770 00000000`00000000 fffffa80`41777400 fffff880`00000050 : nt!KeDelayExecutionThread+0x186
fffff880`0377e710 fffff880`0b28365f : ffffffff`fffe7960 00000000`00000002 fffffa80`146ef030 00000000`00000000 : btwampfl+0x30a2a
fffff880`0377e770 fffff880`0b5623ed : fffffa80`1470ac10 00000000`00000000 fffffa80`1470ac10 fffffa80`14e6e8a0 : btwampfl+0x3065f
fffff880`0377e7e0 fffff880`0b561a92 : fffffa80`1470ac10 00000000`00000000 00000000`00000000 fffffa80`14e6e8a0 : bthport!BthHandleRemoveDevice+0xc1
fffff880`0377e840 fffff880`0b561903 : fffffa80`14e6e8a0 fffff800`00000001 fffff880`0b5778c0 00000000`00000000 : bthport!BthHandlePnp+0x136
fffff880`0377e8b0 fffff800`036e3571 : fffffa80`1470aac0 fffff880`0377e9b8 fffffa80`14e6e8a0 fffffa80`14e6e8a0 : bthport!BthDispatchPnp+0x73
fffff880`0377e900 fffff800`038643a1 : fffffa80`14097060 00000000`00000000 fffffa80`14515890 00000000`00000801 : nt!IopSynchronousCall+0xe1
fffff880`0377e970 fffff800`0357a063 : fffff8a0`33b892d0 fffff8a0`33b892d0 00000000`00000018 00000000`00000000 : nt!IopRemoveDevice+0x101
fffff880`0377ea30 fffff800`03863ef4 : fffffa80`14515890 00000000`00000000 00000000`00000002 00000000`00000000 : nt!PnpRemoveLockedDeviceNode+0x1a3
fffff880`0377ea80 fffff800`03864000 : 00000000`00000000 fffffa80`0fdf6600 fffff8a0`400a4a20 00000000`00000000 : nt!PnpDeleteLockedDeviceNode+0x44
fffff880`0377eab0 fffff800`038640f9 : fffffa80`15797602 fffffa80`15797620 00000000`00000001 fffffa80`15797600 : nt!PnpDeleteLockedDeviceNodes+0xa0
fffff880`0377eb20 fffff800`03481261 : fffff800`03864080 fffff800`0361d2d8 fffffa80`0fdf6600 00000000`00000000 : nt!PnpDelayedRemoveWorker+0x79
fffff880`0377eb70 fffff800`0371373a : 00000000`00000000 fffffa80`0fdf6660 00000000`00000080 fffffa80`0fcf3b30 : nt!ExpWorkerThread+0x111
fffff880`0377ec00 fffff800`034688e6 : fffff880`0356d180 fffffa80`0fdf6660 fffff880`035780c0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`0377ec40 00000000`00000000 : fffff880`0377f000 fffff880`03779000 fffff880`0377e8a0 00000000`00000000 : nt!KxStartSystemThread+0x16

Und da haben wir den Schuldigen: btwampfl.sys

0: kd> lmvm btwampfl
start end module name
fffff880`0b253000 fffff880`0b4dc000 btwampfl (no symbols)
Loaded symbol image file: btwampfl.sys
Image path: \SystemRoot\system32\drivers\btwampfl.sys
Image name: btwampfl.sys
Timestamp: Tue Jul 13 03:41:18 2010 (4C3BC43E)
CheckSum: 0005B643
ImageSize: 00289000
Translations: 0000.04b0 0000.04e4 0409.04b0 0409.04e4

Ein veralteter Broadcom Treiber





Stop 0x124 Fehler (WHEA_UNCORRECTABLE_ERROR).

Nicht immer ist eine Übertaktung die Ursache für den Stop 0x124 Fehler. Grundsätzlich können hierfür auch Temperatur-, oder Spannungsprobleme in Frage kommen. Auch ein fehlerhaftes Bios wäre nicht auszuschließen (allerdings sind mir auch schon fehlerhafte WLAN Module als Ursache untergekommen). Um der tatsächlichen Ursache etwas näher zu kommen bedienen wir uns zunächst dem 1. Argument, in dem wir dies mit der Microsoft Liste abgleichen: Bug Check 0x124: WHEA_UNCORRECTABLE_ERROR (Windows Debuggers)

So steht z.B. das 1. Arg: Arg1: 00000000000000004 für "An uncorrectable PCI Express error occurred". Damit wäre die Ursache beim PCI-E Slot des Boards, oder eines Gerätes in einem dieser Slots (z.B. Grafikkarte) zu suchen.

I.d.R. ist jedoch im 1. Arg. 0000000000000000, Machine Check Exception zu lesen.
Auch hier kann (sofern der PC nicht übertaktet ist!) eine Annäherung an die Absturzursache erfolgen.

Zunächst mit !analyze -V:

2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

WHEA_UNCORRECTABLE_ERROR (124)
A fatal hardware error has occurred. Parameter 1 identifies the type of error
source that reported the error. Parameter 2 holds the address of the
WHEA_ERROR_RECORD structure that describes the error conditon.
Arguments:
Arg1: 0000000000000000, Machine Check Exception
Arg2: fffffa8007fba8f8, Address of the WHEA_ERROR_RECORD structure.
Arg3: 0000000000000000, High order 32-bits of the MCi_STATUS value.
Arg4: 0000000000000000, Low order 32-bits of the MCi_STATUS value.

Debugging Details:
------------------


BUGCHECK_STR: 0x124_AuthenticAMD

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

STACK_TEXT:
fffff880`033a16f0 fffff800`02f0fca9 : fffffa80`07fba8d0 fffffa80`070f3040 00000000`00000006 00000000`00000000 : nt!WheapCreateLiveTriageDump+0x6c
fffff880`033a1c10 fffff800`02df0e87 : fffffa80`07fba8d0 fffff800`02e6a2d8 fffffa80`070f3040 00000000`00000000 : nt!WheapCreateTriageDumpFromPreviousSession+0x49
fffff880`033a1c40 fffff800`02d58285 : fffff800`02ecbae0 00000000`00000001 fffffa80`0714e680 fffffa80`070f3040 : nt!WheapProcessWorkQueueItem+0x57
fffff880`033a1c80 fffff800`02cce251 : fffff880`012d8e00 fffff800`02d58260 fffffa80`070f3000 00000000`00000000 : nt!WheapWorkQueueWorkerRoutine+0x25
fffff880`033a1cb0 fffff800`02f62ede : 00000000`00000000 fffffa80`070f3040 00000000`00000080 fffffa80`0702e740 : nt!ExpWorkerThread+0x111
fffff880`033a1d40 fffff800`02cb5906 : fffff880`03164180 fffffa80`070f3040 fffff880`0316efc0 00000000`00000000 : nt!PspSystemThreadStartup+0x5a
fffff880`033a1d80 00000000`00000000 : fffff880`033a2000 fffff880`0339c000 fffff880`0352b5b0 00000000`00000000 : nt!KiStartSystemThread+0x16


STACK_COMMAND: kb

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: AuthenticAMD

IMAGE_NAME: AuthenticAMD

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAILURE_BUCKET_ID: X64_0x124_AuthenticAMD_PROCESSOR_BUS_PRV

BUCKET_ID: X64_0x124_AuthenticAMD_PROCESSOR_BUS_PRV

Followup: MachineOwner

Hier erhält man schon einen ersten Hinweis auf den Processor Bus.

Noch etwas nähere Informationen erhält man über das Argument 2, der die Fehleradresse enthält (wie oben in der Auswertung zu sehen: Arg2: fffffa8007fba8f8, Address of the WHEA_ERROR_RECORD structure.).

Die Adresse überprüft man mit dem Debug-Befehl !errrec:

2: kd> !errrec fffffa8007fba8f8
===============================================================================
Common Platform Error Record @ fffffa8007fba8f8
-------------------------------------------------------------------------------
Record Id : 01ce8fd38370d3a1
Severity : Fatal (1)
Length : 928
Creator : Microsoft
Notify Type : Machine Check Exception
Timestamp : 8/2/2013 22:56:28 (UTC)
Flags : 0x00000002 PreviousError

===============================================================================
Section 0 : Processor Generic
-------------------------------------------------------------------------------
Descriptor @ fffffa8007fba978
Section @ fffffa8007fbaa50
Offset : 344
Length : 192
Flags : 0x00000001 Primary
Severity : Fatal

Proc. Type : x86/x64
Instr. Set : x64
Error Type : BUS error
Operation : Generic
Flags : 0x00
Level : 3
CPU Version : 0x0000000000100f43
Processor ID : 0x0000000000000000

===============================================================================
Section 1 : x86/x64 Processor Specific
-------------------------------------------------------------------------------
Descriptor @ fffffa8007fba9c0
Section @ fffffa8007fbab10
Offset : 536
Length : 128
Flags : 0x00000000
Severity : Fatal

Local APIC Id : 0x0000000000000000
CPU Id : 43 0f 10 00 00 08 04 00 - 09 20 80 00 ff fb 8b 17
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 - 00 00 00 00 00 00 00 00

Proc. Info 0 @ fffffa8007fbab10

===============================================================================
Section 2 : x86/x64 MCA
-------------------------------------------------------------------------------
Descriptor @ fffffa8007fbaa08
Section @ fffffa8007fbab90
Offset : 664
Length : 264
Flags : 0x00000000
Severity : Fatal

Error : BUSLG_GENERIC_ERR_*_TIMEOUT_ERR (Proc 0 Bank 4)
Status : 0xfa00000000070f0f

Hier kann man nun einen Timeout-Fehler (Prozessor-Bus / Cache Bank #4) erkennen.





Stop 0x7F (1. Argument 0x08 -> Double Fault)

Eine Fehlermeldung, die regelmäßig auf Hardwareprobleme hindeutet. In den seltensten Fällen sind Treiberprobleme hierfür ursächlich. Einen der seltenen Fälle möchte ich hier kurz dokumentieren und zeigen, wie man den Treiber aufdeckt.
Eine Auswertung mittels !analyze -v bringt zunächst keine nachvollziehbare Zuweisung:



1. 0: kd> !analyze -v
2. *******************************************************************************
3. * *
4. * Bugcheck Analysis *
5. * *
6. *******************************************************************************
7.
8. UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)
9. This means a trap occurred in kernel mode, and it's a trap of a kind
10. that the kernel isn't allowed to have/catch (bound trap) or that
11. is always instant death (double fault). The first number in the
12. bugcheck params is the number of the trap (8 = double fault, etc)
13. Consult an Intel x86 family manual to learn more about what these
14. traps are. Here is a *portion* of those codes:
15. If kv shows a taskGate
16. use .tss on the part before the colon, then kv.
17. Else if kv shows a trapframe
18. use .trap on that value
19. Else
20. .trap on the appropriate frame will show where the trap was taken
21. (on x86, this will be the ebp that goes with the procedure KiTrap)
22. Endif
23. kb will then show the corrected stack.
24. Arguments:
25. Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
26. Arg2: 80042000
27. Arg3: 00000000
28. Arg4: 00000000
29.
30. Debugging Details:
31. ------------------
32.
33.
34. BUGCHECK_STR: 0x7f_8
35.
36. CUSTOMER_CRASH_COUNT: 1
37.
38. DEFAULT_BUCKET_ID: DRIVER_FAULT
39.
40. LAST_CONTROL_TRANSFER: from 00000000 to 806e80c4
41.
42. STACK_TEXT:
43. 97896fd0 00000000 00000000 00000000 00000000 hal!HalpIpiHandler+0x7c
44.
45.
46. FOLLOWUP_IP:
47. hal!HalpIpiHandler+7c
48. 806e80c4 89550c mov [ebp+0xc],edx
49.
50. FOLLOWUP_NAME: MachineOwner
51.
52. SYMBOL_NAME: hal!HalpIpiHandler+7c
53.
54. IMAGE_NAME: Unknown_Image
55.
56. DEBUG_FLR_IMAGE_TIMESTAMP: 0
57.
58. STACK_COMMAND: kb
59.
60. BUCKET_ID: ZEROED_STACK
61.
62. MODULE_NAME: Unknown_Module
63.
64. Followup: MachineOwner
65. ---------

Die Bucket_ID "Zeroed_Stack" ist aber einer der -beschrieben- seltenen Fälle, bei denen ein Treiber mit hoher Wahrscheinlichkeit für die Abstürze verantwortlich ist.


Im "Zeroed_Stack" Fall ergänzen wir !analyze -v mit einem "-f" (Force) Befehl. Wir erhalten dann folgende Ausgabe:

1. 1: kd> !analyze -f -v
2. *******************************************************************************
3. * *
4. * Bugcheck Analysis *
5. * *
6. *******************************************************************************
7.
8. UNEXPECTED_KERNEL_MODE_TRAP_M (1000007f)
9. This means a trap occurred in kernel mode, and it's a trap of a kind
10. that the kernel isn't allowed to have/catch (bound trap) or that
11. is always instant death (double fault). The first number in the
12. bugcheck params is the number of the trap (8 = double fault, etc)
13. Consult an Intel x86 family manual to learn more about what these
14. traps are. Here is a *portion* of those codes:
15. If kv shows a taskGate
16. use .tss on the part before the colon, then kv.
17. Else if kv shows a trapframe
18. use .trap on that value
19. Else
20. .trap on the appropriate frame will show where the trap was taken
21. (on x86, this will be the ebp that goes with the procedure KiTrap)
22. Endif
23. kb will then show the corrected stack.
24. Arguments:
25. Arg1: 00000008, EXCEPTION_DOUBLE_FAULT
26. Arg2: ba340d70
27. Arg3: 00000000
28. Arg4: 00000000
29.
30. Debugging Details:
31. ------------------
32.
33.
34. BUGCHECK_STR: 0x7f_8
35.
36. CUSTOMER_CRASH_COUNT: 5
37.
38. DEFAULT_BUCKET_ID: COMMON_SYSTEM_FAULT
39.
40. LAST_CONTROL_TRANSFER: from 805c0de0 to 8054b975
41.
42. STACK_TEXT:
43. 97903040 805c0de0 00000001 0000005c a079654b nt!ExAllocatePoolWithTag+0xd
44. 97903064 805c14de 8630b088 805f1500 00000000 nt!ObpAllocateObject+0xc8
45. 97903098 8062f154 805f1500 89d78040 00000000 nt!ObCreateObject+0x12a
46. 979030f4 8062ff30 e1037008 003fa7e8 00000000 nt!CmpDoOpen+0x19a
47. 979032f4 805bf488 003fa7e8 00000000 860b91d0 nt!CmpParseKey+0x5a6
48. 9790336c 805bba14 00000000 979033ac 00000240 nt!ObpLookupObjectName+0x53c
49. 979033c0 80625696 00000000 89d78040 00000000 nt!ObOpenObjectByName+0xea
50. 979034bc a462357b 97903810 82000000 97903594 nt!NtOpenKey+0x1c8
51. WARNING: Stack unwind information not available. Following frames may be wrong.
52. 979034f0 8054167c 97903810 82000000 97903594 klif+0xe57b
53. 979034f0 80500699 97903810 82000000 97903594 nt!KiFastCallEntry+0xfc
54. 97903574 805e701e 97903810 82000000 97903594 nt!ZwOpenKey+0x11
55. 979037e4 805e712a 00000002 805e70a0 00000000 nt!RtlpGetRegistryHandleAndPath+0x27a
56. 9790382c 805e73e3 9790384c 00000014 97903ba0 nt!RtlpQueryRegistryGetBlockPolicy+0x2e
57. 97903854 805e79eb 00000003 e35e79f4 00000014 nt!RtlpQueryRegistryDirect+0x4b
58. 979038a4 805e7f10 e35e79f4 00000003 97903930 nt!RtlpCallQueryRegistryRoutine+0x369
59. 97903b40 b8aaf1a4 00000005 e1d9dde8 97903ba0 nt!RtlQueryRegistryValues+0x482
60. 97903be8 b8a7485b 00000005 8605e384 8605e484 igxpmp32+0x441a4
61. 97904260 b8a70a7b 89232358 97904290 00000000 igxpmp32+0x985b
62. 97904274 b8a65729 89232358 97904290 00000a0c igxpmp32+0x5a7b
63. 97904338 804ef19f 89232040 8611f228 0000080c VIDEOPRT!pVideoPortDispatch+0xabf
64. 97904348 bf85e8c2 97904610 bf6e6cdc 00000014 nt!IopfCallDriver+0x31
65. 97904378 bf85e93c 89232040 00232150 979043f8 win32k!GreDeviceIoControl+0x93
66. 9790439c bf376769 89232040 00232150 979043f8 win32k!EngDeviceIoControl+0x1f
67. 97905624 bf3b9f19 89232040 bf6a593c bf6a5960 igxpdx32+0x8769
68. 88f41000 00000000 00000000 00000000 00000000 igxpdx32+0x4bf19
69.
70.
71. FOLLOWUP_IP:
72. klif+e57b
73. a462357b e9db000000 jmp klif+0xe65b (a462365b)
74.
75. SYMBOL_STACK_INDEX: 8
76.
77. FOLLOWUP_NAME: MachineOwner
78.
79. SYMBOL_NAME: klif+e57b
80.
81. MODULE_NAME: klif
82.
83. IMAGE_NAME: klif.sys
84.
85. DEBUG_FLR_IMAGE_TIMESTAMP: 4c56e25f
86.
87. STACK_COMMAND: kb
88.
89. FAILURE_BUCKET_ID: 0x7f_8_klif+e57b
90.
91. BUCKET_ID: 0x7f_8_klif+e57b
92.
93. Followup: MachineOwner

Der Debugger gibt nun als Absturzursache die klif.sys aus (Kaspersky). Hier ist es aber einmal mehr wichtig, den Stackverlauf genauer zu betrachten:

52. 979034f0 8054167c 97903810 82000000 97903594 klif+0xe57b53. 979034f0 80500699 97903810 82000000 97903594 nt!KiFastCallEntry+0xfc
54. 97903574 805e701e 97903810 82000000 97903594 nt!ZwOpenKey+0x11
55. 979037e4 805e712a 00000002 805e70a0 00000000 nt!RtlpGetRegistryHandleAndPath+0x27a
56. 9790382c 805e73e3 9790384c 00000014 97903ba0 nt!RtlpQueryRegistryGetBlockPolicy+0x2e
57. 97903854 805e79eb 00000003 e35e79f4 00000014 nt!RtlpQueryRegistryDirect+0x4b
58. 979038a4 805e7f10 e35e79f4 00000003 97903930 nt!RtlpCallQueryRegistryRoutine+0x369
59. 97903b40 b8aaf1a4 00000005 e1d9dde8 97903ba0 nt!RtlQueryRegistryValues+0x482
60. 97903be8 b8a7485b 00000005 8605e384 8605e484 igxpmp32+0x441a4
61. 97904260 b8a70a7b 89232358 97904290 00000000 igxpmp32+0x985b
62. 97904274 b8a65729 89232358 97904290 00000a0c igxpmp32+0x5a7b
63. 97904338 804ef19f 89232040 8611f228 0000080c VIDEOPRT!pVideoPortDispatch+0xabf
64. 97904348 bf85e8c2 97904610 bf6e6cdc 00000014 nt!IopfCallDriver+0x31
65. 97904378 bf85e93c 89232040 00232150 979043f8 win32k!GreDeviceIoControl+0x93
66. 9790439c bf376769 89232040 00232150 979043f8 win32k!EngDeviceIoControl+0x1f
67. 97905624 bf3b9f19 89232040 bf6a593c bf6a5960 igxpdx32+0x8769
68. 88f41000 00000000 00000000 00000000 00000000 igxpdx32+0x4bf19

Diesem ist zu entnehmen, dass auch der iGPU - Treiber am Absturz mit beteiligt ist.

Im vorliegenden Fall hat es ausgereicht den iGPU Treiber zu aktualisieren. Kaspersky konnte auf dem System verbleiben und musste nicht deinstalliert werden.

(wird noch mit weiteren Beispielen ergänzt)





27.08.2014: Stop 0x9F (Arg. 1: 0x04) hinzugefügt
 
Zuletzt bearbeitet:
Auswertungsbeispiele aus der Community

Anfangen möchte ich mit einem aktuellen Problem (Bluescreens), welche(s) durch ein Microsoft Update verursacht wird (Quelle: MS14-045: Description of the security update for kernel-mode drivers: August 12, 2014).

Hierzu wurde ich gefragt, wie man über den Debugger auf die Lösung (Löschen der fntcache.dat) kommen kann.

Die Lösung (löschen der fntcache.dat, oder das Deinstallieren des Updates kbxxxxxxx) wird zwar nicht vom Debugger vorgeschlagen, aber über den Stack-Verlauf kann man darauf kommen:

PAGE_FAULT_IN_NONPAGED_AREA (50)

Arg1: fffff901c069d4c4, memory referenced.
Arg2: 0000000000000000, value 0 = read operation, 1 = write operation.
Arg3: fffff9600009cca3, If non-zero, the instruction address which referenced the bad memory
address.
Arg4: 0000000000000005, (reserved)

FAILURE_BUCKET_ID: X64_0x50_win32k!bLoadFontFile+1f3

STACK_TEXT:
nt!KeBugCheckEx <-- Das ist der Bluescreen/Absturz
nt! ?? ::FNODOBFM::`string'+0x43801
nt!KiPageFault+0x16e <-- Speicherfehler bei einem Lesevorgang (siehe Arg.2)
win32k!bLoadFontFile+0x1f3 <-- Laden der Schriften
win32k!ttfdSemLoadFontFile+0x6b
win32k!PDEVOBJ::LoadFontFile+0x7e
win32k!vLoadFontFileView+0x45b
win32k!PUBLIC_PFTOBJ::bLoadFonts+0x668
win32k!GreAddFontResourceWInternal+0x18e
win32k!NtGdiAddFontResourceW+0x174
nt!KiSystemServiceCopyEnd+0x13
0x7fe`fdcaa88a

Das ist ein ungewöhnlich klares Bild (mehrfache Erwähnung der Fontfile) für ein win32k Problem. Aus dem Stack Verlauf ist auch zu sehen, dass das Laden der Fontfile einen Speicherfehler und damit den Absturz verursacht hat. Grund genug dem LoadFonts mal nach zu gehen. Zu erkennen, dass das Problem mit dem Laden der Schriften zusammenhängen kann ist auch schon der Schlüssel, um auf die Lösung zu kommen.
Bei Problemen mit den Fonts wird regelmäßig empfohlen den Fontcache zu löschen (z.B. über Tante Google zu erfahren). Und hier sind wir bei der "FNTCACHE.DAT", die in diesem Fall zu löschen ist.



Das nächste Beispiel passt zu dem obigen, da es ebenfalls durch Probleme mit den Fonts verursacht wurde:

In diesem Fall traten nachdem der PC komplett neu aufgesetzt willkürlich Bluescreens auf.

BAD_POOL_HEADER (19)
The pool is already corrupt at the time of the current request.
This may or may not be due to the caller.
The internal pool links must be walked to figure out a possible cause of
the problem, and then special pool applied to the suspect tags or the driver
verifier to a suspect driver.
Arguments:
Arg1: 0000000000000020, a pool block header size is corrupt.
Arg2: fffff900c2c5f000, The pool entry we were looking for within the page.
Arg3: fffff900c2c5f240, The next pool entry.
Arg4: 0000000025240000, (reserved)

Debugging Details:
------------------

BUGCHECK_STR: 0x19_20

POOL_ADDRESS: GetPointerFromAddress: unable to read from fffff80002ec0100
GetUlongFromAddress: unable to read from fffff80002ec01c0
fffff900c2c5f000

CUSTOMER_CRASH_COUNT: 2

DEFAULT_BUCKET_ID: WIN7_DRIVER_FAULT

PROCESS_NAME: csrss.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from fffff80002dbbcae to fffff80002c88c00

STACK_TEXT:
fffff880`08237db8 fffff800`02dbbcae : 00000000`00000019 00000000`00000020 fffff900`c2c5f000 fffff900`c2c5f240 : nt!KeBugCheckEx
fffff880`08237dc0 fffff960`000d93f5 : 00000000`00b104a6 00000000`00000000 fffff880`64667454 fffff880`08237f10 : nt!ExDeferredFreePool+0x12da
fffff880`08237e70 fffff960`000e1df4 : 00000000`00b104a6 fffff880`08237f20 00000000`00000000 00000000`00b10012 : win32k!EngFreeMem+0x21
fffff880`08237ea0 fffff960`000d913b : fffff900`c0760030 00000000`00000001 00000000`00000001 00000000`00000000 : win32k!bLoadGlyphSet+0x104
fffff880`08237ed0 fffff960`000d92da : fffff900`c0760030 fffff900`00000001 fffff900`c0760030 fffff960`0024c244 : win32k!bReloadGlyphSet+0x24b
fffff880`08238590 fffff960`000d9232 : 00000000`00000000 fffff900`c0760030 fffff900`00000001 00000000`00000000 : win32k!ttfdQueryFontTree+0x66
fffff880`082385e0 fffff960`001260d3 : fffff960`000d91d8 fffff900`c075f510 00000000`00000001 00000000`00000000 : win32k!ttfdSemQueryFontTree+0x5a
fffff880`08238620 fffff960`00125f73 : fffff880`08238730 00000000`00000000 00000000`00000000 00000000`00000000 : win32k!PDEVOBJ::QueryFontTree+0x63
fffff880`082386a0 fffff960`000e0036 : fffff900`c008a010 00000000`00000000 00000000`00000002 00000000`00000000 : win32k!PFEOBJ::pfdg+0xa3
fffff880`08238700 fffff960`0013a6e0 : fffff900`c1d29010 fffff880`08238990 fffff880`08238890 fffff880`082389e0 : win32k!RFONTOBJ::bRealizeFont+0x46
fffff880`08238820 fffff960`0010b161 : 00000000`10010000 fffff900`00000000 00000433`00000000 ffffffff`00000002 : win32k!RFONTOBJ::bInit+0x548
fffff880`08238940 fffff960`0010b0f7 : fffff900`c0081000 fffff880`08238b60 00000000`64616568 00000000`00a40099 : win32k!ulGetFontData2+0x31
fffff880`082389b0 fffff960`0010b00d : 00000000`ffffffff 00000000`ffffffff fffffa80`08562b90 00000000`000121dd : win32k!ulGetFontData+0x7f
fffff880`08238a00 fffff800`02c87e93 : ffffffff`80010433 fffffa80`07807b50 00000000`0b00e6c8 00000980`00000000 : win32k!NtGdiGetFontData+0x8d
fffff880`08238a70 00000000`73400b4a : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KiSystemServiceCopyEnd+0x13
00000000`0b00e6a8 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x73400b4a

STACK_COMMAND: kb

FOLLOWUP_IP:
win32k!EngFreeMem+21
fffff960`000d93f5 4883c420 add rsp,20h

SYMBOL_STACK_INDEX: 2
SYMBOL_NAME: win32k!EngFreeMem+21
FOLLOWUP_NAME: MachineOwner

MODULE_NAME: win32k
IMAGE_NAME: win32k.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 51302206
FAILURE_BUCKET_ID: X64_0x19_20_win32k!EngFreeMem+21
BUCKET_ID: X64_0x19_20_win32k!EngFreeMem+21

Die Auswertung bringt zunächst nur die win32k.sys als Ursache.

Beim genauen betrachten des Stackverlaufs:

6: kd> k
Child-SP RetAddr Call Site
fffff880`08237db8 fffff800`02dbbcae nt!KeBugCheckEx
fffff880`08237dc0 fffff960`000d93f5 nt!ExDeferredFreePool+0x12da
fffff880`08237e70 fffff960`000e1df4 win32k!EngFreeMem+0x21
fffff880`08237ea0 fffff960`000d913b win32k!bLoadGlyphSet+0x104
fffff880`08237ed0 fffff960`000d92da win32k!bReloadGlyphSet+0x24b
fffff880`08238590 fffff960`000d9232 win32k!ttfdQueryFontTree+0x66
fffff880`082385e0 fffff960`001260d3 win32k!ttfdSemQueryFontTree+0x5a
fffff880`08238620 fffff960`00125f73 win32k!PDEVOBJ::QueryFontTree+0x63
fffff880`082386a0 fffff960`000e0036 win32k!PFEOBJ::pfdg+0xa3
fffff880`08238700 fffff960`0013a6e0 win32k!RFONTOBJ::bRealizeFont+0x46
fffff880`08238820 fffff960`0010b161 win32k!RFONTOBJ::bInit+0x548
fffff880`08238940 fffff960`0010b0f7 win32k!ulGetFontData2+0x31
fffff880`082389b0 fffff960`0010b00d win32k!ulGetFontData+0x7f
fffff880`08238a00 fffff800`02c87e93 win32k!NtGdiGetFontData+0x8d
fffff880`08238a70 00000000`73400b4a nt!KiSystemServiceCopyEnd+0x13
00000000`0b00e6a8 00000000`00000000 0x73400b4a

ist wie (fettgedruckt) zu sehen auch hier ein verdächtig aussehendes Problem mit den Fonts zu beobachten.
Die Auswertung aller Dumps brachte immer das gleiche Ergebnis, mit dem Font-Problem im Stack.

Die Zuordnung des Pools (Arg2: fffff900c2c5f000, The pool entry we were looking for within the page) bestätigt die Vermutung:

6: kd> !pool fffff900c2c5f000
Pool page fffff900c2c5f000 region is Unknown
*fffff900c2c5f000 size: 240 previous size: 0 (Free ) *Ttfd
Pooltag Ttfd : TrueType Font driver

fffff900c2c5f240 doesn't look like a valid small pool allocation, checking to see
if the entire page is actually part of a large page allocation...

GetUlongFromAddress: unable to read from fffff80002e2ea38
Unable to get pool big page table. Check for valid symbols.
fffff900c2c5f240 is not valid pool. Checking for freed (or corrupt) pool
Bad allocation size @fffff900c2c5f240, zero is invalid

6: kd> dc fffff900c2c5f240
fffff900`c2c5f240 00000031 00000032 00000033 00000034 1...2...3...4...
fffff900`c2c5f250 00000035 00000036 00000037 00000038 5...6...7...8...
fffff900`c2c5f260 00000039 0000003a 0000003b 0000003c 9...:...;...<...
fffff900`c2c5f270 0000003d 0000003e 0000003f 00000040 =...>...?...@...
fffff900`c2c5f280 00000041 00000042 00000043 00000044 A...B...C...D...
fffff900`c2c5f290 00000045 00000046 00000047 00000048 E...F...G...H...
fffff900`c2c5f2a0 00000000 00000000 00000000 00000000 ................
fffff900`c2c5f2b0 00000000 00000000 00000000 00000000 .......

Auch in diesem Fall konnte das Problem durch das Löschen des Fontcache gelöst werden.

Ohne den Stackverlauf wäre man vermutlich nicht auf die Lösung des Problems gekommen.
Auch dies zeigt einmal mehr, wie wichtig der Stackverlauf bei der Auswertung ist und dass derartige Fehler nicht mit anderen Auswertungstools (Bluescreenview, etc.) zu lösen sind.




Hier ein Beispiel für einen Driver Power State Fehler. Wie diese auszuwerten sind, habe ich im Beitrag #3 (0x9F (driver_power_state_failure) - 1. Arg: 0x03) genauer erläutert. Dieser Fall war nun etwas spezieller:

Das ist der Thread, über den ich Berichte: http://extreme.pcgameshardware.de/w...er-power-state-failure-windows-8-1-64bit.html

Die Absturzursache ermittelt durch Bluescreenview ergibt:

Bluescreenview.png

Nur nonsens.

Mit den Debugging Tools und Analyz -V erhalten wir zunächst auch nichts genaues:

*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time (usually 10 minutes).
Arguments:
Arg1: 0000000000000003, A device object has been blocking an Irp for too long a time
Arg2: ffffe001a7c95ca0, Physical Device Object of the stack
Arg3: fffff80261a6f960, nt!TRIAGE_9F_POWER on Win7, otherwise the Functional Device Object of the stack
Arg4: ffffe001a2919790, The blocked IRP

Debugging Details:
------------------

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

DRVPOWERSTATE_SUBCODE: 3

IMAGE_NAME: UsbHub3.sys

DEBUG_FLR_IMAGE_TIMESTAMP: 53d0f163

MODULE_NAME: UsbHub3

FAULTING_MODULE: fffff8000d32d000 UsbHub3

CUSTOMER_CRASH_COUNT: 1

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

BUGCHECK_STR: 0x9F

PROCESS_NAME: System

CURRENT_IRQL: 2

STACK_TEXT:
fffff802`61a6f928 fffff802`6000e36e : 00000000`0000009f 00000000`00000003 ffffe001`a7c95ca0 fffff802`61a6f960 : nt!KeBugCheckEx
fffff802`61a6f930 fffff802`6000e28e : ffffe001`a39cfa70 fffff802`605a339a ffffe001`a9bfe9f0 fffff802`5fef9c19 : nt!PopIrpWatchdogBugcheck+0xde
fffff802`61a6f990 fffff802`5fe7de67 : 00000000`00000000 fffff802`61a6fae0 ffffe001`a39cfab0 ffffe001`a34710f8 : nt!PopIrpWatchdog+0x32
fffff802`61a6f9e0 fffff802`5ff5acea : fffff802`60108180 fffff802`60108180 fffff802`60161a00 ffffe001`a7c7f880 : nt!KiRetireDpcList+0x4f7
fffff802`61a6fc60 00000000`00000000 : fffff802`61a70000 fffff802`61a6a000 00000000`00000000 00000000`00000000 : nt!KiIdleLoop+0x5a


STACK_COMMAND: kb

FOLLOWUP_NAME: MachineOwner

FAILURE_BUCKET_ID: X64_0x9F_3_ACPI_IMAGE_UsbHub3.sys

BUCKET_ID: X64_0x9F_3_ACPI_IMAGE_UsbHub3.sys

Followup: MachineOwner

Demnach wurde der Absturz durch den Usbhub3 Treiber ausgelöst.

Erst die Auflösung nach den IRPs bringt etwas genaueres:

0: kd> !irp ffffe001a2919790
Irp is active with 20 stacks 16 is current (= 0xffffe001a2919c98)
No Mdl: No System Buffer: Thread 00000000: Irp stack trace.
cmd flg cl Device File Completion-Context
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-00000000

Args: 00000000 00000000 00000000 00000000
>[ 16, 2] 0 e1 ffffe001a81e9e50 00000000 fffff8000d9c1aa8-ffffe001a83dd180 Success Error Cancel pending
\Driver\ACPI bcbtums
Args: 00000000 00000001 00000001 00000000
Unable to load image \SystemRoot\system32\DRIVERS\btwampfl.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for btwampfl.sys
*** ERROR: Module load completed but symbols could not be loaded for btwampfl.sys
[ 16, 2] 0 e0 ffffe001a83dd030 00000000 fffff8000d40afb8-ffffe001a83a5180 Success Error Cancel
\Driver\bcbtums btwampfl
Args: 00000000 00000001 00000001 00000000
[ 16, 2] 0 e0 ffffe001a83a5030 00000000 fffff8000daa7e40-00000000 Success Error Cancel
\Driver\btwampfl bthport!DevicePowerUpComplete
Args: 00000000 00000001 00000001 00000000
[ 16, 2] 0 e1 ffffe001a84979d0 00000000 fffff8025ff28c30-ffffe001a39cfa70 Success Error Cancel pending
\Driver\BTHUSB nt!PopRequestCompletion
Args: 00000000 00000001 00000001 00000000
[ 0, 0] 0 0 00000000 00000000 00000000-ffffe001a39cfa70

Args: 00000000 00000000 00000000 00000000

Aha...der Bluetoothtreiber. Hier fällt allerdings auch noch auf, dass möglicherweise ein Problem mit der Energieverwaltung vorliegt: "ACPI bcbtums"

Löst man nun weiter nach dem Device Stack auf, erhält man folgendes Ergebnis:

0: kd> !devstack ffffe001a7c95ca0
!DevObj !DrvObj !DevExt ObjectName
ffffe001a84979d0 \Driver\BTHUSB ffffe001a8497b20 InfoMask field not found for _OBJECT_HEADER at ffffe001a84979a0

ffffe001a83a5030 \Driver\btwampfl ffffe001a83a5180 InfoMask field not found for _OBJECT_HEADER at ffffe001a83a5000

ffffe001a83dd030 \Driver\bcbtums ffffe001a83dd180 InfoMask field not found for _OBJECT_HEADER at ffffe001a83dd000

ffffe001a81b8040 Unable to load image \SystemRoot\SysWow64\drivers\ASUSFILTER.sys, Win32 error 0n2
*** WARNING: Unable to verify timestamp for ASUSFILTER.sys
*** ERROR: Module load completed but symbols could not be loaded for ASUSFILTER.sys
\Driver\ASUSFILTER ffffe001a81b8190
ffffe001a81e9e50 \Driver\ACPI ffffe001a27e9910 InfoMask field not found for _OBJECT_HEADER at ffffe001a81e9e20

> ffffe001a7c95ca0 \Driver\USBHUB3 ffffe001a7c98c30 Cannot read info offset from nt!ObpInfoMaskToOffset

!DevNode ffffe001a81b8d30 :
DeviceInst is "USB\VID_0B05&PID_180A\40E23013C82B"
ServiceName is "BTHUSB"

Da hat wohl irgendein Asus Tool die Finger im Spiel. Leztendlich (wie im verlinkten Thread nachzulesen) war es die Asus AI-Suite 3, die diese Probleme verursacht hat. Nach Deinstallation des Tools traten keine Abstürze mehr auf.





Hier ein Problem (Stop 0x9F, 1. Arg. 0x04) mit einem Treiber, der sich excellent versteckt. Der User klagte über Netzwerkausfälle und Bluescreens beim Herunterfahren.

Eins vorneweg, für diese Auswertung, wird ein mindestens ein Kernelspeicherabbild, oder ein vollständiges Speicherabbild (MEMORY.DMP) benötigt. Die Minidump enthält nicht die hier abgerufenen Informationen.

!analyze -v überspringe ich gleich mal und zeige das Ergebnis nach dem Aufruf der Locks und dem Auflösen nach dem entsprechenden Thread (näheres dazu siehe "Auswertungsbeispiele -> Stop 0x9F (Arg. 1: 0x04) "The power transition timed out waiting to synchronize with the Pnp subsystem.").

2: kd> !locks
**** DUMP OF ALL RESOURCE OBJECTS ****
KD: Scanning for held locks..
Resource @ nt!IopDeviceTreeLock (0xfffff8001b2f4120) Shared 1 owning threads
Threads: ffffe001eb3d0040-01<*>
KD: Scanning for held locks.
Resource @ nt!PiEngineLock (0xfffff8001b2f4220) Exclusively owned
Contention Count = 34
NumberOfExclusiveWaiters = 1
Threads: ffffe001eb3d0040-01<*>
Threads Waiting On Exclusive Access:
ffffe001ead44880
KD: Scanning for held locks............................................. .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. .................................................. ...........
22627 total locks, 2 locks currently held
2: kd> !thread ffffe001eb3d0040-01
ffffe001eb3d003f is not a thread object, interpreting as stack value...
TYPE mismatch for thread object at ffffe001eb3d003f
2: kd> !thread ffffe001eb3d0040
THREAD ffffe001eb3d0040 Cid 0004.0918 Teb: 0000000000000000 Win32Thread: 0000000000000000 WAIT: (Executive) KernelMode Non-Alertable
ffffe001eb3ab608 NotificationEvent
Not impersonating
DeviceMap ffffc0002500c320
Owning Process ffffe001e4c428c0 Image: System
Attached Process N/A Image: N/A
Wait Start TickCount 415469 Ticks: 19200 (0:00:05:00.000)
Context Switch Count 204 IdealProcessor: 1 NoStackSwap
UserTime 00:00:00.000
KernelTime 00:00:00.015
Win32 Start Address nt!ExpWorkerThread (0xfffff8001b0bd430)
Stack Init ffffd000224b7c90 Current ffffd000224b6ee0
Base ffffd000224b8000 Limit ffffd000224b2000 Call 0
Priority 15 BasePriority 12 UnusualBoost 0 ForegroundBoost 0 IoPriority 2 PagePriority 5
Child-SP RetAddr : Args to Child : Call Site
ffffd000`224b6f20 fffff800`1b0c11de : ffffd000`48b8e180 ffffe001`eb3d0040 00000000`fffffffe 00000000`fffffffe : nt!KiSwapContext+0x76
ffffd000`224b7060 fffff800`1b0c0c59 : 7fffe001`eb3ab600 ffffe001`eb3ab600 00000000`00000001 ffffd000`224b7254 : nt!KiSwapThread+0x14e
ffffd000`224b7100 fffff800`1b064e50 : ffffe001`e9bb5600 00000000`00000000 ffffe001`e9bb5558 ffffc000`25196760 : nt!KiCommitThreadWait+0x129
ffffd000`224b7180 fffff801`8b113d0e : ffffe001`eb3ab608 fffff800`00000000 00000000`00000000 00000000`00000000 : nt!KeWaitForSingleObject+0x2c0
ffffd000`224b7210 fffff801`8b10c917 : 00000000`00000000 ffffe001`eb3ab600 ffffc000`254731f0 00000000`00000000 : ndis!KWaitEvent::Wait+0x22
ffffd000`224b7250 fffff801`8b1434ca : ffffc000`2759f018 ffffc000`2c182538 00000000`00060003 fffff801`8b117070 : ndis!Ndis::BindEngine::ApplyBindChanges+0xffffffff `ffffffe7
ffffd000`224b72a0 fffff801`8b1174ce : ffffc000`2759f068 00000000`00000000 ffffc000`2c182538 ffffe001`eb3aa1a0 : ndis!<lambda_1ce06b2b40968439b229a98218e85867>::<h elper_func_cdecl>+0x1b
ffffd000`224b72d0 fffff801`8b117417 : 00000000`00000000 00000000`00000000 00000000`00000000 ffffc000`2c182530 : ndis!NDIS_BIND_DRIVER_BASE::ForEachLink+0x9e
ffffd000`224b7320 fffff801`8b11758a : ffffc000`2c182528 ffffe001`ed6bdc10 ffffd000`224b7438 fffff801`8b100cab : ndis!NDIS_BIND_DRIVER_BASE::SetRunningDriverIsRead y+0x3f
ffffd000`224b7350 fffff801`8b153392 : ffffe001`ed6bdc10 ffffe001`e5fff020 ffffd000`224b7438 ffffe001`e4c428c0 : ndis!NDIS_BIND_PROTOCOL_DRIVER::SetRunningDriver+0 x5a
ffffd000`224b73a0 fffff801`8b136d2b : ffffe001`ed6bdc10 00000000`00000000 00000000`00000000 fffff801`8d9ef200 : ndis!NdisDeregisterProtocol+0xa2
ffffd000`224b7400 fffff801`8d9e8262 : fffff801`8d9ef010 ffffe001`00000000 e001ecb9`33700000 0000001b`00000001 : ndis!NdisDeregisterProtocolDriver+0x3c
ffffd000`224b7430 fffff801`8d9f28a0 : 00000000`20206f49 ffffe001`e4c428c0 00000000`00000000 00000000`00000001 : raspppoe!RasPppoeCleanup+0x5a
ffffd000`224b7460 fffff801`8b1144ea : ffffe001`e5fff020 ffffd000`224b7710 00000000`00000ec4 fffff800`1b4392e6 : raspppoe!MpUnload+0x44
ffffd000`224b7490 fffff801`8b114452 : ffffe001`ecb933a0 fffff800`1b135659 00000000`00000000 ffffd000`224b7540 : ndis!ndisMInvokeDriverUnload+0x26
ffffd000`224b74c0 fffff800`1b4f3e4b : ffffe001`ecb933a0 00000000`00000000 ffffd000`224b7710 00000000`00000000 : ndis!ndisMUnloadEx+0x56
ffffd000`224b7500 fffff800`1b4b670d : 00000000`65647050 ffffe001`ecb934f0 00000000`0000007c ffffc000`34cf1c60 : nt!IopUnloadDriver+0x23f
ffffd000`224b76e0 fffff800`1b122a76 : ffffe001`e552a600 ffffdffe`54b80b50 ffffe001`e552a600 00000000`0000000a : nt!PnpUnloadAttachedDriver+0x9d
ffffd000`224b7730 fffff800`1b4d74f1 : ffffe001`e6182b00 ffffe001`e552a600 ffffc000`355b2d20 ffffc000`35a2e1c0 : nt!PnpRemoveLockedDeviceNode+0x222
ffffd000`224b7790 fffff800`1b4d746a : 00000000`00000000 ffffc000`355b2d20 ffffe001`e552a600 fffff800`1b4d7301 : nt!PnpDeleteLockedDeviceNode+0x4d
ffffd000`224b77d0 fffff800`1b4d877c : ffffe001`eca15e40 00000000`00000002 ffffe001`ec09ef10 fffff800`00000000 : nt!PnpDeleteLockedDeviceNodes+0x9a
ffffd000`224b7850 fffff800`1b4d868d : ffffe001`ec09ef10 00000000`00000000 00000000`00000001 ffffe001`eca15e40 : nt!PnpDelayedRemoveWorker+0xc4
ffffd000`224b78a0 fffff800`1b1227ac : 00000000`0000000a 00000000`00000008 00000000`00000000 00000000`00000007 : nt!PnpChainDereferenceComplete+0x119
ffffd000`224b78d0 fffff800`1b4d6b44 : 00000000`00000000 00000000`ffffffff ffffe001`00000018 00000000`00000001 : nt!PnpIsChainDereferenced+0x10c
ffffd000`224b7950 fffff800`1b48240d : ffffc000`29450a00 00000000`00000008 ffffc000`00000003 00000000`ffffffff : nt!PnpProcessQueryRemoveAndEject+0x800
ffffd000`224b7ab0 fffff800`1b482853 : ffffc000`29450ac0 00000000`00000000 00000000`00000000 00000000`00000000 : nt!PnpProcessTargetDeviceEvent+0x9d
ffffd000`224b7af0 fffff800`1b0bd6bc : fffff800`1b482534 ffffc000`2aec02d0 ffffe001`eb458830 ffffe001`eb3d0040 : nt!PnpDeviceEventWorker+0x31f
ffffd000`224b7b50 fffff800`1b11036c : 34e81d2e`30e64650 ffffe001`eb3d0040 00000000`00000080 ffffe001`eb3d0040 : nt!ExpWorkerThread+0x28c
ffffd000`224b7c00 fffff800`1b1672c6 : fffff800`1b313180 ffffe001`eb3d0040 ffffe001`e5a8c880 86c47245`8be0aaf1 : nt!PspSystemThreadStartup+0x58
ffffd000`224b7c60 00000000`00000000 : ffffd000`224b8000 ffffd000`224b2000 00000000`00000000 00000000`00000000 : nt!KiStartSystemThread+0x16

Außer einem Netzwerkproblem (ndis; raspppoe) ist hier nichts zu erkennen.

Also schauen wir uns mal die Netzwerkadapter an. Diese können wir mittels folgendem Befehl aufrufen:

2: kd> !ndiskd.miniport
MiniDriver Miniport Name
ffffe001e9cdd2c0 ffffe001e61f61a0 WAN-Miniport (PPTP)
ffffe001ecb52020 ffffe001e566a1a0 WAN-Miniport (L2TP)
ffffe001e7bb42c0 ffffe001ed5b21a0 WAN-Miniport (IKEv2)
ffffe001eb2fc220 ffffe001eb3aa1a0 Virtueller Microsoft-Adapter für direktes WiFi
ffffe001eb2fc220 ffffe001eb0a21a0 Von Microsoft gehosteter, virtueller Netzwerkadapter
ffffe001e96c0ba0 ffffe001e9bb41a0 Qualcomm Atheros AR5BWB222 Wireless Network Adapter

Zu sehen ist hier ein Qualcom Atheros WLAN Adapter.
Ein Blick auf den Treiber:

2: kd> !ndiskd.minidriver ffffe001e96c0ba0
MINIPORT DRIVER
athr
Ndis handle ffffe001e96c0ba0
Driver Context NULL
DRIVER_OBJECT ffffe001e96c0410
Driver image athwbx.sys
Registry path \REGISTRY\MACHINE\SYSTEM\ControlSet001\Services\at hr
Reference Count 2
Flags [No flags set]

MINIPORTS
Miniport
ffffe001e9bb41a0 - Qualcomm Atheros AR5BWB222 Wireless Network Adapter
Handlers
Device objects

Ein weiterer Blick auf das Gerät selbst (und die "Bindings") zeigt dieses Bild:

2: kd> !ndiskd.miniport ffffe001e9bb41a0

MINIPORT
Qualcomm Atheros AR5BWB222 Wireless Network Adapter
Ndis handle ffffe001e9bb41a0
Ndis API version v6.40
*** ERROR: Module load completed but symbols could not be loaded for athwbx.sys
Adapter context ffffe001e98e3030
Miniport driver ffffe001e96c0ba0 - athr v1.9
Network interface ffffe001e7afa010
Media type 802.3
Physical medium Native802.11
Device instance PCI\VEN_168C&DEV_0034&SUBSYS_E052105B&REV_01\4&2b0 53bd4&0&00E1
Device object ffffe001e9bb4050 More information
MAC address 08-3e-8e-22-5b-db

STATE
Miniport Running
Device PnP Started Show state history
Datapath Normal
Interface Up
Media Connected
Power D0
References 0n369 Show detail
Total resets 0
Pending OID None
Flags BUS_MASTER, SG_DMA, CHECK_FOR_LOOPBACK,
DEFAULT_PORT_ACTIVATED, SUPPORTS_MEDIA_SENSE,
DOES_NOT_DO_LOOPBACK, MEDIA_CONNECTED
PnP flags PM_SUPPORTED, DEVICE_POWER_ENABLED, RECEIVED_START,
HARDWARE_DEVICE

BINDINGS
Bind operations are in progress Switch to the bind thread
Protocol list Driver Open Context
TCPIP6 ffffe001e7b0e500 ffffe001e9ba7c10 ffffe001e4c0e050
TCPIP ffffe001e7afa620 ffffe001eb1b3c10 ffffe001eb1e61a0
(PacketDriver) ffffe001eba693d0 Binding disabled by INetCfg
(PacketDriver) ffffe001eba693d0 Will bind soon
*** ERROR: Module load completed but symbols could not be loaded for npf.sys

PacketDriver ffffe001eba693d0 ffffe001eccf55d0 ffffe001ed385000
PacketDriver ffffe001eba693d0 ffffe001ecbe17f0 ffffe001ed5f1000
PacketDriver ffffe001eba693d0 ffffe001ed718c10 ffffe001ed373000
PacketDriver ffffe001eba693d0 ffffe001ed3b4c10 ffffe001ed35d000
PacketDriver ffffe001eba693d0 ffffe001e565e8a0 ffffe001ed34c000
PacketDriver ffffe001eba693d0 ffffe001ec8d43f0 ffffe001ed5ca000
PacketDriver ffffe001eba693d0 ffffe001e5a953d0 ffffe001ed340000
PacketDriver ffffe001eba693d0 ffffe001ecdb5010 ffffe001ed31f000
(* gekürzt *)
PacketDriver ffffe001eba693d0 ffffe001e55ea6c0 ffffe001e525b000
(PacketDriver) ffffe001eba693d0 Binding disabled by INetCfg
PacketDriver ffffe001eba693d0 ffffe001e56c4c10 ffffe001e5219000
PacketDriver ffffe001eba693d0 ffffe001ebb1e010 ffffe001e4e11000
(RDMANDK) Not running
NDISUIO ffffe001e9b0d6c0 ffffe001eb1fcc10 ffffe001eb1aa010
RSPNDR ffffe001eb1fec10 ffffe001eb1aa440 ffffe001eb1fa010
LLTDIO ffffe001eb1b8c10 ffffe001eb1abc10 ffffe001eb1aca30
(RASPPPOE) ffffe001ed6bdc10
Filter list Driver Module Context
WFP 802.3 MAC Layer LightWeight Filter-0000
ffffe001e4c23370 ffffe001e9ba5840 ffffe001e4c0e630
QoS Packet Scheduler-0000
ffffe001e959f5f0 ffffe001e98adc70 ffffe001eb0a5810
Native WiFi Filter Driver-0000
ffffe001eb19fd80 ffffe001eb19d560 ffffe001eb199810
Virtual WiFi Filter Driver-0000
ffffe001e958c510 ffffe001eb1a3010 ffffe001eb19b010
WFP Native MAC Layer LightWeight Filter-0000
ffffe001e4c230d0 ffffe001eb19f610 ffffe001eb19e630

Hier scheint die npf.sys querzuschießen (in der Grundauswertung mittels !analyze -v wird dies nicht erkannt und als Verdächtiger nur die raspppoe.sys ausgegeben).

Ein Blick auf das Protokoll:

2: kd> !ndiskd.protocol ffffe001eba693d0

PROTOCOL
PACKETDRIVER
Ndis handle ffffe001eba693d0
Ndis API version v5.0
Reference count 0n1028
Flags [No flags set]
Driver image [Not available] Why not?

BINDINGS
Open Miniport Miniport Name
ffffe001e5aa7120 ffffe001eb3aa1a0 Virtueller Microsoft-Adapter für direktes WiFi
ffffe001eca96620 ffffe001e9bb41a0 Qualcomm Atheros AR5BWB222 Wireless Network Adapter
ffffe001e536dc10 ffffe001eb0a21a0 Von Microsoft gehosteter, virtueller Netzwerkadapter
ffffe001ed3a4870 ffffe001eb3aa1a0 Virtueller Microsoft-Adapter für direktes WiFi
ffffe001ecbe17f0 ffffe001e9bb41a0 Qualcomm Atheros AR5BWB222 Wireless Network Adapter
ffffe001e9d1bc10 ffffe001eb0a21a0 Von Microsoft gehosteter, virtueller Netzwerkadapter
ffffe001ed88fc10 ffffe001eb3aa1a0 Virtueller Microsoft-Adapter für direktes WiFi
ffffe001eccf55d0 ffffe001e9bb41a0 Qualcomm Atheros AR5BWB222 Wireless Network Adapter
ffffe001ed39fc10 ffffe001eb0a21a0 Von Microsoft gehosteter, virtueller Netzwerkadapter
ffffe001e6102350 ffffe001eb3aa1a0 Virtueller Microsoft-Adapter für direktes WiFi
ffffe001ed718c10 ffffe001e9bb41a0 Qualcomm Atheros AR5BWB222 Wireless Network Adapter
ffffe001ed5a3c10 ffffe001eb0a21a0 Von Microsoft gehosteter, virtueller Netzwerkadapter
ffffe001ecc16480 ffffe001eb3aa1a0 Virtueller Microsoft-Adapter für direktes WiFi
ffffe001ed3b4c10 ffffe001e9bb41a0 Qualcomm Atheros AR5BWB222 Wireless Network Adapter
ffffe001ed3eec10 ffffe001eb0a21a0 Von Microsoft gehosteter, virtueller Netzwerkadapter
ffffe001ecbaf9e0 ffffe001eb3aa1a0 Virtueller Microsoft-Adapter für direktes WiFi
ffffe001e565e8a0 ffffe001e9bb41a0 Qualcomm Atheros AR5BWB222 Wireless Network Adapter
ffffe001ecebec10 ffffe001eb0a21a0 Von Microsoft gehosteter, virtueller Netzwerkadapter
ffffe001ed5a8c10 ffffe001eb3aa1a0 Virtueller Microsoft-Adapter für direktes WiFi
ffffe001ec8d43f0 ffffe001e9bb41a0 Qualcomm Atheros AR5BWB222 Wireless Network Adapter

HANDLERS
Protocol handler Function pointer Symbol (if available)
BindAdapterHandler fffff8018d9dd548 npf+4548
UnbindAdapterHandler fffff8018d9dc2dc npf+32dc
PnPEventHandler fffff8018d9dc2b4 npf+32b4
UnloadHandler [None]
OpenAdapterCompleteHandler fffff8018d9dc13c npf+313c
CloseAdapterCompleteHandler fffff8018d9dc2a0 npf+32a0
SendCompleteHandler fffff8018d9ddb64 npf+4b64
TransferDataCompleteHandler fffff8018d9dd3b8 npf+43b8
ReceiveHandler fffff8018d9dca38 npf+3a38
ReceivePacketHandler [None]
ReceiveCompleteHandler fffff8018d9dd548 npf+4548
StatusHandler fffff8018d9dd548 npf+4548
StatusCompleteHandler fffff8018d9dd548 npf+4548
RequestCompleteHandler fffff8018d9db788 npf+2788
ResetCompleteHandler fffff8018d9dc320 npf+3320

...zeigt, dass die npf.sys ziemlich viel mitzuschwätzen hat.

Ein Blick auf die Treiberliste von John Carronas Webseite (siehe hilfreiche Webseiten) bringt den Hinweis, dass die Datei mit der Software von Netgear "NetgearGenie" etwas zu tun haben könnte.
Und tatsächlich, nach Deinstallation von NetgearGenie traten die Probleme nicht mehr auf




16.09.2014: Beispiel zu BAD_POOL_HEADER (19) hinzugefügt
19.11.2014: Beispiel zu DRIVER_POWER_STATE_FAILURE (9f) hinzugefügt
10.06.2014: Beispiel zu DRIVER_POWER_STATE_FAILURE (9f; 0x04) hinzugefügt
 
Zuletzt bearbeitet:
AW: [HowTo] Bluescreenauswertung

Herzlichen Dank, simpel1970, für deine Anleitung. :daumen: Das war eine Menge Arbeit, die du da für die Community geleistet hast.
 
AW: [HowTo] Bluescreenauswertung

Auch wenn es an eine Graböffnung erinnert.
Ich versuche mich gerade etwas mit den Minidumps zu beschäftigen und dein Thread hier ist da eine brutale Hilfe:hail:
 
Zurück