Warum beseitigt ein CMOS-Reset den Fehler?

[FANATLA]

Ich hätte da mal eine Frage. Es geht um den mittlerweile über 10 Jahre alten Intel-PC (anfangs Vista, jetzt Windows 10) eines Verwandten, bei dem ich in den Jahren mal eine defekte Festplatte ersetzt habe, eine SSD eingebaut und die Grafikkarte erneuert habe. Die Anforderungen sind nicht hoch und es waren immer nur kleine Investitionen, dass der Rechner wieder super funktionierte.

Naja, seit gestern gab es folgendes Problem: Beim Einschalten kein Bild, kein Pieps, Lüfter laufen einige Sekunden, Power-LED leuchtet. Nach ca. 10-15 Sekunden ging die Power-LED aus und das ganze Spiel begann endlos von vorne. Ich habe es deshalb mit der Nullmethode gemacht, also nur Netzteil, CPU (+Kühler) und Mainboard, leider aber den CMOS-Reset vergessen. Auch habe ich ein anderes Netzteil angesteckt. Es war das gleiche und ich dachte, Mainboard oder CPU defekt. Dann fiel mir ein, dass ich den CMOS-Reset vergessen habe. Nach dem Reset lief der Rechner wieder einwandfrei, es war nichtmal im BIOS irgendwas neu einzustellen.

Ich frage mich nur: Warum passiert sowas? Ich dachte es gibt vielleicht CMOS-Einstellungen, die durch eine eventuelle schwache Batterie verloren gegangen sind. Die Batterie habe ich gemessen (3,071V) und zur Sicherheit trotzdem ersetzt. Wenn ich das vor der Fehlersuche gewusst hätte, bevor ich alles abstecke, hätte ich einfach den CMOS-Reset gemacht und fertig.

Mein Verwandter (als Laie) fand es danach witzig und meinte, dass 99% vermutlich das Teil wegwerfen und sich einen neuen Rechner kaufen würden, und dabei brauchte man in dem Fall nur die Batterie raus und wieder reinstecken. (Ja ich habe keinen Jumper auf dem Board gefunden, sondern nur für 1min die Batterie rausgenommen).

 

[ergibt Sinn]

Hast du mal die BIOS-Batterie ersetzt ?
Nicht richtig gelesen...

 

[deineMudda]

Mir leuchtet deine Logik nicht ein: 3,071V sind für eine Lithium-Ionen-Batterie doch nicht viel.

 

[Bigglesworth]

Edit: Nicht richtig gelesen ^^. Wurde schon beantwortet.

 

[LencoX2]

So nur wegen der Batterie sollte das Problem mit nicht auftreten, dass alles schwarz bleibt.
Eine schwache Batterie wirkt sich eigentlich nur auf die eingebaute Uhr aus derart, dass diese immer zurück gesetzt wird.

Ich wuerde mich nicht wundern, wenn sich die Symptome bald wiederholen würden.

 

[kderf]

Wäre zu schön, wenn man solche Fehler immer durch nen BIOS Reset lösen könnte. Möglicherweise hast du aber auch beim rumdrücken auf dem Board irgendeine Verkrustung auf irgendeinem Kontakt gelöst oder sonstwas. Dafür ist ja die Fehlersuche nach der Methode da, den Miesepeter im System einzukreisen

 

[der Unzensierte]

3,07V sind zwar noch mehr als 3V, aber neu liegen die i.d.R. noch etwas höher, ich meine mich an 3,3V zu erinnern. Ursächlich war das aber eher nicht. Da wird es irgend eine Einstellung im BIOS durcheinander gewürfelt haben und mit dem CMOS reset ist alles wieder ok. Beobachten und weiter machen würde ich sagen.

 

[FANATLA]

Mir leuchtet deine Logik nicht ein: 3,071V sind für eine Lithium-Ionen-Batterie doch nicht viel.

Die CR2032 ist eine Lithium-Mangandioxid-Zelle und hat eine Nennspannung von 3,0V. Ich habe beruflich genau mit diesen Batterien oft zu tun und da werden erst <2,8V als problematisch eingeschätzt. Die werden auch nicht hoch belastet (liegt im Bereich von <10µA)

Ich wuerde mich nicht wundern, wenn sich die Symptome bald wiederholen würden.

Genau das habe ich mir auch gedacht. Mal sehen, wie es weitergeht. Am Anfang hatte ich ja das Netzteil im Verdacht.

Wäre zu schön, wenn man solche Fehler immer durch nen BIOS Reset lösen könnte. Möglicherweise hast du aber auch beim rumdrücken auf dem Board irgendeine Verkrustung auf irgendeinem Kontakt gelöst oder sonstwas. Dafür ist ja die Fehlersuche nach der Methode da, den Miesepeter im System einzukreisen

