Nicht genauer spezifizierter Fehler in chkdsk

[Der Martin]

Hallo,

Tach.

;-)

Natürlich. Schließlich sind die Leseoperationen vom Laufwerk ja - physikalisch betrachtet - erfolgreich.
So selbstverstänlich finde ich das gar nicht. Bei einem "nicht genauer spezifizierten Fehler" hätte ja auch schon das Lesen selber das Problem darstellen können. Mit solchen Fehlermeldungen hält man sich ja alle Optionen offen. ;)

stimmt, aber daran hatte ich überhaupt nicht gedacht.

Du könntest höchstens nachsehen, welchen Block chkdsk als letzten gelesen hat, dann nachsehen, was es ist.

Äh, ja genau. Wie ich dieses Nachsehen am einfachsten mache, war meine Frage. :)

Ach so, ich dachte, man schaut sich den Datenblock im Hexdump an und kann daran zumindest erahnen, ob es z.B. ein Verzeichnis, ein Fragment einer Datei sein könnte. Also quasi angucken und dann erkennen, "Ah ja, das sieht aus wie ..."

Ich hatte auf irgendwelche Hilfsprogramme gehofft, die Windows selber mitbringt, um die Analyse etwas zügiger zu gestalten.

Du Optimist! ;-)

Da ich aber nach einer Weil auch keine mehr Lust auf endlose Sucherei hatte, hab ich vorhin selber ein paar Zeilen Code geschrieben, um die entsprechenden Blöcke auszulesen.

Ups. Bist du sicher, dass dir das wirklich gelungen ist? Unter Windows XP/2k sektorweise unter Umgehung des Filesystems von einer Festplatte zu lesen, ist nämlich nicht trivial. Möglicherweise ist in deinen paar Zeilen das Lesen an sich an irgendwelchen Berechtigungen gescheitert, und du untersuchst jetzt nur zufällige Speicherinhalte.
Ich dachte eigentlich eher, dass filemon auf Wunsch auch Auszüge aus dem Inhalt der gelesenen oder geschriebenen Daten anzeigt. Aber ich bin mir nicht mehr so sicher - ich habe das Tool schon Jahre nicht mehr benutzt.

Nun gut, immerhin hab ich in besagtem Speicherblock – neben einem Haufen expressionistischer ASCII-Kunst ;) – folgendes gefunden (war mal Unicode):

Sieht so aus. Windows spricht intern liebend gern UTF-16.

H.i.v.e. .u.n.l.
o.a.d. .f.o.r. .S.-.1.-.5.-.2.1.-.1.7.0.8.5.3.7.7.6.8.-.1.0.6.0.
2.8.4.2.9.8.-.1.3.4.3.0.2.4.0.9.1.-.5.0.0. .f.a.i.l.e.d. .d.u.É.
.t.o. .o.p.e.n. .r.e.g.i.s.t.r.y. .k.e.y... . .W.i.n.d.o.w.s. .
w.i.l.l. .t.r.y. .u.n.l.o.a.d.i.n.g. .t.h.e. .r.e.g.i.s.t.r.y. .
h.i.v.e. .o.n.c.e. .a. .s.e.c.o.n.d. .f.o.r. .t.h.e. .n.e.x.t. .
6.0. .s.e.c.o.n.d.s. .(.m.a.x.).................................

Das scheint mir aber eher der Text für eine Fehlermeldung einer Applikation oder einer Windows-Komponente zu sein, die abenteuerliche Registry-Operationen machen möchte. Du benutzt ein englisches Windows?

Eine erste Suche nach dieser Meldung im WWW ergab, daß so ziemlich *alles* als Fehlerursache in Frage kommt. Ich meld mich dann in einem Monat nochmal, wenn ich mich eingelesen habe. ;)

*gg*
Ja, es ist in der Tat dürftig, was wir hier an Diagnosemöglichkeiten haben.

Außerdem fand ich in dem Wust etwas, das verdächtig nach einem Verzeichnisnamen aussieht. Allerdings kann ich dessen Position in der Verzeichnisstruktur bisher nicht einordnen, da +50 Unterverzeichnisse gleichen Namens auf dem Laufwerk existieren. Nun müßte ich vermutlich erstmal den generellen Aufbau der FS-Einträge studieren. Heißa!

Die sind aber prinzipiell irgendwo dokumentiert (vielleicht nicht direkt von Microsoft *g*), ich erinnere mich dunkel, dass ich vor ein paar Monaten mal so etwas gelesen habe. Ich gehe davon aus, dass du ein NTFS-Volume hast - denn auf FAT32 wäre sowas trivial (einer der Gründe, warum ich NTFS generell nicht verwende, außer ich brauche unbedingt Dateien >4GB).

Falls Du also ein brauchbares Werkzeug für die Analyse des Dateisystems empfehlen kannst oder selber schon tiefer in die Materie eingestiegen bist ...

Wenn du absolut sicher sein kannst, dass
a) der Speicherinhalt, den du untersuchst, *wirklich* den gelesenen Datenblock enthält und
b) da keine vertraulichen oder sonstwie unangenehmen Daten drinstecken,
dann schick mir doch so einen Block mal als Hexdump oder Binärdatei zu (Mailadresse oben). Vielleicht werde ich daraus schlauer. Einen Versuch wär's wert. ;-)

Schönes Wochenende noch,
 Martin