Regelmäßige BSOD

[faraday]

Hallo Community, ich brauche wieder mal eure Hilfe,
zunächst mal meine Systemkonfiguration:

Motherboard: GA-EP43-UD3L
Prozessor: Intel Core2Duo E8400 @ 3600MHz
Grafikkarte: PNY GTS 250 1GB
Festplatte: SAMSUNG HD502IJ
Arbeitsspeicher: 4x1GB OCZ Nvidia SLI-ready

Seit kurzem habe ich regelmäßig mitten in der Arbeitsphase einen Bluescreen. Es sind immer andere Treiber betroffen, hier mal eine kurze Übersicht:

http://dl.dropbox.com/u/4243656/BSOD.txt

Das System ist übertakten (s.o.) und läuft bis dato stabil unter Prime95 und anderen Stabilitätsprogrammen. Einen Memtest habe ich ebenfalls schon durchlaufen lassen. Dieser hat einige Fehler angezeigt, aber nachdem ich den MCH-Takt (auf 1,3V) geringfügig erhöht hatte, wurde auch dieses Problem aus der Welt geschaffen. Memtest die ganze Nacht durchlaufen lassen und ohne Fehler. Die Gegenprobe (unübertaktet) hat bestätigt, dass der Ram unbeschädigt ist.
Da immer wieder andere Treiber als Fehlerquelle angezeigt werden, hab ich natürlich keinen Anhaltspunkt auf die Ursache. Mein erster Verdacht war der Ram, aber das hat sich ja nun erledigt. Die Temperaturen sind alle im Rahmen - nichts wird zu warm.

Ich bin echt am verzweifeln.

Gruß fara

 

[Friedulin]

In welchen Situationen treten die Screens auf? Arbeitsphase heißt da genau was? (office, CAD, Zocken?)
Und hast Du die Screens auch bei Standardtakt?
Hast Du Systemüberwachungsprogramme von Gigabyte installiert? (vor allem Easytune?)

Muss jetzt aber los, schau evtl. heute Abend aber wohl eher morgen früh noch mal rein.

 

[stw500]

Mach mal statt Prime folgendes:

LinX runterladen, bei Memory "all" markieren, auf "idle" in der Konfiguration stellen und dem System 50MB zuweisen. Dann mit mind. 25 Runden starten. CPU temps überwachen, sind locker mal 5-10°C mehr als Prime. Dann nebenher eine DVD starten und im Hintergrund als Schleife laufen lassen (den Spielfilm!).

Wenn das ganze 3-4 Stunden ohne Fehler läuft, okay...aber nach meiner Erfahrung geben die meisten angeblich stabilen Systeme nach spätestens 30 Minuten einen Fehler aus.

 

[faraday]

Beim Surfen im Internet und Chatten - quasi Idle.
Auf Standardtakt hab ich noch nicht probiert, das wollt ich als nächstes tun. Da ich allerdings nicht weiß, wann der Screen kommt (das dauert zum Teil mehrere Stunden nach dem Reboot), wär das auch kein hilfreicher Indikator.
Nein, die hab ich nicht installiert. Guck ich mir im Laufe des Tages mal an, danke. :-)

Wenn das ganze 3-4 Stunden ohne Fehler läuft, okay...aber nach meiner Erfahrung geben die meisten angeblich stabilen Systeme nach spätestens 30 Minuten einen Fehler aus.

Naja, wenn er schon im Idle Abstürzt, wird es wohl nicht an der Systemlast liegen, geh ich zumindest mal von aus. Aber wenn alle Stricke reißen, probier ich das mal aus. :-)

 

[Dunkelschwinge]

Immer erstmal ohne OC versuchen. Ein OC kann durchaus auch abbauen durch verdreckte Kühler etc. eventuell bringt Dein Board durch gealterte Kondensatoren im Idle nicht mehr die nötige Spannung....

 

[stw500]

Naja, wenn er schon im Idle Abstürzt, wird es wohl nicht an der Systemlast liegen, geh ich zumindest mal von aus. Aber wenn alle Stricke reißen, probier ich das mal aus. :-)

Nein, nein, das verstehst Du falsch...nicht nur idle und last sind Beanspruchung für die CPU/Ram/Mainboard/GPU, sondern auch Lastwechsel!!!

Du bist nie voll im idle. Irgendwas macht das System immer. Deswegen gibt es auch beim Arbeiten, Surfen, etc. wenn keine dauerhafte Volllast anliegt, immer wieder Spitzen, so dass zwischen idle und leichter Last hin- und hergesprungen wird. Das ist auch eine Form von Belastung, die Bluescreens hervorrufen kann.

