Frage Ryzen 9 5950X crash mit Prozessor-APIC-ID14 / WHEA-Logger 18

[Hellsingexe]

AMD Ryzen 9 5950X

Fehlerbild im Windows Event-Log:
Schwerwiegender Hardwarefehler.
Prozessor-APIC-ID: 14



-> Der Fehler tritt zufällig während des Betriebs auf und ist unabhängig von Lastsituation und Temperatur.
-> Der Fehler führt zum sofortigen Crash des Systems.

=====================================================================

Verwendestes System:
Mainboard: ASUS Crosshair VIII Hero (Wi-Fi)
CPU Kühler: Fractal Design S36 Blackout
RAM: G.Skill F4-4000C18Q-128GTRG
GPU: Inno3D iChill Black 2080 Ti
PSU: Bequiet Dark Power Pro 11 1000Watt

Spoiler : Es wurden folgende Versuche unternommen:

Getetstete Mainbaords:
ASUS Crosshair VIII Hero (Wi-Fi) Mit allen verfügbaren BIOS Versionen die Ryzen 5xxx unterstützen:
Version 2311 -> Gleicher Fehler
Version 2402 beta -> Gleicher Fehler
Version 2502 -> Gleicher Fehler
Version 2702 -> Gleicher Fehler

Gigabyte B550 AORUS ELITE (rev. 1.0) Mit allen verfügbaren BIOS Versionen die Ryzen 5xxx unterstützen:
F10 -> Gleicher Fehler
F11i -> Gleicher Fehler
F11k -> Gleicher Fehler

Getestete Varianten:
-BIOS ALLES auf DEFAULT Settings (Jeweils für alle BIOS Versionen des ASUS und Gigabyte Boards)
-Windows 10 Pro 64Bit 20H2
-Windows 10 Pro 64Bit 1909
-Windows 8.1 Pro 64 Bit
-Linux Mint 20
-Ubuntu 20.04

-Windows im Höchleistungsmodus
-Aktuelle AMD Chipsatz Treiber installiert (2.10.13.408)
-LLC auf Level 3, und 4 fixiert
-PBO deaktiviert
-SMT deaktiviert
-DF Cstates auf "Disable" (Global C-state Control)
-GPU Getauscht gegen eine GTX 970 und eine GTX 560Ti -> Gleicher Fehler
-PSU getauscht gegen ein Seasonic Focus Gold 850 Watt -> Gleicher Fehler

Getestete RAM Kits:
G.Skill F4-4000C18Q-128GTRG
4 Riegel mit 3600MHz -> Gleicher Fehler
2 Riegel mit 2666MHz -> Gleicher Fehler
1 Riegel mit 2666MHz -> Gleicher Fehler

G.Skill F4-3600C17Q-64GTZR
4 Riegel mit 3600MHz -> Gleicher Fehler
2 Riegel mit 2133MHz -> Gleicher Fehler
1 Riegel mit 2133MHz -> Gleicher Fehler
1 Riegel mit 2133MHz und 18 / 22 / 22 / 42 Timings -> Gleicher Fehler

 

[voidtrading]

Ich hab jetzt testweise zumindest mal den 5950x eines Bekannten getestet welcher witzigerweise auf dem master x570 rev1 ohne Probleme lief. Bei default bios settings hat sich mein eigener schließlich quasi ohne Probleme innerhalb einer Stunde verabschiedet und seiner lief heute den ganzen abend durch. Auch das Elite habe ich zumindest eine Stunde getestet ohne Abstürze. Ich habe nichts großartiges gebenched aber cr20 und cr23 waren mehr oder weniger identisch mit meiner cpu. Ich hoffe Mindfactory stellt sich nicht quer und tauscht mir unkompliziert den chip.

 

[Amtswalter]

(CB23: 29k Punkte )

Mit oder ohne PBO??

 

[Martin Gut]

Wenn das also ein CPU-Problem ist (Silicon Lottery...), stehen die Chancen wahrscheinlich hoch, dass die neue CPU sich nicht anders als die alte CPU verhält, wenn da in der Produktion nur Sekunden(bruchteile) dazwischen liegen.

