Classpnp.sys (272. Folge) - Wie ich per Offline-Reparatur eine Windows 7 - Havarie heldenhaft abwehren konnte

καλημέρα, liebe Kolleginnen und Kollegen,

es gab hier mal wieder ein geringfügiges Problemchen, für das auf die Schnelle keine Lösung im Internet zu finden war. Vielleicht hilft ja diese Vorgehensweise zur Windows 7 - Offlinereparatur (auch bei anderen Defekten im winsxs-Verzeichnis und bei streikendem sfc /scannow):

Kurze Zusammenfassung für alle Ungeduldigen

1) Diagnose,
2) Backup der havarierten Windows 7 - Installation,
3) Havarierten Windows\winsxs - Ordner löschen,
4) Intakte Windows 7 Installation über die beschädigte Installation kopieren,
5) Maschinenspezifische Registry-Dateien der havarierten Windows 7 - Installation zurückkopieren.

Die unten im Detail geschilderte Vorgehensweise ist übrigens recht allgemein gehalten und auf viele ähnlich gelagerte Probleme anwendbar. Sie sollte sich betriebssystemübergreifend entsprechend auch auf die Offlinereparatur von Windows 8 und Windows Vista übertragen lassen.

Und, damit es schön spannend bleibt, wählen wir dieses Mal einen spartanischen (griechischen!) Lösungsansatz ohne irgendwelche Software von Drittanbietern: Nur die einfache Eingabeaufforderung, wie durch das Windows 7 - Installationsmedium bereitgestellt, soll uns genügen, um es mit dem prüfsummengesicherten %SystemRoot%\winsxs - Automatikreparaturverzeichnis aufzunehmen. No gadgets required to get the job done. None, besides your brain.


Voraussetzungen

Man halte bereit:

• eine Windows 7 Installations-DVD (falls nicht zur Hand: Windows 7 90-Tage Evaluierungsversion; alternativ siehe diese Linkliste hier).
• eine intakte Windows 7 - Installation, entweder möglichst ähnlich oder gerne auch neu, ganz "frisch" auf einer separaten Partition / Platte erstellt, allerdings vollständig durchgepatcht und idealerweise auf der Ziel-Hardware installiert.

Die schmutzigen Details

Windows 7 blieb beim Booten reproduzierbar hängen. Der Bootvorgang brach beim Laden des Treibers classpnp.sys jeweils mit einem Neustart ab (vollständiger Pfad: C:\Windows\System32\drivers\classpnp.sys). Abgesicherter Modus, abgesicherter Modus mit Eingabeaufforderung, letzte bekannte Konfiguration, die üblichen F8-Bootoptionen … sämtlich und alles Fehlanzeige.

Die Fehlermeldung des Bluescreens lautete in diesem speziellen Fall:
STOP: C0000139 [Entry point not found]
The procedure entry point RtlCopyContext could not be located in the dynamic link library ntdll.dll.

Also Windows 7 CD – Service Pack 1 zur Hand genommen und Reparaturinstallation versucht (Kleiner Hinweis am Rande: Wenn man mit einer Windows 7 - DVD ohne SP versucht, eine SP1-Installation zu reparieren, erleidet man Schiffbruch; für einen solchen Fall besser ein aktuelles Slipstream-Installationsmedium erstellen).


Diagnose

• Die - bei ntdll.dll-Problemen obligatorische - Virenanalyse vom sauberen, externen Bootmedium mit aktuellen Signaturen war negativ. Nichts. Nada. τίποτα. Kein Virus. Das System war einwandfrei sauber.
• Hardwareseitig waren zunächst keine Beanstandungen feststellbar (Festplatte - SMART, Dateisystem, Speichertest, minimale Peripherie, Abschalten nicht benötigter Funktionalität im BIOS, etc ...).
• Systemwiederherstellung ging nicht, da Wiederherstellungspunkte nicht vorhanden waren bzw. nicht gefunden wurden.
• Ein Systemabbild war sowieso nicht vorhanden.
• Die Reparaturinstallation wollte ebenfalls nicht. Das Windows-System wurde zwar erkannt, aber die Reparaturinstallation brach mit dem Hinweis ab, das System ließe sich nicht reparieren.
• Eingabeaufforderung: sfc /scannow weigerte sich mit der Bemerkung, eine Reparatur stehe an, das System solle neu gestartet werden, um den Vorgang abzuschließen. Das Originalsystem bootete aber nicht, folglich ließ sich die Reparatur natürlich nicht abschließen und sfc wechselte die Systemdateien nicht aus. Die Schalter /offbootdir und /offwindir halfen ebenfalls nicht weiter, eine ggf. löschbare Datei im Pfad %SystemRoot%\winsxs\pending.xml existierte nicht.
• Jegliche(r) Manipulation, Austausch bzw. Löschung der classpnp.sys und aller Kopien bzw. Hardlinks im per Prüfsummen abgesicherten Windows\winsxs – Verzeichnis führten ebenfalls unweigerlich zum Abbruch des Bootprozesses, mit unterschiedlichen Fehlermeldungen.
• Sämtliche Trauerbekundungen über ähnliche Schadensmeldungen im Internet empfahlen an dieser Stelle eine Neuinstallation. No help available.
• Ein sog. „Backup“ gibt’s hier nicht. Sowas machen wir hier in Griechenland grundsätzlich nicht.

