„Dirty-Bit“ wird bei jedem Systemstart neu gesetzt, CHKDSK bei jedem Systemstart

Das „Dirty Bit“ auch „Dirty Error Bit“ oder „Chkdsk Flag“ wird irgendwo auf den Platten gesetzt und Microsoft will einfach nicht damit herausrücken, wo Windows sich das „Dirty Bit“ merkt. Normalerweise wird es auf allen Platten gesetzt, wenn man den Rechner bei laufendem Windows abschaltet oder einen Stromausfall hat. Es gibt aber auch andere Fälle…

Ich bin am Ende mit meiner Kunst. Angefangen hat alles damit, dass auf meines Sohnes Rechner plötzlich bei jedem Systemstart ein CHKDSK ausgeführt wurde. Die Konfiguration:

- Betriebssystem: Microsoft Windows XP Professional Version 2002 Service Pack 3 (32bit Version), alle UpDates Stand 29. Januar 2010
- Prozessor: Intel Quad-Core Desktop i5-750
- Mainboard: Gigabyte GA-P55-UD4 Bios Version F5
- Speicher: 4 GB Kingston DDR3-1333 RAM (2 * KVR1333D3N9/2G)
- Platten: 4 identische 500 GB Festplatten Seagate ST3500630AS unter AHCI

Mein Backup-Konzept besteht darin, regelmäßig die Boot-Festplatte (Nr. 0) mittels Acronis True Image Home 2010 (Build 6.063) auf eine Backup-Festplatte (Nr. 1) zu klonen. Klonen kann man übrigens auch mit dem kostenlosen DiscWizard von Seagate, da steckt genauso Acronis drin. Dank einer angepassten boot.ini kann ich dann von beiden Platten XP starten und teste dies auch nach jedem Klonen. Die erste Bootplatte ist also C: auf rdisk(0)partition(1), die zweite J: auf rdisk(1)partition(1).

Die boot.ini sieht wie folgt aus:
[boot loader]
timeout=1
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional Original" /fastdetect /NoExecute=OptIn
multi(0)disk(0)rdisk(1)partition(1)\WINDOWS="Microsoft Windows XP Professional Backup" /fastdetect /NoExecute=OptIn

Die Platten lassen sich wie folgt darstellen:
_rdisk(0)partition(1) ST3500630AS C Boot
_rdisk(0)partition(2) ST3500630AS D Daten
_rdisk(0)partition(3) ST3500630AS E DOS
_rdisk(1)partition(1) ST3500630AS J Backup Boot
_rdisk(1)partition(2) ST3500630AS K Backup Daten
_rdisk(1)partition(3) ST3500630AS L Backup DOS
_rdisk(2)partition(1) ST3500630AS F Daten
_rdisk(3)partition(1) ST3500630AS G Video

Als das mit dem CHKDSK anfing, habe ich die Platten zuerst einmal checken lassen. Das läuft halt eine Weile und gut. Beim nächsten Systemstart kam CHKDSK aber wieder, ziemlich lästig. Also fing ich an im Internet zu suchen und kam dann auf das „Dirty Error Bit“.

Um ganz sicher zu gehen, habe ich XP von CD mit gestartet und mittels F6 die AHCI-Treiber eingebunden (für AHCI unter XP gibt es eine Anleitung), dann mit „R“ in den Reparaturmodus (Wiederherstellungskonsole) und jetzt den „CHKSDK C: /P /R“ und „CHKDSK J: /P /R“ ausführen lassen. Der Parameter /P ist übrigens nur in der Konsole erlaubt, ansonsten geht nur „CHKDSK <Laufwerk>: /F /R“.
Nähere Info’s zu CHKDSK bei Microsoft.
Die Abfrage „FSUTIL DIRTY QUERY C:“ und J: lieferte danach wie erwartet „Volume – c: ist NICHT fehlerhaft.“
Alle verfügbaren Befehle der Wiederherstellungskonsole sind hier ausführlich beschrieben. Die FSUTIL (FS = FileSytem) Befehle stehen nur bei laufendem XP zur Verfügung.

Also wieder von C: gebootet, schon lieferte die Dirty Query wieder „Volume – c: ist fehlerhaft.“ Volume J: blieb fehlerfrei, aber auch nur bis zum nächsten Booten von dieser Backup-Platte. Gerade so, als würde „FSUTIL DIRTY SET C:“ in der autoexec.bat stehen.

