Windows Live Alerts
EnglishDeutsch
|
Kontakt und über mich
|  
   
 
Startseite
Artikel
Support Forum
SBC FAQ
XenApp/XenDesktop
Remote Desktop Dienste
Terminal Dienste
Web Interface
Tipps & Tools
Sponsors 
 
Lassen Sie sich von einem Experten Beraten

Windows Crash Debbuging Drucken E-Mail

Ich habe im Internet Informationen gesammelt und diese hier als kurze Einführung in Windows Crash Debugging veröffentlicht.
Eine erweiterte Version habe ich als PDF Version erstellt, ist aber nur in englisch verfügbar. Der Download des PDF Dokumentes ist hier.

Image Introduction to Debugging


Eine einfache Crash Dump Analyse ist recht leicht und benötigt wenig Zeit und Aufwand. Viele Administratoren ignorieren die Option von Windows Crash Dumps. Aber ist es nicht Wert ein paar Minuten aufzuwenden, auch wenn nur 1 von 10 Dumps weiterhelfen?
Darum hier ein kurzer Überblick zu den Grundlagen.


Kernel Mode & User Mode

Mit Windows NT und höher ist der Arbeitsspeicher in zwei Bereiche unterteilt, dem "user mode" und dem "kernel mode". Was diese beiden modies unterscheidet, sind die unterschiedlichen Ebenen der Privilegien. Die primäre Einschränkung im User-mode ist, das Anwendungen keinen direkten Zugriff auf den Speicher im Kernel-mode haben.

Trotz allem kann ein Programm im User-mode versuchen direkt mit Hardware Komponenten zu kommunizieren, dies verhindert jedoch das System und die Meldung des Dr. Watson erscheint.

Eine Kenel-mode Komponente muss entscheiden, ob ein Zugriff das Resultat einer legalen oder ilegalen Operation ist. Wenn die Kernel-mode Komponente einen ilegalen Zugriff abfängt, benachrichtigt sie die User-mode Anwendung "Dr. Watson", die dem Benutzer angezeift wird.



Dr. Watson verwenden
Wenn ein User-mode Fehler aufgetreten ist, dann startet man Dr. Watson [ start | run | drwtsn32 ] und klickt auf den letzten Eintrag in der Fehlerliste. Angezeigt wird der Fehler dann mit einem Klick auf den "View" Knopf. Der Eintrag zeigt alle Details, die während des Fehlers auftraten.

Kernel-mode Gerätetreiber und Subsysteme können fast alles tun, was sie wollen. Dies ist eine Lücke im Systemschutz und zeigt, wie vorsichtig die Installation von Dritthersteller Treibern behandelt werden muss. Erst einmal installiert hat der Treiber Zugriff auf sämtliche Resourcen des gesamten Systems (Software & Hardware)


Genau dies ist der Punkt, warum die Installation von Dritthersteller Druckertreiber auf einem Windows Terminalserver so kritisch ist.



Stop Errors – BSOD (blue screen of death)

Fehler (bugs) im Code können fatale Fehler am System erzeugen. Das kann auch fehlerhafte Hardware und im besonderem der Arbeitsspeicher sein. Viele Probleme werden kein "Blue Screen" hervorrufen, Dienste und Treiber generieren Einträge im System Ereignisprotokoll. Fehlerhafte Anwendungen können durch Dr. Watson angezeigt werden.
Wenn ein kritisches Problem auftritt, generiert das Betriebssystem eine offensichtliche Fehlermeldung, den "Blue Screen", um keinen Datenverlust zu riskieren. Mit anderen Worten, der "Blue Screen of death" selbst ist NICHT das Problem, sondern weist daraufhin, dass ein schwerwiegendes Problem existiert, welches umgehend betrachtet werden sollte.


Speicher Dump Dateien

Wenn ein Stop Fehler auftritt, dann erstellt das System automatisch ein Abbild des Arbeitsspeichers und speichert das Abbild in eine Auslagerungsdatei. Nach dem Neustart wird das Speicherabbild von der Auslagerungsdatei in das Systemlaufwerk verschoben. Eine Analyse des Speicherabbilds kannn weitere Informationen für den Grund des Fehlers liefern.