Doch, die Qualität der Chips unterscheidet sich vor allem dadurch, ob sie in der Mitte oder am Rand eines Wafers produziert wurden. das Silizium wird zu einem Zylinder gegossen. Beim Abkühlen erstarrt es ungleichmässig und zieht sich zusammen. Dadurch wird die Struktur in der Mitte nicht gleich wie gegen den Rand. Auch wenn man sich bei der Herstellung des Silizium grösste Mühe gibt, lässt sich das nicht ganz vermeiden. Den Siliziumzylinder schneidet man dann in Scheiben (Wafer). Dann poliert man die Oberfläche und behandelt sie so, dass daraus die Halbleiterschicht der Transistoren wird. Diese Schicht ist darum relativ entscheidend für die Qualität der Chips. So gibt es immer bei jedem produzierten Wafer bessere und schlechtere Chips. Das lässt sich nicht vermeiden.

 

[Shelly74]

Das Problem ist aber nicht nur bei denn 5000er denn ich hatte immer wieder reboots mit einen Ryzen 3100 ebenfalls mit WHEA Fehler. Trat von einen Tag auf dem anderen auf und hatte dann mindestens einmal am Tag einen Reboot ohne BSOD oder sonstige Fehlermeldung außer eben die WHEA Einträge. Ich hatte paar Tage zuvor ein Bios Update gemacht und ich denke es hatte was mit der damaligen AGESA zutun (ka mehr welche das genau war). Und zu 99% war es immer im Idel Zustand oder bei geringer Last wie im Web Surfen oder mal ein Programm starten. Prime konnte ich 1 Stunde laufen lasse oder Memtest ohne Reboots.

Einer meiner WHEA Einträge von damals:

- System

- Provider

[ Name] Microsoft-Windows-WHEA-Logger
[ Guid] {c26c4f3c-3f66-4e99-8f8a-39405cfed220}

EventID 19

Version 0

Level 3

Task 0

Opcode 0

Keywords 0x8000000000000000

- TimeCreated

[ SystemTime] 2020-10-14T13:24:45.8452085Z

EventRecordID 3836

- Correlation

[ ActivityID] {e60d9cb6-498a-4c93-9b3e-5753d0e202d8}

- Execution

[ ProcessID] 3304
[ ThreadID] 5164

Channel System

Computer DESKTOP-3M3QDUP

- Security

[ UserID] S-1-5-19


- EventData

ErrorSource 0
ApicId 0
MCABank 25
MciStat 0x98004000003e0000
MciAddr 0x0
MciMisc 0xd01a0ffe00000000
ErrorType 0
TransactionType 256
Participation 256
RequestType 256
MemorIO 256
MemHierarchyLvl 256
Timeout 256
OperationType 256
Channel 256
Length 1003

 

[Martin Gut]

Solche Fehlermeldungen sagen meist recht wenig aus. Wenn der RAM nicht mehr funktioniert oder der PC ganz ausgeht, kann Windows ja kein Fehlerprotokoll mehr abspeichern. Erst beim nächsten Einschalten merkt Windows, dass es nicht richtig beendet wurde und schreibt dann die Kernel-Power 41-Meldung ins Protokoll. Warum das passiert ist, kann Windows aber nach dem Neustart nicht mehr nachvollziehen. So kann es leider an verschiedenen Ursachen liegen.

(2022) 6 Lösungen zur Behebung des Fehlers Kernel Power 41

Was tun Sie, wenn Sie auf einem Windows-Computer auf den Fehler Kernel Power 41 stoßen? Wenn Sie es nicht wissen, dann ist dieser Beitrag von MiniTool genau...

www.mynewsdesk.com

 

[Amtswalter]

Die RMA bei Mindfactory für die erste CPU ist durch. Das hat schon mal gut geklappt. Nun muss nur noch der Widerruf für die zweite CPU gebucht werden.

 

[Neutral]

Ich habe gestern 19 Uhr bei AMD die Antworten zum RMA geschickt. Gegen 5:30 Uhr heute morgen wurde der RMA genehmigt und mir wurden Versandlabels in die Niederlande geschickt (leider nicht mit korrekter Firmenadresse, aber naja..). Also aber immerhin schon sehr schnell. Ich habe jetzt 30 Tage lang Zeit den CPU zurückzuschicken.

 

