BSOD bei HCI Memtest (2133 MHz & R5 1600)

[Semper Fidelis]

Hallo Forum,

ich weiß mittlerweile nichtmehr weiter

Aber erstmal zu meinem System:

CPU: AMD Ryzen 5 1600
Mainboard: Asus Prime B350-Plus (Bios Version 3401 vom 08.12.17)
RAM: 16 GB DDR4 G.Skill F4-3200C16D-16GVKB (2x 8 GB Sticks)
GPU: Zotac GTX 1070 Mini
PSU: 630 Watt be quiet! Pure Power L8 CM Modular 80+ Bronze
Kühlung: Thermalright HR-02 Macho + 4x 120mm Gehäuselüfter
OS: Windows 10 64 bit Pro (1706)

GPU, CPU und RAM sind nicht übertaktet.
Der Arbeitsspeicher läuft (auf AUTO Einstellungen im Bios) mit 2133 MHz und 15-15-15-36-51 1T 1,2V.

Ich handhabe es generell so, dass ich selbst zusammengebaute Systeme ausgiebig auf Stabilität überprüfe. So auch dieses. Prime95 (>20h mit vollständiger RAM Nutzung), MemTest86 V7.4 (111 Durchläufe, 15h) und >5h Battlefield 1 stellten kein Problem dar und liefen absolut fehlerfrei!

Letztendlich wollte ich noch HCI Memtest drüberlaufen lassen. And thats how it goes down
Ich habe pro Thread eine Instanz gestartet: Also 12x Memtest geöffnet und pro Instanz 1210 MB Ram zugewiesen. Macht dann etwa 14,5 GB. Die restlichen 1,5 GB waren durch Windows und Hintergrundprogramme belegt. Ich hatte also eine Arbeitsspeicherauslastung von 95-100%.
Nach 30min bekam ich einen Bluescreen (siehe Spoiler). Da hab ich mir erstmal noch nichts gedacht und HCI Memtest nochmal angeworfen. Diesmal liefs 3h und dann kam wieder ein Bluescreen. Tja und so geht das die ganze Zeit, sobald man HCI Memtest anwirft. Die Bluescreens sind also eindeutig durch HCI Memtest reproduzierbar und treten meistens nach 3 bis 4 h auf. Währenddessen zeigt Memtest jedoch keine Fehler an. Es kommt lediglich zum Bluescreen und das System rebootet.

Hier mal ein Auszug der Minidumps:

Spoiler

==================================================
Dump File : 122117-5703-01.dmp
Crash Time : 21.12.2017 14:58:51
Bug Check String : KMODE_EXCEPTION_NOT_HANDLED
Bug Check Code : 0x0000001e
Parameter 1 : ffffffff`c0000005
Parameter 2 : fffff801`75b58d99
Parameter 3 : 00000000`00000000
Parameter 4 : 00000000`de1792bc
Caused By Driver : nvlddmkm.sys
Caused By Address : nvlddmkm.sys+9238c4
File Description :
Product Name :
Company :
File Version :
Processor : x64
Crash Address : ntoskrnl.exe+1640e0
Stack Address 1 :
Stack Address 2 :
Stack Address 3 :
Computer Name :
Full Path : C:\Windows\Minidump\122117-5703-01.dmp
Processors Count : 12
Major Version : 15
Minor Version : 16299
Dump File Size : 1.087.476
Dump File Time : 21.12.2017 14:59:41
==================================================

