Bluescreen!

Seit ich einen Neuen CPU Mainboard und eine SSD eingebaut habe (Mitte Dezember 2013), hatte ich keine Porbleme. Doch heute gleich 2 mal einen Bluescreen innerhalb von 10 min. Dies mag vielleicht ein zufall sein doch habe ich eure anleitung befolgt und ein Debug der Crash Dump gemacht. Hoffe ihr könnt mir helfen.

Falls relevant meine System:
Windows 7 Ultimate 64-bit (6.1, Build 7601) Service Pack 1 (Up-to-date)
Prozessor: Intel(R) Core(TM) i5-4570 CPU @ 3.20GHz (4 CPUs), ~3.2GHz
Mainboard: MSI H81M-P33
Ram: 2x4GB DDR3 Adata 1333Mh´z
Grafikkarte: AMD Radeon HD 6870
Festplatten: Samsung SSD 840 EVO 250GB
ExcelStor Technology J9250S 250GB und SAMSUNG HD103SI 1TB
Netzteil: MS-Tech MS-N750-VAL-CM(750Watt)

Hier der Debug bericht:
Code:
0: kd> !analyze -v
*******************************************************************************
*                                                                             *
*                        Bugcheck Analysis                                    *
*                                                                             *
*******************************************************************************

IRQL_GT_ZERO_AT_SYSTEM_SERVICE (4a)
Returning to usermode from a system call at an IRQL > PASSIVE_LEVEL.
Arguments:
Arg1: 000000007776132a, Address of system function (system call routine)
Arg2: 0000000000000002, Current IRQL
Arg3: 0000000000000000, 0
Arg4: fffff8800bb3db60, 0

Debugging Details:
------------------


PROCESS_NAME:  vsserv.exe

BUGCHECK_STR:  RAISED_IRQL_FAULT

FAULTING_IP: 
+0
00000000`7776132a c3              ret

CUSTOMER_CRASH_COUNT:  1

DEFAULT_BUCKET_ID:  VISTA_DRIVER_FAULT

CURRENT_IRQL:  2

LAST_CONTROL_TRANSFER:  from fffff800032d0169 to fffff800032d0bc0

STACK_TEXT:  
fffff880`0bb3d928 fffff800`032d0169 : 00000000`0000004a 00000000`7776132a 00000000`00000002 00000000`00000000 : nt!KeBugCheckEx
fffff880`0bb3d930 fffff800`032d00a0 : 00000000`00000a98 fffff880`0bb3db60 00000000`00000000 fffff800`035ba383 : nt!KiBugCheckDispatch+0x69
fffff880`0bb3da70 00000000`7776132a : 000007fe`fd656d26 00000000`00000000 00000000`256701b8 00000000`2a7a8970 : nt!KiSystemServiceExit+0x245
00000000`223ffcc8 000007fe`fd656d26 : 00000000`00000000 00000000`256701b8 00000000`2a7a8970 000007fe`fd6310dc : 0x7776132a
00000000`223ffcd0 00000000`00000000 : 00000000`256701b8 00000000`2a7a8970 000007fe`fd6310dc 00000000`24c5bcd0 : 0x7fe`fd656d26


STACK_COMMAND:  kb