Andererseits wäre es in dieser Situation ausnahmsweise mal ganz nützlich gewesen (bzw. im Deutschen sagt man wohl, „es wurde mir nahegelegt“), das bestehende System mittels einer "Sicherheitskopie" schnellstmöglich wieder startfähig zu kriegen (wobei schnellstmöglich hier in Griechenland natürlich durchaus ein paar Tage bedeuten kann).


Back to action

OK, dann hilft nur die griechische Methode:

• Windows XP PE Boot CD bzw. Windows 7 PE Boot USB Stick einlegen und von CD / USB booten.
• Möchte man kein extra Boot-Medium erstellen, reicht es für die griechische Methode übrigens völlig aus, von der - hier ohnehin vorliegenden - Windows 7 Installations-DVD zu booten und die Eingabeaufforderung über die Reparaturoptionen aufzurufen (Falls gerade keine Installations-DVD zur Hand, hier der Link zur Windows 7 90-Tage Evaluierungsversion). Wir brauchen nicht mehr als bordeigene Software sowie eine einfache Windows 7 - Kommandozeile (mit der wir uns natürlich nicht am havarierten System anmelden, sondern extern darauf zugreifen).
• Alternativ klappt natürlich auch das Booten eines zweiten, parallel installierten Windows.

Backup (ok, nicht gerade griechischer Stil, hier aber leider nicht zu vermeiden)

Bestehende Windows 7 Installation sichern:

Beispiel: Wenn E:\ das Systemlaufwerk mit der beschädigten, nun zu klonierenden Windows 7 - Installation ist und nach F:\Systemkopie\2012-12-24 gesichert werden soll, dann lautet der Befehl:


Aah, ich liebe diesen Befehl. Man kann einfach alles mit ihm machen: System-Backups erstellen, Festplatten klonen, Offline-Reparaturinstallationen aller Art vorbereiten, bestehende Windows-Installationen in virtuelle Machinen oder gar auf neue Hardware überführen ... Aber @SlainteMhath wird fluchen: xcopy ist ihm zu langsam.

Jetzt müssen wir etwas warten. Das geht am Besten im Καφενεíο. Damit ist schon mal ein halber Arbeitstag herum. Aber was machen wir nun mit der zweiten Hälfte?

Nun, sobald xcopy fertig ist und so lange der Rechner noch von der Windows PE - Boot CD betrieben wird, löschen wir erst einmal ein paar Dateien, die wir schon immer mal löschen wollten ...


Havarierten winsxs - Ordner löschen

Weg damit. Der Ordner %SystemRoot%\winsxs auf der havarierten Windowsinstallation wird gelöscht. Sämtliche darin enthaltenen, womöglich beschädigten Dateien werden nicht mehr gebraucht. Im besten Falle fressen sie nur unnötig Platz, im schlechtesten Falle machen sie womöglich später irgendetwas unanständiges.

Beispiel: Wenn E:\ das Systemlaufwerk mit dem beschädigten Windows 7 - System ist, wird der folgende Ordner inklusive aller Unterordner gelöscht:


Im Beispiel erledigt das der folgende Befehl auf der Kommandozeile:



Intakte Windows 7 Installation über die beschädigte Installation überbügeln