==================================================
Dump File : 122117-5765-01.dmp
Crash Time : 21.12.2017 13:57:06
Bug Check String : PAGE_FAULT_IN_NONPAGED_AREA
Bug Check Code : 0x00000050
Parameter 1 : ffffd086`00000050
Parameter 2 : 00000000`00000000
Parameter 3 : fffff800`5d0d28b4
Parameter 4 : 00000000`00000002
Caused By Driver : ntoskrnl.exe
Caused By Address : ntoskrnl.exe+1640e0
File Description : NT Kernel & System
Product Name : Microsoft® Windows® Operating System
Company : Microsoft Corporation
File Version : 10.0.16299.125 (WinBuild.160101.0800)
Processor : x64
Crash Address : ntoskrnl.exe+1640e0
Stack Address 1 :
Stack Address 2 :
Stack Address 3 :
Computer Name :
Full Path : C:\Windows\Minidump\122117-5765-01.dmp
Processors Count : 12
Major Version : 15
Minor Version : 16299
Dump File Size : 1.047.204
Dump File Time : 21.12.2017 13:59:15
==================================================

==================================================
Dump File : 122117-5031-01.dmp
Crash Time : 21.12.2017 13:33:07
Bug Check String :
Bug Check Code : 0x00000139
Parameter 1 : 00000000`00000003
Parameter 2 : ffffa784`18d085e0
Parameter 3 : ffffa784`18d08538
Parameter 4 : 00000000`00000000
Caused By Driver : ntoskrnl.exe
Caused By Address : ntoskrnl.exe+1640e0
File Description : NT Kernel & System
Product Name : Microsoft® Windows® Operating System
Company : Microsoft Corporation
File Version : 10.0.16299.125 (WinBuild.160101.0800)
Processor : x64
Crash Address : ntoskrnl.exe+1640e0
Stack Address 1 :
Stack Address 2 :
Stack Address 3 :
Computer Name :
Full Path : C:\Windows\Minidump\122117-5031-01.dmp
Processors Count : 12
Major Version : 15
Minor Version : 16299
Dump File Size : 1.071.780
Dump File Time : 21.12.2017 13:37:19
==================================================

==================================================
Dump File : 122117-5015-01.dmp
Crash Time : 21.12.2017 12:56:16
Bug Check String : KMODE_EXCEPTION_NOT_HANDLED
Bug Check Code : 0x0000001e
Parameter 1 : ffffffff`c0000005
Parameter 2 : fffff802`33f8e025
Parameter 3 : 00000000`00000000
Parameter 4 : 00000000`906d9f0a
Caused By Driver : ntoskrnl.exe
Caused By Address : ntoskrnl.exe+1640e0
File Description : NT Kernel & System
Product Name : Microsoft® Windows® Operating System
Company : Microsoft Corporation
File Version : 10.0.16299.125 (WinBuild.160101.0800)
Processor : x64
Crash Address : ntoskrnl.exe+1640e0
Stack Address 1 :
Stack Address 2 :
Stack Address 3 :
Computer Name :
Full Path : C:\Windows\Minidump\122117-5015-01.dmp
Processors Count : 12
Major Version : 15
Minor Version : 16299
Dump File Size : 1.146.652
Dump File Time : 21.12.2017 12:58:22
==================================================

==================================================
Dump File : 122117-6343-01.dmp
Crash Time : 21.12.2017 11:04:35
Bug Check String : IRQL_NOT_LESS_OR_EQUAL
Bug Check Code : 0x0000000a
Parameter 1 : 00000000`82d63eb8
Parameter 2 : 00000000`000000ff
Parameter 3 : 00000000`000000c1
Parameter 4 : fffff800`ab31af47
Caused By Driver : nvlddmkm.sys
Caused By Address : nvlddmkm.sys+2029e0
File Description :
Product Name :
Company :
File Version :
Processor : x64
Crash Address : ntoskrnl.exe+1640e0
Stack Address 1 :
Stack Address 2 :
Stack Address 3 :
Computer Name :
Full Path : C:\Windows\Minidump\122117-6343-01.dmp
Processors Count : 12
Major Version : 15
Minor Version : 16299
Dump File Size : 1.090.660
Dump File Time : 21.12.2017 11:37:22
==================================================

Was ich bisher unternommen habe (und nichts geändert hat):