Alle Befehle führe ich übrigens in der DOS-Konsole „CMD“ aus und nicht in der Windows-Befehlszeile erreichbar unter „Start – Ausführen…“. Irgendwo habe ich auch gelesen, dass sich XP Einträge in der Auslagerungsdatei merkt, also habe ich die Auslagerungsdatei abgeschaltet, den Papierkorb geleert, temporäre Internetdateien gelöscht und mit Ashampoo den restlichen Datenmüll entsorgt.

Abhilfe gegen den lästigen CHKDSK schafft zunächst „CHKNTFS C: /X“ – damit wird die Festplattenprüfung ausgeschaltet. Das kann es auf Dauer aber auch nicht sein. CHKDSK wird dann zwar beim Systemstart nicht mehr ausgeführt, aber trotzdem lässt sich die Platte mit Windows-Mitteln nicht mehr defragmentieren. Man bekommt schon beim Überprüfen die Meldung „Die Defragmentierung hat ermittelt, dass auf Volume Boot C: „chkdsk“ ausgeführt werden soll. Führen Sie chkdsk /f aus.“

Die Festplattenprüfung kann man übrigens mit „CHKNTFS /D“ für alle Laufwerke wieder einschalten (und sollte dies auch tun). Dabei fällt mir ein, dass ich die Platten vor dem Problem mit „Ashampoo WinOptimizer 6“ habe defragmentieren lassen, Ashampoo meckert natürlich nichts an bei der Defragmentierung.

Mein nächster Gedanke war dann natürlich „Virus“, da muss ja wohl ein Boot-Virus auf den Platten sein. Also mit „McAfee Total Protection Service (Version 5)“ die ganze Platte scannen lassen, der hat aber nichts gefunden. Von McAfee bin ich übrigens überhaupt nicht mehr begeistert, er bremst das System total aus, läuft nicht vollständig auf XP 64bit usw. Auf meinem Laptop habe ich McAfee durch die „Microsoft Security Essentials (MSE)“ ersetzt und bin jetzt wieder mit Leistung und Schutz zufrieden. Und kosten tut MSE auch nichts.

Jetzt kam ich noch auf die glorreiche Idee, dass ich dank meiner Dual-XP-Boot Konfiguration die andere bootfähige Platte ja „CHKDSK“en und dann defragmentieren kann. Sicherheitshalber vorher die Boot-Platte noch auf die dritte Platte G: geklont, dabei wurde das „Dirty-Bit“ übrigens auch „mitgeklont“.

Irgendwie habe ich das Gefühl, XP kommt mit den Festplatten durcheinander und merkt sich das Dirty-Bit auf der falschen Platte für die falsche Platte…

Da mir das alles keine Ruhe lässt habe ich noch mal die Wiederherstellungskonsole bemüht. Also Bios auf von CD booten gestellt, XP CD rein, gestartet, mit F6 die AHCI Treiber eingebunden und mir „R“ in die Konsole. Auf der 1. Installation angemeldet, den Masterbootrecord MBR auf Verdacht mit „FIXMBR“ repariert, beide Platten ge“chkdsk“t. Das gleiche auch auf der 2. Installation. Dann das System mit der F-Secure RescueCD gescannt. Hilft alles nicht.

Dazu noch eine Anmerkung: Vorsicht mit „FIXBOOT <Laufwerk>:“, der Befehl schreibt eine neue Partitionstabelle, damit sind alle Daten auf der gesamten Festplatte im Eimer! „FIXMBR <Gerätename>“ repariert den Masterbootrecord. Den Gerätenamen erhält man mit dem Befehl „MAP“ z.B. „\Device\Harddisk2“. Der Befehl „BOOTCFG /REBUILD“ ist meistens nicht nötig, da die boot.ini ja vorhanden und brauchbar ist.

Den rettenden englischsprachigen Hinweis dachte ich am 30.1.2010 hier gefunden zu haben. Ich habe alle dort beschriebenen Methoden versucht:
1. „chkdsk /x /f <lw>:“ hatte ich schon in allen Variationen
2. Die Festplatte umpartitioniert
3. Ein Backup mit Acronis gemacht, die Platte formatiert und das Backup wieder zurückgespielt &#8594; Das Dirty Bit war sofort wieder gesetzt

Mein Problem besteht weiterhin, mir fällt nichts mehr ein. Was könnte man noch tun?

XP neu installieren scheidet aus, da habe ich zwei Wochen Arbeit

Ich hoffe, jemand hier im Forum hat noch einen guten Tipp…

Weiterführende Informationen:
- Zu AUTOCHK bei Microsoft
- Die beste Anleitung zum Thema hier

 

