SHDOCVW.DLL hat ungültige Prüfsumme – und macht viel Arbeit
Der WinXP-Home-PC eines Bekannten zeigte letzte Woche ein äußerst seltsames Verhalten: Beim Hochfahren kam ein Bluescreen:
Bad Image Checksum: SHDOCVW.DLL – The header checksum does not match the computed checksum.
Da es am vorherigen Tag noch einwandfrei funktioniert hat, war es also naheliegend, die SHDOCVW.DLL aus einer Sicherungskopie wiederherzustellen. Dank einer aktuellen Komplett-Sicherung mit Acronis TrueImage 9.0 war das kein großes Problem (damit kann man erfreulicherweise auch einzelne Dateien aus einem Image wiederherstellen). Nach dem Reboot ist WinXP SP2 dann auch sofort wieder hochgefahren – das war also einfach.
Ein danach ausgeführter CHKDSK /F C: brachte noch ein paar korrumpierte Verzeichniseinträge hervor, die zur Erklärung dieses plötzlichen Fehlers in der Datei beitrugen. Wen es interessiert: “shdocvw.dll is a library used by Windows applications to add basic file and networking operations.” Kein Wunder, dass Windows da moniert, wenn diese Datei nicht mehr gültig ist. Schon ein einfacher Vergleich der Dateigrößen und Datumsangaben von Original und korrumpierter Datei zeigt: Die kaputte Datei ist ein wenig größer – und: wichtig – neuer (23.10.06 versus August 2004 beim Original). Vielleicht also doch ein Virus?
Als dann am nächsten Tag der gleiche Fehler wieder auftrat, wurde ich stutzig. Nanu, schon wieder? An einen Virus oder Trojaner wollte ich weiterhin nicht so recht glauben, da ein aktueller Bitdefender Virenscanner installiert war. Der neuerliche Versuch, die Datei mit Acronis über die Notfall-Wiederherstellungs-CD zurückzukopieren, schlug jedoch fehl: Einen Total-Absturz in der Acronis-Oberfläche habe ich schon länger nicht mehr erlebt. Spätestens jetzt war klar, dass es kein reines Software-Problem sein konnte.
Nachdem das Gehäuse schnell geöffnet war, kam dann die bittere Erkenntnis: Geplatzte Elkos auf dem Mainboard. Das passiert üblicherweise, wenn der Mainboard-Hersteller (Albatron) zu billige Komponenten auflötet. Die leiden dann viel zu früh an Altersschwäche (ca. 3 Jahre nach dem Kauf in diesem Fall). Es waren keine langwierigen Diskussionen nötig: Ein Mainboard-Tausch stand an. Dabei sollten auch gleich CPU und RAM aufgerüstet werden. Eine Windows-Neu-Installation sollte jedoch vermieden werden. Kenner wissen: Kein leichtes Vorhaben. Windows reagiert bei einem Mainboard-Wechsel häufig allergisch (d.h. mit einem Bluescreen), wenn es für den neuen Festplatten-Controller keinen passenden IDE-Treiber parat hat. Das ist immer dann der Fall, wenn sich der Mainboard-Chipsatz in inkompatibler Weise ändert.
Die neue Hardware, ein Pentium D 2,8GHz mit 1GB RAM und Asus-Mainboard mit VIA-Chipsatz (richtig: oh Gott!) wurde also eingebaut. Erwartungsgemäß stürzte Windows beim Hochfahren mit einem Bluescreen 0×0000007B (inaccessible boot device) ab. Nach einigem Googlen und der Recherche in alten c’t Ausgaben habe ich folgende Lösung gefunden:
- Windows findet das Boot Device nicht, weil es nur den Treiber vom alten Chipsatz (Intel i865G) kennt und natürlich nicht auf die Idee kommt, die Standard-IDE-Treiber, mit denen so gut wie jedes Mainboard läuft, zu verwenden. Da müssen wir nachhelfen.
- Im Knowledge-Base Artikel 314082 schlägt Microsoft in diesem Fall die Neuinstallation vor – tolle Idee! Daneben gibt es jedoch auch eine nicht supportete Lösung: Man kann Windows die IDE-Treiber auch nachträglich noch unterschieben, indem man die Registrierung bearbeitet und für den eingebauten IDE-Controller die passenden Treiber einträgt. Das passiert normalerweise bei der Hardware-Erkennung des Setups automatisch – aber soweit kommt WinXP beim Booten ja erst gar nicht.
- Die Registrierung einer Windows-Installation, die nicht bootfähig ist, zu ändern, ist nicht einfach. Die Reparaturkonsole wäre vielleicht eine Lösung, ich habe aber keine Lust, mich mit dem Kommandozeilentool “reg.exe” zu quälen. Ich habe daher die Ultimate Boot CD 4 Windows verwendet, die mit Bart’s PE Builder erzeugt wurde. Dabei handelt es sich um ein WinPE, das von CD-ROM booten kann.
- Auf der UBCD4Win ist zum Glück ein Tool (ich denke es heißt Registry Editor PE oder so ähnlich) dabei, mit dem man die Registrierung einer bestehenden Windows-Installation in die aktuelle (WinPE-)Registrierung einblenden kann. Der Ast HKLM\SYSTEM findet sich dann als HKLM\SYSTEM_ON_C im Registrierungseditor. Nun muss man unbedingt das in der Knowledge-Base bereitgestellte File mergeide.reg anpassen, so dass es 1) den SYSTEM_ON_C Schlüssel verwendet und 2) statt CurrentControlSet (das es zum Zeitpunkt des Importierens nicht gibt) ControlSet001 verwendet. Gibt es mehrere durchnummerierte ControlSet00x-Zweige, sollte man sicherheitshalber getrennte mergeide.reg-Files erstellen und den Import nacheinander durchführen.
- In meinem Fall war übrigens die Vendor-ID 1106 (VIA) und die Device-ID 1057 (der normale VIA IDE Controller), der passende Treiber ist pciide.sys. Praktischerweise waren diese schon in der mergeide.reg aus der Knowledge-Base enthalten. Andernfalls hätte man das REG-File noch um einen passenden Eintrag ergänzen müssen (und dabei den passenden Treiber erraten müssen!). Wie kommt man auf die IDs? Nun, ich habe hierfür mit Knoppix gebootet und wollte mir mit less /proc/pci einfach die Geräteliste ausgeben lassen. Da das ProcFS inzwischen jedoch mehrfach überarbeitet wurde, stimmt dieser Pfad nicht mehr. Wenn ich mich richtig erinnere, gibt es die Datei /proc/bus/pci/devices, die eine Auflistung enthält. Da die Spalten nicht bezeichnet sind, muss man scharf hinsehen, um die IDs richtig herauszupicken. Die Suche nach Zeilen, in denen ein “IDE”-Treiber steht, schränkt die Auswahl jedoch ein.
- Nachdem man nun endlich die Registrierung aktualisiert hat, muss man evtl. noch die passenden Treiber aus dem “Driver Cache”-Verzeichnis in das System32/Drivers-Verzeichnis kopieren. Der KB-Artikel beschreibt das detailliert. Dieser Schritt war bei mir nicht nötig.
- Ist alles soweit überstanden, kann man Windows booten – im abgesicherten Modus erst einmal. Klappt das soweit, sollte man sich kurz Zeit nehmen, um sich selbst zur geglückten Operation zu gratulieren. Wenn man paranoid ist, macht man jetzt ein Voll-Backup und bootet Windows dann im Normal-Modus. Dort wird jede Menge neue Hardware erkannt, die man mit der mitgelieferten Treiber-CD des Mainboards installieren kann.
Bei mir gab es jedoch noch ein anderes Problem zu lösen. Richtig: SHDOCVW.DLL. Auch nach dem Board-Tausch hat Windows Probleme mit dieser Datei (gleicher Fehler wie eingangs). Als dann nach einem erneuten Ersetzen mit der Original-Datei von der Windows-Installations-CD nach einigen Reboots der Fehler noch einmal auftrat, wurde es langsam unheimlich.
Also habe ich in die Trickkiste gegriffen und mit Process Explorer und Rootkit Revealer die gesamte Installation nach Auffälligkeiten durchsucht. Außer falschem Alarm gab es jedoch nichts zu melden.
Nach langem Nachdenken kam ich dann auf die Idee, dass der Windows-Dateischutz (Windows File Protection, WFP, früher System File Protection, SFP) schuld sein könnte. Wahrscheinlich kopierte dieser immer wieder eine kaputte Datei über mein Original. Abhilfe brachte dann endlich das Ersetzen der gleichnamigen Datei im dllcache-Verzeichnis, wo WFP seine Sicherungskopien aufhebt.
Jetzt bootet der PC wieder einwandfrei. Puhhh, das war wieder mal ein Ärger.
1 Kommentar