[V] unspezifischer nicht reproduzierbarer Crash

[KeepXtreme]

hallo zusammen,

ich hab mir vor ca. 2 Monaten mein System mit Ryzen 2600x, MSI x470 Gaming Plus + 16GB Ram (G.Skill F4-3200C14-8GVR) + RX 580 Pulse aktualisiert - und Windows 10 sauber neu installiert. Inzw. läufer der Oktober-Release.

Bitte folgenden Post beachten: *News-Update*

Seit dem Hardware-Upgrade habe ich unregelmäßig Abstürze. Interessanterweise meist auf dem Windows-Desktop, beim Surfen o.ä. jedoch weder im Recodieren mit virtualdub (gut, waren nur wenige Male bisher) oder beim zoggen. Seit dem Bios-Update mit Agesa 1.0.0.4c sind es gefühlt auch weniger geworden.
Der STOP-Fehler ist 0x00000124, minidump anbei.

Die CPU läuft auf Standard (kein OC), der Speicher ber XMP auf 1466MHz.

Temperaturen sind, soweit ich sehen kann auch i.O.:

Netzteil ist ein bequiet mit 450W (glaube ich, find gerade die Rechnung nicht und im Gehäuse ist das Typenschild nicht sichtbar) und müsste von 2015/16 sein.

CPU-Kühler ist eine CoolerMaster AIO, vorne ansaugend. Das Case hat zusätzlich einen 120mm vorne einblasend und einen 120mm ausblasend.

edit:// RAM auf Standard (DDR-2132) löst das Problem nicht. Habe ich schon probiert
edit:// anbei Mainbaord (BIOS-Version ist inzwischen A.50):

 

[Woody126]

Mach mal das XMP profil raus. und schau dann obs weiterhin crasht
Ist ja auch OC

 

[BFF]

Geh zurueck auf 1803, wenn es da besser funktioniert hat.

Auch wenn hier geschrieben wird "Hardware" glaube ich nicht dran.

Spoiler: BugCheck

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: ffffdf82adb3b858, Address of the WHEA_ERROR_RECORD structure.
Arg3: 0000000000000000, High order 32-bits of the MCi_STATUS value.
Arg4: 0000000000000000, Low order 32-bits of the MCi_STATUS value.

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

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

BUGCHECK_STR: 0x124_AuthenticAMD

DEFAULT_BUCKET_ID: WIN8_DRIVER_FAULT

PROCESS_NAME: System

CURRENT_IRQL: 0

BFF

 

[The Pack]

Habe das selbe Problem mit dem 1809er bin gerade am 'downgraden' auf die 1803. Seit dem Update immer wieder freezes mit dem 124er...

 

[octo124]

Tja Leutz, der dmp ist sehr merkwürdig.
Normalerweise kann damit u.a. Board + Bios-Version ausgelesen werden.
Geht nicht (fragt mich nicht warum) - als Fehler wird AuthenticAMD_ PROCESSOR CACHE PRV angegeben.
Folgende Treiber scheinen fehlerhaft zu sein:
krpcdd.sys
msrpc.sys
Nachtrag:
der auch
werkernel.sys


Eventuell da mal ansetzen.

 

[The Pack]

Seit ich auf das 1803 runter bin scheint wieder alles normal zu sein. Werde warten, bis MS das 1809 wieder frei gibt, und dann nochmal das Upgrade laden.

 

[KeepXtreme]

@The Pack @BFF Problem trat schon mit dem 1803 auf
@octo124 Mainbaord/Bios ergänzt (Startpost) Die krpcdd.sys finde ich lokal nicht mal oO

 

[BFF]

Das erneute Freigeben seitens MS wird wohl nix an der Unvertraeglichkeit mancher Kombinationen (Bretter+CPU+BIOS+Treiber) aendern, wenn nicht auch die Hersteller "irgendwas' dazu liefern und MS auch in dieser Hinsicht was tut.

Das im 1809 "Sachen" bzgl. AMD gemacht wurden ist stark zu vermuten.
So war es hier z.B. nicht moeglich mit 1803 VMWare Workstation in Kombination mit AMD-Phenom CPU und virtualisierten W10 zu benutzen. Es ging mit 1709 und jetzt wieder mit 1809.

@KeepXtreme
Geh zurueck auf 1803. Alles andere duerft mehr Nerven kosten.

BFF

Ergänzung (7. Oktober 2018)

Inzw. läufer der Oktober-Release.
Seit dem Upgrade habe ich unregelmäßig Abstürze.

