Ich mach derwegen ungern Backups, habe aber trotzdem jegliche Daten nahezu vollständig parat (selbst, wenn ein Restore etwas Suchen bedeutet). Gut, manche Kleinigkeiten fehlen dann zwar, aber das lässt sich in den meisten Fällen verkraften. So, wie es in diesem speziellen Fall von Dienstag Abend der Fall war: Ich wusste zumindest GANZ genau, welche Daten mir im Fall der Fälle fehlen würden. Denn, wie es nunmal manchmal mit Windows so ist: Irgendwann will es einen einfach nicht mehr lieb haben und verhält sich komisch.
So auch in diesem Fall. Ich war grad am Arbeiten, als Windows der Meinung war, dass er nicht auf Festplatte 0, Partition 4 schreiben könne. Nun handelt es sich dabei zwar um ein Ext3-Laufwerk, wo es schon für Normalbürger verwunderlich ist, dass ich das Nichtschreiben als Ausnahme verstehe, aber dank passender Treiber liegt der Normalfall für den Zugriff durch Windows in diesem Fall bei „funktioniert“.
Das System hatte auch bereits wieder eine Uptime von etwa 30 Tagen erreicht und inzwischen doch ein paar kleinere Lastspitzen aushalten müssen. Nein, nicht etwa, dass da 2,8 GiB von 2GiB physikalischem RAM belegt waren. Obwohl, das kam auch dazu, sondern ich meine GDI-Ressourcen-Engpässe, die durch eine Limitierung unter Win2K durch umfangreiche Anwendungen wie Azureus, Firefox, Thunderbird und einige weitere leicht auftreten können. Zwar ist mein Win2K in der Hinsicht schon etwas aufgebohrt (Registry-Settings auf das vierfache des Defaults erhöht), aber irgendwo sind halt doch Engpässe. Und leider auch Speicherlöcher beim Killen von Anwendungen, wodurch mit der Uptime der RAM immer mehr verstopft und der Spielraum für die laufenden Anwendungen immer weiter sinkt.
Der Regelfall beim Erreichen des GDI-Ressourcen-Limits sieht nun so aus, dass Windows einfach Probleme bekommt, die Anwendungen neu zu zeichnen und man mit einem taskleistengrauen Bildschirm zurückgelassen wird, auf dem außer der Maus nix weiter zu erkennen ist. Eine der bei mir laufenden Anwendungen ist nun auch der Prozess-Explorer, der in solchen Fällen einen gewissen Bug hat (nämlich besagtes Memory Leak), was zwar die belegten GDI-Resourcen wieder freigibt, aber dafür andere Resourcen, die durch den verwendeten Kernel-Mode-Treiber belegt wurden, reserviert hält. Das ist zwar jeweils nicht viel, reicht aber aus, um das System wieder in einen stabilen Zustand bzgl. GDI-Resourcen zu bekommen, dabei aber dennoch Handles zu verschwenden (Müsste bzgl. Process Explorer mal wegen Update schauen, hab nicht ganz die aktuelle Version am Start, denk aber, dass das Problem an sich nicht behoben sein wird).
In diesem speziellen Fall meckerte Windows also nicht mit Hilfe eines grauen Bildschirms, sondern durch besagte Fehlermeldung, die mich nicht weiter gestört hätte, wäre da nicht etwas anderes seltsames: Windows beschwerte sich zudem darüber, dass auf meiner Ext3-Platte kein freier Speicher sei, was bei 10,3 GiB Freiraum garantiert nicht der Fall war. Also habe ich kurzerhand eine Konsole geöffnet, um den freien Speicher zu verifizieren und die erwarteten 10,3 GiB vorgefunden. Ein Blick in die Ordner-Struktur war aber dann doch ein Alarmzeichen: Der Ordner /tmp (ja, ich nutze Unix-Pfade) beinhaltete nur einen Eintrag ., nicht jedoch .. – HIER stimmte also definitiv etwas nicht. Also: Sofort SANFTEN Shutdown angestoßen, letzte Dokumente abgespeichert (unter Vermeidung von C: und Z:. Ein harter Reset wäre hier zwar möglich wgewesen, da das System aber bereits inkonsistent war, wollte ich wenigstens die Caches und Logs der Filesystem-Treiber sauber auf der Platte wissen. Damit vermeidet man etwas Stress beim Reparieren der Dateisysteme.
Da ich auf Grund meiner Voruntersuchung wusste, dass die Ext3-Partition wahrscheinlich nicht konsistent war, ging es sofort im nächsten Arbeitsgang an das Einlegen einer Linux-Live-CD, um eine vollständige Prüfung der Partition vorzunehmen: Zuerst read-only, nach Überprüfung der durchzuführenden Änderungen auch mit Schreiberlaubnis. Außer ein paar Inkonsistenzen beim freien Speicherplatz war auf der Partition nichts zu beanstanden. Das Mounten der NTFS-Partition von Windows habe ich aus Linux nicht probiert, da ich davon ausging, dass diese nicht weiter in Mitleidenschaft gezogen wurde. Ein erneuter Startversuch von Windows widerlegte diese Annahme jedoch: Behauptete Windows doch, dass er /WINNT/SYSTEM32/CONFIG/SYSTEM nicht finden könne. Da es mittlerweile aber bereits Halb 3 war und ich den nächsten Tag kurz nach 7 aufstehen wollte/musste, war an dieser Stelle für’s Erste Schluss. Zudem fehlte mir grad ein für das weitere Vorgehen notwendiges Tool.
Heute ging es nun weiter. Der dabei wichtigste Schritt war es, mir die fehlenden Werkzeuge zu holen, die mir Mittwoch fehlten: Eine Windows-Boot-CD. Ja, sowas gibt es. Und ich mein nicht, diese lahmen Setup-CDs, nach deren Verwendung Windows zwar läuft, DAS Windows aber nicht mehr, sondern in meinem Falle eine BartPE, auf der nebst einem Dateimanager noch eine Reihe weiterer Tools für den Netzwerk-Zugang vorhanden waren.
Trotz der etwas ungewöhnlichen Konfiguration (Windows 2000 auf SATA-Platte) startete die CD erfolgreich und auch der Netzwerk-Chipsatz wurde problemlos erkannt. Womit auch ein weiterer Schritt begannt: Ziehen eines Backup-Images der Platte; schließlich wollte man ja was zum Zurückspielen haben, um die Zerstörung seines Systems nochmals probieren zu können. Aber bevor es dafür soweit war, gab es einen Testlauf nach dem Motto „no Risk, No Fun“ und die Ausgabe des Read-Only-Chkdsk sah auch viel versprechend aus: 4 inkonsistente Dateieinträge und paar Unstimmigkeiten in den Index-Tabellen: Kurzum beste Voraussetzungen dafür, dass man Chkdsk mal auf’s Laufwerk schreiben lassen kann (was ich keinem empfehlen möchte, der nicht absolut weiß, was er an dieser Stelle tut!!!).
Dateisystem korrigiert, Backup beauftragt. aDas hieß für 7GiB über 100MBit etwa 4 Stunden warten. Weitere 8 Stunden gingen danach für das Verifizieren des Backups drauf. Wenn man schon ein defektes Backup hat, sollte dieses wenigstens konsistent kaputt sein. Sorry, ich werd zynisch 😉
Achja, stimmt. Wir waren bei Inkonsistenzen. Da die Ext3-Partition defekt war, die Windows-Partition defekt war und Windows trotz der Reparatur beider partitionen IMMER noch nicht bootete, gab es nun noch einen Versuch, der die Lösung für einen erfolgreichen Systemstart darstellte: Man spielt ein Backup ein 😛 Nicht irgendeines, aber mit der Sicherung der Registry klappt es manchmal.
copy system.alt system
Kurzer Reboot … und Windows strahlt einen wieder genauso jungfräulich wie die Einlagerungen der Asse an. Alles noch da und selbst das Benutzerprofil hat es zu meiner Verwunderung überlebt. Immerhin was. Hatte schon die Befürchtung, mein System auf Linux umstellen zu müssen. Denn Neuinstall heißt Linux. So konsequent bin ich dann wenigstens. Auch wenn ich schon nicht gerne neu installiere. Aber irgendwie halte ich doch an meinen alten Systemen fest, auch wenn mich für dieses Windows schon so mancher schräg angeguckt hat.
Aber wenigstens bootet es (wieder)!