• RAM Timings von AUTO (15-15-15-36-51) auf 16-18-18-38-56 (Herstellerangabe) geändert
• RAM Spannung von 1,2 V auf 1,35 V und 1,4 V angehoben
• Command Rate von 1T auf 2T geändert
• Chipsatz- und Grafiktreiber und BIOS Firmware aktualisiert
• RAM mit MemTest86 V7.4 (via Boot über nen USB Stick) >15h auf fehler überprüft (keine Fehler gefunden!)
• Prime95 >20h mit kompletter RAM Nutzung getestet (keine Fehler)
• Battlefield 1, Call of Duty WW2 und Assassins Creed Origins mehrere Stunden am Stück gespielt (keine Abstürze, etc)
• Temperaturen mit Hardwaremonitor kontrolliert

Tja und nun weiß ich langsam nichtmehr weiter. Auf der einen Seite scheint der RAM wohl fehlerfrei zu sein, weil das (bootbare) Memtest auch nach über 100 Durchläufen keine Defekte entdeckt. Aber irgendwie scheints ja doch damit zusammenzuhängen, da HCI Memtest im Bluescreen endet
Und eigentlich müsste das System so "out of the box" doch "rock stable" laufen?! Der Sachverhalt mit dem RAM und Ryzen ist mir durchaus bewusst, aber hier läuft der RAM ja vollkommen innerhalb der Herstellerspezifikationen von G.Skill, Asus und AMD

Anbei noch ein paar Screenshots aus CPU-Z.






Vielen Dank schonmal! Ich freu mich über jeden Beitrag

 

[yaegi]

ich versteh dich nicht! es läuft doch absolut alles bis auf diesen bekloppten test. wie wärs wenn du den einfach nicht mehr benutzt und gut ist. punkt.

 

[Semper Fidelis]

@yaegi

Genauso denkt eine Hälfte von mir auch

Aber ich komme mit dem Gedanken nicht klar, dass das System anscheinend nicht 100% stabil läuft, obwohl es das sollte. Anscheinend liegt ja irgendwo ein Problem vor :/ Außerdem habe ich Angst, dass das ganze zu korrupten Dateien führen könnte :/

 

[rg88]

Das ist doch ganz einfach: Der Bluescreen sagt, dass dein Grafiktreiber abstürzt.
-> Du benutzt einen absolut sinnlosen, bescheuerten Testaufbau. Das Testen unter Windows kann rein logisch schon nicht funktionieren.
Du treibst es dann damit auf die Spitze, dass die den RAM überlädst. Es kommt zum auslagern, weil zuwenig RAM verfügbar ist. Damit kommt dein Grafikkartentreiber kurzzeitig klar, irgendwann reicht ihm aber die lange Reaktionszeit nicht mehr um auf Daten zu warten und er schmiert ab -> Bluescreen...

So einfach die Lösung: Das Problem ist keine instabile Hardware, sondern sitzt zwischen Tastatur und Stuhllehne

Stell den RAM auf das Profil mit 2933MHz (mehr wirst du mit dem Hynix-Speicher nicht schaffen) und mach dann einen Memtest86 (OHNE PLUS) von einer Boot-CD oder einem Boot-USB-Stick und lass diesen einige Stunden laufen. Nur so kann man RAM halbwegs brauchbar testen

 

[duskstalker]

also zuerstmal habens wir hier vermutlich wieder mit hynix speicher zu tun.

hast du proc_odt angepasst? soc voltage? cldo_vddp? subtimings? oder alles auto?

und mal abseits vom ram - was macht dich so sicher, dass der ram für die bluescreens verantwortlich ist und nicht das programm? creative audio treiber und das msi led utility spucken so viele bluescreens aus, dass es zum heulen ist.


@rg88

interessante und plausible erklärung, allerdings isses laut crashdump nicht immer der nvidia treiber, sondern nur 50% der fälle - andere hälfte geht auf den ntoskrnl - das ist dann schon nicht mehr so spezifisch.

 

[rg88]

@dusk: Er hat doch nun wirklich alle Daten geliefert. Lies dir doch erstmal den eingangspost durch.

Bluescreen kommt vom Nvidia-Treiber und das "warum" hab ich oben versucht zu erklären.

 

