GZB – Gero Zahns Blog – ger.oza.hn

Ein kurzer Praxistipp, der am Wochenende einen nicht mehr funktionstüchtigen Windows 7-Computer wieder flott gemacht hat. Auch wenn die Google-Suche zu classpnp.sys viel zu berichten weiß: Die u.a. rettende Idee hatte ich in dieser Form bislang noch nirgendwo gesehen.

Kurz zur Symptom-Beschreibung, damit sich Hilfesuchende hier wiederfinden:

• Das Windows 7 bootet extrem langsam.
• Der Bildschirm bleibt beim Booten sehr lange schwarz, anschließend gelangt man an den grün-blauen, leider leeren Anmeldebildschirm, wo zwar kurz das Aktivitäts-Rad erscheint, aber anschließend nur ein beweglicher Mauszeiger verbleibt, was sich auch minutenlang nicht ändert.
• Es hilft in dem Moment nur, den Computer durch ca. 5 Sekunden langes Gedrückthalten des Ausschalters zu Boden zu treten.
• Versucht man, den abgesicherten Modus zu starten, bleibt das System an der Datei classpnp.sys hängen.
• Wählt man stattdessen die angebotene Systemstart-Reparatur, kommt diese gar nicht erst an den Start, sondern bleibt wiederum am leeren grün-blauen Bildschirm hängen.
• Bootet man von einer Windows 7-Boot-CD und wählt dort ebenfalls die System-Reparatur, stockt diese ebenfalls unverrichteter Dinge am leeren grün-blauen Bildschirm.

So weit, so bekannt – diese Symptome hört man von vielen Betroffenen. classpnp.sys als solche ist wohl nicht das Problem; einige Google-Fundstellen deuten darauf hin, man solle die Maschine (sofern möglich) im abgesicherten Modus bzw. alternativ mit einer NTFS-read/write-fähigen Ubuntu-Live-DVD starten und die Datei system32/pcmcia.sys umzubenennen oder zu löschen. Von derart mittelalterlichen Methoden möchte ich ausdrücklich abraten.

Ich weiß leider auch nicht im Detail, was auf der Maschine schief läuft, das Bauchgefühl verheißt ein misslungenes Systemupdate. Einiges deutet dabei letztlich auf eine unvollständige oder fehlerhafte Hardwareerkennung hin. Der Umstand, dass diese nicht allein beim Startversuch des aktuellen, scheinbar beschädigten Systems misslingt, sondern ebenfalls beim Kaltstart vom Rettungsmedium, weist in eine andere Richtung.

So findet man im Internet mitunter den Hinweis, dass es manchmal schon ausreichen soll, im BIOS den SATA-Modus einmalig von AHCI auf IDE und anschließend wieder zurück auf AHCI zu stellen (bzw. alternativ umgekehrt). Ich bin noch einen Schritt weiter gegangen:

• Ich habe im BIOS von AHCI auf IDE gewechselt. – Obacht: Dass das Windows in einem derart umgeschalteten Modus nicht mehr booten kann, ist nicht verwunderlich, sondern liegt an dem bei einer AHCI-Installation nicht mehr aktivierten IDE-Treiber (Stichwort: „inaccessible boot device“).
• Der Boot-DVD ist das aber egal, sie arbeitet (theoretisch) problemlos wahlweise via AHCI oder IDE.
• Das heißt: Nach Umschaltung von AHCI auf IDE lief die Systemstart-Reparatur vollkommen problemlos durch.
• Ich habe anschließend prophylaktisch die längere Systemstart-Fehlerbehebung mit der  Zeitprognose „eine Stunde und mehr“ durchlaufen lassen – von der keiner so genau weiß, was sie macht; ich vermute einen Konsistenz-Check aller Systemdateien.
• Beim abschließenden Neustart habe ich zurück von IDE auf AHCI umgestellt, damit das Windows nicht aufgrund des fehlenden SATA-Treibers vor die Wand rennt.

Wie schon so häufig jovial proklamiert: Boot’s, tut’s!

Share