Zwei Dateien wurden zeitnah von unterschiedlichen Programmen falsch gespeichert

[kleiner_hacker]

Hallo liebe Forengemeinde,
ich habe heute morgen ein für mich äußerst ungewöhnliches Problem erlebt.
Ich habe zwei verschiedene Dateien (wurde parallel dran gearbeitet) aus zwei verschiedenen Programmen heraus abgespeichert. Es handelte sich dabei um ein Latex-Dokument in TexMaker und eine G-Code-Maschinensteuerung (ist wie eine .txt) in Notepad++. Da das Problem aus zwei unterschiedlichen Programmen aufgetreten ist, kann ein Softwarebug ausgeschlossen werden.
Ich habe den Pc heruntergefahren und später neu gestartet. Nun hatten die Dateien nicht mehr ihren vorgesehenen Inhalt: Beide Dateien hatten noch eine passende Dateigröße (ein paar hundert Kb, ist ja nur ASCII-Text), in Notepad++ wurde mir allerdings in einem Fall durchgehend das ASCII-Zeichen NULL angezeigt, im anderen Fall fing der Text an, dann kamen viele NULL und dann setzte der Text kurz vor Ende wieder ein.
Die Daten sind mir egal, da war nur eine Stunde Arbeit verloren.
Woran kann dies aber liegen? Ich habe die Arbeit vorsichtshalber auf einem anderen PC fortgesetzt.

Die Smart-Werte der SSD sind fehlerfrei, ich habe mal mit H2wtest ein paar GB geschrieben und wieder gelesen, was auch fehlerfrei war. Da die SSD in Benutzung ist, kann ich ohne konkreten Verdacht leider nicht mal eben die komplette Kapazität vollschreiben, um zu Überprüfen, ob ein anderer Sektor defekt ist (Aber die Smart-Werte sind OK?).
Bei einem Defekt des Sata-Controller würde ich eigentlich Datensalat, aber nicht geordnete Nullen erwarten (hatte ich in einem anderen PC auch schon mal wg. Kondensatorpest - da ist vor allem erst einmal Windows abgestürzt, weil es Probleme beim Schreiben hatte, bevor ich Dateien nicht mehr lesen konnte).

Habt ihr Vorschläge woran dies liegen könnte?
Meine Google-Suche ist leider nicht sehr ergiebig, wenn man nach "Datei mit Nullen gespeichert" sucht, kommt vor allem raus, wie man per Kommandozeile große leere Dateien erstellt und bei "corrupt save" geht es meistens um Spielstände.

Danke für jegliche Hilfe!

 

[rg88]

NULL bedutet gar nichts. Das heißt nur, dass n++ die Daten nicht lesen kann und deshalb NULL-Zeichen ausgibt. Das hat nichts mit geordneten NULLen zu tun

RAM mal getestet?
Virenscanner mal deinstalliert?

 

[kleiner_hacker]

Das wäre ja kein besonders gutes Design wenn bei Lesefehlern nicht Error sondern, eine sinnvolle Ausgabe angezeigt wird.
Womit kann ich denn die Dateien wirklich byteweise lesen? Solange Windows eine Datei mit Dateinamen und Länge erkennt muss man ja auch den Datenmüll darin auslesen können. Ich habe die Dateien mal durch ein paar Hex-Editoren geschickt, die zeigen auch alle durchgehen 00 an.
Memtest zeigt im ersten Durchlauf keine Probleme, würde mich auch wundern, da ich ja keine Systemabstürze habe.
Ob es etwas bringt den Virenscanner abzustellen kann ich nicht nachvollziehen, denn mir ist noch unklar, wie ich das Problem reproduzieren kann.

 

[Holt]

Was für HW hast Du genau? Wenn es keine Workstation oder Server HW mit ECC RAM Unterstützung ist, dann würde ich mal das RAM richtig testen, damit RAM Fehler auszuschließen sind. Dazu stellt man alles im BIOS so ein, wie es auch nachher läuft, also keine OC-Tweaktools unter Windows verwenden! Dann die iso / img von Memtest86+ von CD oder USB-Stick booten, denn man kann nicht unter Windows sinnvoll das RAM testen. Es sollten erst alle Riegel zusammen und unverändert wie sie jetzt verbaut sind getestet und min. 6 PASS abgewartet werden und es darf dabei kein einziger Fehler auftreten, also am Besten über Nacht laufen lassen. RAM-Fehler können die unmöglichsten Probleme erzeugen.