LinX berücksichtigt das konkludent. Denn zwischen jeder Runde wird die Volllast kurzzeitig weggenommen und die Software bereitet den neu zu testenden Ram-Bereich erneut vor. In diesem Moment findet ein deutlicher Lastwechsel (Volllast -> idle/leichter Last) statt, in dem häufig Fehler produziert werden, wenn das System nicht völlig stabil ist. Nachdem der Speicher vorbereitet ist, geht es wieder mit voller Last weiter, also erneuter Lastwechsel, dies mal von leichter Last -> Volllast.

Das alles kann man auch schön an den Temps sehen, die kurzzeitig nach Beendigung einer Runde runtergehen und wenige Sekunden später wieder hochschnellen.

Das Video im Hintergrund dient dazu, auch andere als nur Standardberechnungen von der CPU und GPU zu fordern. Damit wird eine höhere Bandbreite für mögliche Instabilitäten abgedeckt und das lohnt sich!

Also nicht abwarten, sondern ranklotzen und hier Meldung machen!

 

[faraday]

Immer erstmal ohne OC versuchen. Ein OC kann durchaus auch abbauen durch verdreckte Kühler etc. eventuell bringt Dein Board durch gealterte Kondensatoren im Idle nicht mehr die nötige Spannung....

Das Dumme ist nur, dass - wie bereits gesagt - es mehrere Stunden dauert, bis ein Bluescreen auftaucht. Somit weiß ich nicht, wie lange ich warten soll, bis dieser erscheint und wenn dann keiner auftauchen sollte, wüsste ich nicht mit 100%iger Sicherheit, ob es an der Übertaktung lag oder Zufall war. Verstehst du? :-/

Nein, nein, das verstehst Du falsch...nicht nur idle und last sind Beanspruchung für die CPU/Ram/Mainboard/GPU, sondern auch Lastwechsel!!!

Du bist nie voll im idle. Irgendwas macht das System immer. Deswegen gibt es auch beim Arbeiten, Surfen, etc. wenn keine dauerhafte Volllast anliegt, immer wieder Spitzen, so dass zwischen idle und leichter Last hin- und hergesprungen wird. Das ist auch eine Form von Belastung, die Bluescreens hervorrufen kann.

LinX berücksichtigt das konkludent. Denn zwischen jeder Runde wird die Volllast kurzzeitig weggenommen und die Software bereitet den neu zu testenden Ram-Bereich erneut vor. In diesem Moment findet ein deutlicher Lastwechsel (Volllast -> idle/leichter Last) statt, in dem häufig Fehler produziert werden, wenn das System nicht völlig stabil ist. Nachdem der Speicher vorbereitet ist, geht es wieder mit voller Last weiter, also erneuter Lastwechsel, dies mal von leichter Last -> Volllast.

Das alles kann man auch schön an den Temps sehen, die kurzzeitig nach Beendigung einer Runde runtergehen und wenige Sekunden später wieder hochschnellen.

Das Video im Hintergrund dient dazu, auch andere als nur Standardberechnungen von der CPU und GPU zu fordern. Damit wird eine höhere Bandbreite für mögliche Instabilitäten abgedeckt und das lohnt sich!

Also nicht abwarten, sondern ranklotzen und hier Meldung machen!

Und woher weiß ich, ob der Screen durch die Last ausgelöst wurde und nicht durch einen Treiber oder etwas anderes?

 

[stw500]

Und woher weiß ich, ob der Screen durch die Last ausgelöst wurde und nicht durch einen Treiber oder etwas anderes?

Schwierig...man kann schauen, ob beim BSOD ein Treiber- bzw. Dateiname angezeigt wird. Das deutet dann manchmal auf einen Treiberkonflikt hin, ist aber meistens doch eine Hardwareinstabilität nach meiner Erfahrung. Außerdem stehen da auch immer so schöne Stop-Fehlermeldungen ala 0x000004f0 oder so ähnlich. Da kann man dann auch googlen, manchmal findet man etwas, meistens ist es aber dennoch wieder die Hardware.

Was noch helfen kann, ist, Virenscanner mal spaßeshalber wechseln. Wenn kostenlos gewünscht, dann Avira oder Avast. Tritt BSOD bei beiden auf, wirds wohl nicht am AV liegen.

Ein brillianter Tipp ist auch immer, ein bis zwei Stufen Vcore nach oben zu gehen. Auch wenn alles stabil erscheint, manchmal fehlt doch ein kleines bißchen Spannung und bevor man sich tot sucht...damit habe ich mind. 50% aller meiner BSOD auf meinem Rechner und Rechner von Freunden & Bekannten wegbekommen.

