Wo merkt sich WIN dass CHKDSK nötig wäre?

cumulonimbus8

Fleet Admiral
Registriert
Apr. 2012
Beiträge
19.111
Hallo!

Ich finde zu diesem Thema vieles und nichts. Kein Problem den ewigen Lauf beim Booten zu beheben, angeblich soll es ein DirtyBit sein… Aber das passt irgendwie nicht zusammen.

Bei mir tun 4 Platten Dienst in deren 4 Primärpartitionen XP installiert ist. Es verteilen sich je 4, 4, 3, 1 Partitionen (ist halt so gewachsen). Normalerweise nutze ich die Boot.Ini der Platte an BIOS-Position #1, nichtsdestoweniger sind alle Platten autark und ich kann sie übers BIOS-BootMenü anwählen. Das nutze ich allgemein dann, wenn #1 in den Ruhezustand versetzt wurde und mir deswegen das Menü der Boot.Ini nicht angeboten wird (F8 muss nicht sein).

Vielleicht die Hitze hat zu einem (wie ich annehmen muss) Absturz einer Plattenelektronik geführt und das rief CHKDSK auf den Plan. So weit so gewöhnlich.

So hatte ich also den Unfall und, zum Booten gezwungen, griff ich zu einer speziellen Installation die mich mit einigen Runden CHKDSK beglückte. Nach getaner Arbeit (dachte ich) zurück zum Haupt-XP. Wieder die CHKDSK-Ehrenrunden.

Warum? Woher hat dieses WIN die Information CHKDSK erneut aufzurufen? Dass der vorige Lauf einer von der Sorte war der Hektik verbreitet aber nichts repariert merkte ich als ich noch mal die Spezialinstallation brauchte.
Aber: Die To-Check-Listen bieder waren z.T. unterschiedlich. Selbst als ich im Haupt-XP für eine bestimmte Partition CHKDSK /R /F auslöste (was selbst direkt durchgeführt werden konnte) wurde dieses logische LW vom Spezial-XP als behandlungswürdig deklariert.

Wo also versteckt WIN die Information wo CHKDSK erforderlich ist?
Ein LW das i.O. ist muss nicht vom anderen WIN erneut gepflügt werden.

CN8


PS: Ich weiß wann und warum ich CHKDSK ad hoc aussetze und dass ich um CHKDSK /R /F nicht herumkomme; ich will da nichts aushebeln oder so.
 
mea culpa; alles ist NTFS, dies dazu.

Das DirtyBit wäre ja der Ansatzpunkt - wenn nicht unterschiedliche WINs unterschiedliche Partitionen ≡ Laufwerke als prüfwürdig benennen würden. Die LWs haben alle ihren unmissverständlichen Label (was auch unter einem Live-Linux ein Segen ist) sodass ich sicher weiß um welche Partition es sich jeweils dreht.

Es muss da irgendwo noch was anderes geben..!

CN8
 
Lies mal hier nach, da wird einiges erklärt, ist zwar 2k aber für XP gelten die gleichen Bedingungen. Evtl hilft es Dir ja ein wenig weiter.
 
(Nach einem langen Tage Arbeit…)

Auch da hilft nicht weiter. Ich weiß was die Tools tun - ich weiß eben nur nicht woran WIN selbstständig erkennt wo CHKDSK angeblich nötig wäre.

Das geht insgesamt so weit, dass WIN #2 immer noch LW prüfen will die ich in #1 über die Kommandoziele mit CHKDSK /R /F bereits abgefrühstückt hatte.

Dieses Elefantentgedächtnis ist mir mehr als suspekt. Angemessenes CHKDSK, OK. Aber sinnlosem möchte ich kontrolliert (!) den Stecker ziehen können.

CN8
(Chute N-8! ;-))
 
Hallo CN8!

Wenn Du mehrere BS benutzt, dann prüft & merkt sich jedes BS für sich, wenn es z.B. neue LW oder Veränderungen entdeckt.
Aber genauer weiß ich's auch nicht, sorry!

Grüße
 
Hmtja - das habe ich auch schon gemerkt ;)
Deshalb wollte ich ja wissen wo das Gedächtnis steckt.

CN8
 
:grr: Den Link hatten wir schon.

Und ich wäre glücklich wenn man mir meine Frage beantwortete und sagte nicht wie ich unter Rückgriff auf Schrotschüsse in Richtung aller Platten das Bit wegbekäme. Denn offensichtlich ist es mehr als das Bit, wie ich dargelegt habe.