Naja das Rumdrücken passierte eher beim Abstecken der Kabel (besonders vom Netzteil-Stromkabel) und beim Herausnehmen der Grafikkarte und der RAMs. Da hat sich aber nichts getan. Erst nach dem sanften Herausnehmen und Wiedereinsetzen der Batterie war der Fehler weg.

3,07V sind zwar noch mehr als 3V, aber neu liegen die i.d.R. noch etwas höher, ich meine mich an 3,3V zu erinnern. Ursächlich war das aber eher nicht. Da wird es irgend eine Einstellung im BIOS durcheinander gewürfelt haben und mit dem CMOS reset ist alles wieder ok. Beobachten und weiter machen würde ich sagen.

3,3V haben die neu eher nicht, aber so 3,10-3,15V (muss morgen mal eine neue messen). Ich werde es auf jeden Fall beobachten.

 

[wakünick]

Läuft der RAM nach dem CMOS-reset noch mit den vorgesehenen (schnelleren) Einstellungen (Frequenz, Timings)?
(Keyword XMP-Profil)
Falls nein, teste aus, ob dann das Problem wieder auftritt... RAM kann nach vielen Jahren gerne mal zicken

 

[Pitt_G.]

@FANATLA Es gibt Microcode Updates für CPUs ausserhalb des BIOS Updates via Windows Updates,
Ausserdem soll es vorkommen können dass speicherzellen , des nicht beschreiben nach Jahren, ihren Inhalt verlieren,

 

[FANATLA]

Läuft der RAM nach dem CMOS-reset noch mit den vorgesehenen (schnelleren) Einstellungen (Frequenz, Timings)?
(Keyword XMP-Profil)
Falls nein, teste aus, ob dann das Problem wieder auftritt... RAM kann nach vielen Jahren gerne mal zicken

Da wurde nie was umgestellt und wegen der Nullmethode habe ich die RAMs auch rausgenommen.

@FANATLA Es gibt Microcode Updates für CPUs ausserhalb des BIOS Updates via Windows Updates,
Ausserdem soll es vorkommen können dass speicherzellen , des nicht beschreiben nach Jahren, ihren Inhalt verlieren,

Das könnte tatsächlich die Ursache sein. Aber eigentlich ist es noch wirklich ein BIOS und kein UEFI. Ich weiß nicht ob ein Windows-Update darauf zugreifen kann oder ob ein Virus/Malware da was anstellen kann. Naja, jedenfalls ist das Problem derzeit gelöst. Ansonsten melde ich mich zurück. Vielleicht ist ja wirklich in einer Speicherzelle, die von der Batterie gepuffert wird, ein Bit umgefallen oder so was.

 

[wayne_757]

Ist natürlich alles Spekulation, aber ein möglicher Grund wäre fehlende Inputparameter Validierung.

Diese ganzen Lowlevel Bauteile wie CMOS RAM haben keine Fehlererkennung. Die Firmware kann also erstmal nur relativ die Zustände "unprogrammiert" und "programmiert" unterscheiden. Ist der Baustein unprogrammiert kann defaulted die FW z.B. auf einen Wert der immer gültig ist (als Beispiel nehme ich mal RAM Takt = 500 MHz). Ansonsten prüft die FW immer alle User Parameter und wenn diese gültig sind, wird ins CMOS SRAM geschrieben.
Sobald also einmal irgendein Wert programmiert wurde wird beim nächsten Boot dieser angewendet.

Irgendwann passiert ein Bitkipper (z.B. weil die Batterie schwach ist). Dann steht da als RAM Takt plötzlich 1524 MHz. Der RAM läuft aber maximal mit 800 MHz. Die FW liest den Wert aus, wendet ihn an und Zack hängst du in der Bootloop.

Eine mögliche Gegenmaßnahme wäre z.B. eine Checksumme über alle CMOS Parameter zu berechnen und beim einschalten diese prüfen und auf default zurückfallen, falls sie nicht stimmt.

Früher hat man sich sowas aber gerne gespart weil man den Aufwand nicht wollte. Die Argumentationskette war, es gibt im CMOS SRAM keine Bitkipper, also ist das was man ausliest auch gültig. Deswegen hat man sich auch die Prüfung gespart ob der Wert innerhalb der richtigen Range lag.

 

[Pitt_G.]

@FANATLA , die Option Microcode Updates zu blocken gibt's im traditionellen Bios glaub schon länger, müsste mal schauen, ich meine mich zu erinnern dass was in meinem uralten Am2 m2n68 Board von Asus was stand