☰

tl;dr

tag-icon • tag-icon hard-drive windows-8.1 memory file-corruption memory-timings
tl;dr

tl;dr

Auf meinem neuen PC (mit Windows 8.1 x64) werden einige Dateien auf der lokalen SATA-Festplatte ohne ersichtlichen Grund beschädigt (nach einiger Zeit im Leerlauf).

Kein Virus/keine Malware! (habe es mit installiertem AVG Antivirus getestet, außerdem mit der sauberen, brandneuen Version 8.1 ohne Software/Treiber von Drittanbietern)

Es wurden von verschiedenen Testprogrammen keine Hardwarefehler erkannt.

Lange Version

Mir ist aufgefallen, dass einige Dateien in meinen Archiven nach einiger Zeit im Leerlauf beschädigt werden.

Es scheint, dass es immer dieselben Dateien sind, die beschädigt werden: Bei meinen letzten Tests an einem Satz von >33.000 JPEG-Dateien erhalte ich eine Liste derselben 30 Dateien, die immer beschädigt werden. Es sieht so aus, als ob diese 30 Dateien eine bestimmte Byte-Sequenz enthalten, die unter bestimmten Bedingungen die Beschädigung „aktiviert“.

(Nachdem ich festgestellt habe, dass ein Problem vorliegt, stelle ich regelmäßig Dateien aus dem Backup wieder her und vergleiche sie dann mit dem Backup mit WinMerge/BeyondCompare.)

Das Beschädigungsmuster ist ziemlich dasselbe: In den meisten Fällen sind einige der letzten Bytes (etwa 10 bis 20 letzte Bytes) mit zufälligen Daten gefüllt. Aber nicht immer – es gibt auch Dateien mit zufälligen Daten am Anfang/in der Dateimitte.

Ich habe einige Tests auf Hardwareprobleme durchgeführt, aber keine Probleme gefunden:

  • RAM getestet (mit MemTest86+ und einigen anderen Tools – habe über Nacht mit verschiedenen Füllmustern getestet – keine Probleme festgestellt)
  • Festplatte getestet (SMART-Probleme beim Attribut 0x05 „Anzahl neu zugewiesener Sektoren“ festgestellt, Festplatte im Rahmen der Garantie ausgetauscht (dasselbe Modell). Jetzt keine SMART-Probleme, keine fehlerhaften Sektoren bei Oberflächenscans.

Habe auch viele verschiedene Experimente gemacht. Wie:

  • Fenster neu installiert
  • Mit sauberem Windows versucht (auch ohne Treiber vom Motherboard-Hersteller, nur mit den von Microsoft bereitgestellten Standardtreibern)
  • Versucht mit allen richtigen Treibern (heruntergeladen von der Homepage des Herstellers)
  • Alle Partitionen gelöscht und die Festplatte neu partitioniert/formatiert
  • Versucht mit AVG Antivirus installiert und ohne

Ein Test hat (wahrscheinlich) positive Ergebnisse geliefert: Ich habe PartedMagic Linux verwendet und es von einem USB-Stick gebootet. Ich habe nach mehreren Wochen Linux-Nutzung keine Beschädigungen festgestellt. Aber ich bin mir immer noch nicht sicher, ob diese Linux-Distribution dieselben HW-Zugriffsmodi verwendet hat (wie Speichernutzung oder eine SATA-Verbindung usw.) oder ob es einfach nicht zufällig passiert ist.

Am Anfang dachte ich, das läge an den Windows-Treibern/der Cache-Konfiguration. Dieselbe Frage habe ich in der Microsoft-Community gestellt, aber keine Lösung gefunden. ( answers.microsoft.com/en-us/windows/forum/windows8_1-files/files-on-hdd-getting-corrupted/e2b04d4f-d3ea-492d-a181-c1d437ab1507 )

Das Problem wird noch analysiert: Ich habe noch immer keine stabile/vorhersehbare Sequenz gefunden, um das Problem zu reproduzieren. Derzeit verwende ich eine mehr oder weniger quasi-stabile Reproduktionssequenz (die jedoch noch mehrere Tage dauert, um das Problem zu reproduzieren):

  1. Konfiguration ändern (HW oder SW)
  2. Dateien aus der Sicherung wiederherstellen
  3. Starten Sie WinMerge, indem Sie das Archiv auf der Festplatte mit der Sicherungskopie auf dem NAS (über das lokale Netzwerk) vergleichen.
  4. Wenn keine Beschädigung erkannt wurde, fahren Sie mit Schritt 3 fort.

Schritt 3 dauert mehrere Stunden (4-6), außerdem können nach mehreren Iterationen Beschädigungen festgestellt werden. Wahrscheinlich passiert es, wenn ich versuche, den Computer während des Vergleichs zu verwenden – ich bin nicht sicher.

Meine aktuelle Theorie:es könnte mit dem RAM zusammenhängen (auch wenn auf beschädigte Dateien nie im Schreibmodus zugegriffen wurde. Vielleicht führt Windows während eines internen Dateiindizierungsvorgangs eine transparente Neuzuweisung komprimierter NTFS-Inhalte durch ... keine Ahnung).

  • Einzelnes DDR-Modul entfernt: Das Problem konnte nach 3 Tagen Dauertest nicht reproduziert werden.
  • „Gutes“ Modul durch zuvor extrahiertes, möglicherweise „schlechtes“ Modul ersetzt: Problem konnte innerhalb eines Tages reproduziert werden. (MemTest86+ hat jedoch unmittelbar nach Auftreten des Problems keine Probleme mit dem RAM festgestellt – hat 6 Durchläufe erweiterter Tests durchgeführt)
  • Habe das „fehlerhafte“ Modul installiert gelassen, aber die RAM-Frequenz im BIOS von 1600 MHz auf 1300 MHz geändert. Ich führe bereits seit drei Tagen Vergleichstests durch, bisher konnte kein Problem reproduziert werden.

Hardware

Software

  • Windows 8.1 64 Bit (mit allen aktuellen Updates)
  • Dateisystem: NTFS komprimiert

Fragen

Kann mir jemand unter Berücksichtigung der oben genannten Punkte einen Rat geben oder meine Annahmen bestätigen:

  1. Hat jemand eine Idee, was der Grund sein könnte? Oder was kann ich sonst noch tun, um den Grund herauszufinden? Gibt es andere Testtools, die gründliche Tests durchführen können (z. B. Speichertests bei intensiver Nutzung des Videospeichers usw.)?

  2. Wenn meine aktuelle Annahme richtig ist (wahrscheinlich ist mein KINGSTON RAM-Modell nicht vollständig mit dem Motherboard kompatibel oder ein RAM-Modul ist irgendwie defekt und funktioniert bei 1600 MHz nicht richtig), mit welchen Testtools kann ich das beweisen? (MemTest86+ und einige andere haben keine Probleme festgestellt)

  3. Heute ist mir auch aufgefallen: Wenn ich im BIOS die Speichertaktung von AUTO auf MANUAL umstelle, unterscheiden sich die Standardwerte von den in den KINGSTON-Spezifikationen empfohlenen Werten: tRAS sollte >33,75 sein (im BIOS ist der Standardwert 27), tRFC sollte >260 sein (im BIOS ist der Standardwert 208, aber das Maximum ist 255, was immer noch weniger ist als die empfohlenen 260 ns). Könnte das theoretisch ein Grund sein? (werde auch manuelle Taktungen testen, aber das würde einige Zeit dauern).

Antwort1

Also, nach zwei Monaten und einigen weiteren Experimenten. :-)

