Ein mittelgroßes Windows-Problem und dessen Lösung. Und weil es vielleicht für den ein oder anderen interessant sein könnte, den Weg zur Lösung, wie wir ihn als Techniker im Kundensupport gehen.
Problemstellung
Windows Vista. Ich starte meinen Rechner grundsätzlich immer “from the bottom”, also kalt. Das funktioniert unter Windows Vista im Gegensatz zu den Vorgängern flott und zügig, in der Regel ist nach spätestens einer Minute der Anmeldebildschirm da. Das funktionierte jahrelang auch so, bis es irgendwann nicht mehr so funktionierte – der Boot-Vorgang hing beim Booten am Fortschrittsbalken fest, der nach dem BIOS-Bildschirm und vor dem Windows-Trara kommt. Und er hing massiv.
Analyse 1 – Wo klemmt es eigentlich?
Zunächst dachte ich, die Kiste hängt final, was mich anfänglich dazu brachte, den Resetknopf zu betätigen. Das führte beim Neustart dazu, dass es schon wieder an der gleichen Stelle hing. Der erste Schritt war deshalb der, beim Neustart unmittelbar nach dem BIOS-Startbildschirm die F8-Taste zu drücken, um den Windows-Start zu verfolgen. Es stellt sich heraus, dass das Problem beim Laden von fundamentalen Systemdateien entsteht, nämlich beim Laden einer Datei mit dem Namen “crcdisk.sys”.
Diese Datei beinhaltet Funktionen zum windows-eigenen “CRC Disk Filter System”, vermutlich eine Art Technik, mit der der Zustand einer Festplatte auf unerfindliche Weise festgestellt werden kann. I dunno. Was verwunderlich war, war der Umstand, dass beim Hängen offensichtlich nichts mehr passierte, auch kein Festplattenzugriff mehr.
Die erste Suche im Internet nach dem Fehlerschema führt zu abenteuerlichen Lösungsansätzen. Beispiel: Festplatte ausbauen, an einen anderen Rechner anschließen, auf der Festplatte die Datei crcdisk.sys suchen und – löschen. Windows findet die Datei beim Booten nicht und überspringt dann das Laden (glücklicherweise).
Diese Vorgehensweise ist inakzeptabel, denn wer sagt mir, dass Windows irgendwann nicht ins Eiern kommt, wenn diese Datei fehlt?
Analyse 2 – Es klemmt gar nicht final!
In der ersten Verzweiflung überlegte ich, Windows neu aufzusetzen. Also ließ ich den vor sich hinhängenden Rechner für einen Moment allein, um am Notebook irgendwas zu recherchieren. Was genau, ist unwichtig, denn als ich wieder zurückkam, sah ich, dass der vor sich hinhängende Rechner plötzlich am Anmeldebildschirm war. Der Rechner hing also nicht final am Laden dieser “crcdisk.sys”, sondern macht tatsächlich irgendwann weiter, schätzungsweise nach ca. 10 Minuten. Und nach dem Anmelden läuft Windows auch völlig problemlos.
Analyse 3 – Liegt es an der Festplatte?
Wenn ein Treiber, der in irgendeiner Form unmittelbar mit der Festplatte interagiert, werde ich hellhörig, denn Festplattenprobleme kündigen sich selten und in diesen seltenen Problemen gern mit nicht nachvollziehbaren Symptomen.
Also, Festplatte testen. Zunächst einmal schauen, ob die Platte “dirty” ist, also irgendwie das Filesystem beschädigt ist oder sonstige Unfälle Windows dazu gebracht haben, das Dirty-Bit für eine Partition zu setzen. Ist eine Festplatte nämlich “dirty”, hat man danach zu schauen.
Also Eingabeaufforderung als Administrator starten und eingeben:
fsutil dirty query <Laufwerksbuchstabe:>
Das Ergebnis aller Partitionen war eindeutig: Alle Volumes sind nicht fehlerhaft. Trotzdem lässt man die Partitionen besser nochmal generalprüfen, das geht mit dem Kommandozeilenwerkzeug “chkdsk” in folgender Syntax:
chkdsk /f /r <Laufwerksbuchstabe:>
Dieser Prüfvorgang geht nur, wenn “chkdsk” exklusiv auf die Festplatte zugreifen darf, geht also nicht im Betrieb von Windows. “chkdsk” bietet deshalb an, dies beim nächsten Neustart zu tun. Bestätigen, für alle Partitionen und den Rechner neu starten. Dieser Prüfvorgang beim nächsten Neustart dauert in der Regel sehr lange, man darf mit einigen Stunden rechnen. Immerhin gibt es Fortschrittsanzeigen.
Das Durchnudeln von „chkdsk“ ergab, dass die Partitionen in Ordnung waren.
Analyse 4 – Huch, es geht wieder.
Tatsächlich schien das Problem behoben zu sein, Neustarts nach der chkdsk-Behandlung schienen wieder so schnell zu sein, wie vorher. Gut, aber wir halten mal ein Auge drauf.
Analyse 5 – Problem wieder da.
Genau das gleiche, Rechner hängt beim Boot-Vorgang, im abgesicherten Modus hängt der Startvorgang wieder beim Laden der “crcdisk.sys”. Noch einmal die Punkte von Analyseschritt 3 durchgezogen, nach ein paar Neustarts trat wieder der hängende Boot-Vorgang auf. Also, Nahkontrolle ist angesagt, letzter Schritt vor der Windows-Neuinstallation.
Analyse 6 – Um die Ecke schauen.
Schauen wir mal in den Gerätemanager, was denn die Hardware im Rechner macht. Und siehe da, hier klemmt etwas, nämlich die Firewire-Karte, ein No-Name-Produkt, das aber zumindest einmal funktionierte. Ein gelbes Warnsymbol meldete, dass der Treiber zu der Karte nicht geladen und die Hardware deshalb nicht gestartet werden konnte. Der angegebene Treiber ist ein “OHCI-kompatibler Treiber”, die Hardware wird also mit einem allgemeinen Windows-Treiber zu starten versucht. Interessanterweise hat diese Firewire-Karte so gar nichts mit der Festplatte zu tun, die ist per SATA an den PC angeschlossen, die Firewire-Karte über den PCI-Express-Anschluss und an dieser Firewire-Karte hängt auch nichts, außer ab und an mein Camcorder zum Einspielen von Filmmaterial.
Muss allerdings alles nichts bedeuten, Treiber haben oftmals Abhängigkeiten. Prinzipiell lässt sich per Firewire nämlich auch eine Festplatte anschließen und wenn ggf. die Firewire-Karte muckt, könnte das letztendlich auch Windows auf den Plan bringen, sich darüber zu wundern.
Das windows-eigene Ereignisprotokoll (in der Systemverwaltung zu finden) meldete zu diesem Vorgang, der unmittelbar beim Systemstart protokolliert wird, nichts detailiertes, die Hardware lässt sich nicht starten. Also, Hardware checken.
Das bedeutet: Rechner auf, Karte ausbauen, schauen, was da so montiert ist. Die Karte ist, wie geschrieben, No-Name, aber der dickste Chip auf der Karte trägt Informationen, nämlich dass er vom Chiphersteller VIA stammt und die Kennung “VT6306L” hat. Das ist ein recht weit verbreiteter Firewire-Chip, der allerdings, so die Information auf der Produkt-Website von VIA, keinen eigenen Treiber benötigt, sondern dieser von Windows-eigenen Treibern gestartet wird. Es macht also Sinn, nach Chip-Kennungen oder Nummern, die auf so No-Name-Karten aufgedruckt sind, in einer Suchmaschine zu suchen.
Okay, also mal schauen, was Windows für weitere Treiber zu dieser Karte anbietet. Also Karte wieder einbauen, Windows starten, Gerätemanager, Gerät auswählen, Treiber auswählen und zwar manuell. Und tatsächlich führt Windows noch einen weiteren Treiber für das Gerät auf, nämlich einen Treiber für VIA-Chipsätze. Aha, das sieht doch schon mal rein vom Namen her besser aus. Also dieser Treiber ausgewählt, ausprobieren.
Lösung – Karte beerdigen.
Kurzum: Auch dieser andere Treiber führte nicht zum Erfolg, die Karte ist auch mit dem anderen Treiber nicht ansprechbar. Also verlässt die Karte den Rechner und wird ausgebaut. Treiber müssen keine deinstalliert werden, Windows führt nach einem Neustart das ausgebaute Gerät schlicht nicht mehr auf. Dauertesten.
That’s it: Die Firewire-Karte war es. Hinüber. Und darauf wäre man nicht gekommen. Interessanterweise hätte hier vermutlich noch nicht mal die Windows-Neuinstallation geholfen, denn das offensichtliche Hardware-Problem wäre höchstwahrscheinlich auch in der neuen Windows-Umgebung aufgetreten. Vor dem Dampfhammer hilft es also durchaus, wenn man vorher etwas nachdenkt.
Schreibe einen Kommentar