Nicht genauer spezifizierter Fehler in chkdsk

[Blaubart]

Tach.

Anstatt mich um meine eigentliche Arbeit zu kümmern, vergnüge ich mich seit heute mittag mit einem bockigen Windows-2000-Rechner, der bei jedem Start chkdsk laufen läßt und dabei stets zum gleichen Ergebnis kommt:

Der Typ des Dateisystems ist NTFS.

CHKDSK überprüft Dateien (Phase 1 von 3)...
Dateiüberprüfung beendet.
CHKDSK überprüft Indizes (Phase 2 von 3)...
Ein nicht genauer spezifizierter Fehler ist aufgetreten.

Aha, in Phase 2 werden also die Indizes überprüft. Was das genau bedeutet, habe ich in Erfahrung bringen können ... was das eigentliche Problem ist, jedoch nicht. Bei längeren Testläufen mit diesem System konnte ich bisher keine Probleme mit kaputten Verzeichnissen o. ä. feststellen.

Im WWW überschlagen sich die Helfer zu ähnlichen Problemschilderungen mit dem Allheilmittel "Mach alles platt!!!11" und Tips zum Abstellen des automatisch startenden chkdsk's beim Hochfahren von Windows (gewissermaßen die Kopf-in-den-Sand-Methode). Mich interessiert jedoch in erster Linie, woran chkdsk jedes Mal so jämmerlich verreckt. Die englische Wikipedia schlägt für die Auswertung einen Blick in die "Application Logs" vor. Das habe ich übersetzt in Systemsteuerung > Verwaltung > Ereignisanzeige > Anwendungsprotokoll. Dort lachte mir die große Leere ins Gesicht. Kein einziger Eintrag, insbesondere nicht zu chkdsk. ;)

Könnt ihr etwas empfehlen, um dem "nicht genauer spezifizierter Fehler" auf die Spur zu kommen?

Ach ja, Hardwareprobleme gibt es laut eines ausführlichen Tests mit den "SeaTools" des Herstellers der Festplatte keine ... Scheint also wirklich das Dateisystem zu betreffen.

[Tom]

Hello,

dieser Fehler wird mWn durch eine Macke bei den langen Dateinamen hervorgerufen, die wiederum durch einen rotten Internet-Explorer verursacht wird.

Beim Abspeichern von Webseiten wird die zulässige Länge für den Namen gelegentlich übnerschritten und schwupps, hast Du das Problem.

Wie man das aber vermeidet oder beseitigt weiß ich auch nicht, da die betroffenen Dateien sich i.d.R. noch nicht einmla löschen lassen.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[Blaubart]

Tach.

dieser Fehler wird mWn durch eine Macke bei den langen Dateinamen hervorgerufen, die wiederum durch einen rotten Internet-Explorer verursacht wird.

Das kann ich – zumindest für den IE – ausschließen. Alle bekannten Verzeichnisse, in denen er Webseiten u. ä. ablegt, sind leer. :)

Auch beim Durchsehen einer Liste aller Datei- und Verzeichnisnamen auf diesem Laufwerk sind mir keine überlangen Namen aufgefallen.

[Tom]

Hello,

dieser Fehler wird mWn durch eine Macke bei den langen Dateinamen hervorgerufen, die wiederum durch einen rotten Internet-Explorer verursacht wird.

Das kann ich – zumindest für den IE – ausschließen. Alle bekannten Verzeichnisse, in denen er Webseiten u. ä. ablegt, sind leer. :)

Auch beim Durchsehen einer Liste aller Datei- und Verzeichnisnamen auf diesem Laufwerk sind mir keine überlangen Namen aufgefallen.

Schade.
Ist aber leider auch nur _eine_ mögliche Fehlerquelle. Die tritt aber leider ziemlich oft auf.

Harzliche Grüße vom Berg
http://www.annerschbarrich.de

Tom

[imho_tep]

Systemsteuerung > Verwaltung > Ereignisanzeige > Anwendungsprotokoll. Dort lachte mir die große Leere ins Gesicht. Kein einziger Eintrag, insbesondere nicht zu chkdsk. ;)

Hallo Blaubart,

