Win 7 64bit, Bluescreens nach Treiberinstallation

Fooly

Komplett-PC-Käufer(in)
Hallo zusammen!

Ich habe mir vorletzte Woche meinen PC aufgerüstet. Das alte Board samt Core2Duo 6850, und RAM flog raus, der Rest wurde weiter verwendet. Windows wurde natürlich aufgrund der erheblichen Änderungen an der Hardware neu installiert.

Aktuell schaut der Rechner jetzt so aus:

Mainboard: MSI P67A-GD65 (B3 Stepping)
CPU: Intel Core i7 2600K, derzeit von mir nicht übertaktet, aber das System betreibt ihn eigentlich standardmässig dauerhaft mit 3,5 GHz
RAM: 4x Corsair DDR3-1333 á 4 GB, also insgesamt 16 GB
Grafikkarte: Leadtek GeForce 260 GTX, wurde vom Vorrechner übernommen. Wird evtl. später mal noch durch was neueres ersetzt, hat aber keine Priorität
Festplatten: 2x WD Caviar Blue 420 GB SATA-2, 2x WD Caviar Blue 640 GB SATA-2, auch übernommen
sonstige Laufwerke: Blueray, nen herkömmliches DVD-ROM, und ein DVD-Brenner, auch alles SATA-Laufwerke

Nach Konfiguration der SATA-Schnittstellen auf RAID (2x 420 GB als RAID-0, 2x 640 GB als RAID-1), Installation von Windows, aller Treiber und Updates schien der Rechner zunächst einwandfrei zu laufen. Ich hatte jedoch das Pech, das schon am zweiten Tag der Lüfter des verbauten Scythe Rasetsu schlapp machte. Lag an der integrierten Lüftersteuerung, er lief nicht mehr an, zuckte bestenfalls noch etwas unmotiviert. Um das Ding nicht nochmal ausbauen zu müssen habe ich den Lüfter kurzerhand durch einen ungeregelten 120mm Gehäuselüfter ersetzt, der jetzt konstant auf 1300 U/min läuft und seine Sache auch gut macht.

Wieder schien alles in Ordnung, jedoch bekam ich von nun an sporadisch Bluescreens, mindestens einmal pro Tag. Egal ob der Rechner gerade Speicher- oder CPU-mässig ausgelastet war, oder sich grad grösstenteils langweilte. Man konnte es nicht an einem bestimmten Lastzustand festmachen. Auch die Fehlermeldung selbst wechselte sich öfter mal ab. Nach anfänglichem Verdacht, einer der RAMs könnte der Übeltäter sein, habe ich mir die Timings angesehen, die aber augenscheinlich passen (auch nicht übertaktet). Erwartungsgemäss sind die automatischen Einstellungen des RAMs bei Nutzung von 4 DIMMs etwas langsamer als bei nur zweien. Spannungen schienen auch zu stimmen, zumindest soweit angezeigt. Eine externe Messmöglichkeit habe ich nicht. MemTest zeigte nach 12 Stunden auch keinerlei Probleme mit dem RAM auf.

Also habe ich kurzerhand das Debugging Tool von Microsoft installiert, und mir die MEMORY.DMP Dateien mal angesehen, die ja bei jedem Bluescreen abgespeichert werden. Wie vorher schon erwähnt, variierten die eigentlichen Fehlermeldungen. Aber eine Gemeinsamkeit ließ sich immer feststellen. Der Eintrag DRIVER_FAULT und die Erwähnung von iastor.

Also machte ich erst einmal ein Update auf die aktuellste version des Intel-Treibers (dem Mainboard beigelegen war die Vorgängerversion), was aber nichts gebracht hat. Da ich meinen Rechner vor Auftreten der ersten Bluescreens bereits wieder voll mit aller Software ausgestattet hatte, und keine Lust verspürte nochmal komplett neu zu installieren ließ ich mich auf ein Experiment ein. Ich erstellte ein aktuelles Image meiner beiden RAID-Sets, löste die RAIDs auf, stellte im BIOS von RAID auf AHCI um, und machte ein Recovery auf die nun vier Einzelplatten. Obwohl ich es nicht erwartet hätte, verlief der Bootvorgang danach sehr problemlos. Zwar ist für RAID und AHCI der Treiber der selbe, jedoch hätte ich mir Komplikationen erwartet, die aber aus blieben.