Lesen des Stop Bildschirms

Ein "Blue Screen" enthält diverse Informationen aber die Schlüsselinformation ist der error code incl. der Parameter. Zusätzlich wird eine Liste der Module angezeigt, die geladen und erfolgreich inizialisiert wurden. Nach dem Word STOP wird der Fehler oder BugCheck code angezeigt. Dies ist der wichtigste Teil des Stop Bildschirms. Für die häufigsten Stop Nachrichten gibt es Beschreibungen auf Microsoft’s Website.

 0xC000000A
IRQL_NOT_LESS_OR_EQUAL
Prozess versucht einen Speicherzugriff mit einem IRQL der zu hoch ist.
 0xC000001E
KMODE_EXCEPTION_NOT_HANDLED
Prozess versucht einen illegalen oder unbekannten Prozessorbefehl auszuführen.
 0xC0000050
PAGE_FAULT_IN_NONPAGED_AREA
Tritt auf, wenn die angeforderten Daten nicht im Speicher gefunden wurden.

Wenn ein Eintrag im System Log geschrieben wurde, sollte er die gleichen Informationen enthalten, die auch auf dem Stop Bildschirm sichtbar waren. Beschreibung und Format der Logdatei unterscheiden sich von dem, was der Computer in die Memory.dump Datei schreibt, jedoch sollte der Inhalt grundsätzlich gleich sein.




System Debugging

Wenn die Daten vom Blue Screen nicht ausreichen, um die Ursache des schwerwiegenden Fehlers zu finden, hilft die Verwendung von Debugging Programmen wie WinDBG, um viel mehr Informationen zu bekommen.
Ein Debugger sucht nach Fehlern, indem er sich in das System "einbettet" und somit ermöglicht Programme step-by-step zu untersuchen, während diese ausgefürt werden.

WinDBG
WinDBG ist ein populärer und einfacher GUI Debugger. Dieser kann für Win32 Anwendungen und Windows Betriebssystemen verwendet werden. WinDBG kann Dump Dateien lesen und bietet eine hervorragende Unterstützung für Symbole. WinDBG ist GUI gestützt und somit langsamer als andere Debugger.


 
WinDBG Symbol Konfiguration

  1. Sysmbol Pfad ändern: Im View Menü, Options wählen. In der Windows Debugger Option Dialog Fenster, Klick auf Symbol Tab, Festlegen des Pfads für die Symboldateien im Debug Symbol Search Path Text Fenster.
  2. Beispiel:  Für den Download der Symbole nach c:\websymbols, wird folgende Zeile eingetragen:
    SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
  3. Klick auf OK.

WinDBG & Crash Dumps

  1. Start von WinDBG 
  2. Auf dem Debug Menü "File", Klick auf "Open Crash Dump", Auswahl der .dmp (Memory.dmp, user.dmp etc.) Datei und mit "open" abschließen
  3. Im "command" Fenster eingeben: !analyze –v 
  4. Ausführen der Analyse im "fully verbose" Modus und  Anzeige des Ergebnis mit wertvollen Informationen, die weiter helfen können
  5. Zum Beenden "q" im "command" Fenster eingeben

Image Knowledgebase Artikel zum Thema Debugging

  • How to debug Windows services
    Q824344
  • Extracting the Computer Name From a Dump
    CTX104978
  • Troubleshooting of Heap Corruption in Applications
    CTX108312
  • How to Set NTSD as a Default Windows Postmortem Debugger
    CTX105888
  • How to Attach WinDbg to a Process
    CTX106566
  • How to Check In a User Dump That Full Page Heap Was Enabled
    CTX105955
  • How to Enable User Mode Stack Trace Database for IMA Service to Detect Memory Leaks
    CTX106970
  • Using LiveKD to Save a Complete Memory Dump
    CTX107717
     
Image WebLinks

 
Finden oder folgen @