Acer: Ärger mit dem VMD-Controller - inaccessible boot device
Guten Abend, liebe Gemeinde,
heute möchte ich ein Problem schildern, für das ich im Grunde keinen Support mehr benötige, dessen Lösung aber möglicherweise andere vor Schiffbruch bewahren mag. Und wenn das Fachleute unter Euch kommentieren mögen, lerne ich sicher auch noch was dazu. Ich entschuldige mich im Voraus für den vielen Text – kürzer habe ich’s nicht hinbekommen.
Folgendes Problem:
Acer-Notebook, gekauft im Mai 2021, lief seither einwandfrei mit Windows 10 (21H1). Letzte Woche wollte es nach regulärem Herunterfahren nicht mehr starten: Bluescreen mit dem Hinweis „Stop Code … - inaccessible boot device“. Die interne SSD konnte zwar mit Linux Live-System angesprochen werden, war aber verschlüsselt, und den Schlüssel kannte ich nicht (weil mir bei der Erstinstallation nicht aufgefallen war, dass Verschlüsselung aktiviert worden war). Daher war keine Kopie möglich. Schade eigentlich … Sicher sollte man grundsätzlich immer ein Backup haben, aber ich weine hier nicht in erster Linie den verlorenen Daten nach.
Also habe ich es erstmal mit Reparaturen versucht, aber alle Ansätze wie abgesicherter Modus, Installations-Stick und -CD scheiterten immer am „inaccessible boot device“. Schließlich wollte ich eine Reparatur- oder notfalls Neuinstallation versuchen, aber es wurde kein interner Datenträger gefunden. Weil das System zuvor ja einwandfrei gelaufen war (und ich schon eine andere SSD nach wenigen Wochen habe abrauchen sehen), verwarf ich die Idee, irgendwelche Treiber laden zu wollen und glaubte an einen Hardware-Defekt. (Die Sichtbarkeit unter Linux hätte mich vielleicht stutzig machen sollen.)
Über den Verlauf habe ich ausgiebig mit dem Acer-Support konferiert, der auch ein paar Ideen hatte, schließlich aber eindeutig erklärte, dass das Gerät wegen eines offensichtlichen Defekts zur Reparatur eingeschickt werden müsse. Also Gerät verpackt, genaue Fehlerbeschreibung beigefügt und ausdrücklich mitgeteilt, dass mangels Zugreifbarkeit keine Sicherungskopie existiert und deshalb darum gebeten wird, mir im Falle des Austausches des Datenträgers den alten zurückzuschicken, damit ich ggf. einen Datenrettungsversuch starten kann (wenngleich der vermutlich an der Verschlüsselung gescheitert wäre). Damit war zumindest klar, dass die Daten nicht leichtfertig geopfert werden sollten.
Nach einer Woche kam das Gerät zurück mit dem Hinweis, dass es keinen Hardware-Fehler gebe, man aber testweise Windows über das MCT installiert habe (was mir, s.o., nicht gelungen war). Weiterer Hinweis: Da die eingebaute SSD recht neu sei, werde sie vom MCT evtl. noch nicht unterstützt, ggf. müsse man die IRST-Treiber installieren. Das las sich für mich, als wäre der fehlerhafte Boot-Vorgang nur auf ein Treiberproblem zurückzuführen gewesen. Ich habe dann erstmal das vorinstallierte Windows fertig eingerichtet und in den Wartezeiten per Mail um weitere Erläuterung gebeten, wie es zu dem plötzlichen Ausfall nach mehrmonatigem Betrieb kommen konnte. Die Antwort kam bemerkenswert schnell, hat mich aber echt ernüchtert. Ich fasse die Antwort mal zusammen:
Das System habe wohl ein Update bekommen, bei dem das BIOS zurückgesetzt worden sei. Ich möge bitte im BIOS den VMD-Controller deaktivieren, dann sei auch bei Neuinstallation der interne Datenträger sichtbar. Um die Einstellung zu sehen, müsse ich lediglich STRG+S drücken.
Das habe ich sofort getestet: Mit aktiviertem VMD lief das im Rahmen der Reparatur von Acer vorbereitete und inzwischen vollständig installierte Windows normal, nach dem Deaktivieren kam der o.g. Bluescreen. Umgekehrt konnte der Installations-USB-Stick bei aktiviertem VMD keinen Datenträger finden. War VMD jedoch deaktiviert, hätte ich installieren können. Das habe ich schließlich gemacht, was dann die vierte Neuinstallation seit Inbetriebnahme war – inkl. aller Updates und Datenschutzeinstellungen etc.
Fazit: Hätte ich damals, als der Boot-Vorgang zum ersten Mal scheiterte, einfach nur den VMD-Controller deaktivieren müssen?? Das war wirklich alles??? Ja, ich hatte das BIOS komplett durchgesehen und mit verschiedenen Einstellungen experimentiert, aber dass einige davon versteckt sind, war für mich nicht ersichtlich - und ich sehe dafür auch keinen vernünftigen Grund.
Jetzt kommt aber das große Fragezeichen: Warum hat nicht der Acer-Support im Rahmen der „Reparatur“ die Einstellung einfach geändert und meine Daten in Ruhe gelassen? Oder mich schon bei meiner Service-Anfrage auf die Möglichkeit im BIOS hingewiesen? Dann wären die Daten nicht weg und der Aufwand seeeehr viel geringer gewesen.
Warum ich bei einem Laptop, der ohne RAID arbeitet, VMD überhaupt brauche, habe ich auch noch nicht herausgefunden. Jedenfalls habe ich die Neuinstallation jetzt mit deaktiviertem VMD-Controller gemacht (wie von Acer vorgeschlagen) und erinnere mich hoffentlich an STRG+S, wenn nach einem künftigen Update wieder kein SSD-Zugriff gelingt.
Der Rechner läuft bei mir nun wieder, jungfräulich und frei von meinem alten Ballast, nach einer langen, unnützen Reise. Danke für's Mitlesen!
Ich wünsche allen noch einen update-freien Abend
ruby
heute möchte ich ein Problem schildern, für das ich im Grunde keinen Support mehr benötige, dessen Lösung aber möglicherweise andere vor Schiffbruch bewahren mag. Und wenn das Fachleute unter Euch kommentieren mögen, lerne ich sicher auch noch was dazu. Ich entschuldige mich im Voraus für den vielen Text – kürzer habe ich’s nicht hinbekommen.
Folgendes Problem:
Acer-Notebook, gekauft im Mai 2021, lief seither einwandfrei mit Windows 10 (21H1). Letzte Woche wollte es nach regulärem Herunterfahren nicht mehr starten: Bluescreen mit dem Hinweis „Stop Code … - inaccessible boot device“. Die interne SSD konnte zwar mit Linux Live-System angesprochen werden, war aber verschlüsselt, und den Schlüssel kannte ich nicht (weil mir bei der Erstinstallation nicht aufgefallen war, dass Verschlüsselung aktiviert worden war). Daher war keine Kopie möglich. Schade eigentlich … Sicher sollte man grundsätzlich immer ein Backup haben, aber ich weine hier nicht in erster Linie den verlorenen Daten nach.
Also habe ich es erstmal mit Reparaturen versucht, aber alle Ansätze wie abgesicherter Modus, Installations-Stick und -CD scheiterten immer am „inaccessible boot device“. Schließlich wollte ich eine Reparatur- oder notfalls Neuinstallation versuchen, aber es wurde kein interner Datenträger gefunden. Weil das System zuvor ja einwandfrei gelaufen war (und ich schon eine andere SSD nach wenigen Wochen habe abrauchen sehen), verwarf ich die Idee, irgendwelche Treiber laden zu wollen und glaubte an einen Hardware-Defekt. (Die Sichtbarkeit unter Linux hätte mich vielleicht stutzig machen sollen.)
Über den Verlauf habe ich ausgiebig mit dem Acer-Support konferiert, der auch ein paar Ideen hatte, schließlich aber eindeutig erklärte, dass das Gerät wegen eines offensichtlichen Defekts zur Reparatur eingeschickt werden müsse. Also Gerät verpackt, genaue Fehlerbeschreibung beigefügt und ausdrücklich mitgeteilt, dass mangels Zugreifbarkeit keine Sicherungskopie existiert und deshalb darum gebeten wird, mir im Falle des Austausches des Datenträgers den alten zurückzuschicken, damit ich ggf. einen Datenrettungsversuch starten kann (wenngleich der vermutlich an der Verschlüsselung gescheitert wäre). Damit war zumindest klar, dass die Daten nicht leichtfertig geopfert werden sollten.
Nach einer Woche kam das Gerät zurück mit dem Hinweis, dass es keinen Hardware-Fehler gebe, man aber testweise Windows über das MCT installiert habe (was mir, s.o., nicht gelungen war). Weiterer Hinweis: Da die eingebaute SSD recht neu sei, werde sie vom MCT evtl. noch nicht unterstützt, ggf. müsse man die IRST-Treiber installieren. Das las sich für mich, als wäre der fehlerhafte Boot-Vorgang nur auf ein Treiberproblem zurückzuführen gewesen. Ich habe dann erstmal das vorinstallierte Windows fertig eingerichtet und in den Wartezeiten per Mail um weitere Erläuterung gebeten, wie es zu dem plötzlichen Ausfall nach mehrmonatigem Betrieb kommen konnte. Die Antwort kam bemerkenswert schnell, hat mich aber echt ernüchtert. Ich fasse die Antwort mal zusammen:
Das System habe wohl ein Update bekommen, bei dem das BIOS zurückgesetzt worden sei. Ich möge bitte im BIOS den VMD-Controller deaktivieren, dann sei auch bei Neuinstallation der interne Datenträger sichtbar. Um die Einstellung zu sehen, müsse ich lediglich STRG+S drücken.
Das habe ich sofort getestet: Mit aktiviertem VMD lief das im Rahmen der Reparatur von Acer vorbereitete und inzwischen vollständig installierte Windows normal, nach dem Deaktivieren kam der o.g. Bluescreen. Umgekehrt konnte der Installations-USB-Stick bei aktiviertem VMD keinen Datenträger finden. War VMD jedoch deaktiviert, hätte ich installieren können. Das habe ich schließlich gemacht, was dann die vierte Neuinstallation seit Inbetriebnahme war – inkl. aller Updates und Datenschutzeinstellungen etc.
Fazit: Hätte ich damals, als der Boot-Vorgang zum ersten Mal scheiterte, einfach nur den VMD-Controller deaktivieren müssen?? Das war wirklich alles??? Ja, ich hatte das BIOS komplett durchgesehen und mit verschiedenen Einstellungen experimentiert, aber dass einige davon versteckt sind, war für mich nicht ersichtlich - und ich sehe dafür auch keinen vernünftigen Grund.
Jetzt kommt aber das große Fragezeichen: Warum hat nicht der Acer-Support im Rahmen der „Reparatur“ die Einstellung einfach geändert und meine Daten in Ruhe gelassen? Oder mich schon bei meiner Service-Anfrage auf die Möglichkeit im BIOS hingewiesen? Dann wären die Daten nicht weg und der Aufwand seeeehr viel geringer gewesen.
Warum ich bei einem Laptop, der ohne RAID arbeitet, VMD überhaupt brauche, habe ich auch noch nicht herausgefunden. Jedenfalls habe ich die Neuinstallation jetzt mit deaktiviertem VMD-Controller gemacht (wie von Acer vorgeschlagen) und erinnere mich hoffentlich an STRG+S, wenn nach einem künftigen Update wieder kein SSD-Zugriff gelingt.
Der Rechner läuft bei mir nun wieder, jungfräulich und frei von meinem alten Ballast, nach einer langen, unnützen Reise. Danke für's Mitlesen!
Ich wünsche allen noch einen update-freien Abend
ruby
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 1446360279
Url: https://administrator.de/contentid/1446360279
Ausgedruckt am: 25.11.2024 um 11:11 Uhr
7 Kommentare
Neuester Kommentar
Der VMD Controller ist evtl. performanter und wird vom Intel empfohlen.
Ich hatte heute das gleiche Problem mit einem frischen Acer, der allerdings ein geklontes Windows 10 von einem anderen PC bekommen sollte.
Das klonen ging interessanterweise, da Clonezilla offenbar den Controller erkannte.
Danach aber natürlich Inaccessible Boot-Device.
Eine Treiber Injection von WindowsPE aus klappte nicht, da danach Windows einen Bluescreen der iaStorVD.sys meldete. (Treiberfehler).
Aber die Lösung war dann doch einfacher als gedacht, nachdem ich die verstecke VMD-Option im UEFI nicht gefunden hatte.
Einfach einen nvme-USB-Adapter genommen und damit gebootet. Treiber von Intel auf dem nun laufenden Betriebssystem installiert (und gleich auch noch alle anderen fehlenden Treiber).
Danach normal gestartet.
Interessanterweise gab es dann noch einmal den Inaccessible Boot Device Bluescreen, jedoch konnte Windows das dann im nächsten Schritt "reparieren", sprich, die Automatik, die seit Windows 10 automatisch bei einem Bootfehler von AHCI auf RAID, IDE etc. wechselt (oder umgekehrt), hat gegriffen und die Registry entsprechend modifiziert.
Jetzt läuft alles. Zwar sehr umwegig, da ich das neue Laptop nun doch aufschrauben musste, aber naja... Vielleicht schaffen es die Intel Treiber in die nächste Windows Version....
Ich hatte heute das gleiche Problem mit einem frischen Acer, der allerdings ein geklontes Windows 10 von einem anderen PC bekommen sollte.
Das klonen ging interessanterweise, da Clonezilla offenbar den Controller erkannte.
Danach aber natürlich Inaccessible Boot-Device.
Eine Treiber Injection von WindowsPE aus klappte nicht, da danach Windows einen Bluescreen der iaStorVD.sys meldete. (Treiberfehler).
Aber die Lösung war dann doch einfacher als gedacht, nachdem ich die verstecke VMD-Option im UEFI nicht gefunden hatte.
Einfach einen nvme-USB-Adapter genommen und damit gebootet. Treiber von Intel auf dem nun laufenden Betriebssystem installiert (und gleich auch noch alle anderen fehlenden Treiber).
Danach normal gestartet.
Interessanterweise gab es dann noch einmal den Inaccessible Boot Device Bluescreen, jedoch konnte Windows das dann im nächsten Schritt "reparieren", sprich, die Automatik, die seit Windows 10 automatisch bei einem Bootfehler von AHCI auf RAID, IDE etc. wechselt (oder umgekehrt), hat gegriffen und die Registry entsprechend modifiziert.
Jetzt läuft alles. Zwar sehr umwegig, da ich das neue Laptop nun doch aufschrauben musste, aber naja... Vielleicht schaffen es die Intel Treiber in die nächste Windows Version....
Hallo zusammen,
auch 2024 ist das Thema immer noch aktuell.
Vorinstalliertes Windows 11 auf NVMe SSD sollte mit einem eingerichteteten Windows 11 von SATA-SSD ersetzt werden.
Clonezilla erkannte beide Datenträger und das klonen verlief problemlos. Beim booten dann sofort "Inaccesible Boot Device". Ein booten von einem mit RUFUS erstellten Windows-Image klappte, jedoch wurden beide SSds NICHT angezeigt! Suchmaschinen haben mich dann in diesen Thread geführt.
Also im UEFI nachgeschaut und erwartungsgemäß wurde die Option "VMD Controller deaktivieren" nicht angezeigt.
Durch drücken von Strg+S wurde dann die Option angezeigt den NVM Controller zu deaktivieren. Zusätzlich wurde jetzt eine Zeile angezeigt: "SATA-Mode VMD".
Durch deaktivieren des VMD-Controllers wechselte der Status zu "SATA-Mode AHCI". Danach bootete der PC dann sofort ins geklonte Windows 11 23H2 auf NVMe SSD.
Das man eine Tastenkombination braucht um diese Option überhaupt erst anzuzeigen finde ich unglaublich!
auch 2024 ist das Thema immer noch aktuell.
Vorinstalliertes Windows 11 auf NVMe SSD sollte mit einem eingerichteteten Windows 11 von SATA-SSD ersetzt werden.
Clonezilla erkannte beide Datenträger und das klonen verlief problemlos. Beim booten dann sofort "Inaccesible Boot Device". Ein booten von einem mit RUFUS erstellten Windows-Image klappte, jedoch wurden beide SSds NICHT angezeigt! Suchmaschinen haben mich dann in diesen Thread geführt.
Also im UEFI nachgeschaut und erwartungsgemäß wurde die Option "VMD Controller deaktivieren" nicht angezeigt.
Durch drücken von Strg+S wurde dann die Option angezeigt den NVM Controller zu deaktivieren. Zusätzlich wurde jetzt eine Zeile angezeigt: "SATA-Mode VMD".
Durch deaktivieren des VMD-Controllers wechselte der Status zu "SATA-Mode AHCI". Danach bootete der PC dann sofort ins geklonte Windows 11 23H2 auf NVMe SSD.
Das man eine Tastenkombination braucht um diese Option überhaupt erst anzuzeigen finde ich unglaublich!
Nein, ist nicht so!
Es ist ein Universaltreiber für Boards und Laufwerke die das unterstützen. Braucht man nur für RAID eigentlich.
Das ist die IntelRapidStorageTechnologie:
Aktuelle Treiberinstallationssoftware IRST
Habe mir mittlerweile auch die IRST Treiber auf einen extra Ordner auf meinem Win Stick...