[English]Heute mal wieder ein Blog-Beitrag aus der Rubrik "Windows 10, das rätselhafte Update-Wesen". Ein Blog-Leser hat mich kürzlich auf eine neue "Upgrade-Experience" (so nennt Microsoft das Ding) aufmerksam gemacht. Die Experience ist ganz schnell beschrieben: Der nichts ahnende Nutzer erhält eine Aufforderung zur Installation eines Funktionsupdates und endet dann mit einem nicht mehr bootenden System, weil kein Boot-Medium gefunden wurde. Gleichzeitig wurde die Partition "System-reserviert" plötzlich mit einem Laufwerksbuchstaben versehen.
Anzeige
Der Blog-Leser hat mir das Problem Ende Juni 2021 per Mail beschrieben, nachdem er auf ein sehr eigenartiges Verhalten eines Rechners beim Update auf die letzte Windows 10 Version 21H1 gestoßen war. Er schrieb:
Hallo Günter,
ich bin gestern auf ein Es erreichte mich ein Hilferuf einer älteren Dame, die von einer Anzeige "Ihre Windows-Version ist abgelaufen und muss upgedatet werden" (O-Ton) überrascht wurde. Der Rechner ist zwei Jahre alt und wurde bei Amazon als Firmen-Rückläufer verkauft.
Sie hat also dem Update zugestimmt und danach begann das Unglück. Nach dem Reboot blieb der Rechner in der Anzeige hängen, dass kein bootfähiges Medium gefunden werden konnte.
Der Leser schrieb, dass er ab diesem Zeitpunkt in den Vorgang involviert war. Die erste Überlegung des Lesers war, dass beim Update irgendwie der Boot-Sektor der SSD überschrieben wurde und somit keine bootfähige Partition gefunden werden konnte. Doch dieser Ansatz führte nicht weiter, denn der Blog-Leser schrieb:
Dies erst Mal der Seniorin mitgeteilt und sie darauf vorbereitet, das eine komplette Neuinstallation mit Verlust aller persönlichen Daten erfolgen muss. Die Mitteilung war natürlich nicht das, was sie sich erhofft hatte. Also erst Mal Pause.
Ich habe dann mal versucht, mit ihrer Hilfe ins BIOS des Rechners zu gelangen, um die Boot-Reihenfolge zu ändern bzw. zu sehen, was denn tatsächlich eingetragen ist. Der Versuch war nicht von Erfolg gekrönt, so dass wir erst einmal wieder eine Pause verabredeten, nach der ich mich auf den Weg zu ihr machen wollte, um vor Ort nach dem Rechner zu sehen.
Gestern meldete sie sich wieder und teilte mit, dass sie es mittlerweile geschafft hätte, wieder in Seite mit den BIOS-Einstellungen zu gelangen (siehe folgendes Bild). Was mich dabei stutzig machte, war, dass die SSD mit zwei Eintragungen gelistet war, einmal mit dem Zusatz "Windows Boot Manager" und einmal ohne diesen Zusatz.
Wir haben dann zusammen den Eintrag mit Zusatz als Boot-Option #1 eingetragen und den Rechner neu booten lassen. Zu unser beider Erstaunen lief plötzlich die Update-Routine von Windows 10, wie sie nach dem ersten Reboot kommt (30 % Update durchgeführt …) an und wurde dann nach einiger Zeit auch korrekt abgeschlossen. Es wurden dann noch weitere Updates gefahren, alle mit Erfolg und auch das "Classic Menü" erschien wieder, nachdem eine neue Version installiert worden ist. Was soll ich sagen, nur durch den Wechsel der Boot-Option läuft der Rechner jetzt wieder wie er soll und die Dame ist zufrieden.
Der Blog-Leser merkte dazu an, dass Microsoft erneut dazu übergeht, die versteckte Partition "System-reserviert" mit einem separaten Laufwerksbuchstaben zu versehen. Dazu schreibt der Leser:
Anzeige
Was mir bei der Geschichte allerdings aufgefallen ist, und es auch bei meinem privaten Rechner so auftritt: Seit dem letzten Windows 10 Update auf 21H1 Build 1081 wird die sonst versteckte Partition "System-reserviert" mit einem eigenen Laufwerksbuchstaben in der Auflistung der Laufwerke angezeigt. Diese Partition wird bei der Installation angelegt und war sonst in der Auflistung der Laufwerke nicht zu sehen und hatte auch keinen Laufwerksbuchstaben.
Wenn ich jetzt den Rückschluss wage, dass dieses Verhalten auch bei dem Rechner der Dame so war und deswegen die Einträge im BIOS für die Boot-Reihenfolge auf diese "System-reserviert"-Partition als Boot-Option #1 zeigte, dann ist mir klar, warum der Rechner kein bootfähiges Medium gefunden hat.
Bin ich jetzt total auf dem Holzweg oder ist Dir eine derartige Problematik schon untergekommen?
BTW: Bis auf die Anzeige der "System-reserviert"-Partition ist bei mir nicht weiter passiert, der Rechner hat ganz normal nach dem Update einen
Reboot durchgeführt und kam auch wieder in die Windows-Installation. Allerdings ist der Rechner aus 2008 und schafft den Win11-Check mangels TPM und und UEFI und GPT nicht.
Zur angerissenen Frage: Im Juni 2020 hatte ich nach einem Nutzerhinweis den Blog-Beitrag Windows 10 2004: Upgrade-Problem wegen Laufwerksbuchstabe bei Boot-Partition veröffentlicht. Auch dort führte eine Partition "System-reserviert" mit zugewiesenem Laufwerksbuchstaben zu Problemen mit einem Funktionsupdate (Feature Upgrade). Oder gibt es von euch eine andere Erklärung bzw. abweichende Erfahrungen?
Ähnliche Artikel:
Windows 10 2004: Upgrade-Problem wegen Laufwerksbuchstabe bei Boot-Partition
Windows 10: Upgrade-Fehler 0x8024000B 'System reservierte Partition konnte nicht aktualisiert werden'
Mount-Points für logische Laufwerke bereinigen
Was steckt hinter der Partition "system-reserviert"?
Anzeige
Habe bei "Classic Menü" (wird wohl die Classic Shell sein) aufgehört zu lesen, aber eine ältere Dame die "OpenVPN" im Schnellstart hat klingt interessant :)
Da fällt mir ein, ist die 21H1 Build 1081 nicht eine Previewbuild? Falls Ja sollte man mit solchen Fehlern rechnen…
Guten Morgen,
Ihre Schlußfolgerungen sind nicht ganz schlüssig.
Eher wahrscheinlicher ist einer der drei folgenden Abläufe des Geschehens:
a) Am wahrscheinlichsten:
Das Ganze sieht eher nach einem Austausch des Bootmanger durch überschreiben aus:
Windows legt im UEFI-Modus einen Bootloader an und überschreibt den auch mit jedem Upgrade, welcher bei dem beschriebenen Fall initial als 3. Option in den Bootoptionen eingetragen war.
Dies hat des Überschreiben des Bootmangers zu neuen IDs geführt und so den Eintrag im EFI-Bootloader korrigiert: alter Eintrag (zuvor erste Stelle) gelöscht, neuer Eintrag angefügt (letzte Stelle).
b) UEFI-Reset:
Da Windows 10 auch EFI-Flashs per Design ermöglicht, wenn dies im EFI-Setup nicht unterbunden wird, ist hier auch nicht auszuschließen, das das BS-Upgrade ein EFI-Update enthielt und so die Standardparameter in der Bootreihenfolge nach dem erfolgreichen EFI-Update und dem darauf folgendem EFI-Reset das das Problem verursachten.
b) EFI-Bootreihenfolgenmanipulation auf der Boot-Festplatte:
Ein ähnliches Verhalten konnte ich bei einen HP Envy Notebook feststellen, welches mit DUAL-Boot-Option (Win10/Debian) auf der SSD ausgestattet ist und bei Einrichtung des Linuxsystems im EFI-setup manuell auf den Linux-Bootmanager konfiguriert wurde, da dieser die Windows-Installation selbstständig findet.
Nach dem Windows 10 Upgrade erfuhr die Bootkonfiguration ein Reset und das System startete wieder im Default-Modus den Windows-Bootmanager direkt, statt auf den präferierten GRUB-Bootmanger zurückzugreifen.
In anderen System, wo die Bootmanager auf verschiedenen Platten liegen, ist dieses Phänomen bisher nicht aufgetreten, so das ich unterstelle, das Microsoft mal wieder die EFI-Standards manipuliert. Kennen wir ja auch schon von älteren Windows-Betriebssystemen, die den Bootloader bei Installation, Upgrades und teilweise sogar Updates ungefragt überschreiben wurde.
Mit freundlichen Grüßen
Karsten Tönniges
Achja, Nachtrag, wegen dem Laufwerksbuchstaben für die "versteckte Partition „System-reserviert"":
Wenn Windows feststellt (oder irrtümlich glaubt) das sich das Bootlaufwerk verändert hat oder ein Medium als Fremdsystem "erkennt", ordnet es allen lesbaren Partitionen einen Laufwerksbuchstaben zu.
Dies würde bedeuten, das sich hier die Festplattensignatur geändert hat.
Meiner Meinung nach ist der zweite Booteintrag der SSD einfach nur der Legacy Eintrag vom CSM.
Ich hätte mir bei diesem Blog Eintrag einen Screenshot von der Datenträgerverwaltung gewünscht. Meine Vermutung ist das es jetzt mehrere "System-reserviert" Partitionen gibt. Ich meine schon beim 20H1 Update gab es ähnliche Probleme. Auf meinem Notebook habe ich zumindest seit 20H1 zwei "System-reserviert" Partitionen. Eine mit 500MB am Anfang der Festplatte und eine mit 550MB am Ende der Festplatte. Nervt mich eigentlich bin aber zu faul was zu machen ;) Da gab es doch auch einen Blogeintrag hier dazu, das sich das Standard Partitionslayout bei Windows geändert hätte. Bei einer Neuinstallation mit 1909 wird die "System-reserviert" Partition auch weiterhin am Anfang der SSD angelegt mit 20H1 wird sie direkt am Ende angelegt. Aussage Microsoft war das man die Partition am Ende bei Bedarf vergößern könne. Lästig ist das nur wenn man ein Sytem auf eine größere SSD klont!
Ansonsten kann ich nur aus meiner Erfahrung mit diversen Systemen sprechen bei denen sogar noch die Dell, HP oder Lenovo Windows 7 Recovery Partitionen da waren. Alles ohne Probleme durchgelaufen!
Lustig finde ich dafür die Eigenschaft von Windows 10 bei mir häufig neuen USB-Sticks keinen Laufwerksbuchstaben zuzuordnen :)
Ja, die Aussage zum CSM-Boot-Laufwerk in der EFI-Bootreihenfolge ist korrekt, aber spielt bei der Fehlerbetrachtung nicht wirklich eine Rolle, da der erste Eintrag die Netzwerkkarte ist.
So wie ich die Sache lese, hat sich ja nur die Reihenfolge verändert, und das die reservierte Partition einen Laufwerksbuchstaben erhalten hat, ist, wie schon geschrieben, vermutlich einer neuen Speichersignatur zu verdanken. Je nach EFI-Standardverhalten, werden bei neuen Signaturen die alten Einträge der Bootmanager im EFI-Bootloader gelöscht und die neuen nachrangig angefügt.
Ergibt also ein schlüssiges Gesamtbild.
Der Laufwerksbuchstabe ist mir geläufig und hat bisher noch kein Fehlverhalten verursacht.
Es hilft: mountvol X: /D
Mit X: als Laufwerksbuchstabe.
Ich habe kürzlich knapp 120 PC von 1909 auf 20H2 bzw. 21H1 aktualisiert. Die PC haben neben der obligatorischen "System-Reserviert" Partition z.T. noch Recovery Partionen ohne Laufwerksbuchstaben. Das hier geschilderte Problem trat bei keinem einzigen PC auf. Ggf. hatte die "System-Reserviert" Partition bereits einen Laufwerksbuchstaben vor dem Update. Das ist im laufenden Betrieb kein Problem, fällt einem aber bei einem Funktionsupdate auf die Füße. Ich würde das als Einzelfall abhaken.
Bei den Funktionsupdates kommt es immer wieder zu sehr merkwürdigen Problemen. Bei 45 von 50 PC mit absolut identischer Hardware, vom gleichen Image "betankt" läuft alles absolut problemlos, 5 zeigen skurille Fehlerbilder. Thats life.
> 5 zeigen skurille Fehlerbilder
5 haben evtl. einen BIOS/UEFI-Trojaner oder die Intel ME o.ä. spielt Spielchen
Die PC haben kein UEFI und BIOS Trojaner gibt es nicht.
> … BIOS Trojaner gibt es nicht.
Dann lies mal etwas nach, was man mit Computrace/LoJack, Intel ME usw. alles so anstellen kann.
Skurille Fehlerbilder bei absolut identischer Hardware mit gleicher Firmware in allen Komponenten gibt es nicht.
Die 5 "skurillen" PCs haben vermutlich eine minimal andere Konfiguration, sei es andere BIOS-/EFI-Version oder andere Hardwarerevision der Komponenten (Andere Charge?), welche ein Abweichen vom erwarteten Verhalten provozieren.
Was genau ist an "absolut identischer Hardware" falsch zu verstehen?
120 PC mit absolut identischer Hardware?
Absolut sicher?
Alle genannten Optionen geprüft?
Absolut alle?
Die Zeiten, in denen Hersteller noch standardisiert und ohne Normteile (Teile, die nur die sehr ähnliche Qualität und Funktionalität für genau festgelegte Funktionen garantieren) Ihre Systeme ausstatten sind schon sehr lange vorbei. Ohne gesonderten Vertrag, der das mit Vertragsstrafen garantiert, hab ich das nur bei einer Charge mit fortlaufenden Seriennummern und gleichem Produktionsdatum in aktuelleren Systemen vorgefunden.
Ich behaupte auch, dass beides nichts miteinander zu tun hat. Der zweite Eintrag im BIOS muss vorhandenen sein wenn der UEFI und Legacy Boot gleichzeitig aktiviert ist. Und das die versteckte Partition einen Laufwerksbuchstaben erhält sieht man schon gelegentlich seit Jahren.
Hallo,
einen Tag nach der Veröffentlichung hier im Blog durfte ich so ein Phänomen in Live miterleben.
Ein Pc hier im Haus (privat) machte ein Update, erwachte später aus dem Sleep-Modus mit einem BSOD und gibt seitdem beim Booten "Reboot and select a proper boot defice".
Während der ca. 40 Troubleshoot Versuche gab es sogar zwei Fälle, in denen Windows wieder erwacht ist. Leider haben diese beiden Ereignisse keine große Signifikanz und scheinen eher zufällig dazwischen zu sein, da sie sich nicht reproduzieren lassen. Ich habe mit verschiedenen Hardwarekonfigurationen probiert, ohne Erfolg. Bis auf das Mainboard habe ich soweit alles getauscht oder abgeklemmt, auch die Kabel, ohne eine Änderung zu bemerken. Das UEFI ist erreichbar und zeigt zumindest die gleiche Version wie vor dem Update an. Es ist also wirklich die Festplatte (SSD) oder das Windows.
Übrigens war bei dem ersten der beiden Bootversuche der erwähnte "Windows Boot Manager" als extra Partition zu sehen und über diesen wurde dann auch gebootet. Leider gab das keinen langfristigen Erfolg. Die Systempartition hat auch kein Laufwerksbuchstaben bekommen…