Microsoft hat das Update KB5075039 für Windows 10 nochmals aktualisiert und am 3. März 2026 erneut veröffentlicht. Es ist ein WinRE-Patch, der das im Oktober 2025 aus dem Support gefallene Windows 10 wieder mit einer funktionierenden Recovery-Umgebung ausstatten soll. Hier einige kurze Informationen zum Sachverhalt.
Windows 10: Rückblick auf das WinRE-Problem
Mit der Installation des dynamischen Sicherheitsupdates KB5067039 (siehe Windows 10/11 Recovery Updates (14. Oktober 2025)) hat sich ein Bug eingeschlichen. Dieses Update enthielt eine fehlerhafte Version 10.0.26100.6891 des USBHUB3.SYS-Treibers. Wurde nach der Installation des Updates ein Win RE (steht für Windows Repair Environment) aufgerufen, ließen sich USB-Tastaturen und USB-Mäuse unter Windows 10 22H2, Windows 11 24-H2 – 25H2 und Windows Server 2025 nicht mehr verwenden. Zum 17. Oktober 2025 bestätigte Microsoft diesen Bug. Ich hatte dies im Blog-Beitrag Windows 10/11: USB-Tastatur/-Maus funktioniert in WinRE nicht richtig angesprochen.
Mehrere Korrekturversuche schlugen fehl
Zum 20. Oktober 2025 wurde durch Microsoft ein außerplanmäßiges Recovery Update KB5070762 für Windows 11 24H2 und Windows 25H2 freigegeben. Dieses soll die Win PE-Umgebung aktualisieren und dabei das zum Oktober 2025-Patchday verursachte Problem der nicht mehr reagieren USB-Tastaturen und -Mäusen in Win RE beheben. Ich hatte im Beitrag Windows 11 24H2-25H2: Notfall Recovery Update KB5070762 berichtet.
Mitte Januar 2026 gab es dann Recovery-Updates für Windows 10 und Windows 11. Für Windows 10 21H2 und 22H2 wurde zum 15. Januar 2026 das Update KB5075039 freigegeben (siehe Windows 10/11: Recovery-Updates (13. – 15. Jan. 2026)). Das das Windows Recovery Environment update KB5075039 for Windows 10, version 21H2 and 22H2 wurde per Windows Update verteilt und sollte automatisch das Safe OS Dynamic Update (KB5073933) auf die Windows-Wiederherstellungsumgebung (Windows Recovery Environment, WinRE) eines laufenden PCs anwenden.
Microsoft schrieb, dass das Update für die Windows-Wiederherstellungsfunktionen Verbesserungen bringen soll. Für die erfolgreiche Installation dieses Updates sind 250 MB freier Speicherplatz in der Wiederherstellungspartition erforderlich.
Ab diesem Zeitpunkt hatte ich den obige Vorgang längst aus dem Blick verloren. Nur im Hinterkopf hatte ich noch die Information von einem Leser, der schrieb, dass das Korrektur-Update auf seinem System nicht per Windows Update installiert worden sei.
Windows 10-Update KB5073933 vom 3. März 2026
Daher war es für mich recht überraschend, hier und hier zu lesen, dass Microsoft das Update KB5073933 für Windows 10 21H2 und 22H2 ESU und Windows 10 Enterprise LTSC 2021 erneut zum 3. März 2026 freigegeben hat.
Im Supportbeitrag gibt Microsoft an, dass man mit diesem Update einen Bug im Windows Recovery Environment (WinRE) behebt, der verhindert, dass diese Umgebung überhaupt startet, wenn das Windows 10 WinRE-Update KB5068164 vom 14. Oktober 2025 installiert ist. Wer also mit Windows 10 22H2 und ESU-Support unterwegs ist, sollte unbedingt das Update KB5073933 vom 3. März 2026 installieren lassen.
Anmerkung: Bolko weist in nachfolgenden Kommentaren berechtigt darauf hin (danke für die Anmerkungen), dass das Update KB5073933 (laut Supportbeitrag vom 3. März 2026) dem Stand vom 13. Januar 2026 entspricht. Die Veröffentlichung des Supportbeitrags ist lediglich eine Ergänzung, was im Januar 2026 gefixt wurde. Zudem lässt sich das Update, entgegen den Angaben im Supportbeitrag, aus dem Microsoft Update Catalog (mit Stand 13. Januar 2026) herunterladen.
MVP: 2013 – 2016
In dem Support-Artikel KB5073933 steht:
"Verify the installation of this update
After installing this update, the WinRE version installed on the device should greater than or equal to version 10.0.19041.6807."
*ttps://support.microsoft.com/en-us/topic/kb5075039-windows-recovery-environment-update-for-windows-10-version-21h2-and-22h2-march-3-2026-aac888cb-fd3e-4bc0-9ef6-eabd32d4039e
Diese Build-Nummer ist identisach mit dem Resultat des Safe OS KB5073933 vom Januar 2026.
Dieses Update wurde demnach einfach erneut ohne inhaltliche Änderung veröffentlicht, aber jetzt mit dem ausdrücklichen Hinweis im Support-Artikel auf den Fix für das defekte KB5068164.
Dieser Fix war aber bereits im Januar-Safe OS KB5073933 enthalten, er wurde damals aber nicht ausdrücklich im Support-Artikel erwähnt.
Wer es also im Januar bereits installiert hatte oder danach das Februar Safe OS KB5075910 installiert hatte, der muss jetzt gar nichts mehr machen, denn der Fix ist bereits drin.
Mit dem aktuellen Safe OS KB5075910 vom Februar haben wir bereits die Build-Nummer 19041.6925 erreicht. sind also schon höher als 19041.6807 aus dem aktuellen erneut veröffentlichten Support-Artikel vom 3.März 2026.
Das ist ein weiterer Beleg dafür, dass man dieses erneut veröffentlichte Update KB5073933 vom 3.März 2026 gar nicht mehr installieren muss, sondern dass es sich lediglich um eine neue Info im Support-Artikel handelt bezüglich des seit 13.Januar 2026 enthaltenen Fixes.
Im Support-Artikel ist ein Fehler enthalten, denn da steht
Microsoft Update Catalog: Available NO
Dabei ist das KB5073933 im Catalog drin und lässt sich dort seit 13.Januar runterladen.
*ttps://www.catalog.update.microsoft.com/Search.aspx?q=KB5073933
Microsoft sollte generell alle Updates im Catalog verfügbar machen.
P.S:
Am 24.Februar 2026 gab es auch ein neues Safe-OS Update für die WinRE von Windows 11 24H2 und 25H2:
KB5079270
Update fürs Setup Win11:
KB5079271
Soeben wieder erfolglos nach Updates gesucht. 🤔
Auf der System-SSD sind noch 871 GB frei.
Windows 10 IoT Enterprise LTSC 2021 wurde am 2025-10-o6 neu installiert.
aktueller Stand: v19044.6937
Die Build-Nummer des laufenden Betriebssystems hat aber nichts mit der Build-Nummer der WinRE zu tun.
Die Build-Nummer der WinRE kann man so feststellen (in einer Konsole mit Adminrechten):
mkdir %localappdata%\temp\mount
ReAgentC.exe /mountre /path "%localappdata%\temp\mount"
Dism /Get-Packages /Image:"%localappdata%\temp\mount" | find "SafeOS"
(Bei Windows 10 sollte dort aktuell dann folgendes Ergebnis stehen:
Package_for_SafeOSDU~31bf3856ad364e35~amd64~~19041.6925.1.2
Also Build-Numer: 19041.6925
Wenn die letzte Zahl kleiner als 6925 ist, dann fehlt das aktuelle Update KB5075910)
ReAgentC.exe /unmountre /path "%localappdata%\temp\mount" /discard
rmdir "%localappdata%\temp\mount"
Merkwürdig, egal was ich auch versuche, das Update KB5075910 wird nicht installiert,
bzw. es wird bei mir IMMER "Package_for_SafeOSDU~31bf3856ad364e35~amd64~~19041.6807.1.8"
angezeigt!
Und nu?
Sobald der ServicePack Build von winre.wim nicht mehr mit dem vom OS identisch ist werden und wurden schon immer keinerlei Updates auf winre.wim gemacht:
reagentc /disableDism /get-imageinfo /imagefile:c:\\windows\\system32\\recovery\\winre.wim /index:1
reagentc /enable
Das ist hier schon seit September bzw. Oktober 2025 der Fall. Bereits damals bekamen hier die WinRE.wim warum auch immer ihre Updates nicht mehr.
Dieses neue Update KB5075039 ändert daran überhaupt nichts.
Ich habe jetzt mal versuchsweise manuell ein aktuelles winre.wim 10.0.19041 ServicePack Build 6925 ausprobiert.
Das Recovery Menü erscheint und ist genauso wie mit September 2025 ServicePack Build 6094 ohne Probleme mit USB Tastatur oder Maus bedienbar.
Versucht man mit aktuellem ServicPack Build 6925 aber die cmd shell aufzurufen bekommt man nach einem Softreboot nur einen Blue Screen mit Stopcode 0xc000021a und ist nach erneutem Reboot wieder zurück im Recoverymenü.
Mit dem September ServicePack Build 6094 war und ist das dagegen nach wie vor problemlos möglich.
Aber da war damals doch noch irgend etwas Sicherheitsrelevantes für diese Änderung, wenn ich mich noch ganz fern richtig erinnere. Oder?
Man hat derzeit also die freie Wahl zwischen Pest und Colera …
Zitat:
"Versucht man mit aktuellem ServicPack Build 6925 aber die cmd shell aufzurufen bekommt man nach einem Softreboot nur einen Blue Screen mit Stopcode 0xc000021a und ist nach erneutem Reboot wieder zurück im Recoverymenü."
—–
Das ist bei mir nicht so (Win10 LTSC 2021).
Es erscheint kein "Stopcode 0xc000021a".
Wenn ich die "Eingabeaufforderung" auswähle, dann erfolgt zwar ebenfalls ein plötzlicher Reboot und nach dem Neustart ist der Hintergrund blau, aber das ist kein klassischer Absturz-"Bluescreen" und es wird auch kein Fehlercode angezeigt, sondern statt dessen gibt es dort nur eine Anzeige zur Auswahl des Users (Administrator ist voreingestellt) und danach erfolgt die Passwortabfrage, bevor dann tatsächlich die Eingabekonsole erscheint, die normal bedienbar ist.
Nach einem "exit"-Befehl erfolgt normal ein Reboot in das übliche Multi-Bootmenü, wo ich zwischen Win10 und Win7 wechseln kann.
Bei mir erfolgt dieser Softreboot auch dann, wenn ich in dem Bootmenü Win7 auswähle statt Win10. Danach bootet er nicht mehr in das Bootmenü, sondern direkt in Win7. Wenn ich im Windows 7 dann reboote, dann wird wieder in das normale Bootmenü gebootet mit der Auswahl Win10 und Win7 bzw in der untersten Zeile dann die Optionen der Recovery.
Daraus folgt meiner Meinung nach, dass der Bootloader vom Bootmenü der Recovery umgeswitcht (umgeschrieben) wird und dann ein Neustart durchgeführt wird, um so sauber wie möglich das ausgewählte Betriebssystem (Windows 7 oder Windows 10 oder Recovery-Menü oder Eingabekonsole) zu starten.
Das ist zwar gewöhnungsbedürftig, aber es funktioniert.
Ich sehe bei mir jedenfalls nirgendwo eine Fehlermeldung.
Ich halte dieses Reboot-Verhalten nicht für einen Fehler, sondern für Absicht von Microsoft zwecks sauberer Trennung.
Früher war das mal anders, da wurde sofort das gemacht, was man ausgewählt hat, ohne Umswitchen des Bootloaders und ohne Reboot.
Direktes ausführen ohne Reboot erfolgt auch noch dann, wenn man von der Windows 10 ISO bootet und dort die Eingabeaufforderung auswählt. Das geht auch kaum anders, weil man in der ISO nicht mehr so einfach on-the-fly den Bootloader umswitchen kann.
Bei der neuen Methode mit Reboot in die Eingabekonsole ist der Speicher bereinigt, also ohne Reste des Bootmenüs und ohne Reste der Recovery-Menüs. Ist doch eigentlich sehr gut so, weil es keine störende Elemente mehr gibt.
2.
Was meinst du mit "ServicePack"?
Meinst du "Safe OS"?
"Build" ist die Zahl vor dem Punkt (19041 , 19044 , 19045 , 26100 , 26200).
Die Zahl nach dem Punkt ist der "Patchlevel" (6094 bzw 6925).
Du hattest "Build" geschrieben, meintest aber "Patchlevel".
Ich sehe gerade, deine Befehlssequenz zeigt tatsächlich "Service Pack-Build" an, obwohl eigentlich "Patchlevel" gemeint ist.
Die tatsächliche "Build" wird bei deinem Befehl als "Version" angezeigt.
Microsoft hält sich nicht mehr an seine eigenen Begriffsdefinitionen.
Aus
"Build"."Patchlevel"
ist
"Version"."Build"
geworden
Normalerweise ist "Version" sowas wie 21H2, 22H2, 24H2 etc.
Übrigens kann man diese Infos auch anzeigen lassen, ohne vorher die Recovery abzuschalten und hinterher wieder einschalten zu müssen:
reagentc /info
ergibt dann zum Beispiel:
\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE
Die Partitionsnummer (hier 4) kann je nach System unterschiedlich sein.
Diesen Pfad baut man in den folgenden Befehl ein, der auch dein zweiter Befehl ist:
Dism /Get-ImageInfo /ImageFile:\\?\GLOBALROOT\device\harddisk0\partition4\Recovery\WindowsRE\winre.wim /index:1
Das Ergebnis ist identisch zu deiner Befehlssequenz, aber die Recovery blieb zwischendurch intakt.
Das neue Update soll das alte vom Januar automatisch auf bestehende Installationen starten. Also quasi eine Anlasserkurbel für den Windows 10 Aicher Eintopftraktor.
Oder um es mit den Worten vom M. Krüger zu sagen: "Sie müssen nur den Nippel durch die Lasche ziehen …"
Allerdings kann es nach wie vor nicht selbst den notwendigen Platz von der System- an die Recoverypartition abzweigen. Nicht einmal wenn das System keine Bitlockerverschlüsselung mehr hat.
Damit dürfte die Zahl der geeigneten Devices wo gerade zufällig 240MB frei stehen sehr überschaubar sein.
Ich habe jetzt zwei Test VMs entsprechend mit Handarbeit prepariert. Die eine mit BIOS/MBR war immerhin schon auf dem Oktoberstand 10.0.19041.6455. Die andere mit UEFI/GPT hängte dagegen warum auch immer sogar noch auf dem Julistand 10.0.19041.6094.
Wohlgemerkt nur in der winre.wim. Ansonsten sind beide auf 10.0.19044.7922.
Bei der Installation hatte Windows 10 kein einziges Byte mehr als nötig für die Recoverypartition spendiert. Das funktionierte ja früher einmal problemlos dynamisch. WinRE auf die Systempartition umkopieren und dort aktualisieren, alte WinRE Partition löschen und danach WinRE wieder auf eine genau passende neue Partition zurückkopieren nachdem die Systempartition entsprechend Platz dafür freigab.
Schau ma mal ob sich am nächsten Dienstag da irgendetwas bewegen wird. Fette 2.5GB haben die Recoverypartitionen jetzt zumindest. Davon 2GB frei.
Interessanter dürfe aber werden wie sich die beim 24/25H2 Preview sowohl auf die ESP als auch die Recoverypartition installierten brandneuen Boot- und Recoverymanager mit der futuristisch anmutenden Buildnummer 10.0.28000.317 verhalten werden. Da dürfte viel mehr als diese Nummer geändert worden sein. Wenn das mal gut geht.
Ich werde zur Sicherheit am Dienstag erst einmal alle Updates auf den realen Systemen aussetzen. Mögen andere Versuchskarnickel, pardon zahlende Kunden das erst einmal gründlich testen …
Die 240 MB hat Microsoft auch falsch berechnet.
Aktuell braucht die WinRE-Partition bei Windows 10 (Size on disk, berechnet mit dem Tool du64.exe aus den Sysinternals): 556.236.800 Bytes
Die neue WinRE.wim alleine braucht 553.013.841 Bytes
Die originale WinRE.wim aus dem ISO brauchte 443.881.289 Bytes
Differenz: 109.132.552 Bytes
Also 26644 Cluster (4k) auf einem Standard NTFS Dateisystem.
Also 105 MB Mehrbedarf (statt 240 MB).
Diesen Mehrbedarf kann man nochmal um 15 MB drücken, wenn man mit dism den Index 1 der WinRE.wim nochmal "exportiert" und dadurch den restlichen Müll entfernt, der eigentlich bereits durch "/cleanup-image /StartComponentCleanup /ResetBase" hätte entfernt worden sein sollen.
Dann ist man bei einem Mehrbedarf von ca 90 MB und daran scheitert es bei Microsoft, weil die Partition um 90 bzw 105 MB zu klein eingerichtet wurde?
Übrigens sind die Anleitungen von Microsoft bezüglich manuellem Update der WinRE unvollständig und fehlerhaft, weil sie SSU-Update und Bitlocker nicht berücksichtigen.
Das SSU in der Windows 10 IoT Enterprise LTSC ISO hat nämlich eine zu niedrige Version.
Wenn man das SafeOS updaten möchte, dann muss man vorher auch das SSU in die WinRE.wim einbauen.
Das ursprüngliche SSU kann man allerdings auch mit dem Export-Befehl nicht mehr entfernen, so dass die WinRE.wim um ca 15 MB größer ist also sie eigentlich sein müsste, wenn das superseded SSU deinstallierbar wäre. Auch an sowas hat Microsoft nicht gedacht.
Microsoft macht also folgende Fehler:
1. superseded SSU ist nicht deinstallierbar (würde ca 15 MB sparen)
2. dism /export wird nicht durchgeführt (würde nochmal ca 15 MB sparen)
3. Recovery-Partition wurde zu klein erzeugt
4. falsche Berechnung des tatsächlichen Speicherbedarfs (wie Microsoft auf 240 MB kommt ist mir ein Rätsel.)
5. Anleitungen von Microsoft zum WinRE-Update sind falsch, weil SSU und Bitlocker nicht berücksichtigt wurden. Vermutlich weiß Microsoft selber nicht mehr, wie man eine WinRE korrekt updated.
WICHTIG Dieses Update wird nicht angeboten, wenn Ihre Windows-Wiederherstellungsumgebung (WinRE) eine der folgenden Bedingungen erfüllt:
Wenn das WinRE-Image eine Version größer oder gleich Version 10.0.19041.6807 aufweist.
Deshalb wird es mir aktuell auch nicht angeboten, da ich die Version 10.0.19041.6807 habe.
Hatte mich schon gewundert, warum ich es nicht kriege.
Oh!
Wer lesen kann ist klar im Vorteil.
Deshalb kann ich es wahrscheinlich auch gar nicht updaten.
Die Frage ist, warum ihr beide die aktuelle Version 19041.6925 vom Februar nicht bekommt.
@Bolko
Welches Update soll das sein?
Gibt es das auch im Katalog?
KB5075910
Catalog:
*ttps://www.catalog.update.microsoft.com/Search.aspx?q=KB5075910%20×64
Support-Artikel:
*ttps://support.microsoft.com/de-de/topic/kb5075910-dynamisches-sicheres-betriebssystemupdate-f%C3%BCr-windows-10-versionen-21h2-und-22h2-10-februar-2026-ce324321-ad2b-48f5-bd8c-7cded8073cde
Ah, Danke.
Das habe ich per DISM installiert, aber keine Änderung!
"Package_for_SafeOSDU~31bf3856ad364e35~amd64~~19041.6807.1.8"
Eine Anleitung für das manuelle Update der WinRE.wim und der Recovery-Partition.
1.
Falls die Recovery-Partition mit Bitlocker verschlüsselt ist, dann muss man vor dem Update erstmal die Partition entschlüsseln und Bitlocker für diese Partition abschalten. Genaueres dazu siehe im Folgebeitrag.
Falls Bitlocker für diese Recovery-Partition nicht eingesetzt wird, dann kann man zu Punkt 2 springen.
2.
Die 3 Dateien WinRE.wim, Servicing-Stack-Update (SSU) und SafeOS bereitstellen.
Man könnte die vorhandene WinRE.wim aus der Recovery-Partition nehmen und updaten, aber dann bleiben die bisher installierten Servicing-Stack-Updates (SSU) mit drin und blähen die WinRE.wim unnötig auf.
Daher holt man sich besser die saubere WinRE.wim aus dem ISO.
Windows ISO mit Doppelklick mounten.
Mit 7-Zip die originale WinRe.wim aus dem ISO von dort extrahieren:
ISO:\sources\install.wim\1\Windows\System32\Recovery\WinRE.wim
Diese WinRE.wim zum Beispiel in den Ordner %localappdata%\temp speichern.
Das SSU-19041.6935-x64.cab aus dem Rollup KB5075912 mit 7-Zip extrahieren und auch in den Ordner %localappdata%\temp speichern.
(statt 7-Zip kann man auch mit dem expand-Befehl arbeiten.
expand -F : * update.msu ZIEL-Ordner
[die beiden einzelnen Leerzeichen links und rechts des Doppelpunktes müssen weggelassen werden. Die musste ich hier einfügen, weil die WordPress-Blogsoftware sonst spinnt und den Befehl verfremdet.])
In den selben Ordner %localappdata%\temp auch das SafeOS KB5075910 speichern.
3.
WinRE.wim mounten und updaten
Einen Ordner erzeugen, in den die WinRE.wim ausgepackt wird:
mkdir %localappdata%\temp\mount
Die WinRE.wim mounten (auspacken):
Dism /mount-image /ImageFile:%localappdata%\temp\Winre.wim /index:1 /mountdir:%localappdata%\temp\mount
Das SSU in die ausgepackte WinRE.wim integrieren:
Dism /Add-Package /Image:%localappdata%\temp\mount /PackagePath:"%localappdata%\temp\SSU-19041.6935-x64.cab"
Das Safe OS KB5075910 in die ausgepackte WinRE.wim integrieren:
Dism /Add-Package /Image:%localappdata%\temp\mount /PackagePath:"%localappdata%\temp\windows10.0-kb5075910-x64_09a4b2da872136f3b2023cdab7172f2700cb0073.cab
3a.
Optional kann man sich jetzt die integrierten Pakete anzeigen lassen:
Dism /Get-Packages /Image:%localappdata%\temp\mount
Diese Infos kann man auch in einen Text schreiben lassen:
Dism /Get-Packages /Image:%localappdata%\temp\mount >%localappdata%\temp\WinRE-Paket-Info-2026-03-06.txt
Man kann es auch filtern und nur das integrierte SafeOS anzeigen lassen:
Dism /Get-Packages /Image:"%localappdata%\temp\mount" | find "SafeOS"
Bei mir steht dann dort:
Package_for_SafeOSDU~31bf3856ad364e35~amd64~~19041.6925.1.2
3b.
Die gemountete WinRE aufräumen:
dism /image:%localappdata%\temp\mount /cleanup-image /StartComponentCleanup /ResetBase
Neue WinRE.wim erzeugen (packen, unmounten):
dism /unmount-image /mountdir:%localappdata%\temp\mount /commit
3c.
Optional kann man die neu erzeugte WinRE.wim jetzt nochmal exportieren, um wirklich alles überflüssige rauszuwerfen:
Dism /Export-Image /SourceImageFile:%localappdata%\temp\mount\winre.wim /SourceIndex:1 /DestinationImageFile:%localappdata%\temp\mount\winre2.wim
4.
Alte WinRE.wim gegen neue ersetzen
Die bisherige WinRE.wim in der Recovery-Partition abschalten:
Reagentc /disable
Die neue WinRE.wim (bzw die exportierte WinRE2.wim in den Windows-Recovery-Ordner kopieren und dabei die alte überschreiben:
copy %localappdata%\temp\WinRE2.wim c:\windows\system32\recovery\WinRE.wim
Attribute setzen für Archiv, versteckt, System:
attrib +a +h +s c:\windows\system32\recovery\WinRE.wim
Neue WinRE.wim wieder in die Recovery-Partition kopieren und einschalten:
Reagentc /enable
5.
Info über die neue Recovery anzeigen. Bei WinRE-Status muss "enabled" stehen.
reagentc /info
6.
Aufräumen, Temporären Ordner löschen
rmdir "%localappdata%\temp\mount"
7.
Eventuell Bitlocker für die Recovery-Partition wieder einschalten.
Nachtrag zu Schritt 1 (Bitlocker-Entschlüsselung):
reagentc /info
Beispiel-Ergebnis:
\\?\GLOBALROOT\device\harddisk0\partitionX\Recovery\WindowsRE
Dieser Partition X muss man einen Laufwerkbuchstaben zuweisen, damit manage-bde funktioniert. Die konkrete Nummer variiert je nach System, also das X durch die konkrete Nummer ersetzen.
diskpart
select disk 0
select partition X
assign letter r
exit
Recovery-Partition entschlüsseln:
manage-bde –unlock r: -rp 48-digit-numerical-recovery-key
Beispiel:
manage-bde –unlock r: -rp 096393-002596-380402-430804-706420-686928-576741-631994
Bitlocker für die Recovery-Partition abschalten:
manage-bde -off r:
Laufwerkbuchstabe wieder entziehen:
diskpart
select disk 0
select partition X
remove letter r
exit
(diskpart und manage-bde kann man auch in zwei getrennte Konsolen eingeben, dann muss man diskpart zwischendurch nicht mit exit verlassen)
lösch den Scheiß und setz neu auf – ist weniger Arbeit….
Scheiße.
Das ist aber ganz schön arg.
Ob ich mich da ran traue?
Bin mir gar nicht so sicher.
Mit "SafeOS KB5075910 " meinst Du das komplette Update?
"windows10.0-kb5075910-x64_09a4b2da872136f3b2023cdab7172f2700cb0073.cab"
Das ist real viel weniger als es aussieht, denn die Punkte 1, 3a, 3c, 5, 6 und 7 sind optional, also nicht zwingend notwendig, denn normalerweise ist bei Win10 die Recovery nicht verschlüsselt (1 und 7), die Infos braucht man nicht unbedingt (3a und 5), exportieren ist nicht nötig (3c) und aufräumen (6) muss man auch nicht.
Es bleiben also 2, 3b und 4 zwingend übrig und dafür stehen die handvoll Befehle schon fertig da.
Statt %localappdata%\temp kannst du auch einen anderen Ordner nehmen, zum Beispiel
C:\mount
Einfach mal machen, geht recht fix.
@ Bolko
Bei Punkt 3c ist bei mir irgend etwas schief gelaufen!
Nun wollte ich alles, bis auf eben jenen Punkt, widerholen,
funktioniert aber leider nicht mehr!!
C:\>Dism /mount-image /ImageFile:%localappdata%\temp\Winre.wim /index:1 /mountdir:%localappdata%\temp\mount
Tool zur Imageverwaltung für die Bereitstellung
Version: 10.0.19041.3636
Fehler: 0xc1420127
Das angegebene Abbild in der WIM-Datei wurde bereits für den Lese-/Schreibzugriff bereitgestellt.
Wie unmounte ist das Abbild?
unmount, ohne die Änderungen in die Winre.wim zu übernehmen:
dism /unmount-image /mountdir:%localappdata%\temp\mount /discard
oder
unmount, inklusive die Änderungen in die Winre.wim übernehmen, was du in deinem Fall vermutlich nicht möchtest, da ja etwas nicht geklappt hat:
dism /unmount-image /mountdir:%localappdata%\temp\mount /commit
Da du schon bei 3b fertig warst, ist deine WinRE.wim schon fertig.
Mach einfach bei Schritt 4 weiter, egal ob du 3c durchführst oder nicht.
Wenn du 3c nicht gemacht hast, dann kopierst du die neue WinRE.wim (das ist die noch nicht exportierte neue Version) und wenn du 3c doch gemacht hast, dann musst du die WinRE2.wim kopieren (das ist zusätzlich exportierte neue Version).
Fehlerkorrektur:
Im Pfad von 3c sind die beiden "\mount" zuviel.
Der Pfad muss natürlich zur WinRE.wim zeigen und nicht mehr in den mount-Ordner hinein.
Dism /Export-Image /SourceImageFile:%localappdata%\temp\winre.wim /SourceIndex:1 /DestinationImageFile:%localappdata%\temp\winre2.wim
Ich habe 3c jetzt ausgelassen, aber ich bekomme das einfach nicht hin, die "alte" WinRE" gegen die "neue" auszutauschen!
Im Ordner "C:\Windows\system32\recovery\"
gibt es gar keine "WinRE.wim".
Also klappt das mit :
"copy %localappdata%\temp\WinRE.wim c:\windows\system32\recovery\WinRE.wim"
nicht!
D.h. ich hänge an dieser Stelle!
Die bisherige WinRE.wim in der Recovery-Partition abschalten:
Reagentc /disable
Hat geklappt!
Und das "Einschalten" sollte auch funktionieren,
aber wie soll das gehen?
Neue WinRE.wim wieder in die Recovery-Partition kopieren …
Doch irgendwie geschafft!
C:\>Dism /Get-Packages /Image:"%localappdata%\temp\mount" | find "SafeOS"
Package Identity : Package_for_SafeOSDU~31bf3856ad364e35~amd64~~19041.6925.1.2
@Bolko
Ich möchte mich hiermit ganz herzlichst bei Dir bedanken.
DANKE
"alte Hardware Client's Probs" wie immer, auf aktueller bei 25H2-Clean-Install keine Problem mit nix!
https://postimg.cc/VSM3nxJG
Und wie viele Programme nutzt Du so? Eins, zwei oder gar drei?
Und individuell ist da auch nichts eingestellt, was?
Aber schön, dass Du keine Probleme hast.