Stop Error 0x0000007B (INACCESSIBLE BOOT DEVICE)
Systemstand
IDE > ATA Channel 0
HINWEISE: Daten entnommen erst nach der Systemwiederherstellung. Es heißt also nicht, dass die hier angezeigten beiden Treiber (msahci.sys und atapi.sys) auch mit dem Stand vor dem aufgetretenen Problem oder auch nach dem Auftritt des Problems vor der Reparatur geladen waren. Nach der Systemwiederherstellung war das Hochfahren ebenso nicht möglich. Einzig ist jedoch klar, dass nur wenn in BIOS von RAID auf AHCI umgestellt wird, das System dann endlich hochfährt und zurück auf RAID wiederum nicht.
________________________________________
Hallo an alle,
es geht um ein DELL Notebook, das sich seit letzter Woche nicht mehr ganz hochfahren ließ, sondern etwa kurz vor dem Anmeldebildschirm mit dem Stoppfehler 0x0000007B (INACCESSIBLE_BOOT_DEVICE) abbrach.
Das System ließ sich auch nicht in den abgesicherten Modus und auch nicht in den abgesicherten Modus mit Eingabeaufforderung hochfahren.
Alle klassischen Reparaturschritte wie die nachfolgenden, welche jeweils ohne Fehler abliefen, konnten das Problem nicht beheben, weil es ja gar keine Fehler in deren Zusammenhang zu korrigieren gab:
Wenn Windows mit der letzten als funktionierend bekannten Konfiguration immer noch nicht anläuft, wird normalerweise angenommen, dass ein fehlerhaftes Gerät das System stört. Ein Hardwaredefekt kann hier jedoch nicht sein, da ja die Durchführung der restlichen obigen Schritte gar nicht möglich wäre bzw. spätestens zu deren korrekten Abschluss nicht. Ein Test auf einem anderen baugleichen Notebook hätte das problemlos spätestens dann bestätigen können, so eins war aber noch nicht zur Verfügung, da die Reparaturen gleich nach Feierabend dringend erfolgten und sich bis in die Nacht hinausgezogen haben.
Die Startprotokollierung ("Enable Boot Loging"), ließ sich zwar sowohl über das Startmenü (Bootmenü F8), als auch dauerhaft im BCD-Speicher (bcdedit set {default} bootlog Yes) aktivieren, jedoch die Protokolldatei ntbtlog.txt wurde immer wieder nicht erstellt, auch kein MiniDump (*.dmp) und FullDump (MemoryDump), trotz der mehrfach explizit gewählten Option zur Erstellung eines Kernelspeicherabbildes im Startmenü (F8).
Nachdem alles nicht zum Erfolg führte, blieb nichts anders übrig als erneut im BIOS nachzuschauen, weil gleich am Anfang der dort gesetzte RAID-Modus sehr ins Auge stach und nicht in Ruhe gelassen hat. Jedoch wurde wegen der Aussage "am Rechner wurde nichts gemacht" der Versuch es gleich auf einen anderen Modus zu wagen wiederum unterdrückt hat, sodass beim Fortfahren mit der Fehlerbehebung die Priorität erst auf die oben erwähnten Schritte davor gesetzt wurde. Die Überlegung war also erstmals die einfacheren und naheliegend logischen Reparaturmethoden anzuwenden, da es sehr unwahrscheinlich erschien, dass einer im BIOS herumgespielt hat.
Nach der Umstellung der SATA-Operation im BIOS von RAID auf AHCI, ging das Hochfahren nämlich dann auf Anhieb problemlos. Dies heißt nun immer noch nicht, dass das System alleine durch eine manuelle Verstellung von BIOS lahm gelegt sein müsste. Alle bisherigen Anzeichen lassen stark vermuten, dass die betroffenen Änderungen in der gesamten Kette zw. OS und Datenträger eher alleine auf der OS-Ebene geschehen sind. Bei DELL ist angeblich der RAID-Modus generell die Standard-Einstellung, auch selbst bei einem einzigen Datenträger.
Wie es aussieht hätte selbst das Zurückspielen eines gesicherten Systemabbildes das Problem ebenso nicht beheben können.
Und System neu aufzusetzen, wäre ebenso unbezahlbar.
Die Fehlerbehebung hat mit 9 Stunden atemloser Arbeit ordentlich viel Zeit geschluckt und einiges nachher natürlich, so wie es sich halt bei solchen Reparaturarbeiten gehört (Protokollierung, Beschreibung, Begründung, Erklärung …).
Gesagt wurde, dass am Rechner keiner was verstellt hat. Plötzlich fuhr er am letzten Wochenende nicht mehr hoch.
Nun muss festgestellt bzw. soweit es geht eingegrenzt werden was genau die Ursache war bzw. zumindest wahrscheinlich sein könnte.
In der Protokollierung von Windows Update (%WinDir%\WindowsUpdate.log) ist bis zum 10.09.2020 jeden Tag an Updates-Installationen zu sehen.
(In der "%WinDir%\inf\setupapi.app.log" wurde noch nicht nachgeschaut).
Microsoft kann natürlich mit einem Update was in der Registrierung geändert haben, wie z. B. hier
AHCI-Modus aktivieren
IDE-Modus aktivieren
u. ä. … was dann ebenso zum selben Stoppfehler führt, wenn die zu ladenden Treiber nicht dem SATA-Modus (mit den in BIOS gesetzten Einstellungen des SATA-Controllers) entsprechen.
Allerdings würden solche einfache Änderungen ja dann nicht mit der Systemwiderherstellung passen (welche jeweils problemlos verlief - sicherheitshalber wurde das System sogar 3 Mal auf einen früheren Zeitstand fehlerfrei zurückgesetzt), weil spätestens dann wären solche Änderungen vollständig rückgängig gemacht, allerdings brach das Hochfahren weiterhin mit dem obigen BlueScreen ab. Bzw. vor allem beim Zurücksetzen des Systems auf den letzten bekannten erfolgreichen Start (über das Startmenü / F8) hätte ja so ein Problem beheben können, was ebenso nicht der Fall war.
In der Windows Ereignisanzeige konnte mit dem Suchbegriff "RAID" (vor allem unter Windows Protokolle > Installation) nichts gefunden werden.
Das Thema "AHCI RAID BlueScreen" ist mehrere Jahre alt und zieht sich bis heute noch. Anbei die ersten zwei - drei Ergebnisse aus dem i-Netz aus den letzten zwei Wochen und es könnte hier sich eventuell um das gleiche oder ein ähnliches Problem handeln:
Aktualisierungen zu diesem Fall werde ich dann hier veröffentlichen, wenn es neue Erkenntnisse gibt.
Soweit viele Grüße von mir und es würde mich sehr freuen, wenn ihr in diesen Fall auch mal mit eurer Fachkompetenz hineinblicken könntet und eure Tipps dazu ergänzt, wonach noch zu schauen wäre.
Anhänge
- Windows 7, 64-Bit, einschließlich allen Updates bis 10.09.2020
- DELL Latitude E6330
- PCI-Bus
- IRQ-Kanal 19: Standard AHCI 1.0 Serieller-ATA-Controller
IRQ-Kanal 19: PCI Standard-PCI-zu-PCI-Brücke
IRQ-Kanal 19: Intel(R) Active Management Technology - SOL (COM3)
PNP-Gerätekennung: PCI\VEN_8086&DEV_1E03&SUBSYS_05331028&REV_04\3&gerätespezifische Nummer
Treiber c:\windows\system32\drivers\msahci.sys (6.1.7601.17514, 30,38 KB (31.104 Bytes), 21.11.2010 04:23) - 1x Datenträger => Systemdatenträger (1 TB HDD => mechanisch => Festplatte)
am ATA Chanel 0
(Seagate ST1000LM049-2GH172 ATA Device / SATA-III 6.0Gb/s)
IDE > ATA Channel 0
- Hersteller (Standard-IDE-ATA/ATAPI-Controller)
PNP-Gerätekennung PCIIDE\IDECHANNEL\gerätespezifische Nummer
Treiber c:\windows\system32\drivers\atapi.sys (6.1.7600.16385, 23,56 KB (24.128 Bytes), 14.07.2009 01:19)
HINWEISE: Daten entnommen erst nach der Systemwiederherstellung. Es heißt also nicht, dass die hier angezeigten beiden Treiber (msahci.sys und atapi.sys) auch mit dem Stand vor dem aufgetretenen Problem oder auch nach dem Auftritt des Problems vor der Reparatur geladen waren. Nach der Systemwiederherstellung war das Hochfahren ebenso nicht möglich. Einzig ist jedoch klar, dass nur wenn in BIOS von RAID auf AHCI umgestellt wird, das System dann endlich hochfährt und zurück auf RAID wiederum nicht.
________________________________________
Hallo an alle,
es geht um ein DELL Notebook, das sich seit letzter Woche nicht mehr ganz hochfahren ließ, sondern etwa kurz vor dem Anmeldebildschirm mit dem Stoppfehler 0x0000007B (INACCESSIBLE_BOOT_DEVICE) abbrach.
Das System ließ sich auch nicht in den abgesicherten Modus und auch nicht in den abgesicherten Modus mit Eingabeaufforderung hochfahren.
Alle klassischen Reparaturschritte wie die nachfolgenden, welche jeweils ohne Fehler abliefen, konnten das Problem nicht beheben, weil es ja gar keine Fehler in deren Zusammenhang zu korrigieren gab:
- System über das Startmenü (Bootmenü F8) auf den letzten bekannten erfolgreichen Start zurücksetzen (über die Option "Letzte als funktionierend bekannte Konfiguration")
- Systemwiederherstellung zu einem früheren Zeitpunkt (3 Mal auf die letzten 3 Standpunkte durchgeführt, jeweils mit Abstand und weiteren Untersuchungen)
- chkdsk /f /r
- sfc /scannow
(offline, etwa in einer Befehlskonsole von WinPE bzw. WinRE aus, geht dies generell nur mit der langen Syntax: sfc /scannow /offbootdir=c:\ /offwindir=c:\windows
Ansonsten tritt jeweils folgende oder ähnliche Fehlermeldung auf: "Es steht eine Systemreparatur aus, deren Abschluss einen Neustart erfordert. Starten Sie Windows neu, und führen Sie "sfc" erneut aus") - RAM-Diagnose
- Hardware-Diagnose
Wenn Windows mit der letzten als funktionierend bekannten Konfiguration immer noch nicht anläuft, wird normalerweise angenommen, dass ein fehlerhaftes Gerät das System stört. Ein Hardwaredefekt kann hier jedoch nicht sein, da ja die Durchführung der restlichen obigen Schritte gar nicht möglich wäre bzw. spätestens zu deren korrekten Abschluss nicht. Ein Test auf einem anderen baugleichen Notebook hätte das problemlos spätestens dann bestätigen können, so eins war aber noch nicht zur Verfügung, da die Reparaturen gleich nach Feierabend dringend erfolgten und sich bis in die Nacht hinausgezogen haben.
Die Startprotokollierung ("Enable Boot Loging"), ließ sich zwar sowohl über das Startmenü (Bootmenü F8), als auch dauerhaft im BCD-Speicher (bcdedit set {default} bootlog Yes) aktivieren, jedoch die Protokolldatei ntbtlog.txt wurde immer wieder nicht erstellt, auch kein MiniDump (*.dmp) und FullDump (MemoryDump), trotz der mehrfach explizit gewählten Option zur Erstellung eines Kernelspeicherabbildes im Startmenü (F8).
Nachdem alles nicht zum Erfolg führte, blieb nichts anders übrig als erneut im BIOS nachzuschauen, weil gleich am Anfang der dort gesetzte RAID-Modus sehr ins Auge stach und nicht in Ruhe gelassen hat. Jedoch wurde wegen der Aussage "am Rechner wurde nichts gemacht" der Versuch es gleich auf einen anderen Modus zu wagen wiederum unterdrückt hat, sodass beim Fortfahren mit der Fehlerbehebung die Priorität erst auf die oben erwähnten Schritte davor gesetzt wurde. Die Überlegung war also erstmals die einfacheren und naheliegend logischen Reparaturmethoden anzuwenden, da es sehr unwahrscheinlich erschien, dass einer im BIOS herumgespielt hat.
Nach der Umstellung der SATA-Operation im BIOS von RAID auf AHCI, ging das Hochfahren nämlich dann auf Anhieb problemlos. Dies heißt nun immer noch nicht, dass das System alleine durch eine manuelle Verstellung von BIOS lahm gelegt sein müsste. Alle bisherigen Anzeichen lassen stark vermuten, dass die betroffenen Änderungen in der gesamten Kette zw. OS und Datenträger eher alleine auf der OS-Ebene geschehen sind. Bei DELL ist angeblich der RAID-Modus generell die Standard-Einstellung, auch selbst bei einem einzigen Datenträger.
Wie es aussieht hätte selbst das Zurückspielen eines gesicherten Systemabbildes das Problem ebenso nicht beheben können.
Und System neu aufzusetzen, wäre ebenso unbezahlbar.
Die Fehlerbehebung hat mit 9 Stunden atemloser Arbeit ordentlich viel Zeit geschluckt und einiges nachher natürlich, so wie es sich halt bei solchen Reparaturarbeiten gehört (Protokollierung, Beschreibung, Begründung, Erklärung …).
Gesagt wurde, dass am Rechner keiner was verstellt hat. Plötzlich fuhr er am letzten Wochenende nicht mehr hoch.
Nun muss festgestellt bzw. soweit es geht eingegrenzt werden was genau die Ursache war bzw. zumindest wahrscheinlich sein könnte.
In der Protokollierung von Windows Update (%WinDir%\WindowsUpdate.log) ist bis zum 10.09.2020 jeden Tag an Updates-Installationen zu sehen.
(In der "%WinDir%\inf\setupapi.app.log" wurde noch nicht nachgeschaut).
Microsoft kann natürlich mit einem Update was in der Registrierung geändert haben, wie z. B. hier
AHCI-Modus aktivieren
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msahci]
"Start"=dword:00000000
[HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\IastorV]
"Start"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\pciide]
"Start"=dword:00000003
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\pciide]
"Start"=dword:00000000
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\msahci]
"Start"=dword:00000003
u. ä. … was dann ebenso zum selben Stoppfehler führt, wenn die zu ladenden Treiber nicht dem SATA-Modus (mit den in BIOS gesetzten Einstellungen des SATA-Controllers) entsprechen.
Allerdings würden solche einfache Änderungen ja dann nicht mit der Systemwiderherstellung passen (welche jeweils problemlos verlief - sicherheitshalber wurde das System sogar 3 Mal auf einen früheren Zeitstand fehlerfrei zurückgesetzt), weil spätestens dann wären solche Änderungen vollständig rückgängig gemacht, allerdings brach das Hochfahren weiterhin mit dem obigen BlueScreen ab. Bzw. vor allem beim Zurücksetzen des Systems auf den letzten bekannten erfolgreichen Start (über das Startmenü / F8) hätte ja so ein Problem beheben können, was ebenso nicht der Fall war.
In der Windows Ereignisanzeige konnte mit dem Suchbegriff "RAID" (vor allem unter Windows Protokolle > Installation) nichts gefunden werden.
Das Thema "AHCI RAID BlueScreen" ist mehrere Jahre alt und zieht sich bis heute noch. Anbei die ersten zwei - drei Ergebnisse aus dem i-Netz aus den letzten zwei Wochen und es könnte hier sich eventuell um das gleiche oder ein ähnliches Problem handeln:
- Promise AHCI Compatible RAID Controller - Causes BSOD
- Windows 7 fails to boot after windows update for "Promise AHCI Compatible RAID Controller"
Aktualisierungen zu diesem Fall werde ich dann hier veröffentlichen, wenn es neue Erkenntnisse gibt.
Soweit viele Grüße von mir und es würde mich sehr freuen, wenn ihr in diesen Fall auch mal mit eurer Fachkompetenz hineinblicken könntet und eure Tipps dazu ergänzt, wonach noch zu schauen wäre.
Anhänge
- WindowsUpdate.log:
Please also mark the comments that contributed to the solution of the article
Content-ID: 605707
Url: https://administrator.de/contentid/605707
Printed on: December 5, 2024 at 15:12 o'clock
5 Comments
Latest comment
Windows 7 und AHCI... Windows 7 unterstützt das nicht nativ speziell wenn man ohne SP1 angefangen hat sondern braucht einen Kernelmode-Treiber, der zum Bootzeitpunkt geladen werden muß. Sieht mir aber so aus, als ob er von dritter Seite durch eine inkompatible Version ersetzt wurde und der Windows Bootloader kann dann nicht mehr auf den SATA Controller zugreifen. Und aus irgendwelchen Gründen ist das nicht mitprotokolliert worden, so daß einem die Systemwiederherstellung nicht hilft.
Oder du hast so wie mein XPS15 von 2011 einen Hardwaredefekt, daß sich der SATA Controller (gefühlt 1 mal auf 20 Boots) nicht initialisiert und das Bios deshalb keine Festplatte findet. Ich hab schon die Festplatte getauscht und bei der Gelegenheit eine SSD eingebaut, aber das wars nicht.
Deinen Fehler kann man nueventuellr reparieren, indem man die Festplatte unter Linux mit Schreibzugriff mounted und den fehlerverursachenden Treiber (irgendeine .sys Datei) tauscht.
Die Registrydateien kannst du bei der Gelegenheit auch mit extrahieren, und auf einem laufenden Windows öffnen und auswerten.
Oder du hast so wie mein XPS15 von 2011 einen Hardwaredefekt, daß sich der SATA Controller (gefühlt 1 mal auf 20 Boots) nicht initialisiert und das Bios deshalb keine Festplatte findet. Ich hab schon die Festplatte getauscht und bei der Gelegenheit eine SSD eingebaut, aber das wars nicht.
Deinen Fehler kann man nueventuellr reparieren, indem man die Festplatte unter Linux mit Schreibzugriff mounted und den fehlerverursachenden Treiber (irgendeine .sys Datei) tauscht.
Die Registrydateien kannst du bei der Gelegenheit auch mit extrahieren, und auf einem laufenden Windows öffnen und auswerten.
Hi,
Ich sehe da kein Problem und keine Notwendigkeit Zeit zu investieren.
Bei Dell Laptops ist das BIOS Factory default der RAID mode, welcher meiner Knowledge nach nur Probleme macht.
Der erste Blick bei "Stop Error 0x0000007B (INACCESSIBLE BOOT DEVICE)" geht ins BIOS zu SATA mode und dann zur Boot methode (BIOS oder UEFI). Dauert 2 Minuten, umstellen auf den richtigen Wert und der Drops ist gelutscht.
Das ganze läßt sich auch am Telefon durchführen.
In der Ereignisanzeige oä kannst du natürlich nichts finden, da das Bootsystem ja aufgrund des verkehren Modus nichts ins Windows Dateisystem schreiben kann
CH
Ich sehe da kein Problem und keine Notwendigkeit Zeit zu investieren.
Bei Dell Laptops ist das BIOS Factory default der RAID mode, welcher meiner Knowledge nach nur Probleme macht.
Der erste Blick bei "Stop Error 0x0000007B (INACCESSIBLE BOOT DEVICE)" geht ins BIOS zu SATA mode und dann zur Boot methode (BIOS oder UEFI). Dauert 2 Minuten, umstellen auf den richtigen Wert und der Drops ist gelutscht.
Das ganze läßt sich auch am Telefon durchführen.
In der Ereignisanzeige oä kannst du natürlich nichts finden, da das Bootsystem ja aufgrund des verkehren Modus nichts ins Windows Dateisystem schreiben kann
CH