Massiver Datenverlust auf SSD (back-up vorhanden) - Ursachenanalyse win7 event logs?

Xon2

Lt. Junior Grade
Registriert
Feb. 2004
Beiträge
260
Guten Abend Leute,

mich hats Anfang letzer Woche erwischt. Der Rechner lief im idle unbeobachtet für etwa 1.5h und als ich zurück kam, befand er sich im Bootprozess mit der Fehlermeldung, das nicht gestartet werden kann, da der ntoskrnl.exe beschädigt oder nicht vorhanden sei. Habe zuerst gedacht, die boot partion der ssd (win7 bitlocker verschlüsselt) wäre vielleicht beschädigt. Die üblichen Reparaturversuche des BCDs per 'command promt' Konsole der win7 DVD Reparatur Optionen und letztere selbst, brachten nichts. Hab die SSD dann mal ausgebaut und als externes Laufwerk am laptop angeschaut. Und das sah hart aus. Die 120gb Samsung 830er hatte vorher noch etwa 8gb freien Speicherplatz. Jetzt sind dort noch 57gb frei. Daten sind durch die Bank verloren gegangen, von Ordner mit Dokumenten, Spielen und auch Windows System Dateien (deshalb konnte das System wohl auch nicht mehr booten). Wie im Titel bereits erwaehnt; ich hab immer brav per Paragon back-ups alle drei Tage erstellen lassen, das letzte glücklicherweise wenige Stunden davor. Ich habe das aktuellste back-up testweise auf einer anderen Festplatte schon mal eingespielt und alles ist wieder da.

Nun, ich würde schon gerne wissen was da vorgefallen ist, schon allein um zu schauen ob ich irgenein Programm/Dienst oder sontst was laufen habe, der mir sowas nochmal bescheren könnte. Soweit ich weiß, gabs zur fraglichen Zeit keinen Stromausfall und auch keine geflogenen Sicherungen. Der PC idelte vor sich hin, mir fiele jetzt nix ein, was einen etwaigen Crash sammt Datenverlust verursacht haben könnte. Habe regelmässig per Avast und Malwarebytes mein System gescannt und keinen Anlaß, einen Virus zu vermuten. Auch jetzt finden die zwei Antivirenprogramme auf der SSD nichts (hängt derzeit als Zweitlaufwerk eingebunden am Rechner). Samsung Magician v4.6 zeigt die SSD als unauffällig und in 'good health' an (total bytes written 32.46TB).

1.) Was könnte die Ursache für die ganze Nummer sein bzw. welche Umstände können zu so einem massiven Datenverlust führen? (Henne-Ei-Problem --- ist das System, warum auch immer, abgestützt und dabei kam es zum Datenverlust, oder kam es anderweitig zum Datenverlust, und irgendwie wurden dabei (wie auch immer das möglich sein soll) system relevante Datein gelöscht und das verursachte den Absturz? Übrigens, die besagte ntoskrnl.exe ist im system32 Ordner noch vorhanden.

2.) Gibt es irgendwelche aussagekräftigen Windows logs? Ich hab geschaut, die windows 7 event logs sind noch vorhaden. Welche könnten für mein Problem relevante infos enthalten? Gibt es sonst noch tools die hier erhellend sein könnten?

3.) Wie überprüfe ich die Samsung 830er SSD auf Fehler/Schäden? Wie gesgat, Samsung Magician zeigt sie mir als in Ordnung an, aber sollte ich da noch twas gründlicher schürfen?

Jedenfalls war und bin ich heilfroh, diese automatischen back-ups sammt 3facher Sicherung eingerichtet zu haben.

Würde jetzt halt gern verstehen, was da vorgefallen sein könnte.

Best Grüße
 
Wenn das Dateisystem beschädigt wurde, dann bügelt Checkdisk gerne mal einfach alles weg, was an Daten ungültig ist. Insofern würde das die "Verlust" erklären.
 
Infektion ist unwahrscheinlich. Was soll es einer Schadsoftware bringen Daten wahllos zu löschen? Warum sollte jemand so etwas entwickeln? Erpressungtrojaner wären da viel sinnvoller.
 
jo hatte vergessen zu erwähnen: der Ordner ''found.000'' wurde angelegt, enthält chk Ordner/files von knapp 9gb.
 
ja, das sind die Sachen die checkdisk noch gefunden hat aber nicht mehr richtig zuordnen kann.
es ist also von einem defekte des Dateisystems auszugehen. Aber ob der nun Hardware- oder Software-bedingt ist, kann man beim bisherigen Informationsstand nicht wirklich sagen.

Mach mal das mit CDiskInfo und schau in der Ereignisanzeige nach, was da drin steht an Disk-Fehlern. Falls du ins System kommen solltest
 
CDinfo.png
 
Das ist jetzt aber nur die SSD. Bei deinem Laufwerk C, wo wohl das Windows drauf ist, steht groß VORSICHT dort. Aber das Fenster hast du gerade nicht hochgeladen
 
Samsung gibt ja eine mittlere Lebensdauer und maximal transferiertes Datenvolumen je nach SSD Typ an.
Da es sich um statistische (gemittelte) Daten handelt, ist zudem nicht auszuschließen, dass in Abhängigkeit von der Betriebstemperatur sich die Lebensdauer z.B. bei höheren Betriebstemperaturen auch noch verkürzt.
Manchmal kann aber auch ein Absturz (Treiber, OC etc.?) während eines (physischen) Schreibzugriffs solche Probleme verursachen.
Wenn die HD daran eventuell beteiligt ist kann das natürlich auch noch Probleme bereiten, da es sich hierbei um elektro-mechanisches Gerät handelt...
 
