PC stürzt unregelmäßig im "Idle" ab, wenn "Power Supply Idle Control" auf Auto steht

Guten Tag Zusammen,

ich klinke mich hier in die Diskussion auch mal mit ein. Ich hoffe, das ist in Ordnung :-) Mich hat es vermutl. auch erwischt mit dem Problem :-( Ich hoffe das das jetzt nicht zu viel Text ist. Ich bin neu hier :-) .

Rechner (Komponenten neu gekauft Anfang Januar 2020):
Netzteil: be quiet! Pure Power 11 400W
CPU: AMD Ryzen 5 3600
CPU-Lüfter: Alpenföhn (genau Bezeichnug interessant?)
Board: ASRock Fatal1ty B450 Gaming-ITX/AC
RAM: Crucial Ballistix Sport LT 3200 MHz DDR4 Speicher Kit 16GB (2x 8GB) CL16
Festplatte: Intel SSD 660P M.2 PCIe 1.0 TB
Garfikkarte: Inno3D GeForce GTX 1650 4GB X2

Das Problem besteht seit ca. Ende Juli diesen Jahres. Es wurden keine Hardwareänderung vorgenommen. Der Fehler trat von heute auf morgen auf. Der Bildschirm wird sporadisch plötzlich schwarz und der Rechner startet sofort neu (obwohl "Kein automatischer Neustart" in den Einstellung für Systemfehler aktiviert ist). Der Fehler Kernel-Power 41 (63), BugcheckCode 0 ist hinterlegt. Es gibt keinen Bluescreen oder ein MemoryDump-File und auch keinen Hinweis auf den Verursacher. In der Ereignisanzeige steht davor kein Fehler Code, danach steht der Fehler Code 1101 und 6008 drin.

Dies passiert sporadisch im Idle, aber auch bei "leichten" Tätigkeiten wie z. B. in Word, Browser u. a. Youtube, usw., aber bisher nicht unter Last (Stresstests mit prime95 oder Spiele). Temperaturproblem ist es nicht, die Temperatur der CPU beträgt maximal ca. 80 °C bei prime95. Ob das Gehäuse offen oder geschlossen ist, macht im Bezug auf den Fehler keinen Unterschied.

Aktuell ist Windows 10 Version 21H1 (Build 19043.1266) installiert. Der Schnellstart ist deaktiviert. Der Energiesparplan ist auf AMD Ryzen Balanced gesetzt. Es wurden in der Zwischenzeit ein paar Windows Updates installiert. Der Amd Chipsatz Treiber wurde auf die Ver. 3.09.01.140 und der Nvidia Grafikkartentreiber auf die Ver. 472.12 aktualisiert. Alles brachte keine Änderungen.

Getestete Bios-Versionen:
4.60 AMD AM4 AGESA Combo V2 PI 1.2.0.3 Patch C
4.50 AMD AGESA ComboAM4v2 1.2.0.2
4.40 AMD AGESA ComboAM4v2 1.2.0.0
=> CMOS Reset oder Update bringt keine Änderung, unter Stock läuft das System auch nicht stabil

PBO war immer auf Aus
Powersupply idle control bisher immer auf Auto (hier teste ich gerade low current idle)

Der Ram wurde mit und ohne XMP getestet, die Spannung von 1,35 V auf 1,4 V erhöht, Mit dem Windows Speichertest getestet, Auch wurden die Ram Riegel einzeln in jedem Ram-Slot separat getestet, das alles brachte keine Änderung => Ram also in Ordnung