CN8
 
Es gibt nicht mehr als das Bit. Es gibt nur dein System, dass das Dateisystem sofort wieder kaputt reißt. Warum das so ist, kann man bei dieser spärlichen Informationspolitik nicht beurteilen. Klemm alle Platten ab, überprüfe die Platte mit Vendor Tools (UBCD) oder teste sie in einem anderen System. Grenz den Fehler ein.
 
Sorry - aber wenn du unwillig bist den Thread zu lesen (dir wäre das mit dem Link dann nämlich nicht passiert) dann hör bitte auf mich hier anzupfeifen.
In meiner Frage ist alles Nötige erklärt. Wenn dir spezielle Infos fehlen dann frage detailliert nach.

Ich weiß schlicht, dass es mehr als das Bit sein muss - was ich bisher immer glaubte - weil ich genau das beobachtet habe.


-----


Es gibt nicht mehr als das Bit.
Wie gesagt, das glaubte ich bisher auch…

Es gibt nur dein System, dass das Dateisystem sofort wieder kaputt reißt.
Quatsch, was du hier schreibst. Mein System zerreißt nicht das Dateisystem sondern mehrere; und gegen HW-Aussetzer die den Daten-Bus ins Rotieren bringen ist jedes System machtlos.

Warum das so ist, kann man bei dieser spärlichen Informationspolitik nicht beurteilen.
«Vielleicht die Hitze hat zu einem (wie ich annehmen muss) Absturz einer Plattenelektronik geführt und das rief CHKDSK auf den Plan. So weit so gewöhnlich.»
Ich halts für unverschämt von einem toten Gaul einen Furz zu verlangen. HW-Absturz (einer Platte, das kenne ich aus Erfahrung [ja, auch einmal bei diesem System, Garantiefall]) - und Ende-Gelände. Mehr weiß ich auch nicht; woher auch?

Klemm alle Platten ab, überprüfe die Platte mit Vendor Tools (UBCD) oder teste sie in einem anderen System. Grenz den Fehler ein.
Halte mich bitte für intelligent und erfahren genug einen Ausnahmefall als solchen zu erkennen. Nach Tools waren und sind die Platten gesund, falls dich das beruhigt.

CN8

Offenbar fühlt sich tatsächlich eine meiner Platten unwohl. Aber so lange der Finanzminister anderer Meinung ist muss sie weiterlaufen.

Seltsamerweise wird diese (die ich in Verdacht hatte) Platte als 100% gesund angegeben. Ein Kopierproblem ließ mich CHKDSK /R /F auf dem logischen Laufwerk ausführen. Und eine andere als kritisch angemahnte Platte mit einem Tool prüfen (gesund…)

Ein kleines bisschen Programmierspielerei mit VBS lieferte mir die Angabe (wie auch die Kommandozeile) dass kein DirtyBit sämtlicher logischer LW dirty war.

Nun beendete ich den Tag und startete heute (dieses Betriebssystem) neu. CHKDSK begrüßte mich mit den Laufwerken der geprüften Platte. Es ging schnell; und ich hatte da Pech vom Monitor wegzumüssen, es hätte auch noch das geprüfte LW mit bei sein können.


Also rekapitulieren wir, dass kein DirtyBit gesetzt war und dennoch CHKDSK ansprang.

Nun sind alle die dran die immer noch meinen, dass es nur das DirtyBit sein kann.

CN8
 
Zuletzt bearbeitet von einem Moderator:
Wenn Du schon den letzten Beitrag im Thread hast reicht ein Edit um den Thread wieder nach oben zu holen. Fördert die Übersichtlichkeit.
 
Rebooten ich musste, die Platte im BIOS ich wählte. Erstaunt ich war. CHKDSK erneut mit gewähltem Betriebssystem gelaufen ist, über die selben Laufwerk hinweg. Einen Neustart CHKDSK erzwang, wieder im BIOS ich wählte. Weitere Laufwerke geprüft wurden, Windows dann startete.
Vom ersten Windows aus, nun wieder DityBits sind gesetzt (aus Ruhezustand), für zuletzt geprürfte und vorhin geprüfte Laufwerke. Verrückt ich wohl werden muss… :freaky:

CN8
 
Weiß zwar nicht,welcher Teufel dein Windows geritten hat,aber unterbinden kann man es vorerst mit chkntfs ( mit Adminrechte ).

chkntfs /?
 
Das nützt dann nix wenn es (CHKDSK) überraschend kommt. Und Abwürgne wi

