News KB5034441: Windows-10-Update bricht mit Fehlercode 0x80070643 ab

[trullamaik]

Für alle die es erst einmal ohne verschieben und anpassen der Partitionen versuchen wollen, hier die Anleitung die für ein "frisch" installiertes Windows 10 Professional x64 funktioniert hat (meine eigene Veröffentlichung auf deskmodder.de):

Der Fehler trat bei mir auch auf einem frisch von einer ISO installierten Windows 10 auf, es lag schlicht daran, dass das WinRE-Image namens “Winre.wim” nicht in der Wiederherstellungspartition lag. Hier die dafür notwendige Lösung:

Um die Datei Winre.wim zu finden, müssen wir die Datei auf dem Rechner suchen. Dazu öffnen wir die Kommandozeile mit Administratorberechtigung und geben zunächst folgenden Befehl ein:

reagentc /disable

Direkt gefolgt von:

dir /a /s c:\winre.wim

Wenn wir die Datei Winre.wim gefunden haben und sie gültig ist, können wir den nächsten Befehl eingeben:

reagentc /setreimage /path [Pfad der “Winre.wim”] bei mir: “C:\$WinREAgent\Backup”

anschließend geben wir noch die nachfolgende Zeile ein:

reagentc /setreimage /path C:\$WinREAgent\Backup

Nun noch:

reagentc /enable

Fertig, Update installieren und freuen.

Danke für die Info.

hat bei mir, so wie von dir beschrieben, bestens geklappt.

Update ist erfolgreich installiert

 