Ich habe ein anderes Netzteil (beQuit BQ L8-400W) probiert, damit lief der PC zwei Tage ohne Absturz => Also habe mein Pure Power 11 über den Händler eingeschickt und nach 1,5 Monaten zurückerhalten, mit der Aussage: "Es wurde kein Defekt festgestellt". Nach dem Wiedereinbau des Netzteils und dem ersten Start des Pc's nach 1,5 Monaten, hatte ich nach ca. 30 min dreimal nacheinander jeweils im Abstand von ca. 30 min den Fehler 41 gehabt, diesmal aber mit Bugcheckcode 239 in Verbindung mit volmgr (Festplatte) und einem Blueescreen ("Critical Prozess Died", kein Dump-File). Dieser Fehler ist neu und bisher noch nie aufgetreten. Auch habe ich den Fehler seit dem nicht mehr gesehen. Anschließend lief der Rechner ca. 2 Tage und 20 h durch ohne Fehler, dann wieder der schwarzer Bildschirm (wie ganz oben beschrieben, mit dem Fehler 41, BugcheckCode 0) :-( . Bisher läuft der Rechner wieder seit 5 Stunden. Zur Häufigkeit kann man sagen, das passiert mind. einmal am Tag.

Im Bios habe ich von Anfang an "Restore on AC/Power Loss" auf "Power Off" gesetzt. Wenn ich das Netzteil per Schalter im Betrieb ausschalte und wieder einschalte, bleib der Pc aus => Anderes Verhalten als bei dem Absturz, hier startet der Pc direkt neu. Daher vermute ich das das Netzteil doch nicht schuld ist? Sollte das Netzteil schuld sein, müsste der Pc nach dem Fehler doch ausbleiben?

Was nun? CPU einschicken, über Händler oder bei AMD direkt? Mainboard einschicken? Kann ich die Grafikkarte und Festplatte ausschließen? Ich denke schon. Zum Testen habe ich leider keine andere Cpu, Mainboard oder Grafikkarte da.

Auffällig war von Anfang an:
  • Ab und an hatte ich nach dem Hochfahren von Windows 10 im Zuverlässigkeitsverlauf den Fehler 41, BugcheckCode 0. Der Rechner ist aber nicht abgestürzt und wurde zuvor ordentlich heruntergefahren. Der Fehler trat aber nach einem Bios-Update nur noch sehr selten auf.
  • Manchmal ist er im Energie Sparmodus abgestürzt (selten, konnte mit einem Bios-Update behoben werden).
  • Windows meldet ab und an einen Hardwarefehler (BTHUSB Ereignis-ID 18), der mit dem Intel Wlan/Bluetooth-Modul auf dem Mainboard zusammenhängt. Außer der Fehlermeldung habe ich das trotz Bluetooth-Maus im Betrieb aber nie bemerkt.
 

Anhänge

  • SSD.PNG
    SSD.PNG
    64,4 KB · Aufrufe: 292
  • ZenTimings.png
    ZenTimings.png
    32,1 KB · Aufrufe: 284
@RomanticPsycho

Ist schon ein komischer Zufall mit dem RAM-Defekt und dem Bios-Update. Scheint mir etwas suspekt, aber wenn ich das richtig verstanden habe, läuft jetzt erstmal alles gut ?

@Johnny94
Hallo,

was ich bei dir auf Anhieb sehe ist eine sehr hohe VSOC Spannung. Kannst du im bios mal XMP deaktivieren und dann noch ein Screenshot mit ZenTimings machen ?

Zum Restore on AC Power Loss: Bei den Reboots kommt es ja gar nicht zum AC Power Loss. Das Netzteil ist weiterhin in Betrieb. Aber selbst wenn das NT sich kurzzeitig aus- und wieder einschalten würde, wären die Kondensatoren im NT noch längst nicht entladen und das Board würde immer noch Spannung sehen. Das wäre aus Sicht des bios immer noch kein AC Power Loss. Zumal wir nicht wissen, was für Kommandos im Hintergrund während der ganzen idle-crash Geschichte tatsächlich auf Firmwareebene passiert.
 
  • Gefällt mir