Poste bitte auch mal den Screenshot von CrystalDiskInfo (die Portable Standard Edition reicht und ist frei von Werbung, einfach auf den Link der Portable klicken, warten bis die zip Datein automatisch downgeloaded wird, die zip speichern und irgendwohin komplett entpacken, dann DiskInfo.exe dort starten) für die SSD, ziehe aber bitte das Fenster soweit auf, dass alle Attribute und auch die Rohwerte vollständig sichtbar sind.

 

[Smurfy1982]

Völlig verrückte These:

Beginnt/Endet das NULL Chaos an 512 oder 4096 Bytegrenzen? Wenn ja, hat evtl. irgendwas die SSD dazu veranlasst, auf die betroffenen Bereiche TRIM loszulassen.

Oder spinne ich mir da was zusammen und das ist nicht möglich?

 

[Holt]

Das ist nicht möglich, aber wenn die SSD in einem mdraid unter Linux betrieben wird und Queued TRIM unterstützt, dann könnte es sein, da der Kernal da einen Bug hatte, der wurde aber inzwischen gefixt. Notebook++ deutet aber eher auf Windows hin und am wahrscheinlichsten ist Datenverlust beim Desktop durch RAM Fehler, wieso meinst Du ist die Unterstützung von ECC RAM im Pofibereich unverzichtbar? Die wissen eben um die Häufigkeit von RAM Fehlern und das man sich damit die unmöglichsten Probleme einhandeln kann und sind daher im Gegensatz zum gewöhnlichen Heimanwender bereit etwas mehr Geld in die Hand zu nehmen um das zu vermeiden.

Daher meine Aufforderung das RAM zu testen, damit können zumindest hard-erros, also Fehler die bei bestimmten Bitkombinationen auftreten, erkannt werden. Gegen soft-errors, also vor allem allem aufgrund von Strahlung spontan kippende Bits (die finden Memtest86+ allenfalls mal per Zufall), hilft sowieso immer nur ECC RAM und natürlich ein System welches das auch unterstützt. Außerdem die Bitten zu dem Screenshot mit den S.M.A.R.T. Werten, dann sehen wir um welche SSD es sich handelt und wie deren Zustand ist.

 

[kleiner_hacker]

Guten Abend,
ich antworte erst jetzt, weil ja erstmal memtest noch den ganzen Tag lang laufen musste.
Es erscheint logisch, dass memtest für statistisch auftretende Fehler mehr als einmal laufen sollte.
Memtest ist jetzt allerdings 9 mal fehlerfrei durchgelaufen, so dass der RAM wohl einwandfrei funktioniert (schade, dass wäre leicht behebbar gewesen).
Die Smart-Werte der Festplatte sind wie schon im ersten Post erwähnt einwandfrei (abgesehen davon, dass die Betriebsstunden durch einen bekannten Bug unter Windows vollkommen falsch sind, und dass ich durch einen Tag Memtest gerade die höchste Temperatur überhaupt erreicht habe).


Gegen Smurfys Theorie spricht, dass im Dokument, welches zum Teil noch lesbar ist, 1361 NULLs sind, also kein Vielfaches von 512.

Es geht um ein HP Probook 6470b mit nachträglich eingebauter SSD (siehe Screenshot) und aufgerüstetem zweiten Riegel Arbeitsspeicher (von einem anderen Hersteller, obwohl bei HP im BizSupport für teures Geld ein "Original Ersatzteil" für exakt dieses Notebook bestellt wurde). Ich habe diese Angabe im ersten Post weggelassen, da sich meine Frage ja mehr darauf bezieht, welches Bauteil überhaupt solch ein Verhalten erzeugen kann, und nicht, ob ein bestimmtes Teil von einem speziellen Hersteller bekannt für Probleme ist.
ECC Ram wird nicht verwendet, Linux schon, aber eben nicht zum Fehlerzeitpunkt.

Ich werde jetzt mal versuchen, ob ich den Fehler reproduzieren kann.

 

[rg88]

Sind SSD-Firmware, Notebook-BIOS und der Chipsatztreiber aktuell? Hatten mit den ProBooks schon diverse Probleme nach Umrüstungen.

 

[Holt]

rg88, die FW ist aktuell, das könntest Du anhand der Angaben von CDI doch wohl selbst prüfen.

Memtest ist jetzt allerdings 9 mal fehlerfrei durchgelaufen, so dass der RAM wohl einwandfrei funktioniert (schade, dass wäre leicht behebbar gewesen).

Ja, soft-errors, also spontan kippende Bits, können natürlich trotzdem auftreten, die findet memtest86+ eben kaum, weil es die Daten ja schreibt und sofort wieder ausliest, da bleibt wenig Zeit für so einen soft-error.

abgesehen davon, dass die Betriebsstunden durch einen bekannten Bug unter Windows vollkommen falsch sind