[Riplex]

Ist es möglich eine neue CPU von AMD vorab zu bekommen. Also 1 zu 1 Ausstausch ?
Keine Lust 2 Wochen ohne Rechner da zu stehen.

Oder muss ich mir irgendwo eine günstige AM4 CPU besorgen ?

 

[Neutral]

Ist es möglich eine neue CPU von AMD vorab zu bekommen. Also 1 zu 1 Ausstausch ?
Keine Lust 2 Wochen ohne Rechner da zu stehen.

Das hatte ich auch mal angefragt (allerdings bin ich gewerblicher Kunde, bitte beachten), das geht nicht (ist auch nicht gelistet in deren Policy, es kann sein dass für Privatanwender hier einfachere Ausnahmen möglich sind). Zumindest nicht bei AMD. Mit dem Händler kann man da sicher besondere Absprachen treffen. Der 5950x ist ja aus gewerblicher Sicht absurd günstig (etwa 889€ brutto Einzelpreis ohne Rabatte etc.), wenn man mehr als 10 Stück kauft sind solche Absprachen sicher möglich und mir bekannt in anderen Zusammenhängen. Ich würde empfehlen mal anzurufen, es schadet sicher nicht

 

[HerrRossi]

Bei mir/uns war es HWinfo64 welches die Probleme verursacht hat - seit Umstieg auf HWMonitor alles tutti, keinerlei Auffälligkeiten, keine WHEAs, keine Warnungen, nichts.

Puh, das ist eine wichtige Info! Darauf muss man dann auch erstmal kommen. Am besten nutzt man nur den Ryzen Master, aber der kann ja auch mal einen Bug haben...

 

[HerrRossi]

Ich raff grad nicht wie das auf einmal auftreten konnte, mein System war bis vor kurzem stabil.

Vllt. ein Windowsupdate?

 

[Hellsingexe]

Kleines Update bei mir:

Bei mir/uns war es HWinfo64 welches die Probleme verursacht hat - seit Umstieg auf HWMonitor alles tutti, keinerlei Auffälligkeiten, keine WHEAs, keine Warnungen, nichts.

Ich glaube eher das HWinfo64 den Fehler triggert als ihn zu verursachen

Ich konnte den WHEA 18 / ID 14 auch immer wieder reproduzieren (USB Stick einstecken, Nvidia Treiber installieren, etc)

 

[garfield36]

Ich glaube eher das HWinfo64 den Fehler triggert als ihn zu verursachen

Und wo ist da der Unterschied?

 

[Gurdi]

Vllt. ein Windowsupdate?

Hab das H20 rausgenommen gehabt, kann durchaus sein dass es damit zusammenhängt.

 

[voidtrading]

Das Problem ist aber nicht nur bei denn 5000er

Ich möchte dabei kurz anmerken, dass das beim op (und bei mir) aber nicht die gleiche event id war - diese führt zumindest bei mir zum sofortigen Absturz und nicht erst 15 min später.

 

[PLZ4ytPxC]

Ich habe dasselbe Problem (Crashes vor allem im Idle, meistens mit WHEA-Fehler im Event Viewer) mit folgendem System:
AMD Ryzen 5950X
MSI B550 Tomahawk @ 7C91vA51(Beta)
Kingston HyperX Fury Kit 2x32GB, DDR4-3200, CL16-20-20 (HX432C16FB3K2/64) @ XMP-3200 (Profile 1)
ASUS Strix GeForce GTX 970 OC
Corsair AX850 Titanium
Windows 10 20H2

Das Problem tritt selbst mit deaktiviertem XMP, deaktivierte Global C-States, typical Idle Current (deaktiviert Package-C6) auf. Deaktivieren von CPB scheint es aber zu lösen, deswegen sieht es sehr danach aus, dass zumindest bei mir CPB zu aggressiv boostet (zumindest auf manchen Cores).

