Kaputte NTFS Partition nach BSOD - nicht mal Boot Media startet

[Domml]

Hallo liebes CB-Forum,

ich wende mich in voller Verzweiflung an euch. Leider als Man-in-the-Middle, weil der zu Helfende leider absolut nicht technisch bewandert ist.

Zunächst, sein System:
CPU: AMD Ryzen 5 2600
GPU: ASUS TUF 3070 Ti (erst seit 15.03.2022 eingebaut)
Mainboard: MSI B450 Gaming Pro Carbon AC
RAM: 2x 8GB G.Skill Fortis 2400 MHz CL15-15-15-39 (liefen in XMP-1)
SSD: 250GB Samsung 860 Evo (SATA)
HDD: 2TB WD Blue
OS: Windows 10 Version 21H2


Folgendes ist das Problem:
Mein Kumpel war in einer Zoom-Vorlesung und beim Verlassen des Meetings bekam er einen "REFERENCE_BY_POINTER" BSOD (Bug Check Code 0x18, ausgelöst vom ntoskrnl.exe). Soweit so normal, Bluescreens kommen mal vor, er bat mich um Hilfe mir das anzugucken.
Nach dem Bluescreen hatte sein Rechner starke Lags: Normale Anwendungen hingen, Audio war am spinnen und abgehakt, an Spielen war nicht mal zu denken.
Ich habe mir sein Dumpfile angeguckt und auch mit Google bin ich nicht schlauer geworden (klassischer "kann an alles liegen"-Fehler), also habe ich zur Driver Verifier Methode gegriffen. Kurz gesagt: Man testet alle möglichen Treiberfunktionen und "hat als Ziel den PC zu crashen", um aussagefähigere Dumps zu bekommen. Ein wenig darüber zu lesen gibt es in den Microsoft Docs oder auf Microsoft Answers (diesen Leitfaden habe ich auch verfolgt).
In der Vergangenheit konnte ich damit schon mal einen bösen Soundtreiber auf dem PC meiner Freundin ausmachen, der ihr Bluescreens beschert hat.

Nicht so sehr hier leider. Sein PC ist in der Tat in einen BSOD gecrasht, direkt beim Hochfahren: DRIVER_VERIFIED_DETECTED_VIOLATION - das war zu erwarten. Freudig hoffend auf einen aussagefähigen Dump habe ich meinen Kumpel dazu angehalten, in den abgesicherten Modus zu booten und den Driver Verifier auszuschalten oder einfach den zuvor erstellen Wiederherstellungspunkt zurückzusichern.
Da das System überhaupt nicht mehr hochgefahren ist, wollten wir dies über WinRE (2x das Hochfahren von Windows mit Gewalt unterbrechen) machen. Der PC hat dann beim 3. mal Hochfahren auch wunderbar angefangen, WinRE zu starten - um dann mit einem "PAGE_FAULT_IN_NONPAGED_AREA" BSOD zu crashen ohne überhaupt etwas anzuzeigen außer einem blauen Hintergrund.

Mittlerweile springt der Rechner bei jedem Neustart automatisch in die Reperatur, crasht mit BSOD und startet dann neu..

Also haben wir einen Windows 10 Stick frisch erstellt und von diesem gebootet mit der Intention den Wiederherstellungspunkt zu benutzen oder ggf. chkdsk und Ähnliches loszufeuern. Soweit schien alles normal, Lade-Punkte und dann diese violette Hintergrundfarbe - doch leider kein Installationsfenster, sondern der allerserbe nonpaged area BSOD.
Nicht mal Boot-Medien starten mehr?? Das muss am RAM liegen, dachte ich mir.

Also Memtest86 ausgepackt und fleißig mit 4 vollen Passes ohne irgendwelche Fehler die Sticks getestet.

Dann ist mir aufgefallen, dass der nonpaged area BSOD immer von "ntfs.sys" ausgelöst wird. Also habe ich einen kleinen SLAX (leichtgewichtiges Debian based live Linux) Stick fertig gemacht und davon gebootet.
Das hat wunderbar geklappt, dem RAM scheint es also tatsächlich gut zu gehen... aber GParted hat tatsächlich ein Problem mit der Systemplatte erkannt (bitte entschuldigt die abartig schlechte Qualität, curved UWQHD monitor + keine Grafiktreiber sieht unschön aus - man bekommt das Fenster auch nicht kleiner oder ganz ins Bild):

