Debugging-Fallen unter Windows

Heute habe ich noch einen Beitrag für Leute, die sich mit dem Thema Debugging unter Windows auseinander setzen. Blog-Leser Michael Bormann hat mir dankenswerter Weise die entsprechenden Informationen zukommen lassen.

Wenn unter Windows Bluescreens auftreten, kann man die generierten Dump-Dateien im Windows-Debugger analysieren. Erfordert ein wenig Erfahrung und Pertinenz. Hier im Blog habe ich den einen oder anderen Artikel rund um Debugging und den Windows Debugger publiziert (siehe Linkliste am Artikelende). Aber auch Leute, die sich mit dem Debugger sehr gut auskennen, schießen sich mitunter bei der Analyse der Dump-Dateien in den Fuß. Michael hat mal ein wenig aus dem Nähkästchen geplaudert.

Hintergrund-Info: Michael ackert nicht nur mit dem Debugger, um Crash-Dumps zu analysieren, sondern hat sein Wissen in einem Buch zusammen gefasst (siehe meinen Hinweis im Blog-Beitrag Windows BlueScreen-Analyse – Teil 3 oder diesen Google Books-Eintrag). Nach meinen Informationen schreibt er nun an einem zweiten Buchtitel zum Debuggen.

Nachfolgend lasse ich nun Michael Bormann zu Wort kommen. Ich stelle seinen Text unverändert hier ein. Nur die Zwischenüberschriften und was im Text in […] steht, wurde von mir eingefügt. Wer mit dem Windows Debugger windbg auf Du und Du steht, wird damit etwas anfangen können.

Debugging ist nicht so einfach wie angenommen wird, gar nicht.

Mal ein Beispiel was einem so unter die Finger kommt und Experten, die sich weitaus länger damit beschäftigen, ziemlich auf die Nase fallen.

Das Facebook-Problem

Gegeben sei ein Win10 System, aktueller Build xxx.540 und laut Ansage des Fragestellers immer bei FB [GB: meint wohl beim Zugriff auf Facebook] kommt der folgende Fehler, sonst nirgendwo.

Da nicht nur ein einziger Dump zur Verfügung stand (Snapshot des Systems), wurden diese natürlich auch hinzugezogen.

Fehlgeleitet – falscher Verursacher …

Der angeprangerte Verursacher motivierte die meisten (alle) Experten, auch diesen ohne weitere Prüfung als Verursacher anzusehen, ist ja auch einfach

Kurz & knackig die Ansage von WinDbg, der arbeitet fehlerhaft.

Unknown Function hilft weiter – Uralt BIOS …

Schnappt man sich die weiteren Dumps und schaut nach, exakter Fehler an der gleichen Stelle, aber eben nur bei Facebook und Cam.

Auf den winzigen Hinweis „unknown Funktion" triggerte niemand, hätte man aber sollen.

Der Hersteller ist unerheblich, wohl aber die Tatsache das BIOS [GB: von 2011] ist reif fürs Museum, aktuell gibt es die Version F.60 und wie üblich sind die Fixes nicht exakt beschrieben, reichlich Differenz allemal, Microcode angepasst?

Microcode als Verursacher?

Gräbt man weiter nach der Instruktion, die sich als zu SSSE3 zugehörig erweist – laut Intel Spezifikationen – und hier eine AMD CPU werkelt, die in den vorherigen Spezifikationen angesprochenen Register, die dafür notwendig sind, auch vorhanden sind, und zumindest Werte beinhalten, validiert oder nicht was schwieriger ist, bleibt diese unbekannte Funktion im Raum stehen.

Grenzwertig was [das] Wiki dazu verlauten lässt, kann implementiert sein oder auch nicht.
Schaut man sich die vorherigen Befehle an, die klaglos abgearbeitet wurden, und in den Intel Specs aufgelistet sind, sollte man anfangen zu zweifeln; hat aber niemand der Experten gemacht.

Teile von SSSE werden sauber abgearbeitet

Speicherfehler „One Bit" oder doch Microcode bzw. Bios? Ersteres würde Win10 ganz sicher monieren, bisher wenigstens. Ob die Werte valide sind, ist nicht einfach zu erkennen, ohne sich mit dem kompletten Code zu befassen und zu prüfen, ein mehr als zeitraubendes Unterfangen und eher unmöglich.

So viel zu einem Win10, das ansonsten laut Fragesteller läuft, aber nur in diesem einen Punkt auf einen BSOD [Blue Screen] rennt. Bei dem Treiber handelt es sich um Sunplus Technology Digital Camera Driver für Win10, ob ein älterer Treiber das richtet, ist nicht bekannt, neben der Diskrepanz der Bios-Version.

Etwas das BluescreenView und Konsorten niemals aufdecken können, da bedarf es doch noch Wissen.

Nicht unwichtig zu wissen, die Operanden nach dem Komma sind die Quelle der Daten mit denen die links vor dem Komma betankt werden.

Besonderheit dieser xmm-register: die können nicht direkt auf den Speicher zugreifen und bedienen sich von den regulären Registern die diese Fähigkeit haben.

Saluti

Ähnliche Artikel:
Windows BlueScreen-Analyse – Teil 1
Windows BlueScreen-Analyse – Teil 2
Windows BlueScreen-Analyse – Teil 3

Bullshit-Bingo: Windows Debugger WinDbg im Windows Store