Ich bin auch relativ sicher, dass die Crashes nur deswegen im Idle passieren, weil dort die kurzen Singlecore-Boosts am meisten Headroom haben. Das Deaktivieren von Global C-States löst das Problem zwar nicht, aber macht das System deutlich (!) stabiler (crasht 'nur noch' alle 2-3 Tage statt zweimal täglich). Ich vermute, dass das etwas irreführend ist, weil Stabilität nur daher kommt, dass der Chip eine Spur weniger Headroom für Boosting hat wenn C-States aus sind. Einen ähnlichen Effekt kann ich erzielen, indem ich VSOC erhöhe (z.B. von 1.0V auf 1.1V). Das liegt aber vermutlich nur daran, dass die VSOC in die Powerlimits einfliesst, und man damit dann eben auch Headroom für Boosting reduziert.

Natürlich ist das Deaktivieren von CPB keine Lösung. Deswegen habe ich jetzt Alternativ CPB wieder angemacht (und XMP, C-States, und auch sonst alles auf Default/Auto), aber im Curve Optimizer All-Core +7 eingestellt. Ich habe über die letzten 7 Tage verschiedene Werte von 0 bis 7 getestet, und man sieht wirklich sehr deutlich (!), wie die Stabilität signifikant verbessert wird mit einem höheren Wert. Bei +5 hat es 3 Tage bis zum ersten Crash gedauert, deswegen bin seit 4 Tagen auf +7 (bis jetzt ohne Crash). Bei +7 boostet der schnellste Core im Cinebench20 Single-Core jetzt nur noch auf 4.9GHz (vorher bis zu 5.1GHz), aber mit Single- und Multi-Core Scores von 617 und 10057 (vorher ~640 und ~10300) kann ich gerade noch so leben. Zumindest viel besser als wenn CPB deaktiviert ist.

 

[EvilHoppel]

Ich habe dasselbe Problem (Crashes vor allem im Idle, meistens mit WHEA-Fehler im Event Viewer) mit folgendem System:
AMD Ryzen 5950X
MSI B550 Tomahawk @ 7C91vA51(Beta)
Kingston HyperX Fury Kit 2x32GB, DDR4-3200, CL16-20-20 (HX432C16FB3K2/64) @ XMP-3200 (Profile 1)
ASUS Strix GeForce GTX 970 OC
Corsair AX850 Titanium
Windows 10 20H2

Das Problem tritt selbst mit deaktiviertem XMP, deaktivierte Global C-States, typical Idle Current (deaktiviert Package-C6) auf. Deaktivieren von CPB scheint es aber zu lösen, deswegen sieht es sehr danach aus, dass zumindest bei mir CPB zu aggressiv boostet (zumindest auf manchen Cores).

Ich bin auch relativ sicher, dass die Crashes nur deswegen im Idle passieren, weil dort die kurzen Singlecore-Boosts am meisten Headroom haben. Das Deaktivieren von Global C-States löst das Problem zwar nicht, aber macht das System deutlich (!) stabiler (crasht 'nur noch' alle 2-3 Tage statt zweimal täglich). Ich vermute, dass das etwas irreführend ist, weil Stabilität nur daher kommt, dass der Chip eine Spur weniger Headroom für Boosting hat wenn C-States aus sind. Einen ähnlichen Effekt kann ich erzielen, indem ich VSOC erhöhe (z.B. von 1.0V auf 1.1V). Das liegt aber vermutlich nur daran, dass die VSOC in die Powerlimits einfliesst, und man damit dann eben auch Headroom für Boosting reduziert.

Natürlich ist das Deaktivieren von CPB keine Lösung. Deswegen habe ich jetzt Alternativ CPB wieder angemacht (und XMP, C-States, und auch sonst alles auf Default/Auto), aber im Curve Optimizer All-Core +7 eingestellt. Ich habe über die letzten 7 Tage verschiedene Werte von 0 bis 7 getestet, und man sieht wirklich sehr deutlich (!), wie die Stabilität signifikant verbessert wird mit einem höheren Wert. Bei +5 hat es 3 Tage bis zum ersten Crash gedauert, deswegen bin seit 4 Tagen auf +7 (bis jetzt ohne Crash). Bei +7 boostet der schnellste Core im Cinebench20 Single-Core jetzt nur noch auf 4.9GHz (vorher bis zu 5.1GHz), aber mit Single- und Multi-Core Scores von 617 und 10057 (vorher ~640 und ~10300) kann ich gerade noch so leben. Zumindest viel besser als wenn CPB deaktiviert ist.