Reaktionen: RomanticPsycho und e_Lap
Johnny94 schrieb:
Auffällig war von Anfang an:
  • Ab und an hatte ich nach dem Hochfahren von Windows 10 im Zuverlässigkeitsverlauf den Fehler 41, BugcheckCode 0. Der Rechner ist aber nicht abgestürzt und wurde zuvor ordentlich heruntergefahren. Der Fehler trat aber nach einem Bios-Update nur noch sehr selten auf.
Das ist bei mir übrigens auch manchmal so. Teilweise wenn ich nach einem Windows-Update den Rechner neustarte und es keinerlei Auffälligkeiten dabei gab.

@RomanticPsycho Ich glaube teilweise kommen die Probleme auch einfach von bestimmten RAM-Modulen, die Ryzen nicht mag. Ist der neue RAM komplett identisch? Ich weiß z.B. bei meinem RAM (Corsair LPX) gab es verschiedene Versionsnummern und da waren dann Chips von unterschiedlichen Herstellern drauf.
 
Johnny94 schrieb:
Außer der Fehlermeldung habe ich das trotz Bluetooth-Maus im Betrieb aber nie bemerkt.
Deine SoC spannung wird vom Board viel zu hoch angesetzt! Über 1,2 Volt sind schon heftig Brutal.
Das hatte ich bei meinem Board auch bemerkt und tritt erst ab Biosversion 4.xx auf.

Bitte im Bios fest auf 1,00-1,05 Volt einstellen, mehr ist da nicht nötig. Bitte auch den SoC Uncore OC mode einschalten und die SoC Uncore OC Voltage auf den gleichen Wert einstellen.

Denn obwohl er ausgeschalten ist, ist er aktiv!
Ich hatte da anfang des Jahres mal ein paar Tests gemacht und egal was ich versucht hatte, nichts, bis eben besagte Spannung gleich einstellen, hatte nichts geholfen.
 
  • Gefällt mir
Reaktionen: ShiftC und e_Lap
Vielen Dank für Eure Antworten

Zur Vsoc Spannung: Ich habe heute (nur heute, dort habe ich sonst bisher nie irgendetwas eingetragen oder verstellt) unter "SoC/Uncore OC Voltage (VID)" diesen Wert eingetragen, allerdings "SoC/Uncore OC Mode" auf "Disabled" oder "Auto" gestellt (keinesfalls auf "Enabled"). In diesem Fall wird im Uefi der "SoC/Uncore OC Voltage (VID)" Wert auch ausgegraut und man kann ihn nicht ändern. Ich bin daher davon ausgegangen, dass er damit auch deaktiviert ist. Das ist allerdings nicht der Fall, ganz egal ob "SoC/Uncore OC Mode" auf "Disabled" oder "Auto" steht. Das habe ich gerade getestet. Nach einem Reset aller Uefi Einstellungen habe ich jetzt bei Vsco ohne XMP 1,0125V und mit XMP 1,0875V. Soll ich diese ausgelesenen Werte je nach Profil fest bei "SOC Voltage (VID)" und "SoC/Uncore OC Voltage (VID)" mit "SoC/Uncore OC Mode" mit "Enabled" einstellen oder einen ganz anderen Wert nehmen?

Zum AC Power Loss: Ok. Schade, dann kann man so das Netzteil doch nicht ausschließen.

@TornadoX
Interessant das Du dieses Problem auch hast. Bei mir war da immer ein mulmiges Gefühl dabei, da die SSD hier jedes Mal den "Unsafe Shutdowns" Wert erhöht hat. Hier habe ich immer bedenken, dass es evtl. zu einem Datenverlust oder Ähnlichem kommen könnte oder schon gekommen ist (da ist mir aber bisher diesbezüglich noch nichts augefallen).
 

Anhänge

  • ZenTimings_keinXMP.png
    ZenTimings_keinXMP.png
    32,4 KB · Aufrufe: 266
  • ZenTimings_XMP.png
    ZenTimings_XMP.png
    32,1 KB · Aufrufe: 266