Dann ist LPM aktiv, die SSD zählt nur die Stunden in denen der SATA Link auch aktiv ist. Hier ein Link zu einer Anleitung wie man LPM bei Windows auch im Ausgewogenen Energiesparplan einstellbar machen kann, einfach auf Active stellen, dann bleibt der SATA Link aktiv und LPM ist deaktiviert. Danach sollten die Betriebstunden "stimmen".

ECC Ram wird nicht verwendet, Linux schon, aber eben nicht zum Fehlerzeitpunkt.

Hast Di ein Dual-Boot System mit Win 8 oder höher und Linux? Dann könnte da das Problem liegen, da Windows seid Win 8 per Default nicht mehr richtig runterfährt, sondern eine Hybriden Schlafmodus verwendet. Wenn dann Dateien noch im Schreibcache stehen, werden diese u.U. nicht zurückgeschrieben. Du solltest vermeiden den zu verwenden und Windows zwingen richtig runterzufahren. Dann sehe ich 107 unerwartete Spannungsabfälle, die M550 hat zwar Stützkondensatoren aber nur eine kleine Client Lösung für Data-at-rest und keine volle Enterprise Lösuing die auch User-Daten im Schreibcache schützt. Da könnte die Ursache auch liegen.

 

[kleiner_hacker]

Guten Abend,
weiterhin vielen Dank für eure Hilfe.

Die Treiber sind alle auf aktuellem Stand.
Auf dem Notebook sind Win 7 Pro 64 und Ubuntu 14.04 Dual installiert, zwischen Datei speichern und abrufen wurde Ubuntu auch nicht benutzt; unter Win 7 gibt es diesen problematischen Modus des Herunterfahrens noch nicht.
Die Unexpected Power Loss Events kommen wohl daher, dass ich den PC per Power Button schon vor Grub, oder gerade in Grub wieder ausgeschaltet habe. Ich könnte mir vorstellen, dass an dieser Stelle noch keine korrekten Abschaltsignale an die SSD gesendet werden. Ich quäle mein Notebook nicht gerne, habe aber einmal ca. 30 mal am Stück bis zu Grub gestartet und dann wieder ausgemacht, da ich Startprobleme wegen eines defekten DVD-Laufwerks vermutet habe und den Fehler mit ausgebautem Laufwerk verifizieren konnte.
Das Bits spontan ihren Zustand ändern ist eine coole Sache, ich würde in diesem ziemlich unwahrscheinlichen Fall aber vermuten, dass sie es dann nicht gleich in großen Mengen tun, sondern nur ein einziges fehlerhaft ist, was dann meiner Laienmeinung nach eher zu einem Systemabsturz führt, und nicht dazu, dass geordnet Nullen geschrieben werden.

Ich habe es noch nicht geschafft, den Fehler wieder zu reproduzieren (das wäre ja dann doch eher ein bug).
Vielleicht kann ich den Fehler ja einfach abhaken und er tritt nie wieder auf.

 

[Holt]

Poste mal einen Screenshot von Drive Controller Info.

War das mit dem 30mal ausschalten nach dem Schreiben der Daten und bevor sie defekt waren? Hast Du das Fillesystem mal mit chkdsk überprüft oder hat Windows diese Überprüfung beim Booten durchgeführt oder durchführen wollen? Wenn es Fehler im Filesystem gibt und die Cluster auf denen der Dateien stehen mehr als einer Datei zugeordnet sind und die anderen Datei gelöscht wird, dann führt TRIM natürlich bei einer SSD dazu, dass die Daten dort dann genullt sind.

 

[kleiner_hacker]

Die Dateien wurden am Dienstag morgen das erste mal gespeichert, dann wurde einmal neu gestartet und sie waren weg.
Das DVD-Laufwerk war schon vor längerer Zeit defekt, ich gehe davon aus, dass es gigantische Mengen an Fehlermeldungen über den SATA-Port gesendet hat, und damit entweder das BIOS überfordert hat, oder die Leitung derart verstopft, dass der PC mehrere Minuten gebraucht hat, bis er am Splash-Screen vorbei gekommen ist. Das war ein LG-Laufwerk; ich glaube, dass die sich am Lebensende alle so verhalten (basierend auf meiner Stichprobenmenge von 2 ) Ich hatte auch in einem anderen PC schon ein LG-Laufwerk, welches defekt war und in Windows-Berichten mehrfach pro Sekunde Fehlermeldungen erzeugt hat. Laufwerke von anderen Herstellern sind mir noch nicht kaputt gegangen, so dass ich nicht wirklich beurteilen kann, ob das an LG liegt. Beim HP habe ich damals die Fehlerprotokolle nicht konsultiert.
Ende des kleinen Exkurses...

