5
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:
Auf Facebook teilen
Auf Twitter teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 605707
Url: https://administrator.de/tutorial/stop-error-0x0000007b-inaccessible-boot-device-605707.html
Ausgedruckt am: 24.12.2024 um 16:12 Uhr
5 Kommentare
Neuester Kommentar
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
Hallo @GrueneSosseMitSpeck,
Eigentlich ist das Problem mit dem Hochfahren bereits gelöst worden. Eventuell hast du den folgenden Satz überlesen:
Es geht hier primär darum nachzuvollziehen, was genau die Ursache war (ob Windows Update, manuelle Treiberinstallationen …) und warum das System nicht mehr mit der ursprünglichen SATA-Operation im BIOS - im RAID-Modus, was bei meisten DELL-Notebooks scheinbar die Standard-Einstellung ist - hochfährt.
Wenn dagegen relevante Log-Dateien (sämtliche Protokolle aus Installationen und Windows Updates …) auf dem betroffenen System ausgewertet werden würden, können sichere Rückschlüsse gezogen werden und erst wenn der gleiche Fehler reproduziert werden kann, wäre das Problem so stark eingegrenzt, sodass es möglich wäre genauere Fehlerursachen zu finden und sichere Beweise zu ziehen.
Wenn Reparaturen aus eigener Tasche bezahlt werden müssen, entstehen seitens des Geschädigten nicht unberechtigte Gedanken an Schadenersatz. Beweise sind nötig und dann an wen, wenn nicht an Intel, DELL und Microsoft …, insbesondere wenn sich das System durch Systemwiederherstellung (oder komplette Systemabbildung - noch nicht versucht) nicht retten lässt. Natürlich ist es auch dann ärgerlich, wenn festgestellt werden würde, dass das Problem rein aus Manipulationen resultiert.
In der digitalen Welt ist Schadenersatz aufgrund Systemprobleme noch schwer durchsetzbar, weil alles deutlich komplizierter zu überblicken und sicher zu beweisen ist und jeder gerne den Ball weitergibt, nicht zuletzt weil das Spektrum an Manipulationen viel breiter ist und sichere (unverfälschte) Beweise stark erschwert sind.
Schuldfinden lassen wir lieber beiseite. Und jedem passieren mal Fehler. Weil ich das System repariert habe, brennt mich natürlich um so mehr, die Fehlerursachen kennenzulernen und hier den Kreis zu schließen. "Keine Ahnung warum es passiert ist" ist halt nicht meine Art.
Ich hänge mal die "WindowsUpdate.log" hier an (oben eingefügt). Vielleicht erkennt einer mal doch was im Zusammenhang mit dem geschilderten Problem.
Deinen Fehler kann man nur eventuell reparieren, indem man die Festplatte … mountet und den fehlerverursachenden Treiber (irgendeine .sys Datei) tauscht.
Eigentlich ist das Problem mit dem Hochfahren bereits gelöst worden. Eventuell hast du den folgenden Satz überlesen:
Nach der Umstellung der SATA-Operation im BIOS von RAID auf AHCI, ging das Hochfahren nämlich dann auf Anhieb problemlos.
Es geht hier primär darum nachzuvollziehen, was genau die Ursache war (ob Windows Update, manuelle Treiberinstallationen …) und warum das System nicht mehr mit der ursprünglichen SATA-Operation im BIOS - im RAID-Modus, was bei meisten DELL-Notebooks scheinbar die Standard-Einstellung ist - hochfährt.
Die Registrydateien kannst du bei der Gelegenheit auch mit extrahieren, und auf einem laufenden Windows öffnen und auswerten.
Ein REG-Export wäre ein der einfachsten Sachen hier, nur halt um auszuwerten ist wiederum ein Vergleich zum Ursprungszustand nötig. Solange der vorherige Ist-Zustand nicht bekannt ist, können aus Vergleichen meist keine Erkenntnisse gewonnen werden, sondern es lässt sich nur rätseln. Wenn nämlich der vorherige funktionsfähige Zustand doch alleine von der REG abhängig wäre, wäre das System bereits mit der Option LastKnownGood ("Letzte als funktionierend bekannte Konfiguration" aus dem Startmenü / F8) wieder problemlos hochgefahren.Wenn dagegen relevante Log-Dateien (sämtliche Protokolle aus Installationen und Windows Updates …) auf dem betroffenen System ausgewertet werden würden, können sichere Rückschlüsse gezogen werden und erst wenn der gleiche Fehler reproduziert werden kann, wäre das Problem so stark eingegrenzt, sodass es möglich wäre genauere Fehlerursachen zu finden und sichere Beweise zu ziehen.
Wenn Reparaturen aus eigener Tasche bezahlt werden müssen, entstehen seitens des Geschädigten nicht unberechtigte Gedanken an Schadenersatz. Beweise sind nötig und dann an wen, wenn nicht an Intel, DELL und Microsoft …, insbesondere wenn sich das System durch Systemwiederherstellung (oder komplette Systemabbildung - noch nicht versucht) nicht retten lässt. Natürlich ist es auch dann ärgerlich, wenn festgestellt werden würde, dass das Problem rein aus Manipulationen resultiert.
In der digitalen Welt ist Schadenersatz aufgrund Systemprobleme noch schwer durchsetzbar, weil alles deutlich komplizierter zu überblicken und sicher zu beweisen ist und jeder gerne den Ball weitergibt, nicht zuletzt weil das Spektrum an Manipulationen viel breiter ist und sichere (unverfälschte) Beweise stark erschwert sind.
Schuldfinden lassen wir lieber beiseite. Und jedem passieren mal Fehler. Weil ich das System repariert habe, brennt mich natürlich um so mehr, die Fehlerursachen kennenzulernen und hier den Kreis zu schließen. "Keine Ahnung warum es passiert ist" ist halt nicht meine Art.
Ich hänge mal die "WindowsUpdate.log" hier an (oben eingefügt). Vielleicht erkennt einer mal doch was im Zusammenhang mit dem geschilderten Problem.
Hallo @ChriBo,
welcher meiner Knowledge nach nur Probleme macht.
Na, das ist schon mal eine Auskunft, welche hier auch etwas weiter hilft.Dauert 2 Minuten, umstellen auf den richtigen Wert und der Drops ist gelutscht.
Per BIOS-Skript von DELL dauert es bloß Sekunde. Nur wie es halt so im Leben bei einer Fehlersuche ist, bis das Problem gefunden ist, vergehen manchmal Stunden, wenn nicht sogar Tage.In der Ereignisanzeige oä kannst du natürlich nichts finden, da das Bootsystem ja aufgrund des verkehren Modus nichts ins Windows Dateisystem schreiben kann.
Hier ist die Aussage nicht so ganz schlüssig, da ja das System davor jahrelang ordentlich funktioniert hat. Wenn bei DELL RAID ganz klar die Standard-Einstellung ist, müssten die gesuchten Änderungen verbunden mit diesem Problem noch vor dem Hochfahren mit BlueScreen höchstwahrscheinlich unter laufendem OS geschehen sein. Und wenn dem wirklich so ist, protokolliert ja Windows in der Regel sämtliche Änderungen.
(Edit: Satz "Nach der Umstellung der SATA-Operation im BIOS von RAID auf AHCI, ging das Hochfahren nämlich dann auf Anhieb problemlos" oben farblich hervorgehoben, da scheinbar überlesen wurde.)