Johnny94 schrieb:
Soll ich diese ausgelesenen Werte je nach Profil fest bei "SOC Voltage (VID)" und "SoC/Uncore OC Voltage (VID)" mit "SoC/Uncore OC Mode" mit "Enabled" einstellen oder einen ganz anderen Wert nehmen?
Wie ich oben schon geschrieben hatte, reichen für 3200Mhz/1600IF 1,00 Volt bei beiden Spannungen völlig aus.

Erst wenn du über 3600Mhz/1800IF gehst solltest du dann testen, wieviel notwendig ist. Aber davon bist du noch weit entfernt.
 
Ich kann bei wiederkehrenden Problemen wirklich nur dazu raten, für eine längere Zeit zuerst mit absoluten stock-settings zu testen, um die Übeltäter einschränken zu können. Bei OC - und ja XMP ist OC - kommen zu viele potentielle Fehlerquellen hinzu. Der Speichercontroller in der CPU, diverse Spannungen, Abschlusswiderstandswerte, der RAM selbst usw. Auch die Grafikkarte kann die Ursache sein, schon mehrfach mitbekommen. Da kann es helfen den ULPS Modus abzuschalten.

Wenn das System nach nem CMOS Reset auch unter stock-settings mit komplett abgeschalteten OC-Kram (XMP, PBO, LN2, SoC Uncore etc.) dennoch im idle abstürzt und ich keine Ersatz-CPU zum testen hätte, würde "ich" folgende Schritte abarbeiten:


  • CPU Temp
  • VSoC kontrollieren (ohne XMP reicht schon unter 1V, rest hat @peterX ja bereits gesagt)
  • kontrollieren ob RAM auch in A2/B2 sitzt. Die Bänke einmal aussaugen (Schmutzpartikel)
  • CPU einmal ausbauen, auf verbogene Kontakte prüfen und neu einsetzen (man mag kaum glauben wie oft das schon geholfen hat, selbst bei nicht verbogenen Kontakten)
  • CPU Power Connector auf Sitz überprüfen und sofern möglich im Bios/HWInfo die Spannungen +12V (sollte mind. 12V haben) und die PLL Voltage (sollte mind. 1,8V haben) kontrollieren
  • MemTest durchführen, weiterhin unter stock-settings
  • Ersatz Grafikkarte vorhanden ? Testen.
  • wenn nötig, Rechner nur mit einem RAM Riegel in A2, wenn weiterhin Abstürze kommen mit dem selben Riegel in B2 oder nem anderen Riegel wieder in A2 testen.. Das Muster sollte klar sein.
  • PowerSupply Idle Control auf typical current idle / low current idle umstellen und probieren (bei modernen NTs sollte typical current nicht nötig sein, doch testen hilft immer)

Wenn auch das alles nicht hilft, kann man den Fokus auf die CPU legen:
  • Core Performance Boost abschalten
  • Global C-State Control deaktivieren
  • CPPC und CPPC PC deaktivieren
  • positiven VCore Offset in 25mV Schritten
  • negativen VCore Offset in 25mV Schritten

Die obigen Vorschläge nur vorerst immer nur einzeln testen. Sonst weiss man hinterher nicht, woran es genau lag. Die SoC Spannung sollte zwar im Bestfall 1,1V nicht überschreiten, aber eine noch höhere Spannung führt in der Praxis meist nicht zu idle Abstürzen, sondern eher zu Performanceproblemen, Rucklern und Audioaussetzern.

Ich verlinke an dieser Stelle mal wieder die Umfrage, die ich vor mehreren Wochen gestartet hatte. Da kann man immer noch dran teilnehmen:

Zur Umfrage
 
  • Gefällt mir