steht denn irgendetwas unter Systemsteuerung > Verwaltung > Ereignisanzeige > System?
Kannst Du im abgesicherten Modus booten, mit Protokoll?
Sind aber auch nur Vermutungen...

Best wishes, imho_tep

[Blaubart]

Tach.

steht denn irgendetwas unter Systemsteuerung > Verwaltung > Ereignisanzeige > System?
Kannst Du im abgesicherten Modus booten, mit Protokoll?

Inzwischen hat sich Windows dazu entschlossen, auch wieder Ereignisse im Protokoll festzuhalten (sowohl System als auch Anwendungen). Keine Ahnung, was vorher los war. Von Winlogon-Einträgen jedoch nach wie vor keine Spur.

Ehrlich gesagt vermute ich inzwischen auch, daß, wenn die gesuchten Einträge dort auftauchen sollten, sie auch bloß die Meldungen enthalten, die ich ohnehin schon von chkdsk bekomme ...

Ich hab vorhin mal den File Monitor von Sysinternals angeworfen, um chkdsk bei einem manuell gestarteten Durchlauf über die Schulter schauen zu können – der bricht übrigens ebenfalls mit der bereits erwähnten Meldung ab. Allerdings erkenne ich dort nur, daß in 4kB-Blöcken nacheinander von unterschiedlichen Offsets direkt auf dem Laufwerk C: gelesen wird. Alle Leseoperation – einschließlich der letzten vor dem Abbruch – werden als erfolgreich protokolliert. Allein aus den Speicheradressen auf dem Laufwerk bekomme ich bisher leider auch keine Anhaltspunkte, woran chkdsk sich stört ... Hat jemand 'ne Idee, wo und wie ich mit diesen Informationen weiterforschen kann?

[Der Martin]

Hallo,

Inzwischen hat sich Windows dazu entschlossen, auch wieder Ereignisse im Protokoll festzuhalten (sowohl System als auch Anwendungen). Keine Ahnung, was vorher los war. Von Winlogon-Einträgen jedoch nach wie vor keine Spur.

unter anderem diese Beobachtung, dass oft Ereignisse im Protokoll fehlen, die ich eigentlich für erwähnenswert halte, während die vorhandenen Einträge meist wenig wirklich neue Information hergeben, hat mich im Lauf der Jahre dazu gebracht, den Ereignisprotokollierdienst unter Windows zu deaktivieren. Die Ressourcen, die der sonst belegt, kann ich sinnvoller nutzen.

Ehrlich gesagt vermute ich inzwischen auch, daß, wenn die gesuchten Einträge dort auftauchen sollten, sie auch bloß die Meldungen enthalten, die ich ohnehin schon von chkdsk bekomme ...

Genau das meine ich. ;-)

Ich hab vorhin mal den File Monitor von Sysinternals angeworfen, um chkdsk bei einem manuell gestarteten Durchlauf über die Schulter schauen zu können – der bricht übrigens ebenfalls mit der bereits erwähnten Meldung ab. Allerdings erkenne ich dort nur, daß in 4kB-Blöcken nacheinander von unterschiedlichen Offsets direkt auf dem Laufwerk C: gelesen wird. Alle Leseoperation – einschließlich der letzten vor dem Abbruch – werden als erfolgreich protokolliert.

Natürlich. Schließlich sind die Leseoperationen vom Laufwerk ja - physikalisch betrachtet - erfolgreich. Der eigentliche Knackpunkt ist, dass chkdsk den *Inhalt* der meist 4k großen Datenblöcke untersucht und vor allem logische Fehler sucht.

Allein aus den Speicheradressen auf dem Laufwerk bekomme ich bisher leider auch keine Anhaltspunkte, woran chkdsk sich stört ...

Du könntest höchstens nachsehen, welchen Block chkdsk als letzten gelesen hat, dann nachsehen, was es ist. Wahrscheinlich ein Teil eines Verzeichnisses, und einer der Einträge darin ist dann derjenige, der das Problem auslöst. So würde ich jedenfalls vorgehen.

So long,
 Martin

[Blaubart]

Tach.

Allerdings erkenne ich dort nur, daß in 4kB-Blöcken nacheinander von unterschiedlichen Offsets direkt auf dem Laufwerk C: gelesen wird. Alle Leseoperation – einschließlich der letzten vor dem Abbruch – werden als erfolgreich protokolliert.

