windows bluescreen

Dieses Thema im Forum "Windows" wurde erstellt von zodiake, 1. November 2006 .

Schlagworte:
Status des Themas:
Es sind keine weiteren Antworten möglich.
  1. 1. November 2006
    hi leute, ich hatte in letzter zeit oft einen bluescreen, wisst ihr wo man rausfinden kann was dieser bedeutet? (hab die genaue meldung nciht aufgeschrieben) gibt es irgendwo einen überblick über bluescreen's?? mfg zodiake
     
  2. 1. November 2006
    AW: windows bluescreen

    dort steht immer ein Code, den müsstest Du Dir schon merken. Nur so kann man die Fehlersuche eingrenzen.
     
  3. 1. November 2006
    AW: windows bluescreen

    diese fehlermeldung, die dann dasteht gibst mal bei google.de ein.

    also z.B. "unmountable_boot_volumen"

    Und schon weißt in kurzer zeit was sache ist. Konnte so das problem mit dem unmountable boot volumen schnell beheben.

    Mfg
     
  4. 2. November 2006
    AW: windows bluescreen

    Blue-screen bei XP? Kommt äusserst selten vor!!!
    Aber ein Blue-Screen hat zur Bedeutung, dass du Hard- oder Software nicht richtig installiert hast, oder ein Defekt vorliegt! Also hast du neue Hardware eingebaut? Is dir irgendwie ne Platte kaputtgegangen oder so? Überprüf einfach deine Hardware!
     
  5. 2. November 2006
    AW: windows bluescreen


    kommt eben nicht selten vor! kommt nemlich nur vor wenn man die Option "bei schweren systemfehlern automatisch herunterfahrn" aus hat dann macht er dafür n bluescreen! aber wie gesagt kann hard oder software schaden sein! einfach mal aufschreiben und posten

    mfg LLmichi
     
  6. 2. November 2006
    AW: windows bluescreen

    der folgende Text wird zitiert von:
    (quote tags nicht möglich?)

    Windows Bluescreen Analyse
    Geschrieben von Arnulf Werner
    das Wichtigste zusammengefasst

    Geschrieben von Arnulf Werner


    1.10.2004 Vers. 1.01 auf Wunsch noch Tips hinzugefügt (wird ab jetzt laufend erweitert)


    Bluescreens:
    Applikationen können keinen Bluescreen verursachen da sie im User-Mode laufen, hier einen Ansatz zu suchen ist also falsch.

    Ein Betriebssystemabsturz mit einem Bluescreen entsteht nur wenn der Code der im so genannten Kernel-Mode (Ring 0) läuft etwas Illegales tut.

    Gerätetreiber, Systemdienste und der Mikrokernel selbst laufen im Kernelmode und da sich alle diese Gerätetreiber Treiber einen gemeinsamen Adressraum teilen können sich gegenseitig abschießen > Bluescreen

    Bluescreens Systemeinstellungen:
    Es sollte unter System in der Systemsteuerung auf dem Register Erweitert folgendes eingestellt sein:
    Automatisch Neustart durchführen sollte ausgeschaltet sein
    Das unter "Debuginformationen speichern" standardmäßig ausgewählte "Kleine Speicherabbild" reicht dazu in der Regel nicht aus. Besser ist es hier, ein Kernelspeicherabbild anzufordern. (benötigt ca. ein Drittel der Hauptspeichergröße).
    Das vollständige Speicherabild bringt uns hier auch nicht weiter da hier nur noch zusätzlich der Gesamte Speicherbereich der für Applikationen reserviert ist mit abgespeichert wird.
    Aber für eine erste Kurzanalyse reicht das Minidump file allerdings aus.

    Infos die uns der Bluescreen direkt liefert:
    Die Zeile, die mit "*** STOP" gefolgt von einer achtstelligen Hexadezimalzahl beginnt, ist auf jedem Bluescreen zu sehen. Sie liefert einen ersten Hinweis auf die Ursache des Fehlers.

    Manchmal wird zusätzlich die symbolische Beschreibung des Fehlers, etwa IRQL_NOT_LESS_OR_EQUAL oder INACCESSIBLE_BOOT_DEVICE angezeigt.

    Für eine Google-Suche ausreichend.


    Des Weiteren könnte der Bluescreen auch einen eine
    Datei mit der Endung .sys anzeigen. Das muss aber
    nicht die Ursache sein! Das ist nur als Hinweis zu verstehen.

    Falls ntoskrnl.exe angezeigt wird bitte bei Tips am Schluss des Dokumentes nachlesen.

    WinDbg:
    Microsoft stellt den kostenlosen Debugger WinDbg + Symboldateien zur Verfügung:

    Man kann sich beides downloaden und installieren (ca. 9Mb + 170 Mb)
    ich empfehle gerade bei seltenen Analysen sich das Installieren der Symboldateien zu sparen.

    Dazu muss man folgende Einstellungen im WnDbg verändern:

    Menübefehl "File/Symbol File Path" auswählen und in das Eingabefeld die Zeile SRV*C:Symbols*http://msdl.microsoft.com/download/symbols eintragen
    und statt "C:Symbols" muss man neuen Ordner angeben > hier wird der Debugger
    die heruntergeladenen Symboldateien zwischenspeichern.

    Analyse:

    {bild-down: http://techtalk.unterwegs-im.net/unterwegs-im.net/images/articles/BSOD/image001.jpg}


    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 schließen, da die dort dargestellten Informationen zu interpretieren
    erfordert sehr viel an System- und Programmierkenntnissen.

    Das Command-Fenster enthält meist durchaus wertvolle Informationen.

    Interessant sind zwei Zeilen:

    Eine beginnt mit "Probably caused by:" gefolgt von einem Dateinamen.

    Der Tipp, den WinDbg hier abgibt, trifft erstaunlich oft das richtige.
    Zumindest wenn die benannte Datei die Endung .sys trägt, lohnt es sich diese Spur weiter zu verfolgen.

    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 Befehl "!analyze -v" ein.

    Er liefert meist eine Menge an Informationen, von denen zunächst die ersten
    Zeilen 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"

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

    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, durch ein
    Ausrufe- oder ein Plus-Zeichen getrennt, 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.


    {bild-down: http://techtalk.unterwegs-im.net/unterwegs-im.net/images/articles/BSOD/image002.jpg}



    Wenn 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 weitergeben.

    Ein Kommando wie

    irp f8978ffc

    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 somit weitere mögliche
    Schuldige für den Absturz.

    Bei Bluescreens die ein USB-Device verursacht lohnt ein Blick auf die I/O Request Packets.

    Tipps:

    Interrupt-Probleme:

    IRQL_NOT_LESS_OR_EQUAL

    Bei diesem Problem unten im Command-Fenster hinter "kd>" den Befehl "!analyze -v"
    aufrufen da hier der fehlerhafte Treiber mit großer Wahrscheinlichkeit schon ermittelt wird.

    Buffer-Errors (under-/overrun)
    Bei diesen Fehlern kann das System sogar weiter laufen und erst wenn der
    Kernel den Speicherbereich selber verwenden will tritt das Problem (Bluescreen) auf.

    In diesem Fall kann es sein das im Debugger der Kernel (ntoskrnl.exe) als Fehlerursache
    angezeigt wird, jetzt hilft uns das Tool verifier.exe weiter.

    Einfach das Programm starten und die Standart Einstellungen belassen und auf weiter klicken.

    {bild-down: http://techtalk.unterwegs-im.net/unterwegs-im.net/images/articles/BSOD/image003.jpg}


    Im Dialog Treiber zur Überprüfung alle auf diesem Computer installierten Treiber selber wählen.

    {bild-down: http://techtalk.unterwegs-im.net/unterwegs-im.net/images/articles/BSOD/image004.jpg}


    Die Einstellungen sind nach einem reboot aktiv!

    Falls es jetzt wieder zum Bluescreen kommt kann der Debugger das Problem ermitteln.

    (Verifiers lädt alle Treiber in einen überwachten Speicherbereich! (Special pool))

    {bild-down: http://techtalk.unterwegs-im.net/unterwegs-im.net/images/articles/BSOD/image005.jpg}


    Wo finde ich Windbg?
    http://www.microsoft.com/whdc/devtools/debugging/installx86.mspx

    Symbol Packages:

    URL="http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx"] http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx[/URL]

    Literatur:
    [1] Windows Driver Kit (WDK) and Debugging Tools for Windows (WinDbg) downloads
    [2]
    So lesen Sie die kleine Speicherabbilddatei, die von Windows erstellt wird, wenn ein Absturz auftritt

    [3] Hajo Schulz Wenn Windows blaumacht c't 10/04,
    [4] Technet
     
  7. Video Script

    Videos zum Themenbereich

    * gefundene Videos auf YouTube, anhand der Überschrift.