Wir überspielen jetzt ein intaktes Windows 7 von einer weiteren Festplatte. Dazu verwenden wir eine möglichst ähnliche bzw. gerne auch neue, noch jungfräuliche (allerdings vollständig durchgepatchte) Windows 7 – Installation, die wir erneut per xcopy kopieren. Also: Rechner herunterfahren, ausschalten, eine Festplatte mit einer intakten Windows 7 - Installation einbauen (entweder eine möglichst ähnliche Installation, von vergleichbarer oder gar identischer Hardware und/oder eine mit möglichst wenigen gleichnamigen Usern) und erneut von der Windows PE Boot-CD starten. Wir nehmen mal an, die „neue“ bzw. intakte Windows 7 Installation wird unter H:\ angesprochen, während die beschädigte Windows 7 Installation immer noch unter E:\ zu finden ist. Dann lautet der Befehl:


Aah, ich liebe diesen Befehl. Aber @SlainteMhath wird kotzen.

Jetzt müssen wir wieder etwas warten. Das geht am Besten im Καφενεíο. So, nachdem xcopy seinen Job getan hat, ist jetzt schon fast Feierabend und der Rechner läuft immer noch nicht. Was machen wir jetzt?

Erstmal booten und sehen, ob das "neue" Windows startet. Jawoll. Das tut es erwartungsgemäß. Jetzt wollen wir aber wieder das "alte" System rekonstituieren, nur ohne zu riskieren, die "neuen" Windows-Systemdateien mit den alten, zerschossenen Dateien zu überschreiben - um dann erneute kryptische Fehlermeldungen oder gar Bluescreens zu kassieren.


Maschinenspezifische Registry-Dateien der havarierten Windows 7 - Installation zurückkopieren

Machen wir uns an dieser Stelle noch einmal klar, was wir bisher getan haben. Auf dem zu reparierenden Systemlaufwerk (hier E:\) sind ja alle Programmdateien der ursprünglichen Windows-Installation immer noch vorhanden. Lediglich gleichnamige Dateien wurden ersetzt (also u.a. alle Windows-Systemdateien und zugehörige Backups im Windows\winsxs - Verzeichnis, inklusive aller evtl. irgendwo versteckten Prüfsummen - das havarierte, obsolete winsxs-Verzeichnis hatten wir ja gerade gelöscht!).

Die benötigten Windows-Systemdateien sollten also jetzt intakt sein, das winsxs sollte nun auch wieder stimmen, inklusive aller Prüfsummen zum Systemschutz und zur automatischen Systemwiederherstellung. Bestehende Programm- und Benutzerdaten haben wir weder gelöscht noch verändert. Das gilt also auch für die in den Benutzerverzeichnissen gespeicherten, userspezifischen Registry-Daten.

Wenn wir also versuchen wollen, nur die minimal erforderlichen Dateien von der havarierten Installation zurückzuspielen, um den alten Systemzustand zu rekonstituieren und ohne das sensible Zusammenspiel zwischen Windows-Systemdateien und deren prüfsummengesicherten winsxs-Sicherungskopien irgendwie zu stören, langt es folglich völlig aus, wenn wir nun die Eingabeaufforderung öffnen und lediglich die maschinenspezifischen Registry-Dateien der ursprünglichen Windows-Installation auf die klonierte Installation zurück kopieren:



Die userspezifischen Registrydaten sind ja nach wie vor auf der Festplatte vorhanden (sofern nicht auf dem neuen System gleichnamige User vorhanden sind; in diesem Falle würden die userspezifischen Daten des alten Systems mit gleichnamigen Userdaten des "neuen" Systems überschrieben werden; Userdateien nicht gleichen Namens sowie User verschiedenen Namens auf beiden Systemen "akkumulieren" natürlich nebeneinander, ohne sich gegenseitig zu überschreiben, man bekommt am Ende also eine Summe aller nicht gleichnamigen Dateien des alten und des neuen Systems nebeneinander).

An den userspezifischen Registrydaten ändere ich natürlich nix. Ich kontrolliere nur mal eben schnell, ob auf den Accounts vom Scheff und von den Vorgesetzten alles stimmt; die Accounts der Kollegen zu kontrollieren, ist mir zu viel Arbeit. Es ist ja auch schon Feierabend.

So, noch mal schnell booten. Und siehe da: Alles schick.

Was mir an dieser Lösung so gut gefällt, ist, dass sie so schlecht ist.

BTW, dieser gesamte Beitrag wurde auf dem rekonstituierten Windows 7 - System verfasst, ganz gemäß dem "dogfood"-Prinzip.

Das wars.

Bis zum nächsten Mal und viel Erfolg!

Euer symphatischer, griechischer Sysadmin Stronzolios


Es muss ja auch mal EU-Hilfe aus Griechenland geben.