BlueScreen beim Herunterfahren

[x.treme]

Hallo Leute,

ich bekomme beim Herunterfahren jedes mal einen Bluescreen.
(während normaler Benutzung jedoch nie)
Nun habe ich aber weder Lust noch Zeit Windows neuzuinstallieren, da es gerade so perfekt eingerichtet ist.

Hier mal der Fehlerlog:

Problemsignatur:
  Problemereignisname:	BlueScreen
  Betriebsystemversion:	6.1.7601.2.1.0.256.48
  Gebietsschema-ID:	1031

Zusatzinformationen zum Problem:
  BCCode:	50
  BCP1:	FFFFFFFFFFFFFFD0
  BCP2:	0000000000000001
  BCP3:	FFFFF800054E3A4C
  BCP4:	0000000000000000
  OS Version:	6_1_7601
  Service Pack:	1_0
  Product:	256_1

Dateien, die bei der Beschreibung des Problems hilfreich sind:
  C:\Windows\Minidump\120311-57548-01.dmp
  C:\Users\root\AppData\Local\Temp\WER-82945-0.sysdata.xml

Woran kann es liegen?

Edit: Ok, die externe Festplattensammlung vor dem Herunterfahren vom Strom zu trennen hat das Problem gelöst

 

[X23^Piracy]

Hi,

Edit: Ok, die externe Festplattensammlung vor dem Herunterfahren vom Strom zu trennen hat das Problem gelöst

gelöst wohl kaum eher umgangen...


Gruß X23

 

[x.treme]

Hehe

Ich denke es liegt an der WD Mybook die per Firewire angeschlossen ist, die macht eh gerne Probleme und kommt vermutlich mit dem Controller nicht klar.

Mir aber egal, da die externen eh nur 1 mal die Woche für BackUps eingeschaltet werden ^^

 

[X23^Piracy]

Hi,

Ich denke es liegt an der WD Mybook die per Firewire angeschlossen ist, die macht eh gerne Probleme und kommt vermutlich mit dem Controller nicht klar.

wenn du das zweifelsfrei herausfinden willst solltest du dir mal das dmp file mit folgendem tool ansehen: http://msdl.microsoft.com/download/symbols/debuggers/dbg_x86_6.4.7.2.exe

Auszug aus einem Winfaq.de Artikel:

Nachdem Sie das Programm installiert haben, können Sie den Debugger über "Start" -> "Programme" -> "Debugging Tools für Windows" -> "WinDbg" starten.

Damit Sie mit dem Debugger wirklich sinnvoll Arbeiten können, werden auch noch die sog. Symboldateien benötigt. Da die aber vollständig mit ca. 170 MByte zu Buch schlagen, sie aber sicherlich nicht täglich solche Dumpdateien auswerten wollen, sollten Sie lieber einstellen, dass WinDbg sich selber die benötigten Dateien aus dem Internet holt.

Stellen Sie dafür Folgendes ein:

Im Menü "File" -> "Sybol File Path" tragen Sie in die Eingabebox ein:

"SRV*C:\Symbols*http://msdl.microsoft.com/download/symbols".

Anschließend öffnen Sie mit dem Programm die Dumpdatei aus dem Verzeichnis "%SystemRoot%\Minidump" über "File" -> "Open Crash Dump"

Jetzt wird die Datei geladen und die Informationen dazu angezeigt. Dabei werden zwei Fenster geöffnet "Command" und "Disassembly". Das Fenster "Disassembly" können Sie ruhig wieder schließen, da deren Auswertung doch schon erhebliche Programmierkenntnisse voraussetzt.

Das "Command"-Fenster enthält dagegen meist schon durchaus wertvolle Informationen. Die interessanten Informationen finden Sie im Abschnitt:

***************************

* Bugcheck Analysis *

***************************

Hier finden z.B.: hinter "BugCheck" einen Fehlercode. Diesen Fehlercode können Sie anschließend auch für die Suche in der Microsoft Knowledge Base (http://support.microsoft.com/search/) verwenden. Ist der Fehlercode bekannt, finden Sie hier meist genauere Angaben dazu, welcher Treiber diesen Fehler verursacht hat und oft auch entsprechende Lösungsansätze.

Sie können aber auch im Debugger schon mehr über diesen Fehlercode ermitteln. Geben Sie dafür im Command-Fenster den Befehl "!analyze -v" ein.

Anschließend werden eine Menge von Informationen ausgegeben; hier ist in den ersten Zeilen das in Grossbuchstaben geschriebene Wort, welches die Art des Fehlers wiedergibt.

Wenn Sie darüber hinaus noch weitere Informationen aus der Hilfe benötigen, geben Sie im Command-Fenster ".hh [Das Word in Großbuchstaben]" ein.

Weiterhin finden Sie hier auch die Zeile "Probably caused by" (= Fehler verursacht von. Hier wird angegeben, welche Datei vermutlich den Fehler verursacht hat. Mit dieser Datei kann man auch wieder eine entsprechende Suche im Internet starten.

Hat man einen Dateinamen, kann man sich auch im Command-Fenster weitere Informationen dazu anzeigen lassen. Mit dem Befehl "lm v m[Dateiname]" bekommen Sie weitere Infos. Dabei muss der Dateiname ohne Dateiendung eingegeben werden. Der Dateiname wird direkt, gleich hinter dem Parameter m (ohne Leerzeichen) eingegeben.

Über den Befehl "!devnode 0 1" können Sie sich noch eine Liste aller geladenen Treiber ausgeben lassen.

Kommen Sie damit nicht weiter, können Sie sich über den Befehl "!thread" im Command-Fenster, weitere Informationen anzeigen lassen. Finden Sie in der Ausgabe die Zeile "IRP List", dann sollten Sie sich weitere Informationen über die Adressen ausgeben lassen. Dazu rufen Sie den Befehl "!irp [Addresse]" auf. In der Auflistung finden Sie wieder Treibernamen, die am Fehler beteiligt waren.

Informationen zu Fehlern und dem Debugging finden Sie unter:

http://msdn.microsoft.com/library/d...5dc-42de-96af-deb0d7df233b.xml.asp?frame=true

Wenn Sie selber nicht weiterkommen und entsprechende Anfragen in Foren usw. stellen wollen, sollten Sie immer alles aus dem Abschnitt "Bugcheck Analysis" als Informationen weitergeben.

Mir aber egal, da die externen eh nur 1 mal die Woche für BackUps eingeschaltet werden ^^

Vielleicht hilfts ja jemand anderem mit ähnlichem oder gleichen Problem


Gruß X23