[Holt]

Das Memtest von HCI welches unter Windows läuft ist komplett unsinnig, denn Windows hat eine eigene Speicherverwaltung und damit weiß man nie, welcher Teil des physikalischen Speichers nun gerade getestet wird und daher besagt das ausbleiben eines Fehler nicht, dass das ganze RAM wirklich fehlerfrei ist. Man sollte für einen sinnvollen RAM Test also immer mit Memtest86 (oder Memtest86+) machen.

 

[smuper]

Es geht bei dem Einsatz von HCI Memtest nicht darum die einzelnen Bereiche auf Integrität zu prüfen, sondern die Stabilität unter Belastung zu testen. Und zu diesem Einsatzzweck hat sich das Programm international als sehr zuverlässig erwiesen und wird in den Foren mit weit weit mehr Wissen, als auf CB zu finden ist, genutzt.

@ Threadersteller

Du kannst erstmal von 12 Instanzen auf 6*2000 gehen.

Grundsätzlich würde ich mir in deinem Szenario nun nicht sehr viele Gedanken um HCI machen, vorausgesetzt, deine Ausführungen der restlichen Stabilitätsangaben stimmen so.

 

[Semper Fidelis]

Vielen Dank für all eure Antworten!

@rg88

Deine Erklärung halte ich für ziemlich plausibel: Während HCI Memtest wird häufig der Bildschirm dunkel und geht nach ein paar Sekunden wieder an. Laut Eventlog reagierte in der Zeit der Anzeigetreiber nichtmehr und wurde wiederhergestellt. Einen Defekt der GPU schließe ich jedoch aus, da Spiele (über mehrere Stunden) absolut fehlerfrei laufen.

@duskstalker

Proc_odt, soc voltage, cldo_vddp und subtimings stehen alle auf AUTO. Soll ich mich da mal bisschen einlesen?

@Holt

Danke für die Info! Ich gehe mal davon aus, dass der RAM zu 99,99% fehlerfrei ist. Sonst hätte Memtest86 nach 15h bestimmt nen Fehler entdeckt.
Ist es eigentlich egal, ob ich Memtest86 oder Memtest86+ verwende? Soweit ich weiß, unterstützt Memtest86 DDR4 und ist aktueller

@smuper

Das ist genau der Punkt, der mich nicht in Ruhe lässt Also dass mein System unter Belastung eben nicht stabil ist
Ich werde mal 6 Instanzen mit je 2000MB testen und dann berichten

 

[smuper]

Fraglich ist halt, ob das überhaupt ein Hardware Problem an sich ist. Normalerweise gibt HCI nur Fehler aus und lässt das System nicht direkt abstürzen.

Stell den RAM auf das Profil mit 2933MHz (mehr wirst du mit dem Hynix-Speicher nicht schaffen)

Das kann auch Dual Rank Samsung D/E Die sein. Aber auch dann ist nicht (viel) mehr drin. Ist aber immer interessant zu wissen was man da nun wirklich hat.

Hier siehst du wie man die Infos bekommt:

https://www.youtube.com/watch?v=_2iZavugowE

Ist es eigentlich egal, ob ich Memtest86 oder Memtest86+ verwende? Soweit ich weiß, unterstützt Memtest86 DDR4 und ist aktueller

Die UEFI Version von Memtest86 / also 7.xx


Was ist eigentlich mit dem Netzteil? Das hat ja sicher auch schon einige Jahre auf dem Buckel und ist nicht mal ein DC-DC Netzteil. Sowas gehört beim Aufrüsten auch mal ausgetauscht. Unabhängig davon, ob das etwas mit deinem Problem zu tun haben könnte oder nicht.

 

[h00bi]

Naja, 2x wars der Grafiktreiber aber immerhin 3x der Windows Kernel.
Im Gegensatz zu memtest86 der sich in den meisten Tests immer einen Speicherbereich krallt und den testet nutzt HCI Memtest in mehreren Instanzen allen RAM gleichzeitig.