Warum schreibst Du dann sowas und nicht gleich das seit 1803 die Abstuerze sind?

 

[KeepXtreme]

[...]

Warum schreibst Du dann sowas und nicht gleich das seit 1803 die Abstuerze sind?

war missverständlich, sehe ich ein. Ich meinte eigentlich das Upgrade der Hardware, deshalb auch der Absatz. Das das 1809 ja ein OS-Upgrade war, ist mir gar nicht in den Sinn gekommen...

 

[octo124]

Alle oben aufgeführten Treiber (und Asche auf mein Haupt, da sind noch mehr fehlerhafte gewesen) haben die neue Versionsnummer von 1809.
Evt. ist nun der Zeitpunkt gekommen, dieses automatische Treiberupdate zu deativieren? K.A., warum alle dem Glauben nachhecheln, dass die Treiber von MS zur verbauten Hardware besser sein sollen als die von MSI + Co..

@ TE - der Hinweis betreff Board usw. kam ja nur, weil dass der erste dmp war, der dies mir nicht anzeigte.

@All - evt. ist ja ein Intel-User von der 1809-Problematik betroffen und könnte mir mal bei BSD`s den dmp-File online stellen. Ein Vergleich wäre mal interessant.

 

[KeepXtreme]

interessant zu wissen. Aber wenn es alles 1809er-Treiber sind kann das nicht die Ursache sein. Das Automatische Update mag ich hier nich ausschließen...

Ich hab jedenfalls eben noch gesehen, dass es neuere Chipsatz-Treiber auf der AMD-HP gibt - mal schauen ob die einen Einfluss haben. Wenn ich mich richtig erinnere stammten die bei der OS-Installation ziemlich direkt nach der Veröffentlichung der 2000er Ryzen / X470er Chipsätze

 

[octo124]

Alle deine Chipsatztreiber und evt. auch andere sind durch das Update verändert worden. Manuelle Treiberaktualisierung beginnend mit Chipsatz mit den letzten aktuellen vom Boardhersteller.

 

[BFF]

Schon ok.
Fang einfach mit der Abschalten XMP, moegliche Treibererneuerung, RAM-Test usw. an. Bevor Du irgendwas machst mit Treibern, IMMER Wiederherstellungspunkt setzen.

BFF

 

[pvcf]

also aus meiner sicht klingt das nach einem zu tiefen Idle-state der CPU welche reingepatcht wurde.
Ich würde mal testeshalber einen kleinen Spannungsoffset auf die CPU geben und schaun, ob sie dann im Desktop-idle stabiler läuft.

 

[KeepXtreme]

@BFF das XMP sind genau 2933MHz, also kein OC. Weiterhin lief der PC nicht mal mit dem Basistakt von 2133MHz stabil. Treiber sind alle aktuell, der Chipsatzztriber war der einzige der durchgerutscht ist. RAM-Test werd ich morgen nochmal laufen lassen. Die Fehler sind für RAM-Fehler allerdings etwas ungewöhnlich vom Erscheinungsmuster.

@octo124 Die Probleme traten schon vor dem Update und von Beginn an auf --> unlogisch als Fehlerursache
Der einzige veraltete Treiber ist der der D2X - aber da finde ich nur den 2 Jahre alten Beta-Treiber

@pvcf interessante Idee, welche Spannung meinst du? (Core Voltage, NB/SoC Voltage, CLDO_VDP). Es mag Interpretation meinerseits sein, aber gefühlt tritt das Problem auf, wenn kurzzeitig Last angefragt wird, bzw. PRogrammstart, Webseitenwechsel. Mag mich aber auch täuschen...

 

[BFF]

Hi,

Es geht bei XMP nicht darum was da eingestellt ist, sondern darum das es benutzt wird.

Wenn das "Abstuerzen" schon auftritt seitdem Du diese Hardware hast, gehe ich von Hardwarefehlern oder kruden Einstellungen im BIOS/UEFI aus. Einen "Bug" bei der Kombination Deiner Hardware ist auch nicht auszuschliessen.

BFF

 

[pvcf]

> interessante Idee, welche Spannung meinst du?

ich kann dir das so genau nicht sagen, ich hab nen Intel, aber es müsste da so einen voltage offset für die CPU geben, welche vom Board automatisch raufgepackt wird, und dann bei allen states raufsummiert wird. ich würde das thema mal lieber jemand kundigeren zu erläuterung überlassen, entschuldige bitte !

 

[KeepXtreme]

@BFF OK verstanden. Aber nochmal: die gleichen Probleme hatte ich auch ohne XMP mit Basistakt
@pvcf verstehe ich. Trotzdem danke für die Idee. Wenn es mit neuen Treibern nicht besser wird Versuche ich es Mal ohne die d2x und danach eine Zeitlang mit Linux um die Software ausschließen zu können (oder halt nicht) bevor ich die Spannung der CPU anfasse.

 

[pvcf]

verstehe ich. Trotzdem danke für die Idee. Wenn es mit neuen Treibern nicht besser wird Versuche ich es Mal ohne die d2x und danach eine Zeitlang mit Linux um die Software ausschließen zu können (oder halt nicht) bevor ich die Spannung der CPU anfasse.

probiers lieber gleich mit der spannung, das resultat siehst du sofort ohne software oder neues betriebssystem aufspielen zu müssen. pack im bios 0.1v rauf und boote mal hoch. die CPU wird dabei viellei ~3 grad wärmer, das wars aber auch schon.
wichtig ist, dass du dass mit diesem OFFSET findest, damit du keine feste spannung einstellst sondern dein ryzen weiterhin dynamisch geregelt wird, aber halt nen tacken mehr saft bekommt.
was mir noch einfällt: stell mal aus reinem spaß den idle-state deiner ssd in windows energiesparplan ab, nachher spinnt ja da der controller rum.

 

[KeepXtreme]

Nachdem ich das Problem bisher nicht lösen konnte, konnte ich es vielleicht ein wenig eingrenzen:

also, nach langem rumprobieren mit Windows habe ich entschieden, den lang geplanten Schritt eines DualBoot-Systems umzusetzen und hab parallel Linux (Ubuntu 18.10) installiert.

Interessanterweise hatte ich in 3 Monaten noch keinen Crash, wie unter Windows (reboots) --> Idee schien die Treiber/OS-These zu bestätigen.

ABER: wenn der Rechner länger läuft finde ich den logs bzw. genauer gesagt in der Ausgabe von dmesg immer mal wieder so etwas (unregelmäßige Abstände):

[ 7164.911016] mce: [Hardware Error]: Machine check events logged
[ 7164.911019] [Hardware Error]: Corrected error, no action required.
[ 7164.911024] [Hardware Error]: CPU:1 (17:8:2) MC3_STATUS[Over|CE|MiscV|-|-|-|-|SyndV|-]: 0xd820000000000150
[ 7164.911028] [Hardware Error]: IPID: 0x000300b000000000, Syndrome: 0x000000002a000503
[ 7164.911031] [Hardware Error]: Decode Unit Extended Error Code: 0
[ 7164.911033] [Hardware Error]: Decode Unit Error: uop cache tag parity error.
[ 7164.911035] [Hardware Error]: cache level: RESV, tx: INSN, mem-tx: IRD

[ 7476.207776] mce: [Hardware Error]: Machine check events logged
[ 7476.207779] [Hardware Error]: Corrected error, no action required.
[ 7476.207783] [Hardware Error]: CPU:1 (17:8:2) MC3_STATUS[Over|CE|MiscV|-|-|-|-|SyndV|-]: 0xd820000000000150
[ 7476.207786] [Hardware Error]: IPID: 0x000300b000000000, Syndrome: 0x000000002a000503
[ 7476.207789] [Hardware Error]: Decode Unit Extended Error Code: 0
[ 7476.207789] [Hardware Error]: Decode Unit Error: uop cache tag parity error.
[ 7476.207791] [Hardware Error]: cache level: RESV, tx: INSN, mem-tx: IRD

Verstehe ich das richtig, dass hier Mainboard und/oder CPU einen Schlag weg haben oder wie interprätiert ihr das? Kann das der Grund sein, warum Windows crasht - das es den CPU-error im Gegensatz zu Linux nicht abgefangen kriegt?

Was mir noch aufgefallen ist:
Die Zeit, die vergeht, bis das Bios überhaupt mit dem Post beginnt, ist lange:
ca. 5s schwarzer Schirm
ca. 3s schwarzer Schirm mit Unterstrich
dann der Bios-Post
--->systemd-analyze: Startup finished in 11.838s (firmware) + 2.491s (loader) + 8.400s (kernel) + 1.476s (userspace) = 24.206s

ist das normal?

Hardware
* Ryzen 2600x
* MSI x470 Gaming Plus, aktuelle BIOS mit Agesa 1.0.0.6 ist drauf
* 16GB Ram (G.Skill F4-3200C14-8GVR) @ 3200Mhz via XMP-Profil, XMP aus macht keinen Unterschied