Soweit so gut, auf der Boot-Platte hat es also die Partition sdc3 zerschossen, eine "Microsoft Reserved Partition" - kennt man ja auch so.. Wiederherstellung > Boot > Microsoft Reserved > Daten..

Was mich jetzt aber komplett verwirrt ist die fünfte Partition und der nicht allozierte Speicher. Eigentlich sollte es nur eine Daten-Partition geben, eine klassische Installation eben einfach.

Ntfsfix haben wir auch versucht, der spuckt bei der Platte und allen Partitionen einfach nur "ntfs signature is missing" aus und hilft leider auch nicht weiter.. aber wenigstens mal ein ordentlicher Fehler.

Testdisk ist mir ehrlich gesagt etwas zu komplex, dafür bin ich zu wenig in der Materie.. ich bin am Ende des Tages Netzwerkstack-Entwickler und kein Datenretter
Ich habe aber mit enger Anlehnung an Tutorials das hier in checkdisk finden können:

Und das sieht für mich absolut komisch aus. Die erste und zweite Partition passen noch, aber aus den 4 MS Data mit teilweise überschneidenden Start- und Endadressen werde ich nicht schlau. Bei der zweiten Partition von unten sagt er mir "Can't open filesystem. Filesystem seems damaged.", sobald ich versuche, darauf mit "P" zuzugreifen. die oberen Beiden zeigen den Inhalt von C: (??), die unterste enthält eine Recovery und eine Recovery.txt.

Weiß jemand von euch weiter, wie wir das hier retten können? Ich weiß ja nicht mal, ob wir Windows neu installieren könnten, wenn wir die Platte mit Linux platt machen würden - aber vermutlich schon Das wäre aber ein ziemliches Chaos, weil wirklich extrem viele wichtige Daten auf der Platte sind und die vorhandene Internetverbindung eine Neu-Installation aller Software äußerst unangenehm gestalten würde.

Danke schon mal und liebe Grüße!
Domml

Vielen Dank und viele Grüße

 

[redjack1000]

Wenn die Daten wirklich wichtig sind, nichts mehr daran machen, außer eine exakte Kopie zu erzeugen und nur noch mit der Kopie weiterarbeiten.

CU
redjack

 

[Dr. McCoy]

Genau, Caine Live booten und mittels ddrescue eine 1:1-Kopie erstellen.

 

[Domml]

Danke schon mal für eure Antworten.

Dann auf eine andere Platte/Datenträger mit mindestens der Kapazität der SSD? Muss die andere Platte einzig und allein dafür sein?

 

[madmax2010]

oder aus dem schon gebooteten linux heraus.

ddrescue braucht eine zielfestplatte, die ein paar gb groesser ist, als die bestehende festplatte.
auf dieser brauchst du zusätzlich nochmal mindestens so viel platz wie du an daten hattest.


zeig mal bitte sudo smarctctl -a /dev/sdc
dann wissen wir ob ddrescue notwendig ist

Ergänzung (5. April 2022)

Dann auf eine andere Platte/Datenträger mit mindestens der Kapazität der SSD? Muss die andere Platte einzig und allein dafür sein?

ahh, da warst flinker. genau. auch zum retten mit testdisk in jedem fall.

kommst du mit ddrescue (falls gebraucht) klar oder willst eine anleitung?

 

[redjack1000]

Du kannst das auch in eine Imagedatei machen. Es geht jetzt nur darum, die Daten wiederherstellen zu können, ohne dabei die Quelle zu zerstören.

CU
redjack

 

[MountWalker]

Dass die NTFS Partitionen unter Linux nicht eingehängt werden und die Fehlermeldung kommt, die du im Eingangsbeitrag zitiert hast, muss nicht bedeuten, dass die Partition im Arsch ist, es kann ganz einfach daran liegen, dass sie eben nicht sauber ausgehängt wurde, weil NTFS-3g eine unausgehängte NTFS-Partition nicht datensicher einhängen kann.

 

[Domml]

Du kannst das auch in eine Imagedatei machen. Es geht jetzt nur darum, die Daten wiederherstellen zu können, ohne dabei die Quelle zu zerstören.

Eine Image-Datei wäre mir tatsächlich lieber. Die kann ich dann einfach auf die Daten-HDD packen lassen, ohne dort was kaputt zu machen? Das ginge dann ja auch mit meinem bestehenden Live-Linux, wie @madmax2010 schon meinte.
DDRescue bekomme ich hin denke ich, ansonsten melde ich mich nochmal.