Hi! Respekt für die Beschreibung - da traut sich ja kaum noch einer, irgendwas dazu zu sagen ...

> Vorsicht mit „FIXBOOT <Laufwerk>:“, der Befehl schreibt eine neue Partitionstabelle, damit sind alle Daten auf der gesamten Festplatte im Eimer!

das ist allerdings nicht richtig!

hast Du mal eine komplette Oberflächenanalyse (Read-Scan) mit Seatools für DOS gemacht?

 

Nein, einen Oberflächenscan unter DOS habe ich nicht gemacht. Es wäre ja auch sehr unwahrscheinlich, dass alle vier Platten auf einmal eine Macke bekommen, das "Dirty Bit" hat sich ja aúf jeder Kopie der Boot-Platte wieder "eingeschlichen".
Eine Idee wäre noch, die Platten bis auf eine abzuschalten, dann die eine verbleibende von der Wiederherstellungskonsole zu "chkdsk"en und zu sehen was dann passiert. Eine Heilung auf diese Weise spräche für meine Theorie des "mit den Platten durcheinander kommens".
Mein Verdacht ist dass XP sich das "Dirty Bit" sowohl auf der Platte als auch in der Registry merkt.

P.S.: Riskierst Du den FIXBOOT auf Deiner Platte?

 

ich muss das nicht machen, hab' ja kein Problem! - nee, Spaß beiseite: habe das schon bei verschiedenen Gelegenheiten machen müssen, dabei gehen die Daten definitiv nicht verloren!

bezgl. SeaTools meinte ich, dass Du den ReadScan nur mal bei der Platte machen solltest, mit der das Elend angefangen hat - evt. werden dabei Sektoren "repariert" bzw. gesperrt und es wäre interessant, ob beim anschließenden XP-Boot wieder chkdsk läuft ...

 

Ich werde das morgen (20.2.2010) mal testen, auch meine Idee mit dem Platten abklemmen.

 

Wie wärs mit CHKDSK /R /F <LW>: ??

 

Sorry, das habe ich auch so ausgeführt:
CHKDSK C: /p /r
Schaust Du hier.
Der CHKDSK behebt das Problem ja auch, aber nur bis zum nächsten XP-Start...

 

Nein, tut er nicht - ganz offensichtlich.

/R /F musst du aus einer DOS-Box heraus auslösen, /R (max. /R /P, aber das P ist unnötig) von der Reparaturkonsole.

Wenn das nicht hilft müssen andere Betriebssysteme ran…

 

Ich habe den Rechner von der SeaTools f&#252;r DOS CD gestartet und auf allen vier 500 GB Platten einen Langzeittest ausgef&#252;hrt. Hat halt zwei Stunden pro Platte gedauert. Wie erwartet hat SeaTools keine Fehler gefunden.
Danach habe ich alle Platten bis auf die Boot-Platte abgeklemmt, AHCI auf IDE umgeschaltet und die XP-Wiederherstellungskonsole von CD gestartet.
"CHKDSK C: /R" ausgef&#252;hrt und nach einer Stunde XP gestartet, das Dirty Bit war wieder gesetzt.
Scheinbar setzt Windows auch zwei Bits:
- Clean Shut Down Bit
- Hard Disk Error Bit
Die haben (zumindest unter Win95) als beide "low order bits" im ersten Cluster des FAT Eintrags gestanden. Ich werde jetzt mal suchen, ob ich diese Eintr&#228;ge unter XP auf der Platte finden kann und zur Not mit einem entsprechenden Tool manuell von 0 auf 1 setzen.

 

Oder sollte das heißen: ›ist immer noch gesetzt‹?

Schon mal profan FIXMBR versucht?

Ich müsste lügen zu sagen, dass ein Partitionstool oder zumindest TESTDISK hier was flicken kann.

 

Hallo Eric,

den FIXMBR hatte ich ja schon im ersten Versuch mit allen Platten in Betrieb.

Damals hatte ich auch beobachtet, dass das Dirty Bit auf der Platte, von der ich gerade nicht gebootet habe, nach dem Wiederherstellungskonsolen "CHKDISK <LW>: /R" weg war.

Folglich gehe ich automatisch davon aus, dass das Dirty Bit nach dem CHKDSK weg ist und erst beim XP-Boot wieder gesetzt wird.

Den letzten Satz in Deinem Beitrag deute ich als "Vergiss die Partitionstools". Das Re-Partitionieren hatte ich ja auch schon versucht.

Ich gebe auf und bleibe bei "CHKNTFS /X", die Kiste l&#228;uft dann wenigstens ohne zu meckern.