[Felix#]

Ist tatsächlich ein ganz schönes Gefummel, vor allem bei kleinen Platten bzw. Platten, die stärker gefüllt sind.
Kann die Deskmodder-Anleitung aber auch nur empfehlen. Man muss dann schauen, ob man ggf. noch MBR verwendet in älteren Systemen https://www.deskmodder.de/blog/2023...zu-kleiner-partition-anleitung-von-microsoft/
Funktioniert auch mit Windows 10 die Anleitung. Bei der Verwendung von MBR noch ist der Eintrag id=27 immer noch funktional.
Die Windowsanleitung, vor allem in der Deutschen Übersetzung mit zum Teil übersetzten Cmd-Befehlen, die dann natürlich nicht mehr gehen - also das hat mich schon sehr angekotzt.

Unsere Testsysteme - z.T. eben auch mit Windows - laufen nun wieder. Man fragt sich nur, ob das Update bei MS irgendjemand mal ebenso "getestet" hat. Also ausgiebig in mehreren Varianten. Mir scheint: nein.

 

[fdsonne]

Systempartition verkleinern um irgendeine versteckte Zusatzpartition zu vergrößern, geht’s noch?
Wie wäre es damit, das Update zurückzuziehen und es wieder auszurollen, wenn es ordentlich läuft und nicht so einen Frickelkram braucht?

Es passt halt nicht rein. Bzw. es lässt sich nicht rein patchen, wenn nicht genug Platz vorhanden ist.
Das lässt sich schwer bis gar nicht anders lösen als eben diese Partition zu vergrößern.

Man muss halt auch die Kirche mal bisschen im Dorf lassen. Es gibt hier Mittel und Wege um Bitlocker Verschlüsslung über die WinRE Umgebung zu umgehen, WENN!! man ohne PreBoot Authentication (also Pin Eingabe) unterwegs ist. Wer bitte macht sowas!?
Wenn die Kiste selbst bis in das OS rein bootet, dann ist doch eh vorbei? Am Besten noch alle Schnittstellen offen, also keine USB Sperre oder sowas...

Hat man die Pineingabe, dann ist die Kiste sicher. Technisch bräuchte es diesen Patch für die WinRE Umgebung nicht, da man da gar nicht ran kommt. Auch nicht von extern, weil das nur via Recovery Key geht. Alternativ WinRE ausknipsen und im Fall der Fälle via ISO/Stick booten.

Und im nächsten Thread wird Linux wieder als "Frickelsystem" verschrien 🤣

Wenn da was nicht geht, fängst du halt an zu frickeln. Ja, warum darf bei Windows dann nicht auch mal gefrickelt werden? Wobei das hier weniger ein frickeln ist, da der normale reguläre Weg ja funktioniert. Es geht hier eher um die Problemfälle. Wie viele auch immer das sind... Wahrscheinlich sind am ehesten die betroffen, die ne OEM Installation haben, wo die Größenverhältnisse nicht stimmen durch zusätzliche Daten, die der OEM da rein brachte. Oder die, welche beim letzten WinRE Problem angefangen haben, krampfhaft über Kompression und andere "Tricks" wie Files da raus zu löschen, das Platzproblem zu lösen. Bzw. Nummer 3, die ne alte Install immer weiter hoch gepatcht haben und wo die Partition dann eben zu alt/klein ist. Geschweige denn von denen, wo das Basis Image der WinRE wahrscheinlich zu alt ist für nen Patch.

Damals gab es den Automatismus nicht. Heute halt schon. Damals musste man sich das alles selbst hin patchen (frickeln).


Interessant wäre, ob sich das mit einem 06/2023er Image mit inkl. der WinRE Patches vom letzten Jahr auch bockig hat. Denn MS hat eigentlich alle im Support befindlichen Images meines Wissens nach versorgt mit den Updates, sodass man das nicht mehr selbst patchen musste damals.
Das meint btw. nicht nur das Install Image (WIM/ESD) was man via Windows Update beziehen kann, sondern ein reguläres Install Medium. Bspw. aus dem VLSC Portal oder MSDN. Potentiell auch eins via MediaCreationTool, wobei ich nicht sicher bin ob die auch angepasst wurden.

Der Fehler trat bei mir auch auf einem frisch von einer ISO installierten Windows 10 auf, es lag schlicht daran, dass das WinRE-Image namens “Winre.wim” nicht in der Wiederherstellungspartition lag. Hier die dafür notwendige Lösung:

Das WinRE Image liegt auch nicht in der Recovery Partition
Beim deaktivieren der Recovery Partition wird die WIM Datei aus den Daten der Recovery Partition geschrieben -> diese WIM Image Datei ist nicht vorhanden, wenn man die Recovery Partition aktiv hat.
Danach kann man sie theoretisch manuell patchen. Also via dism Update Pakete rein impfen und im Nachgang wieder in die Recovery Partition schieben.

-> das war btw. der Weg, den man beim letzten WinRE Problem gehen musste, wo es noch keinen Automatismus gab.

 

[Seinfeldfreak]

Hatte gerade bei einer Win 10 VM den Fall.
Habe es mit EaseUS Partition Master Free getestet, funktioniert mit der einfachen Verschiebefunktion.
WinRE Partition von 500 auf 1000 MB vergrößert, danach lief das Update fehlerfrei durch.

 

[Oldtimer]

Never change a running system ist schon immer ein guter Wahlspruch gewesen.

 

[Freiheraus]

Ich habe das Problem mit dem "MiniTool Partition Wizard Kostenlos 12.8" gelöst. Einfach die betroffene Partition erweitern. Allerdings ist der Mindestschritt beim Erweitern ~750MB groß, so dass meine Widerherstellungs-Partition jetzt rund 1,3GB beträgt (zumindest hat man dann Luft nach oben). Das Win-Update ging danach einwandfrei.

 

[mibbio]

Wenn da was nicht geht, fängst du halt an zu frickeln. Ja, warum darf bei Windows dann nicht auch mal gefrickelt werden? Wobei das hier weniger ein frickeln ist, da der normale reguläre Weg ja funktioniert. Es geht hier eher um die Problemfälle.

Es geht dabei auch gar nicht darum, dass unter Windows nicht auch mal gefrickelt werden darf - auch unter Windows hat Cmd & Powershell eine Berechtigung.

Nur wird es aber oft so dargestellt (und steckt auch so in vielen Köpfen fest), dass Linux ohne Frickeln gar nicht betrieben werden kann, während es unter Windows nur in wenigen Problemfällen nötig ist. Das ist aber schon längst nicht mehr so und bei der richtigen Wahl der Distribution kommt der Durschnittsnutzer unter Linux bei normaler Nutzung auch nicht häufiger mit Frickeln/Kommandozeile in Berührung als unter Windows. Der braucht man es unter Linux auch nur in einigen Problemfällen und kann ansonsten Alles über normale Menüs machen.

 

[theGucky]

Die (WinRE = Windows Recovery?) Wiederherstellungspartition von meiner Win 11 Installation auf meiner 500GB M.2 ist 450MB groß.

 

[Donnerkind]

Windows 11 ist auch ein tolles Betriebssystem aus dem Hause Microsoft.

Ich habe auch schon Linux ausprobiert, aber das ist ja alles kompliziert

Falschen Faden erwischt?

 

[Poati]

Eine "normaler Endanweder" schaut weder in der Microsoft KB nach Lösungen, noch kann er was mit der Kommanzozeile oder gar "diskpart" anfangen, aber Hauptsache ausgekotzt.

Mhh naja. Ein Endanwender, dem das Problem im Updateverlauf aufgefallen ist, der fängt durchaus an zu googlen und wenn MS selbst schon dazu rät, why not? Dass das nicht gut gehen muss, sollte man als Forummitglied wissen.

Mir war der Fehler auch schon aufgefallen am heimischen Gaming PC. Die Windows Installation ist unverbastelt und wenig Software installiert, im Grunde fast nur Steam und eben die Spiele. Habe aber schon länger damit aufgehört da mit MS Workarounds nachzubessern. Lohnt nicht. Mit der Zeit löst sich das auch durch reguläre Updates.

 

[amorosa]

Als ich davon gelesen habe, hab ich erstmal Windows Update für 4 oder 5 Wochen pausiert.
Bis dahin, sollte MS ja selbst was gebracht haben als Lösung.

Ich frickel nicht in meinem System rum, BitLocker nutze ich sowieso nicht.

Aber wer es natürl. nutzt und betroffen ist, für den machts natürl. Sinn.

Nur mal so am Rande meine Meinung. Man muss ja nicht jedes Update sofort "mitnehmen".

Siehe Nvidias neue Treiber momentan hust hust

 

[elgorro]

Danke - hat funktioniert! Der Pfad zur WinRe.wim war bei mir "c:\Windows\System32\Recovery".

Wenn wir die Datei Winre.wim gefunden haben und sie gültig ist, können wir den nächsten Befehl eingeben:

reagentc /setreimage /path [Pfad der “Winre.wim”] bei mir: “C:\$WinREAgent\Backup”

anschließend geben wir noch die nachfolgende Zeile ein:

reagentc /setreimage /path C:\$WinREAgent\Backup

Etwas ungeschickt formuliert ;-)

 