zeig mal bitte sudo smarctctl -a /dev/sdc
dann wissen wir ob ddrescue notwendig ist

Ergänzung (5. April 2022)

SMART overall-health self-assessment test result: PASSED

Nochmals entschuldigung für die Qualität, wir machen das hier gerade per Videocall in Discord weil wir 2h entfernt voneinander wohnen:

 

[madmax2010]

zoom mal raus - man sieht die werte nicht


raw werte und so
https://www.mars-solutions.de/sites...visual/public/smartmontools.gif?itok=cUFDMXF4

 

[Domml]

[...] es kann ganz einfach daran liegen, dass sie eben nicht sauber ausgehängt wurde, weil NTFS-3g eine unausgehängte NTFS-Partition nicht datensicher einhängen kann.

Danke für die Erklärung, wieder was gelernt. Ich bin echt ein Neuling im Datensicherungs-Spektrum.

zoom mal raus - man sieht die werte nicht

Das ist uns nicht möglich gerade, ich guck mal, ob wir die Darstellung besser hin bekommen. SLAX ist irgendwie auf 600x400 gelockt, es gibt keine andere Auflösung. Das ist zu klein für einige Programme um überhaupt zu funktionieren und auch das Terminal sieht absolut fragwürdig aus. Was du da auf den Screenshots siehst ist alles, was wir auch sehen. Ich melde mich wieder

 

[Dr. McCoy]

weil wirklich extrem viele wichtige Daten auf der Platte sind

Wo genau liegen die denn? Vermutlich auf der System- und der Datenpartition verteilt, oder? Auf den Screenshots ist zu vieles abgeschnitten, aber das ist ja inzwischen bekannt.

Ich halte es für problematisch, so eine wichtige Datenrettung "am seidenen Faden" über eine solche Entfernung zu versuchen, zumal ein Datenträger, der womöglich defekt ist, so wenig und so kurz wie möglich in Betrieb bleiben sollte, bevor man nicht weiß, was er denn genau hat.

Außerdem umgeht man solche Probleme mit der Bildschirmauflösung am besten, indem man das Ergebnis in eine Textdatei schreiben lässt:

sudo smartctl -a /dev/sdc > result.txt

Diese kann dann versendet und hier in einem Beitrag angehängt werden.

 

[Domml]

Wo genau liegen die denn? Vermutlich auf der System- und der Datenpartition verteilt, oder?

Richtig, auf beiden verteilt.

Ich halte es für problematisch, so eine wichtige Datenrettung "am seidenen Faden" über eine solche Entfernung zu versuchen, zumal ein Datenträger, der womöglich defekt ist, so wenig und so kurz wie möglich in Betrieb bleiben sollte, bevor man nicht weiß, was er denn genau hat.

Das halte ich auch für problematisch, gerade gibt es für uns aber nicht gerade eine Alternative. Und "so wichtig" ist sie nicht, es wäre nur in der Kategorie "sehr ärgerlich", wenn wir die Daten nicht mehr bekämen. Ist jetzt nicht so dass dort eine offline-only-Bachelorarbeit oder dergleichen rumhängt.
Ich stimme dir zu, ich würde auch viel lieber direkt am Rechner in Frage sitzen...

Außerdem umgeht man solche Probleme mit der Bildschirmauflösung am besten, indem man das Ergebnis in eine Textdatei schreiben lässt:

sudo smartctl -a /dev/sdc > result.txt

Das weiß ich, ich kenne nur keine einfache Möglichkeit, die Textfiles aus der CLI irgendwo hochzuladen weil ich das noch nie gemacht habe. Den Browser zu benutzen ist eine Zumutung bei der Auflösung, der funktioniert nicht mal richtig und glitcht raus...
Ohne viel drum rum kann ich nur an Lösungen wie transfer.sh oder pastebinit denken, wo wir dann die URL abtippen müssten. Wäre wohl fast das Einfachste..

Ergänzung (5. April 2022)

Wir haben eine Möglichkeit mit netcat gefunden, das ist ja mal mega einfach...
Der Output für smartctl der Platte hängt an, @Dr. McCoy.

Das jetzt auch noch mit interaktiven Tools wie Testdisk hinzubekommen, wird wohl schwer