> Dasselbe Prob hatte ich auch mal, selbst mit dem Ram-Checker von ct, der
> sich im Videoram einnistet und da läuft (hab ich das richtig in
> Erinnerung?) wurde nichts gefunden.

Ja, der c\'t-RAM-Test (\"ctramtst\") kopiert sich in den RAM der Grafikkarte und läuft dann dort, so dass er den ganzen RAM des Rechners (außer eben der Grafikkarte) überprüfen konnte. Auf Systemen mit RAM, der auch von der Grafikkarte benutzt wird, gibt es da evtl. Probleme, aber sonst ist das schon \'ne feine Sache.

Der c\'t-RAM-Test hat mittlerweile zwei Probleme: Erstens ist er meines Wissens seit vielen Jahren nicht mehr weiterentwickelt worden, so dass er viele PC-Chipsätze nicht kennt und dann auch so manche schönen Parameter nicht einstellen kann, und zweitens musste man die Ergebnisse des Programms sowieso mit etwas Hintergrundwissen interpretieren.

Der Grund lag in der Arbeitsweise des Programms sowie einfach in der Tücke des Objekts bzw. der Technik hinter den RAMs. Es ist so, dass die heute verwendeten Speicherbausteine eine Weile lang ihren Inhalt speichern können, aber dann \"vergessen\" sie ihn wieder. Als Gegenmaßnahme macht der Rechner in bestimmten Zeitabständen (einige Millisekunden, soweit ich weiß) etwas, was man \"Refresh\" nennt. Der sorgt (irgendwie) dafür, dass die \"Erinnerung\" in den Speicherbausteinen wieder \"frisch gemacht\" wird, so dass die Bausteine die Inhalte wieder eine Weile länger behalten.

Das c\'t-Programm lässt nun diesen \"Refresh\" nicht so häufig ablaufen wie normal, sondern im Extremfall nur einmal alle zwei Sekunden (statt ca. 2000 Mal in diesen zwei Sekunden). Danach schaut es nach, ob der Inhalt des Speichers noch derselbe ist wie vorher. Ist er verschieden, meldet das Programm einen Fehler.

Ich habe oft mit dem Programm gearbeitet und konnte mit seinen Ergebnissen mehr anfangen als mit denjenigen von memtest86. Mit 1x Refresh in zwei Sekunden wurden normalerweise null bis zwei Fehler bei ansonsten funktionierenden Systemen (also: kein Verdacht auf defekten RAM, nur prophylaktischer Test) gefunden. Etwa drei bis fünf Fehler machten einen defekten (bzw. \"altersschwachen\") RAM-Baustein wahrscheinlich, was man u.U. noch durch Ändern der Speichereinstellungen im Rechner-BIOS zum sauberen Funktionieren bringen konnte. Mehr als sieben Fehler traten eigentlich nur bei Systemen auf, die auch häufiger als üblich abstürzten oder seltsame Fehler machten.

Ich konnte also anhand der Fehlerzahl erahnen, ob das System wirklich ein Problem hatte oder ob noch was zu machen war - ganz sicher ist sowas aber auch nicht. Es kommt auch darauf an, wie \"empfindlich\" das Board ist. Mit einem Bekannten habe ich schon mal bei einem alten 486er so lange RAMs getauscht, bis der endlich wieder lief, wobei auch c\'t-RAM-Test viel zum Einsatz kam. Die RAMs, die der eine Rechner nicht wollte, liefen aber in einem anderen eine längere Zeit problemlos, ergaben sogar mit c\'t-RAM-Test etwas weniger Fehler. Sprich: Der 486er, dem sie ursprünglich angehörten, war sehr viel \"empfindlicher\" als die anderen Rechner.

Das Ganze liegt auch daran, dass diese Messmethode gar nicht sicher sagen kann, ob ein Speicherbaustein kaputt ist. Nur, wenn c\'t-RAM-Test überhaupt keinen Fehler trotz mehrmaliger Durchläufe anzeigte, konnte man sicher sein, dass die RAMs OK waren - ansonsten blieb immer ein kleines Bißchen Unsicherheit. Rein theoretisch muss ein RAM-Baustein seinen Inhalt ja auch nur Millisekunden lang behalten können, bis der Refresh kommt. Tausend Mal länger muss eigentlich nicht sein. Insofern ist das immer noch etwas Kaffeesatzleserei - nur las das c\'t-Programm damals (vor ca. 4-8 Jahren) deutlich besser im Kaffeesatz als andere Programme.

memtest86, worauf viele schwören, hat bei mir dagegen immer \"alles OK\" gemeldet, egal welchen Speicher ich ihm vorsetzte. Von daher halte ich persönlich von memtest86 auch nichts.