Reaktionen: peterX und e_Lap
ShiftC schrieb:
Die SoC Spannung sollte zwar im Bestfall 1,1V nicht überschreiten, aber eine noch höhere Spannung führt in der Praxis meist nicht zu idle Abstürzen, sondern eher zu Performanceproblemen, Rucklern und Audioaussetzern.
Das hättest du mal dem IO Die meines R5 3600 sagen sollen. :D Der mochte Spannungen (SoC) über 1,035 Volt Überhaupt nicht, im besten Fall hattest du stottrigen Sound. Aber meistens hatte er ganz einfach einen Reboot gemacht. Auch wenn viele Schreiben, dass die Spannung noch voll im grünen Bereich ist, meinem R5 gefiel sie üüüberhaupt nicht.
Aber ja, meine CPU war da ne richtige Diva. Dafür schaffte sie IF1900/3800Mhz Ram mit 1,0125 Volt. :daumen: :schluck:
 
  • Gefällt mir
Reaktionen: ShiftC
Gestern ist mein Pc wieder mit demselben Fehler abgestürzt. Die Option "Power Supply Idle Control" auf "low current idle" zu stellen hat nichts gebracht. Ich test jetzt eine SoC Spannung von 1 Volt, wie PeterX vorgeschlagen hat (ZenTimings VSOC 0,9875V). Falls das nichts hilft, stelle ich die Option "Power Supply Idle Control" auf "typical current idle" und teste das.
Ansonsten kann habe ich das meiste aus deiner Liste ShiftC schon ausprobiert. Ich kann die CPU noch aus- und wieder einbauen. Sollte das alles nichts helfen, werde ich die CPU reklamieren, in der Hoffnung das die defekt ist und nicht das Mainboard oder doch das Netzteil. Ich habe leider schon sehr viel Zeit mit dem Problem verschwendet ohne Lösung. Das muss meine ich einfach alles im Stock laufen. Auf jetzt z. B. die Soc-Spanung in 25mV selber justieren und jedesmal ein oder zwei Tage warten, habe ich eigentlich keine Lust. Da gehen wieder Wochen ins Land. Zumal es auch schwierig ist, da 2 Tage ohne Absturz nicht gleich heißt, dass es keine Probleme mehr gibt. Der Absturz kann auch erst am 3. Tag auftauchen. Das ist absolut beschissen zum Testen.
Ein Ersatz Grafikkarte, CPU oder Mainboard sind nicht vorhanden. An der Umfrage habe ich teilgenommen.
 
@ShiftC Läuft bei dir noch alles stabil mit CPPC und CPPC Preferred Cores deaktiviert? Bei mir ist gerade wieder nach ca. 1 Monat mit aktuellstem BIOS und Typical Current Idle der PC neugestartet. Ich würde jetzt auch mal gucken, was passiert, wenn ich diese Optionen bei mir deaktiviere.

Hier mal meine Benchmark-Ergebnisse. Minimal schlechtere Single Core Ergebnisse, aber insgesamt bessere Ergebnisse mit deaktiviertem CPPC.

CPPC + CPPC Preferred Cores aus / an

Cinebench R15
Single: 203 / 205
Multi: 2108 / 2099

Userbenchmark
Bench: 92.3% / 92.2%
Normal: 93% (166 Pts) / 93% (167 Pts)
Heavy: 100% (808 Pts) / 97% (782 Pts)
Server: 99% (1473 Pts) / 98% (1465 Pts)

3DMark Time Spy
Overall: 10270 / 10259
Graphics: 10284 / 10278
CPU: 10193 / 10156
 
Zuletzt bearbeitet:
  • Gefällt mir
Reaktionen: ShiftC
Ich habe seit dem zweiten BIOS-Update (mit einem anderen USB-Stick) keine Abstürze mehr.
Scheint, als wäre das Beta-BIOS falsch aufgespielt worden.
 
  • Gefällt mir
Reaktionen: ShiftC
@TornadoX
Läuft bisher unauffällig, aber wir wissen ja, dass das leider nichts heissen muss.
Zumal ich auch anmerken muss, dass ich ein paar Tage nach dem Deaktivieren von CPPC(&PC) den AMD Adrenalin Treiber komplett rausgeschmissen habe. Also momentan ist nur der reine GPU Treiber installiert.