Zu der Beobachtung muss ich auch mal meinen Beitrag leisten und habe mich extra dafür registriert, da ich ebenfalls von dem Problem mit den Crashes geplagt bin.
Also konkret: Restart und WHEA-Fehler "Cache Hierarchy Error" mit Ereignis-ID 18 und immer Prozessor-APIC-ID: 0, der auch mein stärkster Kern ist.

Meine Config:
- AMD Ryzen 5950X (alles Stock, also auch CPB an)
- ASUS Crosshair VIII Dark Hero
- G.Skill Trident Z RGB 32GB (F4-4133C19D-16GTZR) @3600 Mhz CL16 (Problem tritt auch ohne XMP bzw. Übertaktung auf)
- ASUS Strix RTX 3090 OC
- Corsair RM850X
- Windows 10 20H2

Das was PLZ4ytPxC schreibt, deckt sich stark mit meinen Beobachtungen. Da ich das Problem unabhängig von der Geschwindigkeit des RAM habe und dieser beim Karhu RAM Test kein Problem zeigt, würde ich das ausschließen.

Ich kann das Problem relativ gut reproduzieren, wenn ich bei Cinebench R20 den Single Core Benchmark starte. Dann kommt sehr häufig der Restart mit dem "Cache Hierarchy Error". Da auch immer mein bester Kern als Verursacher im Event-Log auftaucht, deutet das auf zu heftiges Boosten hin.
Heute habe ich mal die Global C-States deaktiviert und seit dem keinen Crash mehr gehabt.

Ich beobachte mal weiter und hoffe, dass das ganze mit einem BIOS/AGESA Update zu beheben ist.

 

[PLZ4ytPxC]

Ich kann das Problem relativ gut reproduzieren, wenn ich bei Cinebench R20 den Single Core Benchmark starte.

Ja, das ist exakt wie ich das auch am besten reproduzieren kann: Alle Anwendungen beenden (wirklich alle!), und nur CB20 Single-Core starten, dann besteht eine gewisse Wahrscheinlichkeit, dass es direkt crasht. Für meine Tests habe ich dafür ein kleines Skript geschrieben, indem ich CB20 in einer unendlichen Loop aufrufe:

:loop
start .\Cinebench.exe -g_CinebenchCpu1Test=true -g_acceptDisclaimer=true
timeout /t 10 /nobreak > NUL
taskkill /f /im Cinebench.exe
timeout /t 8 /nobreak > NUL
goto loop

Da es immer Anfang passiert, schiesse ich CB20 nach ein paar Sekunden ab, warte ein paar Sekunden (damit die CPU wieder in idle geht), und starte es dann wieder neu. Damit konnte ich relativ gut den Crash reproduzieren (bei höherer Stabilität, z.B. höherem Curve Optimizer All-Core Wert, hat es allerdings dann doch 30-90 Minuten gedauert, bis das den Crash getriggert hat).

Heute habe ich mal die Global C-States deaktiviert und seit dem keinen Crash mehr gehabt.

Wie gesagt, ich hatte auch zuerst gehofft, dass das das Problem löst, aber dann ist er nach ein paar Tagen wieder gecrasht. Vielleicht kannst Du ja mal mein Skript oben mit Cinebench R20 laufen lassen und sehen, ob er das 2-3 Stunden überlebt. Wenn ja, dann gibt es Hoffnung, dass das bei Dir wirklich ausreicht. Allerdings ist es völlig absurd C-States zu deaktivieren nur um zu verhindern, dass CPB zu hoch boostet.

 

[Casi030]

Schon mal PBO von Hand eingestellt und Max CPU Boost auf 0 oder 25MHz?!

 

[PLZ4ytPxC]

Schon mal PBO von Hand eingestellt und Max CPU Boost auf 0 oder 25MHz?!

Ja, bei mir kann ich den Curve Optimizer nur einstellen, wenn ich PBO auf manuell stelle. Ich stelle dann das alles wie auf Stock ein (PPT 142W, TDC 95A, EDC 140A, 1x scalar, 0MHz offset, Thermal Limit default), aber eben Curve Optimizer All-Core +7.