Fragensteller
Windows 7 BSOD IRQL_NOT_LESS_OR_EQUAL nach automatischer Treiberinstallation

Allgemeine Diskussion
-
Ich versuche eine Windows 7 Professional Installation von einem defekten Fujitsu Amilo Notebook als virtuelle Maschine wiederzubeleben. Dazu habe ich die Festplatte aus dem Notebook ausgebaut, ein Image erstellt und als Festplatte in eine VM eines KVM-Hosts eingebunden.
Die erste Hürde "inaccessible boot device" kann ich überwinden, indem ich die VM von einer Windows-7-Installations-CD boote, über die Computerreparaturoptionen den Registry Editor starte, den HKLM Hive aus dem Image lade und in HKLM\ControlSet001\services bei den Keys atapi und intelide den Wert Start von 3 auf 0 ändere. Die VM startet daraufhin erfolgreich, ich kann mich bei Windows anmelden und es funktioniert zunächst auch alles. Erwartungsgemäß meldet Windows jede Menge neu erkannte Hardware und installiert ohne Rückfrage Treiber dafür. Hier die Aufstellung aus dem Fenster "Gerätetreiberinstallation":
Intel(R) ICH9-Familie USB universeller Hostcontroller - 2934 -- OK Verwendung jetzt möglich
Intel(R) ICH9-Familie USB universeller Hostcontroller - 2935 -- OK Verwendung jetzt möglich
Standard-VGA-Grafikkarte -- OK Verwendung jetzt möglich
USB-Eingabegerät -- OK Verwendung jetzt möglich
AMD PCI Express (3GIO) Filter Driver -- OK Abgeschlossen. Ein Neustart ist erforderlich.
Intel(R) ICH9-Familie USB universeller Hostcontroller - 2936 -- OK Verwendung jetzt möglich
Intel(R) ICH9-Familie USB2 erweiterter Hostcontroller - 293A -- OK Verwendung jetzt möglich
Intel Xeon E312xx (Sandy Bridge) -- OK Abgeschlossen. Ein Neustart ist erforderlich.
PCI Standard-RAM-Controller -- OK Verwendung jetzt möglich
Intel Xeon E312xx (Sandy Bridge) -- OK Abgeschlossen. Ein Neustart ist erforderlich.
Intel 82371SB PCI-zu-ISA-Brücke -- OK Abgeschlossen. Ein Neustart ist erforderlich.
Intel(R) PRO/1000 MT-Netzwerkverbindung -- OK Verwendung jetzt möglich
Intel 82371SB PCI-Bus-Master-IDE-Controller -- OK Abgeschlossen. Ein Neustart ist erforderlich.
Intel 82441FX Pentium(R) Pro Prozessor-zu-PCI-Brücke -- OK Verwendung jetzt möglich
Audiocontroller für Multimedia -- X Es wurde kein Treiber gefunden.
USB-Root-Hub -- OK Verwendung jetzt möglich
USB-Root-Hub -- OK Verwendung jetzt möglich
Standardtastatur (PS/2) -- OK Abgeschlossen. Ein Neustart ist erforderlich.
ATA Channel 0 -- OK Abgeschlossen. Ein Neustart ist erforderlich.
Synaptics PS/2 Port TouchPad -- OK Abgeschlossen. Ein Neustart ist erforderlich.
ATA Channel 1 -- OK Verwendung jetzt möglich
USB-Root-Hub -- OK Verwendung jetzt möglich
System CMOS/Echtzeituhr -- OK Abgeschlossen. Ein Neustart ist erforderlich.
USB-Root-Hub -- OK Verwendung jetzt möglich
QEMU QEMU DVD-ROM ATA Device -- OK Verwendung jetzt möglich
QEMU HARDDISK ATA Device -- OK Abgeschlossen. Ein Neustart ist erforderlich.Zu diesem Zeitpunkt ist das System voll benutzbar. Sobald ich aber den verlangten Neustart durchführe, ist der Spaß vorbei. Es erscheint ein Bluescreen mit der Fehlermeldung IRQL_NOT_LESS_OR_EQUAL und der Meldung, ein Systemabbild werde geschrieben. Dann startet die VM automatisch neu und bietet mir eine Reparatur mit der Starthilfe an. Diese meldet nach einer halben Stunde Arbeit:
Die Starthilfe kann diesen Computer nicht automatisch reparieren.
Problemsignatur:
Problemereignisname: StartupRepairOffline
Problemsignatur 01: 6.1.7600.16385
Problemsignatur 02: 6.1.7600.16385
Problemsignatur 03: unknown
Problemsignatur 04: 1898
Problemsignatur 05: AutoFailover
Problemsignatur 06: 1
Problemsignatur 07: BadDriver
Betriebssystemversion: 6.1.7600.2.0.0.256.1
Gebietsschema-ID: 1033Diagnose- und Reparaturdetails:
Gefundene Fehlerursache:
--------------------
Das System kann möglicherweise aufgrund einer kürzlichen Treiberinstallation oder eines -upgrades nicht gestartet werden.
Reparaturaktion: Systemwiederherstellung
Ergebnis: Fehler, Fehlercode = 0x1f
Erstellungszeit = 309844 ms
Reparaturaktion: Integritätsprüfung und Reparatur von Systemdateien
Ergebnis: Fehler. Fehlercode = 0x490
Erstellungszeit = 561250 msDas angeblich geschriebene Systemabbild ist, wenn ich das Plattenimage anschließend in einem anderen System mounte, nirgends auffindbar. Die Datei \Windows\Memory.dmp, in der es normalerweise liegen sollte, existiert nicht, und selbst eine Suche über die ganze virtuelle Platte nach Dateien mit der Erweiterung .DMP bringt nichts zum Vorschein außer ein paar alten Firefox Crash Dumps aus der Zeit vor dem Hardwareausfall.
Das Ganze ist reproduzierbar. Ich kann ein neues Image der Notebook-Platte machen, und der Prozess verläuft wieder exakt gleich: System bootet, Windows installiert Treiber, System bootet nicht mehr.
Auslöser des Problems ist anscheinend der Treiber "AMD PCI Express (3GIO) Filter Driver", denn wenn ich diesen vor dem Neustart über den Gerätemanager deinstalliere, kann ich das System ein weiteres Mal erfolgreich neu starten. Die Freude ist allerdings von kurzer Dauer, denn beim nächsten Start installiert Windows ihn sofort wieder. Ob ich das System normal oder im abgesicherten Modus starte, ändert nichts. Auch diverse Änderungen in der VM-Konfiguration, die ich versucht habe, z.B. unterschiedliche Typen von emulierten Grafik-, Netzwerk- oder Sound-Adaptern, hatten keinen Einfluss.
Welche Optionen habe ich noch? Kann ich irgendwie verhindern, dass Windows den tödlichen Treiber installiert?
- Typ geändert Yavor TanevMicrosoft contingent staff Montag, 28. August 2017 08:07
Sonntag, 28. Mai 2017 10:23
Alle Antworten
-
Welche Optionen habe ich noch? Kann ich irgendwie verhindern, dass Windows den tödlichen Treiber installiert?
Ja. Im Gerätemanager die Device-ID abschreiben und anschließend unter LocalGPO unterbinden:
Evgenij Smirnov
I work @ msg services ag, Berlin -> http://www.msg-services.de
I blog (in German) @ http://it-pro-berlin.de
my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
Exchange User Group, Berlin -> http://exusg.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.comSonntag, 28. Mai 2017 15:02 -
Klingt vielversprechend. Wie kann ich die LocalGPO des Image bearbeiten, bevor ich es boote?
Hmm. Gute Frage. Abgesicherter Modus vielleicht? Ansonsten: Booten (einmal geht es ja), Treiber deinstallieren und im gleichen Zuge die LocalGPO bearbeiten.Evgenij Smirnov
I work @ msg services ag, Berlin -> http://www.msg-services.de
I blog (in German) @ http://it-pro-berlin.de
my stuff in PSGallery --> https://www.powershellgallery.com/profiles/it-pro-berlin.de/
Exchange User Group, Berlin -> http://exusg.de
Windows Server User Group, Berlin -> http://www.winsvr-berlin.de
Mark Minasi Technical Forum, reloaded -> http://newforum.minasi.comMittwoch, 31. Mai 2017 05:33 -
Der abgesicherte Modus bringt nichts, die automatische Treiberinstallation läuft trotzdem ab. Das hatte ich schon früher getestet.
Ich habe jetzt einige weitere Versuche durchgeführt, leider alle erfolglos. Hier ein kurzer Abriss, genauere Details gerne auf Anfrage:
Die im Gerätemanager angezeigten Hardware-IDs des "AMD PCI Express (3GIO) Filter Driver" lauten:
ACPI\PNP0A03
*PNP0A03Zunächst habe ich versucht, die vorgeschlagene GPO-Einstellung auf demselben Weg in das Image zu injizieren wie die Reaktivierung der ATAPI-Treiber, also Boot vom Windows7-CD-Image, Start von regedt32 aus dem Installationssystem heraus und Laden des Registry Hive - in diesem Fall C:\Windows\System32\config\SOFTWARE, um HKLM\Software\Policies\Microsoft\Windows\DeviceInstall\Restrictions anzulegen und zu befüllen. Das wurde leider ignoriert. Der "AMD PCI Express (3GIO) Filter Driver" wurde trotzdem wieder installiert.
Daraufhin habe ich im vorläufig laufenden System das Gerät "AMD PCI Express (3GIO) Filter Driver" im Gerätemanager deinstalliert - mit Entfernen der Treiberdateien. Vor dem angeforderten Neustart habe ich im Gruppenrichtlinien-Editor die Richtlinie "Installation von Geräten mit diesen Geräte-IDs verhindern" aktiviert, die Device-ID ACPI\PNP0A03 eingetragen und die Option "Auch auf übereinstimmende Geräte anwenden, die bereits installiert sind" aktiviert. Beim anschließenden Neustart im abgesicherten Modus erschien AtiPcie.sys trotzdem wieder in der Liste der geladenen Treiber, das System bluescreente und bot mir - wie bei den vorhergehenden Versuchen - eine Reparatur mit der Starthilfe an, mit exakt demselben Ergebnis wie im Ausgangsposting. ("Das System kann möglicherweise aufgrund einer kürzlichen Treiberinstallation oder eines -upgrades nicht gestartet werden." und "Windows kann diesen Computer nicht automatisch reparieren.")
Über die Erweiterten Wiederherstellungsoptionen - Kommandozeile - regedt32 habe ich dann wieder den SYSTEM-Hive geladen, unter ControlSet001\services erneut atapi und intelide aktiviert (Start von 3 auf 0) und zusätzlich AtiPcie deaktiviert (Start von 0 auf 4). Um den verfluchten Treiber auszumerzen, habe ich nach weiteren Einträgen mit dem String "AtiPcie" gesucht, die Keys ControlSet001\Control\Class\{4D36E97D-E325-11CE-BFC1-08002BE10318}\0012 und ControlSet001\Enum\ACPI\PNP0A08\1 gefunden und kurzerhand komplett gelöscht. Die darin referenzierten Dateien C:\Windows\inf\oem10.inf und C:\Windows\system32\drivers\AtiPcie.sys habe ich um ganz sicher zu gehen von der Kommandozeile aus in oem10.infDELETED und AtiPcie.sysDELETED umbenannt.
Beim anschließenden Neustart (wieder im abgesicherten Modus) kam das System dann tatsächlich wieder hoch, diesmal tatsächlich ohne AtiPcie.sys zu laden, meldete aber sofort: "Der Computer muss neu gestartet werden, damit die Änderungen wirksam werden." Da eine Kontrolle im Gerätemanager und in der Registry ergab, dass auf der Device-ID ACPI\PNP0A03 jetzt nicht mehr "AMD PCI Express (3GIO) Filter Driver" (oem10.inf / AtiPcie.sys), sondern "PCI-Bus" (machine.inf / pci.sys) installiert war, habe ich den Neustart ohne weitere Eingriffe durchgeführt. Trotzdem dasselbe Ergebnis wie immer beim zweiten Start: Bluescreen, Starthilfe, "Das System kann möglicherweise aufgrund einer kürzlichen Treiberinstallation oder eines -upgrades nicht gestartet werden", "Windows kann diesen Computer nicht automatisch reparieren."
Die anschließende Untersuchung aus dem Wiederherstellungssystem ergab, dass die beiden von mir umbenannten Dateien wieder mit ihren ursprünglichen Namen da waren. Auch die gelöschten Registry Keys waren zurück und verwiesen wieder darauf. Irgendetwas - ich habe die Starthilfe in Verdacht - hat also meine Datei-Umbenennungen rückgängig gemacht und den "AMD PCI Express (3GIO) Filter Driver" installiert. Auch die services-Keys atapi und intelide waren wieder auf Start=3 gestellt.
Nachdem ich atapi und intelide wieder auf Start=0 und AtiPcie auf Start=4 gestellt habe, konnte ich die VM ein weiteres Mal erfolgreich booten. Im Gerätemanager war das Gerät "AMD PCI Express (3GIO) Filter Driver" wieder vorhanden. In den Details stand:
- Allgemein
Das Gerät funktioniert einwandfrei.
Sie müssen den Computer neu starten, damit die am Gerät vorgenommenen Änderungen wirksam werden. - Details - Hardware IDs
ACPI\PNP0A03
*PNP0A03 - Ressourcen
Gerätekonflikt:
E/A-Bereich 0000-0CF7 wird verwendet von:
ACPI x86-basierter PC
Ich habe dann noch versucht, das Gerät einmal nicht zu entfernen, sondern nur in der Registry unter CurrentControlSet\services\AtiPcie Start wieder von 0 auf 4 zu setzen. atapi und intelide standen noch auf Start=0. Das war nicht genug, das System kam beim Neustart trotzdem nicht wieder hoch.
Fazit: Ich habe es bis jetzt nicht geschafft, das System vom Selbstmord durch Treiberinstallation abzubringen.
Montag, 5. Juni 2017 17:01 - Allgemein
-
Nach einigen weiteren erfolglosen Versuchen habe ich aufgegeben, nur die Anwendungsdaten von der Notebook-Platte kopiert und Windows mit allen Anwendungen in einer frischen VM neu installiert. Das hat natürlich geklappt. Es war halt nur mehr Arbeit als erhofft.
Heute bekam ich dann doch noch einen möglicherweise nützlichen Hinweis: das Dienstprogramm ServiWin von NirSoft soll tatsächlich in der Lage sein, den tödlichen Treiber dauerhaft zu deaktivieren. Ich kann es selbst nicht mehr testen, gebe den Tipp aber gerne hier weiter für den Fall, dass jemand mit demselben Problem auf diesen Thread stoßen sollte.
Sonntag, 20. August 2017 19:10