chkdsk findet auch keine Fehler.
TRIM-Fehler erscheinen mir mittlerweile auch am ehesten logisch. Jedoch fällt mir leider auch kein Grund ein, was zu einer Fehlfunktion geführt haben könnte, da die SSD und ihr Dateisystem ja eigentlich kerngesund sind und kein Bug zu Crucial-SSDs unter Windows bekannt ist.

 

[Holt]

Wenn zwischendurch kein Linx gebootet wurde, dann ist das Risiko eines Fehler beim TRIM unter Linux (die lange Blacklist bei Linux lässt mich eher auf einen (weiteren) Bug im Kernal tippen, als dass so viele SSD Hersteller Fehler gemacht habe, deaktiviere TRIM unter Linux lieber) natürlich nicht gegenen. Das defekt optische LW könnte mit Übertragungsfehlern schon für Ärger sorgen, bei Übertragungswiederholungen offenbar den ganzen SATA Host Controller blokieren und wenn dann gerade versucht wurde den Inhalt des Schreibcaches von Windows auf die SSD zu schreiben und das nicht zuende erfolgt, könnte es die Ursache sein. Wurde normal neu gestartet oder irgendwie Gewalt angewendet?

 

[kleiner_hacker]

Das Laufwerk habe ich gegen ein Neues eines anderen Herstellers ausgetauscht, das ist auch schon etwas längere Zeit her. Ich habe nur die UPL Events erklären wollen, damit klar ist, dass ich nicht regelmäßig den Akku im laufenden Betrieb entferne.

Ich habe den Fehler gefunden. Dank deiner Frage ob wirklich normal neu gestartet wurde, habe ich noch mal ganz genau nachgedacht und nachgestellt. Ich habe mich sonst gar nicht mehr erinnert, dass ich das getan habe. Schande über mich!
Ich habe anscheinend zwischendurch gespeichert, aber nicht den letzten Stand und dann beim Herunterfahren auf "Trotzdem herunterfahren" geklickt, als irgendein meiner Meinung nach sinnfreier Windows-Prozess (also nicht so etwas offensichtliches wie N++) das Herunterfahren verhindert hat.
Ich konnte das gerade nachstellen, indem ich eine Datei mit Inhalt gespeichert habe, dann etwas hinzugefügt habe und nicht gespeichert, sondern direkt per Power-Button hart runtergefahren habe. Voila - die Datei ist voller NULLs.

Man klickt ja oft "Trotzdem herunterfahren" an, weil man ja (eigentlich) selbst gespeichert hat, und nur Windows-Prozesse stören, von denen man denkt, dass es nicht schadet sie zu killen.
Es ist mir unklar, wieso ich mich daran nicht mehr erinnern konnte und eine halbe Woche Forenunterstützung gebraucht habe.
Die Forenunterstützung war insgesamt gesehen dann allerdings ja auch sehr hilfreich; vielen Dank!

Noch einmal: Schande über mich.
Es wird immer zuerst ein Problem bei der Soft- oder Hardware vermutet, dabei sitzt das Problem davor.

 

[Holt]

Ist das defekte optische LW noch verbaut? Dann dürfte das Problem speziell bei Dir existieren weil das defekte LW die Kommunikation stört und daher nicht geschrieben werden kann, denn killst Du den Service der versucht die Dateien zu schreiben und schon ist es passiert. Offenbar nullt oder trimmt Windows LBAs womöglich auch noch bevor sie geschrieben werden, was natürlich unsinnig ist. Baue das optische LW mal aus und schau ob es dann auch noch auftritt.

 

[kleiner_hacker]

Wie schon geschrieben: reiner Bedienerfehler.
Das Laufwerk ist nicht mehr verbaut.
Es ist nicht unbedingt gutes Design, wie N++ sich in diesem Fall verhält. Ich würde entweder erwarten, dass es die Datei in Ruhe lässt und nicht verändert, oder, dass es an anderer Stelle die seit dem letzten Speichern vorgenommenen Änderungen sichert (so wie Word das z.B. macht).
Anscheinend versucht N++ noch etwas zu schreiben, wird damit aber nicht mehr fertig. Ein Problem beim Controller sehe ich darin nicht.

Ergänzung (5. Dezember 2015)

Addendum:
Ich habe den Fehler gerade auch auf einem anderen PC erfolgreich hervorrufen können, liegt also nicht an irgendwelchen Controllern.

 

[Holt]

Dann liegt es wohl klar an N++, melden den Bug dort mal und bis dahin solltest Du N++ eben vorher schließen und dann erst Windows runterfahren.

 

[kleiner_hacker]

Bug ist gemeldet:
https://github.com/notepad-plus-plus/notepad-plus-plus/issues/1227