Ansonsten ist auch nie verkehrt: mit cmd als Administrator eine Dos-Box öffnen und dort "sfc /scannow" eingeben. Dann werden die Systemdateien überprüft und bei Fehler ausgetauscht. Eine fehlerhafte sys-Datei kann einen schon in den Wahnsinn treiben. :-)

 

[faraday]

So, ich hab jetzt in der Konsole "sfc /scannow" eingegeben und es wurde keine Fehlerhafte Systemdatei gefunden.
Sonst noch Ideen?

 

[simpel1970]

Wie bereits schon geschrieben wurde, OC rausnehmen und warten ob wieder Bluescreens auftreten.
Treten Bluescreens auf, den Stopfehlercode aufschreiben oder besser noch die Kerneldump auswerten, die zum Bluescreen geschrieben wird. Sollte ein Treiber für die Bluescreens verantwortlich sein, kann das damit herausgefunden werden. Eine kurze Anleitung für die Auswertung findest du in meiner Signatur.

 

[faraday]

Ich hab schon wieder diesen Bluescreen gehabt. Auf einer Seite stand, dass IRQL_NOT_LESS_OR_EQUAL auf einen Hardwarefehler im PCI oder Ram-Bereich hinweist und eigentlich kein Treiberproblem sein sollte. Ist das so korrekt?

 

[simpel1970]

Das wissen wir genau, wenn das Kernelspeicherabbild ausgewertet wurde.

 

[faraday]

Und wie tu ich das?

 

[simpel1970]

Entweder die Minidumps (C:\Windows\Minidump\) hochladen, oder selbst auswerten (siehe Link in meiner Signatur).

 

[Friedulin]

@simpel1970: Du bist auch überall, wo das Wort Bluescreen auftaucht, oder Danke noch mal für den Tip mit dem Easytune, ich hätte es ja echt nicht geglaubt!

EDIT: Aber sowas von

 

[simpel1970]

@Friedulin: Erwischt...

 

[faraday]

Hab ich die nicht schon hochgeladen?
Siehe: http://dl.dropbox.com/u/4243656/BSOD.txt

 

[Inzersdorfer]

Nein. Du stellst nur den Text der Meldung online, das ist ja sehr nett, hilft aber nicht viel weiter.
Schau in die Signatur von simpel1970, "Bluescreenauswertung" ist ein Link. Entweder die .dmp Datei selbst auswerten oder verzippt an deinen Post anhängen.

 

[simpel1970]

Und nicht vergessen die Übertaktung raus zu nehmen und erst mal testen, ob die Abstürze auch ohne OC auftreten.

 

[faraday]

Okay, das Debugging Tool funktioniert nicht, wie es in der Anleitung steht. Er lädt zu anfang gar nichts. Wenn die die Symbole laden will, ist "Reload" grau unterlegt. Wenn ich die Memory.dmp direkt aufrufe, fehlen die Symbole.
Irgendwelche Ideen?

EDIT: Ich hoffe, das war jetzt richtig. Was als Text rauskam war das hier:

WHEA_UNCORRECTABLE_ERROR (124)
A fatal hardware error has occurred. Parameter 1 identifies the type of error
source that reported the error. Parameter 2 holds the address of the
WHEA_ERROR_RECORD structure that describes the error conditon.
Arguments:
Arg1: 0000000000000000, Machine Check Exception
Arg2: fffffa80057dd038, Address of the WHEA_ERROR_RECORD structure.
Arg3: 00000000b2000040, High order 32-bits of the MCi_STATUS value.
Arg4: 0000000000000800, Low order 32-bits of the MCi_STATUS value.

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


BUGCHECK_STR: 0x124_GenuineIntel

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: f