Und jetzt kommts: seitdem habe ich keine Bluescreens mehr. Es lag also am RAID.

Die Frage bleibt jedoch offen, wars der Treiber selbst, oder lag die Ursache an einer oder mehreren Platten? Die Platten laufen jetzt einwandfrei, konnte auch keinen Fehler darauf feststellen. Zudem liefen die vorher mit dem alten Board auch schon in der gleichen RAID-Konfiguration problemlos.

Auf das RAID-0 kann ich notfalls verzichten, durch Verteilen der zugriffslastigen Partitionen auf zwei separate Platten relativiert sich das weitgehend. Aber ich hätte doch gerne für meine Datenplatte wieder Netz und doppelten Boden in Form des RAID-1.

Hat da noch jemand einen Rat übrig?
 
Hi,
wenns am Raid liegt, deine "alten" Platten iO sind, kanns eigentlich nur am Mainboard oder den Anschlüssen liegen.
Wenn kein "externer" Raidcontroller verwendet wird, kanns eigentlich nur an der Southbridge des MB liegen oder wie gesagt ist vllt ein Kabel defekt, wackler usw...
Wäre das einzigste was mir gerade spontan dazu einfällt, hoffe ich konnte helfen
 
Hi,
wenns am Raid liegt, deine "alten" Platten iO sind, kanns eigentlich nur am Mainboard oder den Anschlüssen liegen.
Wenn kein "externer" Raidcontroller verwendet wird, kanns eigentlich nur an der Southbridge des MB liegen oder wie gesagt ist vllt ein Kabel defekt, wackler usw...
Wäre das einzigste was mir gerade spontan dazu einfällt, hoffe ich konnte helfen

Tja, da bin ich eben in der Sackgasse. Bei defektem Kabel oder Wackelkontakt müsste ich ja auch jetzt wo die Platten nicht im RAID laufen was davon merken. Das scheidet schon mal aus. Obs am Board liegt kann ich mit eigenen Mitteln kaum überprüfen, zumindest nicht ohne einen Satz anderer Platten, die ich nicht habe. Ich vermute fast der Restverdacht ruht, obwohl kein Fehler gefunden, auf wenigstens einer der Platten. Das finde ich aber frühestens dann raus, wenn ich die mal durch zeitgemässe SATA-3 Platten ersetze. Das ist aber auch erstmal noch aufgeschoben, denn Platz hab ich noch genug und nur allein der Geschwindigkeit wegen muß ich jetzt nicht anfangen neue Platten zu kaufen.

Der einzig wirkliche Grund fürs RAID wär eben die Datenplatte zu spiegeln. Ich mache zwar regelmässig Backups auf externe Platten, jedoch würde beim Ausfall einer Platte der absolut aktuelle Datenbestand erhalten bleiben, während ich sonst "nur" auf dem Stand des letzten Backups wär, was im schlimmsten Fall bedeuten würde die Änderungen eines Tag zu verlieren.

Interessant wär aber, ob es halt vielleicht doch am Treiber oder möglicherweise BIOS liegt, und andere ähnliche Erfahrungen gemacht haben. Immerhin kümmert sich um die Platten jetzt genau der gleiche Treiber, nur eben nicht als RAID sondern AHCI, und das funzt nun einwandfrei. Dann könnte das Problem ja mit einer folgenden Treiber- oder BIOS-Version ggf. erledigt sein.