FOLLOWUP_IP: 
nt!KiSystemServiceExit+245
fffff800`032d00a0 4883ec50        sub     rsp,50h

SYMBOL_STACK_INDEX:  2

SYMBOL_NAME:  nt!KiSystemServiceExit+245

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: nt

IMAGE_NAME:  ntkrnlmp.exe

DEBUG_FLR_IMAGE_TIMESTAMP:  521ea035

FAILURE_BUCKET_ID:  X64_RAISED_IRQL_FAULT_vsserv.exe_nt!KiSystemServiceExit+245

BUCKET_ID:  X64_RAISED_IRQL_FAULT_vsserv.exe_nt!KiSystemServiceExit+245

Followup: MachineOwner
---------

Bin über jede Hilfe dankbar wenn ihr noch Infos braucht so sagt es;)
 
Ich denke auch wen mein System eigentlich neu ist werde ich mal alles neu machen. Hatte zwar bis jetzt keinen Bluescreen mehr aber sowas wurmt dann doch echt. Danke für die Hilfe.

Sehe gerade das ich meine Mail als Nutzername habe haha man muss ich Panik gehabt haben XD.
 
Hallo,

Ich hatte meinem FJS-OEM-Board das MSI-Retail-Bios geflasht und damit ein (auf dem OEM nicht vorhandenes) Firewire-Device. Nach Flashen des OEM-Bios scheint jetzt gerätemäßig alles ok zu sein.

Von den 4 Crashdumps lief bei den ersten 2 noch RMClock mit, das hab ich dann deaktiviert. Der BSoD passiert nie nach normalem Booten, nur (ca. 10 min.) nach dem Resume aus dem Energiesparmodus von Win7. Dazu kommt noch (vielleicht kennt jemand die Lösung), daß nach dem Resume die Lüftersteuerung nicht mehr greift, der läuft dann immer auf Fullspeed.

Wenn ich das richtig interpretiere, verweisen die Dumps auf die acpi.sys. Kann man den Verursacher noch weiter eingrenzen?

Anhang anzeigen DRIVER_POWER_STATE_FAILURE.rar
 
Hab im Bios eigentlich alles aktiviert, was Strom spart. Ohne Zwischenstation "Energie sparen" gibt es keinen BSoD, d.h. die Fehlerquelle wird erst dadurch aktiviert.
Kann man aus den Dumps mehr erkennen?
 
Müßte mal gucken, ob ich noch ne Platte frei hab.
Der (hoffentlich) relevante teil des Reports von osronline.com
Code:
DRIVER_POWER_STATE_FAILURE (9f)
A driver has failed to complete a power IRP within a specific time (usually 10 minutes).
Arguments:
Arg1: 00000003, A device object has been blocking an Irp for too long a time
Arg2: 85cabb90, Physical Device Object of the stack
Arg3: 82b75ae0, nt!TRIAGE_9F_POWER on Win7, otherwise the Functional Device Object of the stack
Arg4: 85802e00, The blocked IRP

Debugging Details:
------------------

TRIAGER: Could not open triage file : e:\dump_analysis\program\triage\modclass.ini, error 2

DRVPOWERSTATE_SUBCODE:  3

IMAGE_NAME:  ACPI.sys

DEBUG_FLR_IMAGE_TIMESTAMP:  4ce788e0

MODULE_NAME: ACPI

FAULTING_MODULE: 8b8cd000 ACPI

DEFAULT_BUCKET_ID:  WIN7_DRIVER_FAULT

BUGCHECK_STR:  0x9F

PROCESS_NAME:  System

CURRENT_IRQL:  2

STACK_TEXT:  
82b75a94 82b15377 0000009f 00000003 85cabb90 nt!KeBugCheckEx+0x1e
82b75b00 82b153f0 82b75ba0 00000000 82b82380 nt!PopCheckIrpWatchdog+0x1f5
82b75b38 82ac74d9 82b906e0 00000000 6a7baade nt!PopCheckForIdleness+0x73
82b75b7c 82ac747d 82b78d20 82b75ca8 00000001 nt!KiProcessTimerDpcTable+0x50
82b75c68 82ac733a 82b78d20 82b75ca8 00000000 nt!KiProcessExpiredTimerList+0x101
82b75cdc 82ac54ce 00556d65 87069030 82b82380 nt!KiTimerExpiration+0x25c
82b75d20 82ac52f8 00000000 0000000e 00000000 nt!KiRetireDpcList+0xcb
82b75d24 00000000 0000000e 00000000 00000000 nt!KiIdleLoop+0x38


STACK_COMMAND:  kb

FOLLOWUP_NAME:  MachineOwner

FAILURE_BUCKET_ID:  0x9F_3_i8042prt_IMAGE_ACPI.sys

BUCKET_ID:  0x9F_3_i8042prt_IMAGE_ACPI.sys

Followup: MachineOwner
---------
Könnte man nicht mit sysprep alle Treiber rausschmeißen und dann alles neu erkennen lassen?
Kann das Problem mit der Lüfterdrehzahl nach Resume auch damit zusammen hängen?

Ich guck mal wegen Platte, kann etwas dauern.
 
Nach dem Dumps sieht es nach einem ACPI Problem aus.

Ich hatte meinem FJS-OEM-Board das MSI-Retail-Bios geflasht und damit ein (auf dem OEM nicht vorhandenes) Firewire-Device

Möglicherweise hast du dir die Probleme mit dem Bios eingefangen, welches nicht für dein Board bestimmt ist?
 
Zum Bios:
Das Board ist eigentlich ein MSI-Board, undzwar das "MSI G31M", auch unter MS-7379 zu finden. Unter der Bezeichnung führt es auch FJS.
Ich hatte das MSI-Bios geflasht, das Board lief damit auch, im Gerätemanager gabs aber einen Firewire-Anschluß, der nicht funktioniert hat, bzw. logischer Weise nicht funktionieren konnte, da der auf dem OEM-Board eingespart wurde.
Ich hab mir vom FJS-Support den Link zum OEM-Bios schicken lassen und das dann geflasht. Das Bios ist also jetzt schon das "passende". Ich hab auch vor und nach dem Flashen nen Cmos-Reset gemacht.

zu Maus/Tastatur:
Beides funktioniert auch nach dem Resume, die Maus ist ne USB (Speedlink), die Tastatur ist ne PS2 "Lenovo LXH-JWE2207P".
Da ich jetzt von Energiesparen auf Ruhemodus umgeschaltet hab, gibts z.Z. auch keine Bluescreens mehr und die Lüftersteuerung funktioniert auch nach dem Resume.

Um vom Driver Verifier Ergebnisse zu bekommen, muß ich erst wieder auf Energiesparen umstellen und den BSoD auslösen, da drücke ich mich grad noch drum.
 
Zuletzt bearbeitet:
fakeraol schrieb:
Da ich jetzt von Energiesparen auf Ruhemodus umgeschaltet hab, gibts z.Z. auch keine Bluescreens mehr und die Lüftersteuerung funktioniert auch nach dem Resume.

Kurz zur Begriffsbestimmung...
Ruhemodus = Suspend to Disk
Energie sparen = Suspend to RAM

Hibernate (hybrider Standby Modus - vereint Ruhemodus und Energie sparen) ist bei dir deaktiviert?
 
Ja, die Bluescreens traten im hybriden Standby Modus auf und den hab ich jetzt deaktiviert und nutze Suspend to Disk, weil ich denke, daß sowohl der BSoD als auch das Problem mit der Lüftersteuerung damit zusammenhägen, daß bei Suspend to Ram die Intitialisierung eines Gerätes verloren geht, so daß nach dem Resume die gespeicherten Software-Zustände nicht mehr auf die gleichen Initialisierungszustände des Gerätes treffen.

BSoD also = Resume vom hybriden Standby Modus
 
fakeraol schrieb:
und nutze Suspend to Disk, weil ich denke, daß sowohl der BSoD als auch das Problem mit der Lüftersteuerung damit zusammenhägen, daß bei Suspend to Ram die Intitialisierung eines Gerätes verloren geht,

Dann könnte das Problem durchaus beim RAM (defekt, fehlerhafte Einstellungen, Kompatibilitätsprobleme) zu suchen sein.

Poste bitte mal ein paar Screenshots von CPU-Z (Reiter CPU, Memory und SPD).
Überprüfe zur Sicherheit auch die RAM mit Memtest86+ auf Fehler.
 
Zurück
Oben