Ist es eigentlich egal, ob ich Memtest86 oder Memtest86+ verwende? Soweit ich weiß, unterstützt Memtest86 DDR4 und ist aktueller

Da memtest86+ nicht mehr weiterentwickelt wird würde ich den auch nicht mehr nehmen. Zum DDR4 Start hatte ich mit memtest86+ oft Probleme, sowohl false negatives als auch false positives.
Von daher rate ich immer zum memtest86 und zwar in der Version 7, also per UEFI boot.

 

[Semper Fidelis]

Kleine Zwischeninfo:

HCI Memtest läuft seit etwa 4h stabil und ohne Fehler. Bisher gabs keine Abstürze oder Probleme mit dem Grafiktreiber.



RAM scheint von Hynix zu sein.

Das Netzteil habe ich Ende 2013 gekauft. Also das ist jetzt etwas mehr als 4 Jahre alt. Glaubt ihr, dass es für die Fehler verantwortlich sein könnte? Eigentlich doch nicht, oder? Bei Spielen liegt doch wesentlich mehr Last drauf, als wenn Memtest läuft?

 

[rg88]

Es geht bei dem Einsatz von HCI Memtest nicht darum die einzelnen Bereiche auf Integrität zu prüfen, sondern die Stabilität unter Belastung zu testen.

Aha, ein Speichertest, der an und für sich so nicht funktionieren kann, wird nur als Speichertest vom Hersteller deklariert, ist aber eigentlich ein Stabilitätstest. Ja das klingt vollkommen logisch.

Und zu diesem Einsatzzweck hat sich das Programm international als sehr zuverlässig erwiesen und wird in den Foren mit weit weit mehr Wissen, als auf CB zu finden ist, genutzt.

"international" bedeutet jetzt genau was? inwiefern ist das ein Argument?
Diese Foren mit "weit mehr Wissen" sind ebenso kein Argument. Was soll diese sinnentleerte Aussage nun genau beweisen?

 

[smuper]

Es ist doch vollkommen irrelevant wofür der Test deklariert wird, sondern dafür wofür er eingesetzt wird?

HCI Memtest läuft seit etwa 4h stabil und ohne Fehler. Bisher gabs keine Abstürze oder Probleme mit dem Grafiktreiber.

12 Instanzen ist halt echt Wahnsinn, nur um die Threads auszulasten.

 

[Shaav]

Ich habe denselben Fehler. Sobald ich meinen R5 1600 (8-Kerner) mit 16 Thread à 850MB füttere schmiert er zeitnah ab. Die Ānderung von Timings, Spannungen etc. konnte die Stabilität nicht verbessern. Sämtliche anderen Stabilitatstest finden hingegen keine Fehler.

Mit 14 Threads à 1024MB läuft er aber ewig weiter. Echt merkwürdig.

 

[rg88]

R5 1600 (8-Kerner) mit 16 Thread

das bezweifle ich mal

 

[Shaav]

mach das

 

[rg88]

CPU-Z Screenshot @Shaav?

 

[Holt]

Ist es eigentlich egal, ob ich Memtest86 oder Memtest86+ verwende? Soweit ich weiß, unterstützt Memtest86 DDR4 und ist aktueller

Unterstützung bedeutet ja nur, dass es die Daten davon korrekt auslesen kann, für den Test selbst ist es egal welche RAM drin steckt, denn dabei wird ja nur geschrieben und danach wieder gelesen und vergleichen ob die gelesenen Daten denen entsprechend die geschrieben wurden. Solange die Gesamtkapazität korrekt erkannt wird ist es also egal welches man nimmt, wenn man auch über inkorrekte oder fehlende Angaben in den Kopfzeilen hinwegsehen kann.

 

[Shaav]

CPU-Z Screenshot @Shaav?

Muss reichen:
https://out.reddit.com/t3_7awpuj?ur...LWVKqtPkljSmgZGHMfASAPDvuCGNB&app_name=mweb2x