Ich hab halt nur keine Lust großartig Experimente zu machen. Das Recovern meines Backups dauert auch jedesmal immerhin gut 8-10 Stunden von ner USB 2.0 Platte. Das war ja ausschlag gebend zum Kauf dieses Boards. weil es eben 8 interne SATA-Ports hat, und 2 eSATA, bzw. auch 4x USB 3.0, um künftig die Möglichkeit für schnellere Backups mit den passenden externen Platten zu haben. Die inkrementellen Backups sind auch so harmlos. Aber hin und wieder, spätestens wenn die erste Backup-Platte voll wird, fängt man halt doch auf der zweiten Platte mit nem Voll-Backup wieder an. Und das läuft jetzt auch immer über Nacht, dauert halt seine Zeit.
 
Hm, zu früh gefreut. Hatte gerade wieder Bluescreen, auch wenn das System schon fast ungewöhnlich lange lief. WinDbg sagt folgendes:

Loading Dump File [F:\MEMORY7.DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: SRV*C:\Synmbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17514.amd64fre.win7sp1_rtm.101119-1850
Machine Name:
Kernel base = 0xfffff800`02c65000 PsLoadedModuleList = 0xfffff800`02eaae90
Debug session time: Sun Apr 10 16:41:47.651 2011 (GMT+2)
System Uptime: 0 days 4:27:17.494
Loading Kernel Symbols
...............................................................
................................................................
...............................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type ".hh dbgerr001" for details
Loading unloaded module list
...........
The context is partially valid. Only x86 user-mode context is available.
The wow64exts extension must be loaded to access 32-bit state.
.load wow64exts will do this if you haven't loaded it already.
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1E, {0, 0, 0, 0}

PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type ".hh dbgerr001" for details
Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

Followup: MachineOwner
---------
Geht man ins Detail kommt das raus:

16.0: kd:x86> .load wow64exts
16.0: kd:x86> !analyze -v
The context is partially valid. Only x86 user-mode context is available.
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: 0000000000000000, The exception code that was not handled
Arg2: 0000000000000000, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: 0000000000000000, Parameter 1 of the exception

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

PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type ".hh dbgerr001" for details

EXCEPTION_CODE: (Win32) 0 (0) - Der Vorgang wurde erfolgreich beendet.

FAULTING_IP:
+0
00000000 ?? ???

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000000000000000

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x1E

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0000000000000000 to 0000000000000000

STACK_TEXT:
00000000 00000000 00000000 00000000 00000000 0x0


STACK_COMMAND: kb

SYMBOL_NAME: ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

BUCKET_ID: INVALID_KERNEL_CONTEXT

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

Nachtrag: Ok, grad gesehen, hab beim debuggen nicht richtig in den 64bit Modus umgeschaltet. Nachdem ich das getan hab weist die Analyse wieder auf was vom Intel-Treiber hin. Ich hab jetzt einfach mal die Intel-Treiber komplett runtergeschmissen und fahr wieder mit den AHCI-Treibern die Win 7 an Bord hat. Mal schauen obs was bringt.
 
Zuletzt bearbeitet:
Hier das Ergebnis mit den Standard-AHCI Treibern. Nun soll es plötzlich der Windows Media Player sein:

Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [F:\MEMORY8 (standard Windows AHCI Treiber).DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: SRV*C:\Synmbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17514.amd64fre.win7sp1_rtm.101119-1850
Machine Name:
Kernel base = 0xfffff800`02c68000 PsLoadedModuleList = 0xfffff800`02eade90
Debug session time: Sun Apr 10 18:14:56.178 2011 (GMT+2)
System Uptime: 0 days 0:59:40.021
Loading Kernel Symbols
...............................................................
................................................................
..............................................
Loading User Symbols
PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type ".hh dbgerr001" for details
Loading unloaded module list
.......
The context is partially valid. Only x86 user-mode context is available.
The wow64exts extension must be loaded to access 32-bit state.
.load wow64exts will do this if you haven't loaded it already.
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 3B, {c0000005, fffff80002fe3d32, fffff8800bec0f40, 0}

PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type ".hh dbgerr001" for details
Probably caused by : Unknown_Image ( nt!ObOpenObjectByName+e2 )

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

16.3: kd:x86> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff80002fe3d32, Address of the exception record for the exception that caused the bugcheck
Arg3: fffff8800bec0f40, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

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

PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type ".hh dbgerr001" for details

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

FAULTING_IP:
nt!ObOpenObjectByName+e2
02fe3d32 8801 mov byte ptr [ecx],al

CONTEXT: fffff8800bec0f40 -- (.cxr 0xfffff8800bec0f40)
Unable to read context, NTSTATUS 0xC0000147

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x3B

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0000000000000000 to 0000000000000000

STACK_TEXT:
00000000 00000000 00000000 00000000 00000000 0x0


STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nt!ObOpenObjectByName+e2
02fe3d32 8801 mov byte ptr [ecx],al

SYMBOL_NAME: nt!ObOpenObjectByName+e2

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

BUCKET_ID: INVALID_KERNEL_CONTEXT

MODULE_NAME: Unknown_Module

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

16.3: kd:x86> !wow64exts.sw
The context is partially valid. Only x86 user-mode context is available.
Switched to 64bit mode
16.3: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

SYSTEM_SERVICE_EXCEPTION (3b)
An exception happened while executing a system service routine.
Arguments:
Arg1: 00000000c0000005, Exception code that caused the bugcheck
Arg2: fffff80002fe3d32, Address of the exception record for the exception that caused the bugcheck
Arg3: fffff8800bec0f40, Address of the context record for the exception that caused the bugcheck
Arg4: 0000000000000000, zero.

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

PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type ".hh dbgerr001" for details
PEB is paged out (Peb.Ldr = 00000000`7efdf018). Type ".hh dbgerr001" for details

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - Die Anweisung in 0x%08lx verweist auf Speicher 0x%08lx. Der Vorgang %s konnte nicht im Speicher durchgef hrt werden.

FAULTING_IP:
nt!ObOpenObjectByName+e2
fffff800`02fe3d32 8801 mov byte ptr [rcx],al

CONTEXT: fffff8800bec0f40 -- (.cxr 0xfffff8800bec0f40)
Unable to read context, NTSTATUS 0xC0000147

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x3B

PROCESS_NAME: wmplayer.exe

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0000000000000000 to 0000000000000000

STACK_TEXT:
00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x0


STACK_COMMAND: .bugcheck ; kb

FOLLOWUP_IP:
nt!ObOpenObjectByName+e2
fffff800`02fe3d32 8801 mov byte ptr [rcx],al

SYMBOL_NAME: nt!ObOpenObjectByName+e2

FOLLOWUP_NAME: MachineOwner

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

BUCKET_ID: INVALID_KERNEL_CONTEXT

MODULE_NAME: Unknown_Module

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

Danach der Versuch den Rechner nur mit 8 GB zu betreiben, die DIMMs aus Slot 2 und 4 entfernt:

Microsoft (R) Windows Debugger Version 6.11.0001.404 AMD64
Copyright (c) Microsoft Corporation. All rights reserved.


Loading Dump File [F:\MEMORY9 (nur DIMM1+3 belegt).DMP]
Kernel Summary Dump File: Only kernel address space is available

Symbol search path is: SRV*C:\Synmbols*http://msdl.microsoft.com/download/symbols
Executable search path is:
Windows 7 Kernel Version 7601 (Service Pack 1) MP (8 procs) Free x64
Product: WinNt, suite: TerminalServer SingleUserTS
Built by: 7601.17514.amd64fre.win7sp1_rtm.101119-1850
Machine Name:
Kernel base = 0xfffff800`02c66000 PsLoadedModuleList = 0xfffff800`02eabe90
Debug session time: Sun Apr 10 19:31:16.149 2011 (GMT+2)
System Uptime: 0 days 1:03:59.008
Loading Kernel Symbols
...............................................................
................................................................
..............................................
Loading User Symbols

Loading unloaded module list
...........
The context is partially valid. Only x86 user-mode context is available.
The wow64exts extension must be loaded to access 32-bit state.
.load wow64exts will do this if you haven't loaded it already.
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

Use !analyze -v to get detailed debugging information.

BugCheck 1E, {0, 0, 0, 0}

Probably caused by : Unknown_Image ( ANALYSIS_INCONCLUSIVE )

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

16.2: kd:x86> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: 0000000000000000, The exception code that was not handled
Arg2: 0000000000000000, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: 0000000000000000, Parameter 1 of the exception

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


EXCEPTION_CODE: (Win32) 0 (0) - Der Vorgang wurde erfolgreich beendet.

FAULTING_IP:
+0
00000000 ?? ???

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000000000000000

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x1E

CURRENT_IRQL: 0

LAST_CONTROL_TRANSFER: from 0000000000000000 to 0000000000000000

STACK_TEXT:
00000000 00000000 00000000 00000000 00000000 0x0


STACK_COMMAND: kb

SYMBOL_NAME: ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

BUCKET_ID: INVALID_KERNEL_CONTEXT

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

16.2: kd:x86> !wow64exts.sw
The context is partially valid. Only x86 user-mode context is available.
Switched to 64bit mode
16.2: kd> !analyze -v
*******************************************************************************
* *
* Bugcheck Analysis *
* *
*******************************************************************************

KMODE_EXCEPTION_NOT_HANDLED (1e)
This is a very common bugcheck. Usually the exception address pinpoints
the driver/function that caused the problem. Always note this address
as well as the link date of the driver/image that contains this address.
Arguments:
Arg1: 0000000000000000, The exception code that was not handled
Arg2: 0000000000000000, The address that the exception occurred at
Arg3: 0000000000000000, Parameter 0 of the exception
Arg4: 0000000000000000, Parameter 1 of the exception

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


EXCEPTION_CODE: (Win32) 0 (0) - Der Vorgang wurde erfolgreich beendet.

FAULTING_IP:
+0
00000000`00000000 ?? ???

EXCEPTION_PARAMETER1: 0000000000000000

EXCEPTION_PARAMETER2: 0000000000000000

DEFAULT_BUCKET_ID: VISTA_DRIVER_FAULT

BUGCHECK_STR: 0x1E

PROCESS_NAME: System

CURRENT_IRQL: 2

LAST_CONTROL_TRANSFER: from 0000000000000000 to 0000000000000000

STACK_TEXT:
00000000`00000000 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : 0x0


STACK_COMMAND: kb

SYMBOL_NAME: ANALYSIS_INCONCLUSIVE

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Unknown_Module

IMAGE_NAME: Unknown_Image

DEBUG_FLR_IMAGE_TIMESTAMP: 0

BUCKET_ID: INVALID_KERNEL_CONTEXT

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

Langsam verzweifel ich. Ich tausch jetzt mal die RAMs aus.
 
Nach den Auswertungen sieht es nicht danach aus, als ob ein Treiberproblem vorliegen würde.

Überprüfe deine Festplatten mit dem herstellereigenen Diagnosetool.
Mache ein Screenshot von CrytalDiskinfo von jeder Platte.
An welchem Port (Anschluss Motherboard) hängt welche Platte?

Mache noch ein paar Screenshots von CPU-Z (Reiter Mainboard, Memory und SPD).
 
und ich würd mal verifier.exe ausführen, das testet beim starten alle Treiber, damit könnte man (falls es ein Treiber Prob. ist) den oder die Übeltäter herrausfinden. Aber erstmal Hardware checken, die Platten müssen 100% iO sein, dh leider testen, testen und nochmal testen :ugly:
 
Die Platten sind überprüft, da sind keine Fehler drauf. Die Screenshots häng ich mal dran.

Verifier hab ich schon mal ausgeführtm brachte aber keine Erkenntnis da kaum nach der Anmeldung sofort der Bluescreen (von Verifier ausgelöst) kam. Das Debuggen dieses Bluescreens führte mich zum USB 3.0 Treiber. Überhaupt wars zunächst der iastor.sys, als ich den eliminiert hatte wars die wmplayer exe, und es lässt sich nicht an etwas festmachen.

Allerdings habe ich anderorts noch einen Tip bekommen, den ich grad austeste. Ich habe im BIOS (UEFI), die erweiterten Stromsparfunktionen C-State deaktiviert. Um dem mal nachzugehen habe ich auch das komplette RAM wieder eingesetzt. Seitdem hatte ich noch keinen Bluescreen. Das heißt zwar noch nicht Entwarnung, aber mal abwarten was kommt, oder auch hoffentlich nicht. Bisher konnte ich täglich mit mindestens einem Bluescreen rechnen, eher aber mehrere. Also wenn sich die nächsten Tage nichts mehr tut, dann denk ich wars der C-State.

Die RAM Timings scheinen in Ordnung zu sein, erwartungsgemäß sind die Einstellungen bei 4 DIMMs automatisch etwas langsamer gesetzt als bei Nutzung von nur zweien. Spannung steht auch korrekt bei 1,5V.

CDI_SATA_1.jpg CDI_SATA_2.jpg CDI_SATA_5.jpg CDI_SATA_6.jpg CPU-Z Memory.jpg CPU-Z Mainboard.jpg CPU-Z SPD.jpg
pencil.png
 
Zuletzt bearbeitet:
Die Schreibfehlerwerte bei den beiden 400GB-Platten sind erhöht, da haben sich Fehler eingeschlichen. Kannst Du die Kabel tauschen?
 
Überhaupt wars zunächst der iastor.sys, als ich den eliminiert hatte wars die wmplayer exe

Bei der Auswertung der Bluescreens nicht auf die Zeile "Process Name" schauen. Dort wird nicht die Absturzursache genannt, sondern nur der Prozess, der zur Absturzzeit im Kernel ausgeführt wurde.
Die Ursache erkennst du insbes. im Stack Verlauf und in der Zeile "Image Name".

Hast du denn das System schon mal mit nur zwei RAM Riegeln laufen lassen, um Probleme -bedingt durch die Vollbestückung- auszuschließen (beide Kits einzeln testen)?
 
Die Schreibfehlerwerte bei den beiden 400GB-Platten sind erhöht, da haben sich Fehler eingeschlichen. Kannst Du die Kabel tauschen?

Nicht so ohne weiteres. Die Platten sind im Gehäuse quer verbaut, und auf der linken Seite gehts dann mit dem Deckel so eng zu daß ich abgewinkelte Kabel nehmen muß. Davon hab ich aber nur die vier mit denen die Platten angeschlossen sind da.

Bei der Auswertung der Bluescreens nicht auf die Zeile "Process Name" schauen. Dort wird nicht die Absturzursache genannt, sondern nur der Prozess, der zur Absturzzeit im Kernel ausgeführt wurde.
Die Ursache erkennst du insbes. im Stack Verlauf und in der Zeile "Image Name".

Hast du denn das System schon mal mit nur zwei RAM Riegeln laufen lassen, um Probleme -bedingt durch die Vollbestückung- auszuschließen (beide Kits einzeln testen)?

Ah gut zu wissen. Sind meine ersten Versuche Probleme mit dem Debugger anzugehen. Ich habe mal probehalber die DIMMs aus den Slots 2 und 4 herausgenommen, brachte aber keine Besserung. Beim Tausch der vorher rausgenommenen und der Verbliebenen hing ich erstmal in einer Bootloop fest, lag aber wohl dran daß ein Riegel nicht richtig saß. Ist auch ne Frickelei die zu wechseln, man kommt wegen dem Kühler schlecht ran. Hatte dann mal erst nur einmal 4 GB im Slot 1 um alle Riegel einzeln zu testen. Jedoch bekam ich dann den Tip mit dem C-State und probier nun erstmal das aus, wieder mit Vollbestückung. Scheint mir momentan ein vielversprechender Kandidat zu sein, dieser Tip. Bis jetzt keine Probleme seit gestern Abend. Aber auf den kurzen Zeitraum sagt das noch nichts.
 
Bis jetzt schauts gut aus, gestern keinen einzigen Bluesreen. Und das obwohl ich über den Zeitraum von mehreren Stunden mal alles mögliche ausprobiert hab. PC mit wenig Last betieben bzw. idle laufen lassen, mehrere Stunden 100% Auslastung auf allen Kernen, und auch mal mit dem gleicjzeitigen laufen lassen von 9 (!) virtuellen Maschinen den Speicher bis zu 91% ausgelastet. Hab ein gutes Gefühl bis jetzt. Wenn die nächsten paar Tage nichts mehr kommt, dann war das glaub ich des Rätsels Lösung.
 
Ja, habe die C-States komplett deaktiviert. C1E und EIST sind aber aktiv. Laut MSI Supportforum würde möglicherweise bis C2 funktionieren. Das aktuelle (offizielle) BIOS des Boards meint es mit dem Strom sparen wohl zu gut, und senkt die Spannungen zu weit ab, was Probleme geben kann. Es gibt ein Beta-BIOS met dem das behoben, oder zumindest verbessert sein soll. Jedoch wenn es so auch geht werde ich nicht BIOS flashen wenns nicht unbedingt sein muß.
 
Fooly schrieb:
Hallo zusammen!

Ich habe mir vorletzte Woche meinen PC aufgerüstet. Das alte Board samt Core2Duo 6850, und RAM flog raus, der Rest wurde weiter verwendet. Windows wurde natürlich aufgrund der erheblichen Änderungen an der Hardware neu installiert.

Aktuell schaut der Rechner jetzt so aus:

Mainboard: MSI P67A-GD65 (B3 Stepping)
CPU: Intel Core i7 2600K, derzeit von mir nicht übertaktet, aber das System betreibt ihn eigentlich standardmässig dauerhaft mit 3,5 GHz
RAM: 4x Corsair DDR3-1333 á 4 GB, also insgesamt 16 GB
Grafikkarte: Leadtek GeForce 260 GTX, wurde vom Vorrechner übernommen. Wird evtl. später mal noch durch was neueres ersetzt, hat aber keine Priorität
Festplatten: 2x WD Caviar Blue 420 GB SATA-2, 2x WD Caviar Blue 640 GB SATA-2, auch übernommen
sonstige Laufwerke: Blueray, nen herkömmliches DVD-ROM, und ein DVD-Brenner, auch alles SATA-Laufwerke

Was hast du mit der 6850 gemacht?
Die ist schon schneller als die 260.
 
Ich denk ich hab die Bluescreen-Ursachen jetzt eingegrenzt auf 2 Fehlerquellen, und hab das System jetzt in einem stabilen Zustand.

1. Deaktivieren der C-State Funktion brachte ein stabiles System. Zu dem Zeitpunkt lief das System ohne RAID, das ich vorher aufgelöst und normal auf AHCI gesetzt hatte.
2. Spielen die von euch verdächtigten Platten wohl auch noch eine Rolle. Nach neu aufsetzen des RAID hatte ich kurz darauf wieder einen ersten Bluescreen. Vermutlich ist der ICH10R hier etwas empfindlich gegenüber den erhöhten Schreibfehlerwerten die mae1cum77 geschrieben hat, und hält deshalb dann das System an. Jedenfalls hat mit den selben Platten das RAID bis zum Umbau aufs neue Board mit einem Gigabyte GA-P35DS3R (ICH9R) reibungslos funktioniert.

Ich habe also wieder auf AHCI-Modus gewechselt, und werd mal gelegentlich schauen ob neue SATA-Kabel was bringen. Ansonsten bleib ich erstmal bei AHCI und versuchs nochmal wenn neue Platten anstehen mit RAID.
 
Zurück