Seltsames Verhalten bei Bestückung mit mehr als einem Riegel (Timings, Bitrate...)

Ahoi.

Ich hatte im April von 8GB auf 16GB aufgestockt und seitdem sporadische Bluescreens mit diversen Verweisen auf fehlerhaften RAM. Die traten allerdings nur sporadisch auf, deswegen tat ich das als Windowsmacke ab und scherte mich nicht weiter drumm. Gestern abend allerdings ist der PC gleich zweimal hintereinander mit dem Fehlercode 0x3B System service exception abgestürzt, als ich im Browser war. Laut der Microsoft Dev Center ist das

This error has been linked to excessive paged pool usage and may occur due to user-mode graphics drivers crossing over and passing bad data to the kernel code.

Zum Vergrößern anklicken....

Da ich am Samstag eine R9 290 erhalten, eingebaut und den Treiber dafür installiert sowie wegen defekter R9 wieder deinstalliert habe, kann es durchaus an Treibergemetzel liegen, aber seltsam ist es dennoch. Vorher war auch mal ein 0x50 dabei (PAGE_FAULT_IN_NONPAGED_AREA)

Bug check 0x50 usually occurs after the installation of faulty hardware or in the event of failure of installed hardware (usually related to defective RAM, be it main memory, L2 RAM cache, or video RAM).
Another common cause is the installation of a faulty system service.
Antivirus software can also trigger this error, as can a corrupted NTFS volume.

Zum Vergrößern anklicken....

Wieder RAM als Fehlermöglichkeit. Dazu eine Bemerkung am Rande: es sind zwei mal die gleichen Kits, also insgesamt 4x4GB Corsair XMS3 mit 1600MHz und 9-9-9-24 Timings bei 1.65V. Das erste Kit ist Version 2.12, das zweite Kit 8.16. Kit 1 (alt) steckt von links gezählt in Slot 2 und 4, Kit 2 (neu) in Slot 1 und 3 und so habe ich auch die Riegel nummeriert. Ergo Riegel 1 neu, Riegel 2 alt, Riegel 3 neu, Riegel 4 alt.

Zur Fehlersuche wurde Memtest86+ auf einem Stick rangezogen und gleich vorweg: Es bleibt bisher in jeder Kombination mit mehr als einem Riegel bei Test 7 Block move einfach hängen. Alle Riegel einzeln in verschiedenen Slots laufen problemlos einen Pass durch (länger noch nicht getestet). Sobald zwei oder mehr in den Slots stecken, kommt der Test nicht weiter. Die Zeit stoppt und einzig das + vom Schriftzug oben links blinkt weiter. Prime95 hat beim ersten Blendtest sofort einen Bluescreen produziert (ich glaube wieder 0x3B), beim zweiten Mal liefs ein paar Minuten bis ich manuell abgebrochen habe.

Desweiteren ändern sich die Timings, Taktraten und Bitraten manchmal, selbst wenn ich Takt und Timings manuell im UEFI festlege (CMOS Reset schon durchgeführt).



Ich nehme an, dass bei Mehrfachbestückung und CL9-Timings auf die langsamere Rate angepasst wird. Jetzt in der Vollbestückung zeigt mir CPU-Z für alle Riegel CL9 und DRAM-Frequenz 798.2MHz.

Kann sich das jemand erklären? Das RAM-Diagnosetool von Windows hat zweimal nichts gefunden, was aber nichts bedeuten muss. Ich nehme an, dass sich das alte Kit nicht so gut mit der neuen Revision verträgt, aber dann müssten die Kits alleine doch funktionieren. Der Prozessor war etwa 2.75 Jahre lang auf 4GHz übertaktet, dann von März bis Vorgestern dank Battlefield 4 nicht mehr (zyklisch etwa alle 15s starke Framedrops), falls relevant.

Hat jemand eine Ahnung, wo der Fehler liegen könnte?

Die "älteren" Module in "A1 & B1"

Command Rate = 2T (im BIOS)

EDIT:

9-9-9-27 / TRC 36-41 / TRFC 160 oder nächst höher / CR = 2T