Danke für die Benchmarks. Man muss dazu sagen, dass die ganze CPPC Geschichte unter Windows ohnehin nicht sauber läuft.

@RomanticPsycho
Das klingt doch gut 👍
 
Habt ihr irgendwelche Programme von den MB Herstellern installiert?
Programme wie z.B. MSI Center machen sehr gerne Probleme oder auch Steuerprogramme wie iCue.

Bei Abstürzten gibt es ja immer einen Eintrag im Zuverlässigkeitsverlauf, sollte der Eintrag keine Technischen Details haben kann man dem Datum und Zeitangaben in der Ereignisanzeige genauere Daten bekommen. Im ZV Verlauf stehen auch Programme drin die nicht funktionieren oder Updates die fehlerhaft sind.
Anhand von Fehlercodes kann das Problem eigentlich sehr schnell gefunden werden.

Im BIOS gibt es auch eine Einstellung die für Stabilität sorgt, die habe ich schon lange Aktiv und mein System, war schon immer stabil, wurde danach z.B. nach RAM OC noch stabiler.
Gerade wenn man 4.0 Geräte verwendet aber nicht nur dann.

1634907901233.png
 
Update: Und täglich grüßt das Murmeltier. Nach so vielen Wochen gleich zwei Reboots an einem Tag..

Das einzige, was sich geändert hat bei mir: Der Bildschirm wird nicht unmittelbar beim crashen schwarz, sondern für 2-3 Sek. grün. Ich denke für mich hat die monatelange Suche und Experimentiererei heute ein Ende. Ich hab zwar wieder eins bis zwei Sachen umgestellt, aber nur aus Jugs und nicht aus Hoffnung oder Verdacht.
Entweder besorge ich mir jetzt ne gebrauchte Übergangs-CPU und schick den jetzigen 3700X zu AMD, oder ich steige direkt auf'n 5800X (besser vielleicht 5700G ?) um und verkaufe den 3700X nach der RMA. Mal schauen.

@Müritzer
Vertrau an dieser Stelle einfach der Aussage, dass ich - ich spreche jetzt für mich - schon alles durch habe. Ich möchte jetzt ungern alles niederschreiben, was ich bisher getestet habe, weil das echt viel Text bedeutet :)
 
Zuletzt bearbeitet:
@ShiftC Schade, das höre ich natürlich auch nicht gerne, weil ich ja gerade die Idee mit CPPC deaktivieren ausprobiere.

Ich werde das Problem wahrscheinlich einfach aussitzen, weil es zum Glück bisher recht erträglich war und nicht allzu oft auftritt. Aber natürlich wäre mir ein stabiler PC deutlich lieber...

Neue Hardware wäre mir im Moment zu teuer. Und ich bin mir immer noch nicht sicher, ob jetzt eigentlich CPU, Mainboard, RAM, Netzteil, ... letztendlich die Ursache ist. Höchstwahrscheinlich aber wohl die CPU.

Zu dem LCLK DPM Thema: Die Einstellungen sind bei mir beide auf Auto.
MSI BIOS schrieb:
LCLK Power Management. Auto = Enabled. Enabled = Automatically lower LCLK frequency to save power. Disabled = Fixed LCLK.
Die Einstellungen sind ja mal ganz schön dämlich benannt, wenn "Auto" enabled heißt und "Enabled" auto heißt. Von den Einstellungen würde ich jetzt erwarten, dass "Disabled" am stabilsten sein sollte.
 
Zuletzt bearbeitet:

@ShiftC


Ich meinte das man diese Einstellungen und Programme zu Hilfe nehmen sollte wenn was nicht so richtig läuft. Wenn alles überprüft wurde ist ja gut.


@TornadoX


Diese Einstellungen gibt es schon seit 2011 in AMD Prozessoren aber die waren bei den meisten BIOS Versionen wohl nicht sichtbar.