Ich gebe da langsam (den Geist) auf. Habe ebne in Laufwerk mit CHKDSK /R /F angegriffen, was aber ein Rebooten erzwang. 2 weitere (logische) LWs wurden mit /F (offensichtlich ohne /R) bei der Aktion mit geprüft.
Allerdings setze ich dieses Betriebssystem #1 in den Ruhezustand um #2 über BIOS-Bootmenü zu starten. Hurra, CHKDSK… Sogar eins der oben betroffenen wurden mit /F allein geprüft. Ich hatte in#2 zuletzt aber keinen CHKDSK-Auftrag abgesetzt.

Was tickt da nur in WIN's Geist Dinge zu tun die man nicht nachvollziehen kann.

Und frage mich keiner warum bei soeben geprüften LWs plötzlich wieder das DirtyBit gesetzt ist.

:freak:

CN8
 
Vielleicht ist es doch ein Hardware Problem. Poste doch mal SMART Werte. Eventuell sinda ja hohe Schreib und Lesefehlerkorrekturen vorhanden.
 
Hallo!

Oder Du hast eins der ominösen HDD's im Betrieb, die ein FW-Update benötigen (manchmal bei Samsung, Seagate & auch WD Platten).

Grüße
 
Wenn Fehler nicht behoben werden können, wird das Flag nicht zurückgesetzt. Und Tasks werden unabhängig vom Zustand des Laufwerks ausgeführt.

Es sollte sich jeder darüber im Klaren sein, dass chkdsk zwar durchaus nützlich ist, andererseits bei seinen Reparaturversuchen Daten unwiderbringlich zerstören kann, die ohne Benutzung von chkdsk möglicherweise mit anderen Tools wiederhergestellt werden könnten. Deshalb ist Datensicherung unerlässlich!

In dem ominösen Link ist doch die empfohlene Lösung beschrieben: Inhalt der Partition sichern (mit Tool, das die Integrität prüft), neu formatieren und Sicherung zurück spielen.
Wenn dabei bereits Probleme auftreten, hast du ein Problem, das mit chkdsk ohnehin nicht zu lösen ist (dann ist von chkdsk sogar dringend abzuraten! s.o.).

Imho ist es wichtiger, das Problem zu beheben, als den technischen Hintergrund von chkdsk zu erforschen.

Du könntest:
- deine Tasks bzgl. chkdsk überprüfen und testweise aussetzen, da gibt es zuweilen ungewollte Einträge.
- chkdsk manuell mit Protokoll aufrufen, um aufgetretene Fehler zu identifizieren.
Code:
chkdsk /Parameter1 /Parameter2 >>chkdsk.txt
(>chkdsk.txt überschreibt die vorhandene Datei, >>chkdsk.txt schreibt neuen Inhalt hinzu)
Für das Bootlaufwerk lässt sich winlogon in der Ereignisanzeige einsehen.
- wie bereits empfohlen, die Smartwerte überprüfen. Wenn es Probleme beim Plattenzugriff gibt, dann kann auch chkdsk scheitern.
 
@miac
Eine Platte - aber nicht die hier, sagen wir, erwischte, hat schlechte Werte. Aber gewiss schon länger.
Ich wechsele fröhlich durch meine WINs und erhalte inkonsistente Auffassungen wo zu CHKDSKen wäre. DirtyBits kommen aus dem nichts, aber sie werden unterschiedlich bewertet.

@MiesMosel
Kann ich offen gesagt nicht mal sagen… Die (kritischeren) Platten dürften so 8 Jahre sein, die neuren etwa 4 bzw. 3 auf Garantietausch. Mir wäre da nicht ersichtlich mit FW-Updates nachfassen zu müssen; und ich zweifele mal an, dass ich da überhaupt was fände.

@derblöde
Wenn Fehler nicht behoben werden können, wird das Flag nicht zurückgesetzt. Und Tasks werden unabhängig vom Zustand des Laufwerks ausgeführt.
So weit stimme ich zu; mit ›Tasks‹ meisnt du aber konkret?

Es sollte sich jeder darüber im Klaren sein, dass chkdsk zwar durchaus nützlich ist, andererseits bei seinen Reparaturversuchen Daten unwiderbringlich zerstören kann, die ohne Benutzung von chkdsk möglicherweise mit anderen Tools wiederhergestellt werden könnten. Deshalb ist Datensicherung unerlässlich!
Weiß ich. :-) Und da sind nicht umsonst 4 Platten drin damit beim plötzlichen Tod einer immer noch restauriert werden kann (bzw. kommt die Systmepartition ais einem Image).

