Ergebnis 1 bis 2 von 2

Thema: Wenn Windows blau macht

  1. #1
    Azubi(ne)
    Registriert seit
    23.07.2007
    Ort
    usm scheena Schwoabaländle
    Beiträge
    69
    Danke
    0
    Bekam 0 mal "Danke" in 0 Postings

    Standard Wenn Windows blau macht

    Ursachen von Bluescreens aufspüren

    Seit Windows XP sind sie seltener geworden, aber auch hier gibt es sie doch noch:
    Rätselhafte Systemneustarts oder die blauen Bildschirme, mit denen das Betriebssystem sich für arbeitsunfähig erklärt. Auch der Hinweis „Wenden Sie sich an den Administrator“ hilft nicht weiter, wenn dieses Schicksal den Heim-PC ereilt.

    Eigentlich ist so ein Bluescreen nichts Schlechtes: Wenn er erscheint hat das Betriebssystem festgestellt, dass es in einen Zustand geraten ist, in dem ein sicheres Weiterarbeiten nicht mehr möglich ist. Jede weitere Aktion könnte mehr Schaden anrichten, als ein vielleicht seit einer halben Stunde nicht gespeichertes Word-Dokument für den Anwender bedeutet. Um die Hardware und den Inhalt der Festplatte vor Schäden zu bewahren, fährt sich das System in so einem Fall kontrolliert herunter. Ob es den Rechner danach automatisch neu startet oder einen Bluescreen anzeigt und die CPU anhält, kann der Anwender einstellen.

    Die zuständigen Optionen verbergen sich in den Systemeinstellungen (Rechtsklick auf „Arbeitsplatz“ dann auf „Eigenschaften“) im Register „Erweitert“. Hier führ ein Klick auf „Einstellungen“ im Bereich „Starten und Wiederherstellen“ auf einen Dialog, dessen Einstellmöglichkeiten im Bereich „Systemfehler“ definieren. Was Windows im Falle eines Komplettabsturzes noch alles unternimmt.
    Zur Fehlersuche sind hier 2 Optionen wichtig: „Automatisch Neustart durchführen“ sollte ausgeschalten sein (kein Haken im Kästchen), damit ein Bluescreen nicht sofort wieder verschwindet, dem man unter Umständen noch wertvolle Informationen entnehmen kann. Kommt es dann trotzdem zu plötzlichen reboots, ist in der Regel nicht Windows oder sonst eine Softwarekomponente schuld, sondern es liegt ein Hardwareproblem vor. In Frage kommt zum Beispiel ein Netzteil, das die Versorgungsspannung nicht stabil genug liefert und so einen Reset auslöst.
    Zum Aufspüren der Ursache für Bluescreens ist es außerdem wichtig, möglichst genaue Informationen über den Systemzustand zum Zeitpunkt des Absturzes zu haben. Das unter „Debuginformationen speichern“ standardmäßig ausgewählte „Kleine Speicherabbild“ reicht dazu in der Regel nicht aus. Besser ist es hier, ein Kernelspeicherabbild anzufordern. Die Größe einer solchen Datei entspricht etwa einem Drittel der Hauptspeichergröße. Ein „Vollständiges Hauptspeicherabbild“ wird dagegen stets so groß wie der Hauptspeicher (plus einem Megabyte für einen Header und ein paar Verwaltungsinformationen). Dieser zusätzlich belegte Platz zahlt sich aber für die reine Fehlersuche in der Regel nicht aus.
    Ob man das Häkchen bei „Vorhandene Dateien überschreiben“ setzt, ist nicht nur Geschmackssache: Fehlt es, legt Windows beim nächsten Absturz nicht etwa ein neues Speicherabbild an, sondern schreib schlicht ein kleines und man hat keine Chance, den Fehler zu analysieren. Ist die Option eingeschaltet, geht beim nächsten Crash eine schon vorhandene und vielleicht noch nicht komplett ausgedeutete Datei verloren. In dem Fall empfiehlt es sich, nach einem BSOD und anschließendem Neustart den Memory-Dump so schnell wie möglich durch Umbenennen oder Verschieben in Sicherheit zu bringen.

    Ermittlung

    Auch wenn ein Bluescreen reproduzierbar immer im selben Programm auftritt: Die Anwendung selbst kann daran nicht schuld sein – jedenfalls nicht unmittelbar. Unter Windows NT Abkömmling laufen ordinäre Programme nämlich im so genannten User-Mode (auch „Ring 3“ genannt). Sie bekommen einen eigenen virtuellen Adressraum zugewiesen und können nicht auf den Adressraum anderer Anwendungen oder direkt auf die Hardware zugreifen. Wenn in einer Anwendung etwas Gravierendes schief geht, kommt es daher allenfalls zum Absturz dieses einen Programms, was sich ain einer Fehlermeldung der Art „WinBugPro.exe hat ein Problem festgestellt und muss beendet werden“ äußert. Windows selbst läuft in so einem Fall unbeeindruckt weiter.

    Ein Betriebssystemabsturz in Form eines Bluescreen kann nur enstehen, wenn Code etwas Illegales tut, der im so genannten Kernel-Mode („Ring 0“) läuft. Dazu gehören Gerätetreiber und der Mikrokernel selbst. Im Ring 0 teilen sich alle Treiber einen gemeinsamen Adressraum und können sich durchaus gegenseitig abschießen.

    Um herauszufinden, welche Komponente genau den Fehler verursacht hat, muss man sich den Zustand des Systems unmittelbar vor dem Absturz ansehen. Einige Informationen zeigt schon der Bluescreen selbst: Eine Zeile, die mit „*** STOP“ gefolgt von einer achtstelligen Hexadezimalzahl beginnt, ist auf jedem BSOD zu sehen. Sie liefert einen ersten Hinweis auf die Art des Fehlers – wenn man sie denn zu interpretieren weiß. Manchmal findet sich in der Nähe der STOP-Zeile eine symbolische Beschreibung des Fehlers, etwa IRQL_NOT_LESS_OR_EQUAL oder INACCESSIBLE_BOOT_DEVICE, und damit zumindest einen Anhaltspunkt für eine Google-Suche. Mit etwas Glück enthält der Bluescreen auch einen Hinweis auf eine Datei mit der Endung. Sys. Die ist damit natürlich verdächtig, aber leider noch lange nicht als eindeutig schuldig identifiziert.

    Mit den Informationen auf dem Bluescreen selbst kommt man also nicht allzu weit. Ein Blick in das Speicherabbild ist angesagt. Glücklicherweise bietet Microsoft dafür ein geeignetes Werkzeug an: den Debugger WinDbg [1 siehe unten], den Sie über den Softlink herunterladen können.
    Die Download-Größe ist mit knapp 9 MByte noch erträglich. Um den Debugge allerdings sinnvoll einsetzen zu können, benötigen Sie noch die so genannten Symboldateien – und die schlagen je nach Windows-Version mit ca. 70 bis 170 MByte zu Buche. Ein Komplett-Download ist aber nicht unbedingt nötig, wenn der Rechner, auf dem Sie die Analyse durchführen wollen (das muss nicht notwendigerweise der von den Abstürzen betroffene sein), mit dem Internet verbunden ist. Dann können Sie nämlich WinDbg so einrichten, dass er immer nur die benötigten Symbole lädt und auf dem Rechner zwischenspeichert. Dazu legen Sie nach der Installation des Debuggers zunächst irgendwo auf der Festplatte ein neues Verzeichnis an.
    In WinDbg wählen sie den Menübefehl „File/Symbol File Path“ und tragen in das Eingabefeld die Zeile
    SRV*C: \Symbols*http://msdl.microsoft.com/download/symbols ein. Statt „C: \Symbols“ müssen Sie dabei den neuen Ordner angeben; hier wird der Debugger die heruntergeladenen Symboldateien zwischenspeichern.
    Ein Speicherabbild lädt WinDbg mit dem Menübefehl „File/Open Crash Dump“. Daraufhin öffnet der Debugger zwei Fenster mit den Titelzeilen „Command“ und „Disassembly“. Letzteres kann man der Übersichtlichkeit halber gleich wieder schlissen – die dort dargestellten Informationen zu interpretieren erfordert so viel an System- und Programmierkenntnissen, dass eine Beschäftigung damit den Rahmen dieses Turtorials sprengt.
    Das „Command“ – Fenster enthält dagegen meist schon durchaus wertvolle Informationen. Beachtenswert sind zwei Zelen: Eine beginnt mit „Probably caused by:“ (deutsch: „Vermutlich verursacht von:“) gefolgt von einem Dateinamen. Der Tipp, den WinDbg hier abgibt, trifft schon erstaunlich oft ins Schwarze. Zumindest wenn die benannte Datei die Endung .sys trägt, lohnt es sich, zu untersuchen, woher sie stammt.

    Die zweite interessante Zeile in WinDbgs Kurzanalyse beginnt mit „BugCheck“ und enthält danach eine Hexadezimalzahl und eine Reihe weiterer kryptischer Angaben in geschweiften Klammern. Hier handelt es sich um eine Wiederholung dessen, was der Bluescreen in der STOP-Zeile angezeigt hat. Um Genaueres über die Bedeutung dieser Angaben zu erfahren, gibt man unten im Command-Fenster hinter „kd>“ den Befehel !analyze –v
    Ein . Er liefert meist einen Wust an Informationen, von denen zunächst die ersten Zeilen besondere Beachtung verdienen: Ein symbolischer, aus Großbuchstaben und Unterstrichen bestehender Name wie NTFS_FILE_SYSTEM nebst einer Kurzbeschreibung erklärt die Art des aufgetretenen Fehlers. In den folgenden Zeilen gibt es eine kurze Erklärung der mitgelieferten Parameter. Wer es noch genauer wissen will, kopiert das Fehlersymbol und fügt es in der Eingabezeile hinter dem Befehl .hh wieder ein:
    .hh NTFS_FILE_SYSTEM

    startet die WinDbg-Hilfe und zeigt einen Artikel an, der weitere Informationen zu dem Fehler enthält. Bei vielen Fehlerarten finden sich hier auch gleich Erklärungen, wie man die möglichen Fehlerursachen einschränken kann oder was zu tun ist, um den Fehler künftig zu vermeiden. Wenn dort steht, dass die häufigste Fehlerursache defekte Hardware ist, dann sollten Sie das durchaus ernst nehmen und die weitere Fehlersuche zunächst darauf konzentrieren.

    Detektivarbeit

    In der Ausgabe von !analyze –v sind außerdem noch die Zeilen unter der Überschrift „STACK_TEXT:“ interessant: Sie enthalten eine umgekehrt chronologische Liste der Funktionen, die sich kurz vor dem Crash gegenseitig aufgerufen haben. In der letzten Spalte steht dabei jeweils der name des zuständigen Moduls und dahinter, abgetrennt durch ein Ausrufe- oder ein Plus Zeichen, die Adresse innerhalb des Moduls. Taucht hier in den ersten paar Zeilen ein anderer Modulname als „nt“ auf, ist dieses Modul zumindest verdächtig, an dem Crash beteiligt gewesen zu sein.
    Weitere Kandidaten kann man manchmal identifizieren, indem man den Befehl !thread eingibt.
    Enthält die Ausgabe die Überschrift „IRP List:“, dann sollte man die Adressen aus der ersten Spalte dieser Liste an den Befehl !irp verfüttern: Ein Kommando wie
    !irp ffabccd8
    gibt detailliert Auskunft über ein so genanntes I/O Request Packet, das an dieser Adresse im Speicher liegt. Es enthält immer auch die Namen der Treiber, die an dieser Ein-/Ausgabeoperation beteiligt sind, und damit weitere mögliche Schuldige für den Absturz.

    Wenn der Rechner immer beim Diskettenzugriff oder beim Anstöpseln eines USB- Gerätes abschmiert, lohnt ein Blick auf die I/O Request Packets.
    Achtung: Dies ist ein alter Thread im HTML und Webmaster Forum
    Diese Diskussion ist älter als 90 Tage. Die darin enthaltenen Informationen sind möglicherweise nicht mehr aktuell. Erstelle bitte zu deiner Frage ein neues Thema im Forum !!!!!

  2. #2
    Azubi(ne)
    Themenstarter

    Registriert seit
    23.07.2007
    Ort
    usm scheena Schwoabaländle
    Beiträge
    69
    Danke
    0
    Bekam 0 mal "Danke" in 0 Postings

    Standard

    Under Cover
    Leider lassen sich mit den bisher vorgestellten Methoden noch nicht alle Fehlerursachen eindeutig erkennen. Vor allem wenn diese Bemühungen bei jedem Crash ein anderes Bild liefern, ist Misstrauen angezeigt: Der Verdacht fällt dann zunächst auf Hardwareprobleme wie vergesslichen Hauptspeicher oder einen unzuverlässigen Festplatten-Controller. Trotzdem kommen immer noch Treiber-Malaisen als Ursache in Frage. Es kann nämlich sein, dass eine Systemdatei Unordnung in die Datenstrukturen des Kernels bringt, was dem aber nicht sofort auffällt. Erst ein späterer harmloser Aufruf eines eigentlich intakten Treibers stolpert dann über diese Falle und gerät zu Unrecht in Verdacht, den Crash verursacht zu haben.

    Häufig versteckt sich der für den Crash verantwortliche Treiber im Aufruf-Stack.

    Zum Aufspüren dieser Art von Fehlern bringen Windows 2000 und XP von Haus aus eine erweiterte Treiberüberprüfung mit. Einstellen lässt sich dieses Diagnosewerkzeug, indem man per „Start/Ausführen“ das Programm verifier aufruft. Es stellt verschiedene Möglichkeiten zur Auswahl, mit denen Windows geladenen Treibern auf die Finger schaut. Verstößt ein Treiber gegen die verschärften Spielregeln, erzeugt die Treiberüberprüfung einen speziellen BSOD, dessen Speicherabzug sich dann wie oben beschrieben analysieren lässt.
    Unter Windows XP ist der verifier als Wizard ausgelegt, bei dem man sich durch verschiedene Schritte klicken muss. Folgende Einstellungen haben sich bewährt: Auf dem ersten Schirm „Benutzerdefinierte Einstellungen verwenden“, im zweiten Schritt „Vordefinierte Einstellungen verwenden“, „Standardeinstellungen“ und „Simulierung geringer Ressourcen“. Im dritten Teil der Einstellung reicht es meist, die nicht signierten Treiber automatisch auswählen zu lassen – die signierten haben diese Tortur ja schon hinter sich. Um Wechselwirkungen auszuschließen, kann man hier auch „Treiber aus einer Liste wählen“ anklicken und im letzten Schritt alle Treiber überprüfen lassen, die nicht von Microsoft stammen.
    Der verifier von Windows 2000 zeigt alle Optionen gemeinsam auf dem Register „Einstellungen“ an. Hier sollte man „Ausgewählte Treiber überprüfen“ markieren, in der Liste alle nicht von Microsoft stammenden Treiber auswählen und unten auf „Überprüfen“ klicken. Anschließend kann man durch einen Klick auf „Bevorzugte Einstellungen“ die gängigsten Überprüfungen aktivieren und das Ganze per „Übernehmen“ bestätigen. Sowohl unter Windows XP als auch unter Windows 2000 werden die Einstellungen mit dem nächsten Neustart aktiv.

    Nicht übersehen sollte man, dass die Treiberüberprüfung ein zweischneidiges Schwer ist: Zwar identifiziert sie recht zuverlässig Treiber, die sich nicht anständig benehmen. Nimmt man aber zu viele Treiber in de Prüfung auf, kann das das System bis zur Unbrauchbarkeit herunterbremsen.
    Außerdem kann die Treiberüberprüfung dafür sorgen, dass einer der Checks schon beim Booten zuschlägt und so einen Systemstart verhindert – den man aber braucht, um sie wieder abzuschalten. Ihre Einstellungen speichert die Treiberüberprüfung im Systemzweig der Registry. Von dem sollte man daher sicherheitshalber mit Hilfe der Wiederherstellungskonsole eine Kopie anlegen, bevor man die Treiberüberprüfung aktiviert.

    Verurteilung

    Mit der Erkenntnis, welche Treiber am Zustandekommen des BSOD beteiligt gewesen sein könnten, geht es nun daran, Abhilfe zu schaffen. Zunächst lohnt es sich, mit WinDbg nach weiteren Informationen über die Treiberdatei zu fahnden. Dazu übergibt man den Namen des verdächtigen Moduls an den Befehl lm. Ist Ihnen beispielsweise die Datei bsod.sys ins Auge gefallen, lautet der komplette Befehl
    Lm v mbsod

    Hinter dem „lm“ kommt ein Leerzeichen, dann ein „v“, noch ein Leerzeichen und anschlißend ein „m“, an das der Name des Moduls ohne Dateiendung unmittelbar angehängt wird. Mit etwas Glück enthält die Ausgabe dieses Befehls den kompletten Dateinamen samt Pfad der Treiberdatei und gibt Auskunft über den Hersteller. Wenn nicht, hilft nur noch die Brechstange: Der Befehl
    !devnode 0 1

    gibt eine Liste aller geladenen Gerätetreiber aus. In der kann man mit dem Menübefehl „Edit/Find“ nach dem verdächtigen Modulnamen – wieder ohne Dateiendung – suchen. In dem Eintrag, in dem er hinter „ServiceName“ erscheint, ist der „InstancePath“ interessant – merken oder notieren.
    Alsdann startet man das Programm regedit, navigiert nach
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Enum und von dort weiter entlang dem in InstancePath angegebenen Pfad . Hier verrät der Eintrag „ DeviceDesc“, um was für ein Gerät oder Treiber es sich handelt, und weitere Informationen, etwa wo auf der Festplatte die Treiberdatei liegt oder wer ihr Hersteller ist, sollten über den Gerätemanager beschaffbar sein.

    Abführ’n

    Mit diesen Angaben versehen, kann man daran gehen, das Problem zu beseitigen: Erste Anlaufstelle ist der Hersteller, der sich die Frage gefallen lassen muss, ob das Problem bekannt und vielleicht schon ein neuerer Treiber verfügbar ist. Wenn nicht, stellt sich die Frage, was am System verändert wurde, bevor der Fehler zum ersten Mal auftrat. Beim Versuch, diese Änderung rückgängig zu machen, kommen Rettungsversuche über die Systemwiederherstellung, das Einspielen eines gesicherten Festplatten-Images oder eines anderen System-Backup in Betracht. Ist die Treiberdatei schlicht beschädigt, hilft oft eine Neuinstallation des Treibers oder das manuelle Herausfummeln der betroffenen Datei aus einem Installationspaket. Bringt das alles keine Besserung, sollten bei der Ursachenforschung zumindest genug Stichwörter zusammengekommen sein, um eine erfolgversprechende Internet-Recherche zu starten.


    Literatur
    [1] Microsoft Debugging Tools, www.microsoft.com/whdc/ddk/debugging

Ähnliche Themen

  1. kein Blau beim Drucken
    Von nogeno im Forum Computer - Internet Forum
    Antworten: 1
    Letzter Beitrag: 04.04.2008, 19:10
  2. Wie man sich das Leben mit Windows einfacher macht...
    Von CLiff im Forum Computer - Internet Forum
    Antworten: 3
    Letzter Beitrag: 05.12.2007, 10:06
  3. blau ecken :S
    Von kadeux im Forum HTML & CSS Forum
    Antworten: 3
    Letzter Beitrag: 23.11.2007, 09:55
  4. erste tabelle rot folgende blau und so weiter wie?
    Von SonicChriz im Forum PHP Forum - Apache - CGI - Perl - JavaScript und Co.
    Antworten: 13
    Letzter Beitrag: 03.01.2006, 01:30
  5. Wenn, ja wenn das Wörtchen Wenn nicht wär ....
    Von umbenannt im Forum Off Topic und Quasselbox
    Antworten: 5
    Letzter Beitrag: 09.11.2003, 00:16

Stichworte

Berechtigungen

  • Neue Themen erstellen: Nein
  • Themen beantworten: Nein
  • Anhänge hochladen: Nein
  • Beiträge bearbeiten: Nein
  •