[Vexz]

Hab den Fehler bei mir auch. Wäre zwar leicht zu beheben, aber wenn Microsoft das Update verbockt, dann sollen sie erstmal ein Update rausbringen, das ordentlich funktioniert.

 

[Weedlord]

Ich weiß schon warum bei mir alle Updates erst mit monatelanger Verspätung runtergeladen und installiert werden

Spoiler

Dieses Jahr noch garkein Update gemacht lul.

 

[der Unzensierte]

Na ja, ich werde erst am Freitag Zeit für die Frickelei haben. Vielleicht gibt's ja bis dahin mehr als einen work around aus Redmond. So ich denn überhaupt betroffen bin. Fakt ist aber auch das ich eine neue Installation nicht schon wieder neu installiere. Meine Zeit ist eine begrenzte Ressource.

 

[Caramon2]

Ich würde das einfach von einem Linux Livesystem aus machen: Mit GParted bequem per GUI. Das sind nur ein paar Mausklicks.

Ich wollte das gerade in der VM mit Win10-1803 durchspielen, das ich damals einem Nachbarn installiert habe, da ich das ISO noch gesichert hatte (die Partitionierung ändert sich ja nicht mehr).

Der Installer erstellt die Wiederherstellungs-Partition standardmäßig an erster Stelle:

Wie soll man die vergrößern?

Dazu müsste man die Windows-Partitionen nicht nur verkleinern, sondern auch nach hinten verschieben (einschließlich EFI und reserved), was bei SSD massiv auf die Schreiblast geht und bei HDDs in ewiges gerödel ausarten würde, was nicht gut für die Mechanik ist.

Da hatten die Redmonster (Tippfehler beabsichtigt) ja mal wieder richtig gut nachgedacht…

 

[Cl4whammer!]

Bei PoP_OS gab/gibt es einen ähnlichen Bug wenn die Verschlüsselung aktiv ist, dann werden Kernels nicht mehr nach dem Update auto entfernt (nichtmal mit apt autoremove) und deren kleine System Partition läuft voll und Updates bleiben kleben.

Nur um dem Obligatorischen wäre mit Linux nicht passiert etwas zu entgegnen xD

 

[Ganjafield]

Habe ich mittlerweile bei 3 völlig verschiedenen Windws 10 Pro Rechnern ebenfalls.
Liebes Microsoft Team, bitte fummelt euern Update-Mist so dass er funktioniert. Ich bastel jetzt nicht irgendwelche RE Partionen auf allen Rechnern um.

 

[xexex]

Wie soll man die vergrößern?

