In der letzten Zeit kommt es unter anderem bei der Windows 10 2004 und 20H2 (2009) häufiger beim Windows-Update zur Fehlermeldung 0x800f0988. Microsoft selber hat die Bereinigung des WinSxS-Ordners als Workaround angegeben. Aber genau hier liegt das Problem und bringt nichts.
Denn wie Ben bei uns im Forum ausführlich berichtet hat, fehlen Komponenten im System, die ein reibungsloses Update zulassen würden. Dadurch dass die Dateien im Ordner WinSxS fehlen, kommt es zu der Fehlermeldung 0x800f0988. Das kann durch eine zu starke Bereinigung passieren, oder wie er und DK2000 herausgefunden haben, am unterschiedlichen Inhalt der 19041 ISO. Die „Urversion“ 19041.1 „sind die fehlenden Dateien größer als die aus der 19041.388 ISO“. Step by Step hat Ben dann eine fehlende Datei nach der anderen in das Windows System kopiert, bis dann auch das Update durchlief.
Workaround (nicht nur) für den Fehler 0x800f0988
Wer nun auch von der Fehlermeldung mit der Windows 10 2004 betroffen ist, muss nun nicht auch die einzelnen Dateien finden, die im System fehlen. Hier reicht ein Inplace Upgrade (Siehe Anleitung bei uns) und das Update wird dann während der Reparatur integriert. Das Inplace ist natürlich auch für die 1903 / 1909 geeignet.
Bei der Windows 10 20H2 sieht es aktuell noch etwas anders aus. Da bis zur 19042.450 kein Inplace mit „Daten behalten“ möglich ist, bliebe nur die KB4562830 (Feature Update auf die Windows 10 20H2) zu deinstallieren und dann das Inplace durchführen. Oder eben das Paket mit den Dateien, die Ben zur Verfügung gestellt hat inkl. Batchdatei ausführen. Hier aber erst eine Sicherung (Backup) erstellen und dann ausführen.
[Update 26.02.2021]: Durch die neue Bündelung SSU + LCU in einem Update hat Ben sein Script noch einmal überarbeitet. Hier der Link.
Hinweis für Windows 11: Da die bereitgestellten Dateien nur für Windows 10 sind, hilft unter Windows 11 der Workaround mit einer Inplace Reparatur. Eine aktuelle ISO dafür findet ihr wie immer bei uns.
Windows 10 Tutorials und Hilfe
In unserem Windows 10 Wiki findet ihr sehr viele hilfreiche Tipps und Tricks. Falls ihr Fragen habt, dann stellt diese ganz einfach bei uns im Forum.
- Installationsmedien: Aktuelle Installationsdateien findet ihr hier immer in der rechten Sidebar. Windows 10 2004 ISO (19041), oder 20H2 (2009) ISO (19042)
- Installation: Windows 10 Clean installieren, Win 10 2004 neu installieren
- Aktuelle Probleme mit der: Windows 10 2004
- Reparaturen: Inplace Upgrade Reparatur, Win 10 reparieren über DISM, sfc und weiteres, Windows Update reparieren, Startmenü reparieren, Apps reparieren, Store reparieren, Netzwerk reparieren
- Anmeldung: Win 10 automatische Anmeldung
- Entfernen, Deinstallieren: Apps deinstallieren
- Datei Explorer: Ordner unter Dieser PC entfernen, Netzwerk, OneDrive u.a. im Explorer entfernen
- Richtige Nutzung: Startmenü richtig nutzen, Suche richtig nutzen,
- Wichtig: In jedem Tutorial steht, für welche Version es geeignet ist.
Das gibts doch nicht. Schon wieder bleibe ich von Fehlern verschont. Kann mir mal jemand eine modifizierte Iso schicken damit ich mein System auch mal richtig zerschießen und Microsoft die Schuld geben kann, weil sie zu unfähig sind? Danke im Voraus.
Erstelle dir die ISO selber. Hier gibt es keine modifizierten.
Ich hab dir zwischenzeitlich auch schon eine Mail geschickt. Unwahrheiten im Netz verbreiten ist ein No Go.
Was für Unwahrheiten? Ich habe nie Probleme das ist die Wahrheit!
Simmt das so ?
Die „Urversion“ 19041.1 „sind die fehlenden Dateien viel kleiner als die aus der 19041.1 ISO“.
Was ist da der Unterschied.
Kleiner Fehler. Ist korrigiert.
Und der Applaus des Tages für den wertvollsten Beitrag geht heute aaaaan Ichhalt – ach Quark – geht selbstverständlich an @Ben für den besten workaround für ein sehr ärgerliches Problem bei mind. einem meiner 20H2 Systeme, was ich sonst hätte am WE zeitaufwendig troubleshooten müssen und an Jürgen für den freundlichen Hinweis auf die Lösung.
Einfach mal DANKE an der Stelle!
Mal wieder Murks made by Microsoft. Ich hatte keine Lust mehr auf diese Schlampereien und habe das OS gewechselt.
Erstmal besten Dank an Ben & DK2000 für die Recherche!
Hab bei 2 Rechnern mit 20H2 nur bis Version 19042.331 updaten können, danach nicht mehr. Dank diesem Fix geht es wieder! Bin begeistert.
Grüße Carsten und nochmals vielen lieben Dank euch beiden!
1. Standcomputer: Bis zur Version 19042.388 hat jedes Update funktioniert. Das …..30 und ….82 nicht mehr installationsfähig. Alles versucht nach Angaben von Microsoft mit DISM – alles negativ. Inplace Upgrade ohne Internet – negativ, da sonst Datenverlust gedroht hätte. Letzte geglaubte Rettung BEN mit der BatchDatei – zeigt zwar Verarbeitung 100%, aber dann wieder Fehler 0x800f081f.
Viel Arbeit und kein Erfolg!!
2. Laptop: Kein Problem Version 19042.450 einwandfrei.
gepostet mit der Deskmodder.de-App
Melde dich doch mit der Log-Datei im Forum. DK2000 ist da Profi und könnte vielleicht herausfinden, woran es nun liegt.
Dann bräuchte man mal die CBS.log vom Installationsversuch. Das ist zwar ein anderer Fehler, der müsste sich aber auch so lösen lassen, sofern man herausfindet, welches Paket bei Dir fehlt. Das muss man herausfinden, ansonsten klappt das alles nicht.
…nach Update Fehler 0x800f0988 habe ich ein Inplace-Upgrade inintialisiert. Trotz Inplace Upgrade von Birkuli Win10_19041.450, erhalte ich die Fehlermeldung 0xC190101 – 0x30018, die Installation war nicht erfolgreich. In der Phase FIRST_BOOT ist während des Vorgangs SYSPREP_SPECIALIZE ein Fehler aufgetreten. Es kann natürlich sein, dass es sich hierbei um ein spezielles Problem handelt. Dennoch betrifft es ein System mit 2 unterschiedlichen Win 10 Partitionen. Der Fehler tritt nach 48 % des Installationsprozesses auf…
Das geht aber wieder in Richtung Treiber / Programme ohne jetzt die Log gesehen zu haben.
…auf diesem Weg ein riesen Lob an Ben für das excellente Script in Version 2. Nachdem es bei meinem in die Jahre gekommenen Lenovo Laptop G510 mit Version 1 nicht geklappt hat und das Problem anscheinend in Richtung Treiber ging, hat es nun mit Version 2 einwandfrei geklappt. Microsoft hätte es nicht besser machen können…👍😉
ich habe die Fehlermeldung 0x800f0988 beim WU von 19041.388 auf 450, welche ISO soll ich für das Inplace verwenden?
Der Workaround klappt nicht:
https://www.deskmodder.de/phpBB3/viewtopic.php?f=334&t=24069&start=15#p349730
Ansonsten ist es egal, welche ISO verweidet wird. Entweder die mit der 388 oder gleich die mit der 450.
sollte man nun gar kein „Systemdateien bereinigen“ mehr durchführen, um die Fehlermeldung für die nächsten Updates auszuschließen?
Die kann man weiterhin mit den Windows-eigenen Methoden durchführen.
Das „Wie“ und „Warum“ es hier passiert ist, haben wir noch nicht genau herausgefunden.
Am Bereinigen glaube ich, liegt es eher nicht. Damals wurde der Fehler bereits beseitigt. Ich selber aktiviere bei meinen persönlichen ISOs die DISM ResetBase-Funktionalität sowohl allen wims. In der install.wim wird sogar noch der reservierte Speicher aktiviert. Hatte bisher keinerlei Probleme.
Wundernswert ist, dass ich nie den Eintrag „SupersededActions=3“ in der Registry habe. Komplette Zeile nicht vorhanden.
Hatte gestern die Zeit, meine angepasste Master-ISO zu testen. Alles angepaßt, wie ich es wollte, inkl. Sandbox, Hyper-V, aktueller Edge, dunkler Modus, Acrobat Reader, PowerDVD 20 und und und. Version 19041.450. Alles verlief super. Bei der 20H2 hatte ich selber das Problem mit der 423, dass keine Aktualisierung klappte. Da war bis auf das damailige Inplace mit den 20H2 Features dann jedes Update von Microsoft über WIndows Update…
@Roland Brem:
So geht es mir auch. Habe da auch diverse Tests durchgeführt, auch mit aktiviertem ResetBase und „SupersededActions=3″ und keine Probleme feststellen können. Update von 19041.264 bis 19041.450 mit allen Zwischenschritten und immer direkt nach der Installation des CU Bereinigung mit ResetBase ausgeführt, verlief ohne Probleme.
Bei mir selber habe ich „SupersededActions=3″ auch nicht in der Registry. Habe da keine Ahnung, welche Einstellung der CBS als Standard verwendet, wenn der Eintrag fehlt.
Da ich im Moment auch nicht weiter weiß, habe da keinen Idee mehr, was ich da noch testet könnte, habe ich das erst einmal aufgegeben und beobachte das Ganze mal nebenbei.
Wenn es überhaupt an der Bereinigung liegt, dann muss das ein seltsamer Bug sein.
Ich hab noch eine 19041.423 ISO da, gleich hier mal testen, ob sich die Updates auf 450 integrieren lassen. Wenn es an meiner persönlichen ISO funktioniert, mit ResetBase usw, hat es nichts mit der Bereinigung zu tun, da ich diese schon in der UR-Version 19041.1 aktiviert habe. Diese nehme ich für meine privaten Anpassungs-ISOs als Vorlage.
Was ich vorhin vergessen hatte, die Master-ISO war eine Home, wo die genannten Pro- und 20H2-Features direkt in der 19041.1 integriert wurden. Wäre die PowerDVD 20 ULtra VL nicht integriert, würde ich sie zum Testen/Vergleichen anbieten.
@DK2000: ich bleibe meiner Linie treu. Mein Script, kein anderes. Dauert zwar länger, funktioniert aber problemlos. Lieber noch die etwas altmodische Variante…
Die UUPD Sripte verwende ich da auch regelmäßig und habe damit auch keine Probleme. Allerdings lasse ich keine Bereinigung durchführen, nur die Updates integrieren. Daher habe ich auch nichts mit „SupersededActions“ in der Registry und ResetBase ist deaktiviert. Wie gesagt, ich beobachte das mal mit „SupersededActions=3“. Eventuell ergibt sich da etwas im Laufe der Zeit.
@DK2000
Kurioserweise hab ich selbst bei der 21H1 den Eintrag in der Registry
( so mal nebenbei erwähnt) und auch ResetBase ( aber deaktiviert)
@Manny:
Bei mir gibt es den Eintrag nicht. Aber wie gesagt, beim UUPD immer ohne Bereinigung. Dann wird der nicht eingetragen. Weiß jetzt auch nicht, ob der Eintrag bei einem Upgrade überhaupt migriert wird. Habe da seit der 19551 nicht mehr über ISO das Upgrade ausgeführt. und keine Ahnung, ob in der 19551 den Eintrag gab oder nicht. Die 19551 war wohl eine Neuinstallation.
Und aus dem verünglückten 19042.421 ist eine .450 geworden.
Danke Ben dafür
gepostet mit der Deskmodder.de-App
Ich möchte mich ganz herzlich für die Zip und das Skript bedanken! Sie waren die Rettung für gleich zwei PCs von mir. Tolle Arbeit! Euch allen ein schönes Wochenende!
Habe nun (wie angekündigt) meine Home-ISO mit der Build 19041.423 dafür benutzt, ob es hier möglich ist eine Aktualisierung mit dem ADK auf 19041.450 durchzuführen.
Wie schon erwähnt, habe ich bei mir die Ur-Version 19041.1 bereits bearbeitet. Das heißt, Sandbox, Hyper-V, ResetBase aktiviert und weitere Anpassungen vorgenommen.
Es ließ sich alles problemlos aktualisieren. Lediglich beim Cleanup-Vorgang geht es nur bis 10%, danach 100% (müsste ResetBase sein).
Was mir aber seit längerem schon aufgefallen ist, wenn man eine bereits aktualisierte wim benutzt, aktuelle SSU, LCU integriert usw. stehen die älteren noch im Installationsverlauf (bei dism++ mehrmals bemerkt).
Früher wurden die Einträge entfernt, wenn sie aktualisiert wurden. Nicht einmal der Vermerk „ersetzt“ steht da. Ist mir als erstes bei den ISOs der Server von MS aufgefallen.
Wie erwähnt, die ISOs können problemlos aktualisiert werden. Lediglich Windows schiebt einen Riegel davor, wenn man das aktuelle LCU installieren möchte. Wieso auch immer…
Das mit den Zwei Zeilen bei der Bereinigung macht er auch ohne ResetBase. Die erste Zeile geht bis 10% (Planung) und die zweite Zeile dann von 19% – 100% (Ausführung). Wenn es nichts zu tun gibt, geht die erste Zeile bis 20% oder bis 100%. Eine zweite Zeile gibt es dann nicht.
Was den Verlauf angeht, so ist das ein wenig undurchsichtig. Bis vor kurzem stand noch in der Log, dass neben dem aktuellen kumulativen Update zwei Vorgängerversionen als Superseded/Permanet behalten wurden. Mit dem aktuellen Servicing Stack finde ich das nicht mehr.
Und das ADK, ist das mittlerweile aktualisiert worden, was die Bereitstellungstools angeht?
Soweit ich weiß, ist die dism-Version immer noch die 19041.1 beim ADK, also keine Aktualisierung. Die dism.exe im System hat die Version 19041.329. Aber schon einige Zeit…
Also nicht aktualisiert. Schade, dass Microsoft kein Changelog dazu veröffentlicht, so dass man weiß, warum DISM auf 19041.329 ist bzw. Teile der Kernkomponenten 19041.423 aktualisiert wurden. Muss ein Grund für die zwei Updates haben.
Habe bei mir hier am Laptop auch noch einmal nachgescheut, was die Updates angeht. Es sind immer noch drei Versionen vorhanden: 329, 388 und 450. 423 wurde entfernt und alle CUs vor 329 auch. Ist schon etwas länger so, dass da jeweils zwei abgelöste CUs irgendwie zurückgehalten werden, warum auch immer. Von den SSUs ist die 262 bis 441 noch vorhanden und wird von der Bereinigung übersprungen (Skip servicing stack upgrade package).
besten Dank für Hinweise und das Skriptfile. Hat bei zwei Rechnern funktioniert. gibts das Skript auch für 32 bit Systeme?
Ich habe mal anhand dessen was in der X64 Version fehlt, die Dateien für die x86 Version herausgesucht.
Und auf Letsupload hochgeladen. Aber ich kann nicht garantieren ob es bei der x86 Version funktioniert. Da vielleicht weitere Pakete fehlen könnten. Aber wenn du willst kannst du es ja mal Testen und bescheid sagen ob es funktioniert hat.Hallo Ben,
ich habe die geänderte Datei heruntergeladen und ausprobiert. Der Reparaturversuch ist leider mit Fehlermeldung beendet worden. Vielen Dank trotzdem für deine Bemühungen.
Welcher Fehler kam denn? der 0x800f0988? Weil durchaus sein, das bei Dir andere Sachen fehlen oder mehr fehlt.
Es wurde der besagte Fehler 0x800f0988 angezeigt
Ja, da fehlen dann noch andere Sachen. Das ist schwer zu sagen. Und das herauszufinden, ist zeitraubend, da man jedesmal die Installation starten muss und im Anschluss die CBS.log auswerten. Außer Ben hat da einen einfacheren Weg gefunden.
Die andere Überlegung wäre da, einfach von einer 19041.1 x86 ISO pauschal mal alle Ordner aus dem ~\Windows\SxS in das Verzeichnis des entpackten Updates zu kopieren. Dann müsste er alle fehlenden Sachen eigentlich finden. Ist bloß die Frage, was er dann mit den nicht benötigten Paketen macht. Lässt er die links liegen und kopiert er die dann auch alle mit?.
@DK2000
Ich habe da keinen einfacheren Weg gefunden.
Aber ich versuche mal deinen Tipp mit den Ganzen Paketen aus dem WinSxS Ordner. Mal schauen wie lange es braucht bis das Installiert ist.
Also das könnte sogar funktionieren da die Installation nicht länger gedauert hat als vorher. Es schreibt dann wohl nur die Dateien neu die fehlen. Weil sonnst hätte das sicher eine Viertelstunde benötigt um das Update zu installieren, bei knapp 6,5 GB bei der x64 Windows Version.
Das klingt doch interessant.
vielen Dank an Ben für die zip/script. Endlich hat alles geklappt.
kleine Frage noch am Rande: warum kümmert MS sich eigentlich nicht um dieses Problem dann müsste man nicht selber Stunden herum experimentieren bis jemand etwas dazu programmiert und man den Fehler dann beheben kann. Ich finde das erbärmlich.
Hatte auch einen Bluescreen bei KB5001330. SFC und DISM Reparatur ausgeführt und Nivida Treiber aktualisiert ohne Erfolg.
Danach habe ich ESET und zusätzlich alle Programme entfernt die ich in den letzten Tag installiert hatte und dann habe ich es, mit der CAB von MS manuell installiert per DISM.
Update wurde erfolgreich installiert. Tipp: einen Wiederherstellungspunkt manuell einrichten damit man gleich zur aktuellen Version zurück kommt falls eine Systemreparatur nötig ist.
Edition Windows 10 Pro
Version 20H2
Installiert am 09.03.2021
Betriebssystembuild 19042.928
Leistung Windows Feature Experience Pack 120.2212.551.0
Hoffe das hilft jemanden weiter.
Grüß, Harry
Ich wollte gestern die vor wenigen Tagen frisch auf eine eigene Partition installierte Win11-22000.1 mittels KB5004745 updaten. Die vorherige SSU-Installation (22000.65) verlief ohne Probleme. Die KB5004745-Installation bricht bei 73% mit der Fehlermeldung 0x800f0988 ab. Diese Fehlermeldung soll ja (wie hier geschildert) auf angeblich fehlende wichtige Dateien des Windows-Ordners hinweisen. Wie kann den das bei einer frischen, quasi jungfräulichen Installation sein?
Seit der ersten Version liefen alle Updates problemlos durch.
Heute jedoch bricht die Installation auf zwei Geräten mit Fehler 0x800f0988 ab.
Bei mir auch… gibt es keine andere Lösung (habe schon einiges versucht… bisher erfolglos) außer dem Inplace Update?
Für Windows 10 gibt es nur den Fix von Ben. Oder für Windows 10 und Windows 11 eine Inplace Reparatur. Leider,
Für Windows 11 siehe meinen nebenstehenden Post.
Nachdem ich einige Monate Windows 11 erfolgreich updaten konnte, dachte ich schon, MS hätte da etwas getan. Leider trat nun wieder das allbekannte 0x800f0988 in Erscheinung. Da ich nicht gewillt war, schon wieder eine Inplace-Reparatur durchzuführen, habe ich mich an die Entstehungsgeschichte des Scripts von Ben erinnert und seinen Weg nachvollzogen. Erschwerend kommt bei Windows 11 hinzu, dass man es inzwischen auch noch mit der psf-Datei im msu-Paket zu tun hat. @ben @moinmoin Ich präsentiere hier meine quick&dirty-Lösung, vielleicht kann einer der Spezialisten hier die Sache noch etwas verfeinern, z.B. durch ein anpasstes Script durch „Aufbohren“ von W10UI_10.18.cmd (https://raw.githubusercontent.com/abbodi1406/WHD/master/scripts/W10UI_10.18.zip).
Händisch ging es folgendermaßen:
a) Gescheitert war das Update von April 22 zur Zielversion 22000.613. Das das cbs-log immer nur den ersten Fehler ausspuckt, an dem das Update KB5012592 zunächst scheiterte, ist es der mühevolleste Teil, die fehlenden SxS-Dateien ausfindig zu machen. Man benötigt für das April-Update aus einer noch funktionierenden (updatefähigen) Installation im Moment folgende 27 Ordner aus WinSxS:
amd64_microsoft-windows-s..-installers-onecore_31bf3856ad364e35_10.0.22000.1_none_42000e39aa2f7db4
amd64_microsoft-windows-s..cingstack-onecoreds_31bf3856ad364e35_10.0.22000.1_none_0a9c1b6a26747107
amd64_microsoft-windows-s..ck-mof-onecoreadmin_31bf3856ad364e35_10.0.22000.1_none_7005870033dee5f0
amd64_microsoft-windows-s..formers-shell-extra_31bf3856ad364e35_10.0.22000.1_none_40526a4b81f29e43
amd64_microsoft-windows-s..gstack-boot-onecore_31bf3856ad364e35_10.0.22000.1_none_ac0ac17775441b2b
amd64_microsoft-windows-s..k-transformers-core_31bf3856ad364e35_10.0.22000.1_none_c2773851da3a2165
amd64_microsoft-windows-s..llers-onecore-extra_31bf3856ad364e35_10.0.22000.1_none_7a1e60d3c801fe2d
amd64_microsoft-windows-s..ngstack-onecorebase_31bf3856ad364e35_10.0.22000.1_none_46c8936fe6ad3045
amd64_microsoft-windows-s..ransformers-onecore_31bf3856ad364e35_10.0.22000.1_none_7a9a536000494a97
amd64_microsoft-windows-s..stack-inetsrv-extra_31bf3856ad364e35_10.0.22000.1_none_8f73b87fa672e0d9
amd64_microsoft-windows-s..stack-termsrv-extra_31bf3856ad364e35_10.0.22000.1_none_69147025447c84ab
amd64_microsoft-windows-servicingstack-inetsrv_31bf3856ad364e35_10.0.22000.1_none_8b70cd5d6bc0d9fc
amd64_microsoft-windows-servicingstack-onecore_31bf3856ad364e35_10.0.22000.1_none_949494002416ab6a
amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.22000.1_none_5fa2feeecc138dd4
x86_microsoft-windows-s..-installers-onecore_31bf3856ad364e35_10.0.22000.1_none_e5e172b5f1d20c7e
x86_microsoft-windows-s..cingstack-onecoreds_31bf3856ad364e35_10.0.22000.1_none_ae7d7fe66e16ffd1
x86_microsoft-windows-s..ck-mof-onecoreadmin_31bf3856ad364e35_10.0.22000.1_none_13e6eb7c7b8174ba
x86_microsoft-windows-s..formers-shell-extra_31bf3856ad364e35_10.0.22000.1_none_e433cec7c9952d0d
x86_microsoft-windows-s..gstack-boot-onecore_31bf3856ad364e35_10.0.22000.1_none_4fec25f3bce6a9f5
x86_microsoft-windows-s..k-transformers-core_31bf3856ad364e35_10.0.22000.1_none_66589cce21dcb02f
x86_microsoft-windows-s..llers-onecore-extra_31bf3856ad364e35_10.0.22000.1_none_1dffc5500fa48cf7
x86_microsoft-windows-s..ngstack-onecorebase_31bf3856ad364e35_10.0.22000.1_none_eaa9f7ec2e4fbf0f
x86_microsoft-windows-s..ransformers-onecore_31bf3856ad364e35_10.0.22000.1_none_1e7bb7dc47ebd961
x86_microsoft-windows-s..stack-termsrv-extra_31bf3856ad364e35_10.0.22000.1_none_0cf5d4a18c1f1375
x86_microsoft-windows-servicingstack-inetsrv_31bf3856ad364e35_10.0.22000.1_none_2f5231d9b36368c6
x86_microsoft-windows-servicingstack-onecore_31bf3856ad364e35_10.0.22000.1_none_3875f87c6bb93a34
x86_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.22000.1_none_0384636b13b61c9e.
[[Vielleicht kann ein Kenner der Materie bereits aus den fehlenden Dateien ablesen, welcher „Bereinigungsmechanismus“ hier die User peinigt?]]
Diese Verzeichnisse in einem geöffneten Fenster bereithalten zum Kopieren durch Markieren.
b) Das oben erwähnte Skript W10UI in einen weiteren Ordner auf C: zusammen mit der 7-zip-entpackten KBxxx.msu-Datei plazieren und ausführen, starten und erstes Optionswahlfenster stehen lassen
c) Das Laufwerk C anzeigen lassen, hier erscheint dann ein temporärer Ordner mit W10UI und einer random-Nummer im Namen (aktualisieren drücken während der Laufzeit von W10UI in weiterem Verlauf).
d) Im Optionswahlfenster Script mit Eingabe von 0 (=normale Installation des Updates im laufendem System) starten und sofort den entstandenen Temp-Ordner von c) öffnen.
e) Dort werden Dateien in Unterordnern entpackt, sobald der Ordner mit dem Hauptpatch KBxxxx aufscheint, schnell aus dem Fenster von a) die SxS-Verzeichnisse mit hineinkopieren.
f) Script durchlaufen lassen und am Ende nach der dism-Aktion mit 9 schließen. Der temp-Ordner wird vom Script schon selbsttätig bereinigt und dann gelöscht.
Zum Abschluß hier noch die Frage: Ist es jemand schon einmal gelungen, Dateien zum SxS-Ordner hinzuzufügen und sie in der Registry anzumelden? In dem Falle bräuchte man kein Skriptaktionen mehr, sondern nur eine aktuell zu haltende Liste wie unter a), wenn sich weitere SxS-Fehlstellen auftun sollten.
Ich habe jetzt auch bei 4 von 6 PC (!!) diesen Fehler beim Win10 Update 21H2 (KB5011831). Irgendwie bin ich nicht gewillt zu glauben, dass es nicht an M$ liegt!
Bei Windows 10 hilft nach wie vor das Script von Ben. Hier im Forum Win 10 2004-20H2 x64 0x800f0988 v4 Maghook Fix.7z herunterladen. Auch bei mir wieder der Fehler nach 3 Monaten Ruhe seit Februar, windows10.0-kb5013942-x64 (Mai-Update), damit behoben.
Danke und natürlich, das half ja auch.
War auch eher als Hinweis gemeint, was M$ da wieder verzapft hat.
ich mache jetzt schon seit über 1 Jahr keine Update Bereinigung mehr auf meinen Geräten und habe auch keine Schwierigkeiten mehr seit dem.
Ok, werde ich auch nie wieder machen. Aber wie werde ich den Fehler los?
Der kommt immer mal wieder. Lässt sich bisher nicht eingrenzen wie und wann der kommt.
Ich hab mir angewöhnt, immer nur noch nach dem Sicherheitsupdate eine Bereinigung durchzuführen.
Ja, aber wie kann ich jetzt überhaupt wieder ein Update ausführen? Seit 2 Monaten stecke ich fest…
Wenn du jetzt eine Inplace Reparatur durchgeführt hast, beobachte das mal. Eigentlich sollte der Fehler dann nicht mehr kommen.
Es sei denn, du hast dein System öfter mal mit „Wundermitteln“ aufgeräumt und damit, na nennen wir es mal „versaut“.
Da hilft am Besten ein Inplace Upgrade. Ansonsten bleibt nur eine manuelle Reparatur übrig, welche aber bei Windows 11 etwas umständlich ist. da man hier am Besten einen sauberen WinSxS Ordner benötigt. Einzeln die Pakete rauszusuchen, ist da langwierig und das können über 100 Pakete werden.
https://www.deskmodder.de/wiki/index.php?title=Windows_11_Inplace_Upgrade_Reparatur_oder_Feature_Update
Und für Windows 10? Was bedeutet inplace Upgrade? Geht es nicht irgendwie anders?
Wenn es die üblichen Verdächtigen sind, die fehlen, dann könnte der Script von Ben helfen:
https://www.deskmodder.de/phpBB3/viewtopic.php?t=24069&hilit=0x800f0988
Andere Möglichkeiten gibt es da nicht. Fehlen halt Pakete der 19041.1. Die müssen wieder hinzugefügt werden. Solange die Fehlen, geht nichts.
Es gibt ja noch ein kumulatives Update mit 2,38GB. Das könnte eventuell auch helfen. Aber keine Ahnung, wie man Windows dazu bringt, dieses zu verenden.
Die Vorsicht beim manuellen Anstossen der Update-Bereinigung ist Besorgnis an der falschen Stelle. Unmittelbar danach lässt sich das System zumeist sowohl unter Windows 10 als auch W11 immer ein bis zwei Monate weiter updaten (Ausnahmen nach einer Neuinstallation sind allerdings schon berichtet worden). Und bei einem Systemupgrade will man ja doch den Windows.old-Ordner loswerden, von chronischen Platzproblemen auf mancher C-Partition zu schweigen. Das Schlimme ist ja, dass irgendeine Bereinigung entweder von einem Wartungstask aus dem Aufgabenplaner angestoßen wird, und ein zweiter Verdächtiger ist m.E. der Servicestack mancher KBs.
Und es fehlen eben auch ab und an plötzlich Pakete aus dem .Net-Framework, also Pakete der 15805.0 (W10) bzw. 15806.0 in W11. Bei deren Update wird sogar ab und an zum Neustart hin angezeigt, dass eine Bereinigung durchgeführt wird. Bringt mich immer zum Zittern, ob das nächste Monatsupdate wohl wieder betroffen sein wird.