TESTEN

Danke für die Antwort. TRC steht leider nicht zur Auswahl, den Rest habe ich so eingestellt und es kam kurz bevor der Test wieder stoppte tatsächlich ein Fehler bei Memtest raus, was vorher nicht der Fall war. Seltsamerweise steht unter Tst 6, obwohl es wieder bei Test 7 war. Ich mach mich die Tage dann auf die Suche nach dem defekten Modul.

...und bei "1333" (667) ?

Der Unterschied zu "1600" (800) ist fast nur messbar > in Anwendungen / Spiele nicht / kaum spürbar -

Welches MB ist es genau ?

AsRock Z68 Pro3 ?!

EDIT :

"Unganged" - Mode ?

Ja, ein Asrock Z68 Pro3. Bei 1333MHz stoppt Memtest wieder bei Test 7 ohne Fehlermeldung. Ganged/Unganged scheint es nur bei AMD zu geben.

€dit: Geisterten hier nicht auch mal Mitarbeiter von Corsair rum?

(XMP) versucht ?

XMP lädt doch nur ein bestimmtes Profil, oder? Hat jetzt bei 4 Riegeln keinen Unterschied gemacht. Riegel 2 (alt) lief gerade in Sockel 1 3.5 Stunden ohne Fehler durch. Seltsamerweise war da gerade mal Pass 6 am Rödeln, wo der erste Pass nur 12 Minuten gedauert hat. Ich nehme an, dass auch hier der Test mal gestoppt und nach einer Zeit wieder fortgesetzt wurde. Die restlichen Riegel teste ich in den nächsten Tagen mal.

Riegel 1 lief jetzt 1.5 Stunden und 3 Passes fehlerfrei. Ist es normal, dass die Passes immer langsamer bearbeitet werden?

Riegel 3 lief gerade 1.8 Stunden 3 Passes fehlerfrei. Soeben habe ich noch ein Biosupdate gemacht, vielleicht bringts ja was.

Wo liest du denn die Werte aus deiner Tabelle aus? Im memtest? Da steht oft Mist, lass dich dadurch nicht verwirren.

Hat das UEFI eine soll / ist Anzeige? Wenn nein, lies unter Windows mit CPU-Z aus.

Mein Vorschlag zum Speicher:
Lies mit Thaiphoon Burner das SPD der beiden Kits aus und sichere es als Backup.
Dann schreibst du beide Kits neu mit dem selben SPD Code. Ob du die Parameter vom Kit1 auf Kit2 oder umgekehrt schreibst, ist relativ egal.
Achtung: Führt höchstwahrscheinlich zu Garantieverlust.

Sö, Riegel 4 lief jetzt 4 Stunden fehlerfrei, ergo alle einzeln anscheinend OK.

Ja, war Memtest. CPUZ zeigt mir für jeden Riegel das gleiche an:



Am SPD rumpielen werde ich wohl nur als allerletzte Instanz, nachdem ich die Riegel (sofern notwendig) eingeschickt habe und auch der Support nichts finden konnte. Ich probiere alle Riegel gleichzeitig bald mit dem neuen UEFI.

Du kannst mit Thaiphoon Burner auch bequem ALLE Timings der Speicher auslesen und vergleichen.
Dann im UEFI alle händisch auf den jeweils höheren Wert stellen.

Ok, werde ich machen. Aber eine Frage noch: Thaiphoon Burner zeigt mir unter Clock Frequency bei allen 4 Riegeln PC3-10600, 667MHz und 1.5V an, unter XMP Enthusiast dann 800MHz. Heisst das, dass die Riegel eigentlich nur durch das XMP-Profil übertaktet werden?

Das ist korrekt. So zeigt es ja auch CPU-Z an.

Das UEFI-Update scheint die Lösung des Problems gewesen zu sein. Seitdem trat kein weiterer Bluescreen mehr auf, selbst mit übertakteter CPU. Memtest habe ich zwar nicht mehr laufen lassen, aber das scheint nicht nötig zu sein.