»»

Natürlich. Schließlich sind die Leseoperationen vom Laufwerk ja - physikalisch betrachtet - erfolgreich. Der eigentliche Knackpunkt ist, dass chkdsk den *Inhalt* der meist 4k großen Datenblöcke untersucht und vor allem logische Fehler sucht.

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. ;)

Allein aus den Speicheradressen auf dem Laufwerk bekomme ich bisher leider auch keine Anhaltspunkte, woran chkdsk sich stört ...

»»

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. :) Ich hatte auf irgendwelche Hilfsprogramme gehofft, die Windows selber mitbringt, um die Analyse etwas zügiger zu gestalten. 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. Leider hab ich mich mit der Struktur des NT-Dateisystems bisher nicht besonders beschäftigt, deshalb ist die Auswertung für mich natürlich erstmal ein ziemliches Rumgestocher.

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

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.).................................

Danach leider keine Angaben mehr zum Erfolg dieser Maßnahme.

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. ;)

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!

Tja, eigentlich hatte ich nicht vor, chkdsk jetzt selber nochmal nachzuprogrammieren. Falls Du also ein brauchbares Werkzeug für die Analyse des Dateisystems empfehlen kannst oder selber schon tiefer in die Materie eingestiegen bist ...

[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

[Blaubart]

Tach.

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 ..."

Das wäre in der Tat sehr hilfreich, ist aber mit dem Filemon nicht möglich. Hier wird wirklich nur der Prozeß aufgelistet und die Dateioperation mit Speicheradresse sowie Blocklänge. Deshalb meine Frage nach anderen Programmen.

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

Du Optimist! ;-)

Passiert mir sicher nicht nochmal. :)

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?

Nein, wirklich sicher bin ich mir da nicht. Dazu weiß ich wie gesagt bisher zu wenig über den Aufbau der FS-Einträge. Die anderen aufgelisteten Adressen des Filemon-Scans sehen aber recht ähnlich aus, nur eben ohne solche Fehlermeldungen. Ein 4-kB-Block besteht jeweils aus vier 1-kB-Blöcken, die alle mit der Zeichenkette FILE* beginnen. Einige von ihnen enthalten, jeweils beginnend beim gleich Offset, den Namen einer Datei, die tatsächlich auf dem Laufwerk existiert oder eine UICLSID. Der Rest ist für mich momentan noch Binärmüll ...

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 hab mich beim Auslesen des Laufwerks an Microsofts Doku zu diesem Thema gehalten. So zufällig sehen die Inhalte auch nicht aus (s. o.).

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?

Nein, das ist ein deutsches W2K. Ich hielt das auch erst für die Fehlermeldung einer Anwendung, da solche oder ähnliche Texte normalerweise in Logfiles aufzutauchen scheinen. Vielleicht ist ja genau das das Problem: irgendein Schreibfehler in der Vergangenheit, der nun zu unerwartetem Mist im Dateisystem und "nicht genauer spezifizierten Fehlern" in chkdsk führt.

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 mal stark davon aus, daß es dazu Doku gibt. Ist für mich aber momentan wirklich eine Zeitfrage, mich intensiver damit zu beschäftigen. Meine Hoffnung war, hier einen Tip für hilfreiche Software abzugreifen oder einen NTFS Wizard anzutreffen, der schon seit Tagen darauf wartet, daß ihm jemand Fragen zu Fehlern im Dateisystem stellt.

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).

Jep, NTFS. Im Normalfall wähle ich aber das verwendete Dateisystem auch nicht mit Hinblick auf möglichst einfachen Aufbau, nur falls ich mal von Hand dran schrauben muß. ;) Bis jetzt zumindest nicht ...

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).

Danke für das Angebot, aber ich kann beides nicht mit Sicherheit sagen (s. o.). Schon gar nicht mit absoluter. ;) Da der Fehler bisher ja bloß eine kuriose Randerscheinung ist, heb ich mir das Ganze noch ein paar Wochen auf, bevor ich weiter dran forsche.

Vielen Dank soweit; auch an die anderen, die sich hier im Thread gemeldet haben!