Gar nicht! Windows erstellt in so einem Fall schlichtweg eine zweite am Ende des Datenträgers und lässt die alte so wie sie ist, sie wird dann schlichtweg nicht mehr genutzt. Der einfachste Weg diesen Fehler zu beheben, dürfte ein "reagentc /disable" in der Kommandozeile mit Adminrechten sein. Die meisten hier dürften sowieso für jedwede "Rettungsmaßnahmen", von einem USB Stick booten.

 

[fdsonne]

Nur wird es aber oft so dargestellt (und steckt auch so in vielen Köpfen fest), dass Linux ohne Frickeln gar nicht betrieben werden kann, während es unter Windows nur ein wenigen Problemfällen nötig ist. Das ist aber schon längst nicht mehr so und bei der richtigen Wahl der Distribution kommt der Durschnittsnutzer unter Linux auch nicht mehr mit Frickeln/Kommandozeile in Berührung als unter Windows. Dann braucht man es unter Linux auch nur in einigen Problemfällen und kann ansonsten Alles über normale Menüs machen.

Ich möchte kein Windows <> Linux Thema vom Zaun brechen, aber es geht dabei gar nicht darum dass Frickeln = Kommandozeile ist Ist es mMn nicht. Weder bei Linux noch bei Windows.

Hier gibt es einfach für den Fall eines auftretenden Problems eine Anleitung, das Problem zu fixen. Vom Hersteller. Streiten kann man darüber ob die ihre Updates smarter machen soll(t)en und sowas vorher erkennen bzw. selbst fixen -> wie beim 10 > 11 Upgrade, wo die Recovery Partition neu angelegt wird mit mehr Größe.


Frickeln ist für mich bspw. wenn ich ein Betriebssystem installiere, ein Treiber für die Soundkarte zwar gefunden und installiert wird, man aber nen Ton wie Feldtelefon 1945 Marke Blechdose hat und dann anfängt, wildeste Anleitungen mit Befehlen und Dingen aus Foren in das System rein zu prügeln, in der Hoffnung, dass einer der gefundenen Dinge irgendwie das Problem behebt.
Auch frickeln ist für mich, wenn ich ne ISO nehme und das in eine VM installiere um am Ende dann festzustellen, dass Wayland dafür sorgt, dass der Mauszeiger springt, wenn man von Eingabefeldern raus hovert oder über Dinge wie Buttons zum breiter ziehen von Festern fährt, und der Zeiger dann springt -> und um das zu fixen man dann wieder Foren wälzt und Dinge durch probiert bis man irgendwas findet, was vielleicht das Thema löst. Oder halt auch nicht -> X11 lief dann, dafür dann halt lahm...

Würde es dafür dann ein HowTo geben von offizieller Quelle, so nach dem Motto, mache das und das, dann funktioniert das, wäre es kein Frickeln mehr. Aber das gibts halt nicht. Du suchst nach möglichen Lösungen und probierst das alleine durch -> DAS ist das Frickeln dabei.
Der Hinweis zur richtigen Distribution ist mMn auch ein zwei schneidiges Schwert, denn der Wechsel löst ja Probleme in aller Regel nicht, sondern bringt einfach andere mit sich. Dabei ist nichts unlösbar, die Frage ist nur immer, wie viel Aufwand willst du da rein stecken oder bist du bereit, Stunden und Tage dich damit zu beschäftigen oder nicht.

Wie soll man die vergrößern?

...

Da hatten die Redmonster (Tippfehler beabsichtigt) ja mal wieder richtig gut nachgedacht…

Gar nicht. Shrink das Windows Volume um 1GB und erzeug einfach eine Recovery Partition dahinter.

Per default wird die Recovery Partition immer davor angelegt. Das ist auch gut so, dann in aller Regel benötigt man die Flexibilität das Systemlaufwerk hintenraus zu vergrößern eher als die Recovery Partition zu vergrößern.

Und ja, die haben richtig gut mitgedacht - im VM Hosting Umfeld wird exakt dieser Umstand verwendet, um die Systempartitionen nach belieben hoch zu drehen, während der Fahrt. Windows Server und Client sind dabei identisch vom Ansatz her.
Upgradest du hingegen von 10 auf 11, tätigt der 11er Installer exakt das für dich. Die neue Recovery Partition mit mehr größe kommt hinter das Systemlaufwerk.


Btw. gilt es bei externen Tools immer aufzupassen. Bitlocker Vollverschlüsslung bspw. (also das, was man brechen kann bei Boot ohne PreBoot Authentication und aktiver ungepatchter WinRE Umgebung) verhindert ohne die Schlüssel das ändern der Partitionsgröße. Und theoretisch verhindert SecureBoot auch ein Boot von einem extern zugeführten OS.