Zuletzt bearbeitet:
@rg88 Das ist besagte hdd auf die ich mein back-up testweise eingespielt habe, um den Rechner erstmal wieder nutzen zu können. Zu deim Zeitpunkt diente diese als externes Datengrab und hat sonst nix mit dem PC zu tun. Die SSD ist die eigentliche Systemplatte und bis vor dem Crash/Verlust Laufwerk C gewesen (und soll es auch wieder werden).
 
Achso, das hat mich jetzt verwirrt. Dann ist ja alles klar.
Was sagt nun die Ereignisanzeige?
 
Also die CrystalDiskInfo Werte sehen unbedenklich aus?

Bezüglich der Ereignisprotokolle bin ich nicht sicher welches mir hier hilft. Die finden sich ja als files unter C:\Windows\System32\winevt\Logs. Da kann ich mir also die einzelnen logs der orginalen win7 Installation auf der SSD bis zum Absturz anschauen. Das sind insgesamt 145 Datein. Welches ist da relevant?

Auf der HDD auf die ich das back-up eingespielt habe und die jetzt als C: fungiert und von der ich im Moment aus boote/den PC hochfahre hat die logs bis ein paar stunden vor dem Vorfall und dann beginnend ab Donnerstag Abend als ich es eingespielt hatte.
 
Schau erstmal in die Logs die du direkt über die Ereignisanzeige abrufen kannst. Meist passiert sowas nicht spontan sondern baut sich auf, so dass dort vll schon die Fehlerursache erkennbar ist.
 
Früher ja, aber sowas macht heutzutage niemand mehr. Es ist viel aufwändiger geworden und warum soll sich jemand für sowas noch Mühe machen...

Es würde auch keinen Sinn geben bei der nicht wirklich logischen Art des Datenverlusts. Das spricht eher für einen Fehler im Dateisystem und anschließendem Checkdisk-Rundumschlag. Scheiß auf Daten, Hauptsache das Dateisystem wieder gerade biegen lautet da gerne die Devise.

Wobei auch noch als Vorgeschichte interessant wäre, ob das Windows sauber auf die SSD installiert wurde oder da einfach eine vorhandene Installation von einer alten HDD übernommen und schlicht quick-and-dirty rüberkopiert wurde.
 
Habe ich frisch 2012 installiert und lief bisher problemlos.
 
Ich hatte gestern ein ähnlich unerklärliches Problem mit Windows 10 auf einer SSHD von Seagate: dort konnte von einem Start auf den anderen (kein Absturz) die Registry nicht mehr gelesen werden, der Rest der Daten war jedoch in Ordnung. Nach dem Wiederherstellen der Registry läuft das System wieder. Grundsätzlich sind bei NAND und SMR Festplatten Datenverluste möglich, die bei früheren HDDs im Bereich des Unmöglichen lagen. Die Samsung 830 ist jetzt nicht gerade für Firmware-Fehler bekannt und meine 256 GB Version läuft schon seit Jahren ohne jeglichen Datenverlust. Bei der Komplexität der Firmware ist es jedoch sehr wahrscheinlich, dass diese Bugs enthält. Für einen solchen Datenverlust reichen bereits wenige Byte an verlorenen Daten, falls sich diese in den Strukturen des Dateisystems befinden (und können z.B. auch durch fehlenden ECC RAM verursacht werden, manche Dateisysteme wie ZFS sind sehr empfindlich auf fehlerhaften RAM). Ich würde das Backup zurückspielen und die SSD noch eine Zeit beobachten: passiert es noch einmal, dann ist wohl wirklich etwas defekt, ansonsten würde ich von einem Bug ausgehen.
 
Wie gesagt, es gibt 145 evtx Datein im C:\Windows\System32\winevt\Logs Ordner. Wenn ich die öffne kann ich sie unter dem Reiter 'Saved Logs' anschauen. Das wären dann die orginal Logs bis zum Zeitpunkt des Crashs oder was auch immer da abging. Hab da jetzt bisher noch nichts auffälliges gefunden. Hat jemand ne Ahnung welche von diesen logs wichtig sind?

Aber; das 'System' log zeigt als letztes event das Starten des Defragmentierungsdienstes an. Das wäre ja ein Kandidat. Bin mir eigentlich sicher gewesen, die Degragmentierung nur händisch und nicht automatisch auf der sonst im System verbauten HDD ausgeführt zu haben. Nicht auf der SSD. Für die SSD zeigt Windows an, diese noch nie defragmentiert zu haben. Allerdings ist nicht ganz klar ob die Einstellungen dort jetzt denen von der Orginal Installation entsprechen.

Kann ich irgendwo mehr zu dem angeblichen Defragmentierungsvorgang sehen? Gibts da speziellere logs?
 
Zuletzt bearbeitet:
Xon2 schrieb:
Also die CrystalDiskInfo Werte sehen unbedenklich aus?
Ja die Werte sind bestens, die Ursache würde ich nicht bei der SSD sondern dem Rechner vermuten, zumal die SSD ja auch immer noch tadellos funktioniert und nur die Datenstrukturen darauf korrupt geworden sind. Hier kann wenn man Pech hat, schon ein RAM Fehler genügen aufgrund dessen die Metadaten des Filesystems dann korrupt auf die SSD geschrieben wurden. Consumer HW ist eben vor allem auf die Kosten hin optimiert und es genügt wenn sie meistens bei den meisten Usern problemlos funktioniert, bei Server- und Workstation HW ist dies anderes, die ist im Gegensatz zu Desktop-HW auch für Dauerbetrieb und Dauerlast ausgelegt, daher hat man dort auch in aller Regel ECC RAM und die nötige Unterstützung dafür, Laufwerke die für Dauerbetrieb und höhere Workloads ausgelegt sind, SSDs die eine Full Power-Loss Protection und Internal Data Path Protection haben, etc.
 
Zurück
Oben