In dem ominösen Link ist doch die empfohlene Lösung beschrieben: Inhalt der Partition sichern (mit Tool, das die Integrität prüft), neu formatieren und Sicherung zurück spielen.
Wenn dabei bereits Probleme auftreten, hast du ein Problem, das mit chkdsk ohnehin nicht zu lösen ist (dann ist von chkdsk sogar dringend abzuraten! s.o.).

So einfach ist das nicht. Gehen wir mal von dem Punkt aus, dass qualifizierte Tools die Platten so weit als gesund melden. Weiterhin sind mir aus Beobachtungen die Mechanismen der Fehler bekannt; ich gehe mit Grund nicht von Plattenversagen sondern von Aussetzen aus. Vor CHKDSK hab ich so wenig Angst, und Formatieren würde da auch nur am Dateisystem schrauben, und ich schließe dieses als Ursache aus (anderweitig müsste ich 11 Partitionen behandeln, das wäre bei einem einzigen Schuldigen nicht logisch).

Imho ist es wichtiger, das Problem zu beheben, als den technischen Hintergrund von chkdsk zu erforschen.
Vielen Dank. Just das versuche ich die ganze Zeit. Ich bemängele ja nicht CHKDSK sondern die Kreativität nach der WIN es auslöst.

Du könntest:
- deine Tasks bzgl. chkdsk überprüfen und testweise aussetzen, da gibt es zuweilen ungewollte Einträge.

..? Welche ›Tasks‹ meinst du hier? Kein Scheduler und ich nur nach konkreten Anlässen löschen CHKDSK aus - oder ebne von WIN selbst.

- chkdsk manuell mit Protokoll aufrufen, um aufgetretene Fehler zu identifizieren.
Sag das WIN wenn es beim Booten damit lostickt.
Eben dieses Losticken-nach-Gutsherrenart ohne Logik ist es ja die mich auf die Palme bringt.

CN8
 
cumulonimbus8 schrieb:
mit ›Tasks‹ meisnt du aber konkret?
Den Taskplaner
ich gehe mit Grund nicht von Plattenversagen sondern von Aussetzen aus. Vor CHKDSK hab ich so wenig Angst, und Formatieren würde da auch nur am Dateisystem schrauben, und ich schließe dieses als Ursache aus (anderweitig müsste ich 11 Partitionen behandeln, das wäre bei einem einzigen Schuldigen nicht logisch).
Wenn es "Aussetzer" gibt, dann hat dies eine Ursache. Wenn es am Dateisystem liegt, dann kannst du das einfach durch die beschriebene Lösung (neu formatieren) beheben. Ohne langes Herumeiern.
Wenn es an der Platte liegt (mit Sicherheit nicht an der Plattenelektronik), dann solltest du zuerst die SMART-Werte auslesen und außerdem ein Herstellertool laufen lassen.
Hast du das getan? Hast du dir das chkdsk-Protokoll angesehen?

..? Welche ›Tasks‹ meinst du hier? Kein Scheduler und ich nur nach konkreten Anlässen löschen CHKDSK aus - oder ebne von WIN selbst.
Keine Ahnung, was dieser Satz bedeuten soll.
- chkdsk manuell mit Protokoll aufrufen, um aufgetretene Fehler zu identifizieren.
Sag das WIN wenn es beim Booten damit lostickt.
Eben dieses Losticken-nach-Gutsherrenart ohne Logik ist es ja die mich auf die Palme bringt.
Sorry, aber wenn du meinst, dass dich Rumbölken weiter bringt als das Finden der Fehlerursache...
Nochmal: Du hast ein Problem. chkdsk versucht es zu lösen. Du siehst dir nicht das Ergebnis (Protokoll) an, sondern willst über Sinn/Unsinn/technische Hintergründe von chkdsk diskutieren. Den Gedanken, dass das Dateisystem und/oder die Platte defekt sind, willst du nicht wahrhaben.
Wenn die Platten 4-8 Jahre alt, gönne dir 1 oder 2 neue (S-ATA-)Platten, dann tauschst du etwas Geld gegen viel Zeit, Datensicherheit, mehr Geschwindigkeit usw. ein: Ein gutes Geschäft. Das Herumfuhrwerken mit alten, angeschlagenen Platten ist sinnlos.
 
Zurück
Oben