kurz und knapp;

Das Problem wurde durch Deaktivieren der NTFS-Komprimierung gelöst.

DerWurzelUrsache ist noch unbekannt: Ich glaube, es kann entweder an der Festplatte, dem Speicher oder der Hauptplatine liegen. Oder durch Implementierung der NTFS-Komprimierung.

Lange Version

Ich habe mit RAM-Timings gespielt – hat nicht geholfen.

Habe den Herstellersupport mit Fragen zu bekannten Hardwareproblemen kontaktiert. RAM- und Motherboard-Hersteller haben keine Informationen zu bekannten Problemen. Der HDD-Hersteller (Toshiba) hat nicht geantwortet :-)

Nachdem ich die Komprimierung deaktiviert hatte, trat das Problem nach fast 2 Monaten normaler Computernutzung nicht mehr auf. Eine andere Beispielkopie, die im komprimierten Ordner gespeichert war, wurde dagegen mehrfach beschädigt/wiederhergestellt.

Möglicherweise liegt ein Fehler bei der Implementierung des in Windows 8.1 verwendeten Komprimierungsalgorithmus vor.

Ich habe es auch mit der Windows 10-Version getestet – komprimierte Dateien werden während eines Tages im Leerlauf beschädigt.

Antwort2

Haben Sie versucht, das SATA-Datenkabel auszutauschen? Wenn Sie ein Ersatzkabel haben, probieren Sie es aus. Versuchen Sie, eines zu finden, das keine Metallklammern an den Enden hat. Ich hatte damit viel Ärger.

Antwort3

Führen Sie CHKDSK C: /F in der Eingabeaufforderung (Administratormodus) aus (beachten Sie die Leerzeichen im Befehl) und prüfen Sie, ob dies hilft. Check Disk scannt und behebt Fehler während des Neustarts und bevor Windows selbst geladen wird.

verwandte Informationen