...Cleaning up minor inconsistencies on the drive...
so begrüßt mich eines Morgens das Windows eigene Festplattentool Chkdsk. Sie sind selten geworden, diese Chkdsk-Durchläufe. Durfte man sich zu Zeiten von Windows 95 oder 98 noch nach jedem Systemcrash diese (wichtige) Datenprüfung ansehen, wird seit dem Siegeszug des NTFS-Dateiformats auf Windows-PCs kaum mehr jemand damit belästigt. Schon scherzt man, dass einer der wenigen notwendigen, früher meist harmlosen Chkdsk-Durchläufe nur noch Ärger bedeuten kann.
So schlimm ist es zum Glück natürlich nicht. Dieses eine Mal hat es mich aber erwischt.
...Cleaning up minor inconsistencies on the drive... Chkdsk will nur Spielen und ein paar Unstimmigkeiten im Dateisystem aufräumen. Keine Panik also. Die nächsten Zeilen handeln jetzt sicherlich von glücklichen Clustern die Hand in Hand über Sektorwiesen hüpfen. Denkste!
(Kopie aus MS Knowledgebase)
Checking file system on C:
The type of the file system is NTFS.
Volume label is Vista64.
Cleaning up minor inconsistencies on the drive.
Cleaning up 1496 unused index entries from index $SII of file 0x9.
Cleaning up 1496 unused index entries from index $SDH of file 0x9.
Cleaning up 1496 unused security descriptors.
CHKDSK discovered free space marked as allocated in the
master file table (MFT) bitmap.
Windows has made corrections to the file system.
Sieht doch nicht so schlimm aus oder? Aber das System muss ja noch einmal neu booten nach den Korrekturen. Aber warum noch einmal Chkdsk?
Checking file system on C:
The type of the file system is NTFS.
Volume label is Vista64.
A disk check has been scheduled.
Windows will now check the disk.
Cleaning up minor inconsistencies on the drive.
The security data stream entry at offset 0x1bfff0 with length 0x80010033
crosses the page boundary.
The security data stream entry at offset 0x4bfff0 with length 0x80010033
crosses the page boundary.
Repairing the security file record segment.
Deleting an index entry with Id 4971 from index $SII of file 9.
Deleting an index entry with Id 9614 from index $SII of file 9.
Deleting an index entry with Id 9614 from index $SDH of file 9.
Deleting an index entry with Id 4971 from index $SDH of file 9.
Replacing invalid security id with default security id for file 1.
Replacing invalid security id with default security id for file 2.
2 Stunden später...
Replacing invalid security id with default security id for file 27789.
Reboot und schwarzer Bildschirm. Nichts geht mehr. Was war passiert?
Anscheinend gab es einen Fehler, welcher die Sicherheits- und Zugriffseinstellungen der Dateien betrifft. Ohne genaue Erklärungen: Chkdsk repariert einen Fehler und setzt alle Dateien auf der Partition zurück auf die ursprünglichen Zugriffsrechte. Und schon hat das Betriebssystem keinen Zugriff mehr auf einen beachtlichen Anteil seiner Daten. Zugriffsrechte für den Benutzer-Ordner? Sicherlich alles hier: System, Authenticated User, TrustedInstaller.. aber nichts was einen Benutzer darauf zugreifen ließe. So sieht es nun mit nahezu allen Daten aus.
Was hilft? Abgesicherter Modus, Vista-DVD-Repair-Modus, Letzte bekannte funktionierende Konfiguration? Alles Fehlanzeige. Also zweites Betriebssystem auf der nächsten Partition starten und Daten retten.
Checking file system on C:
The type of the file system is NTFS.
Volume label is XP64.
A disk check has been scheduled.
Windows will now check the disk.
Cleaning up minor inconsistencies on the drive.
... und auch hier das gleiche Spiel von Vorne. Nach einer Stunde macht sich aber ein Unterschied bemerkbar. Windows XP ist weit weniger penibel was die Zugriffsrechte betrifft. Das System startet bis zum Desktop. Allerdings sind nahezu alle Dienste deaktiviert und der Administrator hat keine Rechte. Das wars dann wohl.
Eine Suche im Internet bringt 3 Erkenntnisse:
1) Das geht auch wenigen Anderen so (XP und Vista)
2)Da hat auch keiner eine Lösung. Neuinstallieren soll angeblich helfen ;)
3)Bei Microsoft gibt es Artikel zu genau diesem Problem. Diese betreffen allerdings Windows2000! und XP vor den neuesten Servicepacks. Kein Wort von Vista...
Zum Glück befindet sich noch ein 3. System auf dem PC, welches auf einer 2. Festplatte residiert. Wie durch ein Wunder ist hier kein Fehler zu erkennen. Nach dem Neustart der erste Glücksmoment: Die Daten sind noch da. Die Sicherheitseinstellungen unterscheiden sich jedoch gravierend von denen im laufenden System. Was würde nun passieren, wenn man diese ändert?
Es ist nahezu unmöglich alle Zugriffsrechte wieder herzustellen. Manche erlauben Benutzerzugriff, andere nur vom System und zertifizierten Programmen. Also auf die harte Tour. Alle Dateien auf der gesamten Festplatte mit Zugriffsrechten für den Benutzer, Administrator und Ersteller/Besitzer ausgestattet. Und siehe da – es läuft.
Beide Systeme sind nun wieder in Benutzung. Allerdings kann wohl keine Rede mehr von Sicherheit sein. Es hat schon Gründe, warum es unterschiedliche Zugriffsrechte gibt. Allerdings sind die Systeme ausschließlich für Benchmarks im Einsatz. Daher kann auf die dringend benötigte Neuinstallation vorerst verzichtet werden.
Aber wer war nun Schuld an der ganzen Sache? Konkrete Beweise gibt es keine. Es sind allerdings nur 2 offensichtliche Änderungen am System vorgenommen worden. Zum einen eine Boot-Time-Defragmentation durch PerfectDisk2008. Zum anderen eine Woche zuvor die Aktivierung von AHCI für den SATA-Controller und der Installation des neuesten zugehörigen Intel Matrix Treibers.
Wer nun genau, oder beide zusammen – das bleibt offen. Treiber und AHCI sind weiter im Einsatz, Boot-Time-Defragmentation vorerst nicht. Und das Problem ist seit dem auch nicht mehr eingetreten.
Sollte übrigens jemand eine schnelle und exakte Lösung für dieses Problem haben, immer her damit. Das Zurücksetzen der Rechte mittels secedit hat aufgrund fehlender Zugriffsrechte allerdings nicht funktioniert.