STACK_TEXT:
fffff880`009f29d8 fffff800`02e09a3b : 00000000`00000124 00000000`00000000 fffffa80`057dd038 00000000`b2000040 : nt!KeBugCheckEx
fffff880`009f29e0 fffff800`0299b563 : 00000000`00000001 fffffa80`0367c460 00000000`00000000 fffffa80`0367c4b0 : hal!HalBugCheckSystem+0x1e3
fffff880`009f2a20 fffff800`02e09700 : 00000000`00000728 fffffa80`0367c460 fffff880`009f2db0 fffff880`009f2d00 : nt!WheaReportHwError+0x263
fffff880`009f2a80 fffff800`02e09052 : fffffa80`0367c460 fffff880`009f2db0 fffffa80`0367c460 00000000`00000000 : hal!HalpMcaReportError+0x4c
fffff880`009f2bd0 fffff800`02e08f0d : 00000000`00000002 00000000`00000001 fffff880`009f2e30 00000000`00000000 : hal!HalpMceHandler+0x9e
fffff880`009f2c10 fffff800`02dfce88 : 00000000`5d67c194 fffff880`030d6358 00000000`00000000 00000000`00000000 : hal!HalpMceHandlerWithRendezvous+0x55
fffff880`009f2c40 fffff800`0288c5ec : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : hal!HalHandleMcheck+0x40
fffff880`009f2c70 fffff800`0288c453 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KxMcheckAbort+0x6c
fffff880`009f2db0 fffff800`028937f0 : fffff880`009ea180 00000000`00000001 00000000`00000000 fffff880`030d6358 : nt!KiMcheckAbort+0x153
fffff880`030d6220 fffff800`0282fde3 : 00000000`00000000 00000000`00000000 fffff800`02ac05c0 00000000`00000000 : nt!KeFlushMultipleRangeTb+0x250
fffff880`030d62f0 fffff800`0298c7e8 : 00000000`00000000 00000000`00000000 00000000`00000001 00000000`00000000 : nt! ?? ::FNODOBFM::`string'+0x4b3bb
fffff880`030d6450 fffff800`0298cc8e : fffff980`03830fa0 fffff800`0298ca6a 00000000`00000001 fffff880`030d64c0 : nt!MiPurgeSpecialPoolPaged+0x18
fffff880`030d6480 fffff800`029b8975 : fffff800`0280e000 00000000`6446744e ffffffff`fffff5ec fffff880`030d67a8 : nt!MmFreeSpecialPool+0x45e
fffff880`030d65d0 fffff880`014c627a : fffff980`03d98e40 fffff980`03942a90 fffff980`03942a90 00000000`0000000b : nt!ExDeferredFreePool+0xf6d
fffff880`030d6680 fffff880`014cd62c : fffff980`03d98e40 fffff980`03942bc0 fffff980`03942a90 fffffa80`0531d180 : Ntfs!NtfsCommonClose+0x43a
fffff880`030d6750 fffff800`02d30c16 : fffff980`03d96c01 fffff980`03d96c10 00000000`00000000 00000000`00000003 : Ntfs!NtfsFsdClose+0x2dc
fffff880`030d6850 fffff880`012336af : fffffa80`0531b040 00000000`00000002 fffffa80`0531b040 fffffa80`05c10f40 : nt!IovCallDriver+0x566
fffff880`030d68b0 fffff800`02d30c16 : fffff980`03d96c10 00000000`00000002 fffffa80`03705040 fffffa80`05c6b040 : fltmgr!FltpDispatch+0x9f
fffff880`030d6910 fffff800`02b89a1e : fffffa80`05c6b070 00000000`00000001 fffff980`03d96c10 fffffa80`05c10c00 : nt!IovCallDriver+0x566
fffff880`030d6970 fffff800`02897b14 : fffffa80`03705040 fffffa80`03705040 fffffa80`037259f0 fffff8a0`00001870 : nt!IopDeleteFile+0x11e
fffff880`030d6a00 fffff800`02b84614 : fffffa80`03705040 00000000`00000000 fffffa80`0584d670 00000000`00000000 : nt!ObfDereferenceObject+0xd4
fffff880`030d6a60 fffff800`02b84bc4 : 00000000`0000019c fffffa80`03705040 fffff8a0`00001870 00000000`0000019c : nt!ObpCloseHandleTableEntry+0xc4
fffff880`030d6af0 fffff800`0288cf93 : fffffa80`0584d670 fffff880`030d6bc0 fffffa80`05848e10 00000000`00000037 : nt!ObpCloseHandle+0x94
fffff880`030d6b40 fffff800`02889530 : fffff880`01255c33 00000000`00000017 00000000`00000037 fffffa80`05848e10 : nt!KiSystemServiceCopyEnd+0x13
fffff880`030d6cd8 fffff880`01255c33 : 00000000`00000017 00000000`00000037 fffffa80`05848e10 00000000`00000037 : nt!KiServiceLinkage
fffff880`030d6ce0 fffff880`01256f81 : fffffa80`00000040 00000000`00000040 00000000`00000038 00000000`00000000 : fltmgr!FltpExpandShortNames+0x283
fffff880`030d6d40 fffff880`01256e1e : fffffa80`05848e10 fffff880`01250000 00000000`00000000 00000000`00000000 : fltmgr!FltpGetNormalizedFileNameWorker+0xc1
fffff880`030d6d80 fffff880`012384fb : fffffa80`05129080 00000000`00000000 fffffa80`05c731c0 fffff880`030d8000 : fltmgr!FltpCreateFileNameInformation+0xee
fffff880`030d6de0 fffff880`01243b44 : 00000000`00008000 fffffa80`05c731c0 00000000`00000000 00000000`00000401 : fltmgr!FltpGetFileNameInformation+0x26b
fffff880`030d6e60 fffff880`0128736b : fffffa80`05848e10 fffff8a0`0380d8c0 00000000`00000001 fffff880`030d6f90 : fltmgr!FltGetFileNameInformation+0x184
fffff880`030d6ef0 fffff880`01285bdb : fffff140`003ab4a7 00000052`00000000 fffff140`003ab400 fffff8a0`00000085 : fileinfo!FIStreamGetInfo+0x11f
fffff880`030d6f70 fffff880`01236288 : fffffa80`00000000 fffff8a0`0380d8c0 fffff980`03d24fb0 00000000`00000000 : fileinfo!FIPostCreateCallback+0x1c7
fffff880`030d7000 fffff880`01234d1b : fffff980`03d24fb0 fffffa80`05bff160 fffffa80`058446b0 fffffa80`058448d0 : fltmgr!FltpPerformPostCallbacks+0x368
fffff880`030d70d0 fffff880`012542b9 : fffff980`03d24c10 fffffa80`0531b650 fffff980`03d24c00 fffffa80`0531b040 : fltmgr!FltpLegacyProcessingAfterPreCallbacksCompleted+0x39b
fffff880`030d7160 fffff800`02d30c16 : fffff980`03d24c10 00000000`00000002 00000000`00000240 00000000`00000000 : fltmgr!FltpCreate+0x2a9
fffff880`030d7210 fffff800`02b8b625 : 00000000`00000004 fffffa80`05c0fcc8 fffffa80`05c0f010 fffffa80`05c10cd0 : nt!IovCallDriver+0x566
fffff880`030d7270 fffff800`02b87ec8 : fffffa80`05504640 fffff800`00000000 fffffa80`05c0fb10 fffff8a0`00000000 : nt!IopParseDevice+0x5a5
fffff880`030d7400 fffff800`02b890e6 : 00000000`00000000 fffffa80`05c0fb10 00000000`00000034 fffffa80`037259f0 : nt!ObpLookupObjectName+0x588
fffff880`030d74f0 fffff800`02b8a9ec : fffff800`02ac0500 00000000`00000000 fffff800`02ac0500 fffff800`02ac0500 : nt!ObOpenObjectByName+0x306
fffff880`030d75c0 fffff800`02b95608 : fffff8a0`007d95c0 00000000`00010003 fffff880`030d7980 fffff880`030d79b0 : nt!IopCreateFile+0x2bc
fffff880`030d7660 fffff800`0288cf93 : 00000000`00000000 0000007f`ffffffff fffff8a0`001b4f20 00000980`00000000 : nt!NtCreateFile+0x78
fffff880`030d76f0 fffff800`02889530 : fffff800`02bfe098 fffff8a0`007d9010 fffff8a0`007d9010 fffff800`029c4f10 : nt!KiSystemServiceCopyEnd+0x13
fffff880`030d78f8 fffff800`02bfe098 : fffff8a0`007d9010 fffff8a0`007d9010 fffff800`029c4f10 fffff780`00000008 : nt!KiServiceLinkage
fffff880`030d7900 fffff800`02d08f51 : 00000000`00000000 fffff800`00000200 fffff8a0`007d9010 fffff800`02a00093 : nt!CmpInitBackupHive+0x1a8
fffff880`030d7a70 fffff800`02b2a32e : 00000000`029d4e14 fffffa80`0584d670 00000000`00000080 fffffa80`03705040 : nt!CmpLoadHiveThread+0x201
fffff880`030d7d40 fffff800`0287f666 : fffff800`02a00e80 fffffa80`0584d670 fffff800`02a0ecc0 fffff880`01437cb0 : nt!PspSystemThreadStartup+0x5a
fffff880`030d7d80 00000000`00000000 : fffff880`030d8000 fffff880`030d2000 fffff880`030d6100 00000000`00000000 : nt!KiStartSystemThread+0x16


STACK_COMMAND: kb

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: hardware

IMAGE_NAME: hardware

DEBUG_FLR_IMAGE_TIMESTAMP: 0

FAILURE_BUCKET_ID: X64_0x124_GenuineIntel_VRF_PROCESSOR_BUS

BUCKET_ID: X64_0x124_GenuineIntel_VRF_PROCESSOR_BUS

Followup: MachineOwner