Im OC Forum konnten Leute diese WHEA Fehler verringern oder die Schwelle erhöhen bis der Fehler anspricht. Auto ist immer so eine Sache, gerade bei MSI, habe schon mehrere Boards selber gehabt oder verbaut, sollte man solche Einstellungen immer auf Enabled stellen.

http://developer.amd.com/wordpress/media/2012/10/41131.pdf

Das ist ein:
BIOS and Kernel Developer’s Guide (BKDG) For AMD Family 12h Processors

Hier mal ein Auszug aus der PDF

2.5.5.1.3 LCLK DPM

LCLK DPM operates in one of two modes, either by tracking root complex activity, or by tracking PCIe bandwidth and GFX DMA activity. This is specified by SMUx0B_x8434[LclkDpmType].

LCLK DPM is enabled by setting SMUx0B_x8434[LclkDpmEn] to 1 and interrupting the SMU with Service Index 08h. See 2.12.1.2 [Software Interrupts]. Voltage changes due to LCLK DPM state changes are enabled using FCRxFF30_01E4[VoltageChangeEn].
.
.
.
.
2.5.5.1.3.2 LCLK DPM Using PCIe Bandwidth and GFX DMA Activity

LCLK DPM using PCIe bandwidth and GFX DMA activity consists of up to 10 PCIe bandwidth states and 8 GFX DMA activity states. Any number of states may be used and there is no requirement that the states be contiguous. The PCIe bandwidth states and the GFX DMA activity states transition independently from each other.
 
Wenn ich die Einstellung richtig verstehe, ist es eine dynamische Energieverwaltungsoption und mit LCLK DPM aktiviert/deaktiviert man die dynamische Performanceregulierung des pci-e busses anhand von Aktivitätsberechnungen.

Klingt für mich rein theoretisch auch erstmal danach, als würde das Abschalten für mehr Stabilität sorgen.

@Müritzer

Das Hauptproblem in diesem Thread ist ja das Abstürzen im idle, auch unter absoluten stock settings, ohne xmp und ohne kuriose Spannungswerte etc., während es unter Last (auch mit XMP) stabil läuft.
 

@ShiftC

Ja wenn das immer im Idle passiert können Programme die im Hintergrund laufen ( die gleich im Autostart sind ) schon für Probleme sorgen aber auch Einstellungen im BIOS.
Auch sollte man ein Auge auf die Treiber haben, da habe ich Festgestellt das man nach einer Windows 10 Installation immer zuerst den Chipsatz installieren sollte. Da die meisten aber die Win Installation mit LAN Anschluss machen und Windows gleich mal Treiber installiert konnte ich dort auch schon gleich Fehler feststellen. Eine Windows Clean Installation ohne Internetanschluss mit vorher runtergeladenen Treiber hat ein besseres Ergebnis gebracht.
Viele schalten ja PBO ab, oder so wie ich setzen einen festen PPT wert. Da sind Tests mit verschiedenen Einstellungen angebracht.

Zu den LCLK Einstellungen, wenn man die disabled also auf feste Werte geht muss man hier auch die Werte testen.

1635092450979.png


Habe verschiedene Einstellungen die in diesem Thread behandelt werden getestet.
https://www.overclock.net/threads/msi-b550-unify-unify-x-overclocking-discussions-thread.1774910/
 
@alle

Wäre ganz hilfreich, wenn ihr mal in der Ereignisanzeige auf den WHEA ID 18 Eintrag geht und die im Bild markierten Werte (MCABank und MciStat) mitteilt. Dazu am besten rechts auf "aktuelles Protokoll filtern" klicken und in der unteren Hälfte bei <Alle Ereignis-IDs> 18 eintippen.

Falls bei euch die Bank und Stat Werte aller WHEA18 Fehler nicht gleich sein sollten, bitte auch die unterschiedlichen mitteilen.

Ich werde versuchen die Werte zu dekodieren.

Screenshot 2021-10-25 172319.jpg
 
Zurück
Oben