[English]Zum 12. April 2022 hat Microsoft Sicherheitsupdates für Windows 10 und Windows Server freigegeben. Mir liegen über Benutzerkommentare Hinweise vor, dass das Update KB5012599 für Windows 10 Version 20H2-21H2 bei einigen Installationen Probleme verursacht. Die Installation bricht mit dem Fehlercode 0x800F0831 oder dem Fehlercode 0x8024200B ab. Ich habe inzwischen ein wenig recherchiert und den Sachverhalt in nachfolgendem Artikel zusammen gefasst.
Anzeige
Das Windows 10 Update KB5012599
Das kumulative Update KB5012599 steht für Windows 10 Version 20H2 – 21H2 zur Verfügung, und enthält Sicherheitsfixes, aber keine neuen Betriebssystemfunktionen. Das Update kann automatisch von Windows Update heruntergeladen und installiert werden, ist aber auch im Microsoft Update Catalog und per WSUS sowie WUfB erhältlich. Ich hatte im Blog-Beitrag Patchday: Windows 10-Updates (12. April 2022) auf das Update hingewiesen.
Problem: Installationsfehler 0x8024200B
Bezüglich des Update KB5012599 gibt es aber verschiedene Nutzerberichte, dass sich dieses nicht installieren lässt, sondern mit dem Fehlercode 0x8024200B abgebrochen wird.
Eine Meldung hier im Blog
Die erste Meldung zu diesem Installationsfehler findet sich hier im Blog in diesem Kommentar. Blog-Leser Dayst schreibt dazu:
Ich kann Update KB5012599 nicht installieren bekomme den Fehler 0x8024200b im ReportingEvents.log….hat jemand das gleiche Problem?
und ergänzt in einem Nachfolgekommentar zu meinem Hinweis, den Komponentenstore reparieren zu lassen:
Anzeige
Hallo Günter, das mit SFC /scannow habe ich schon gemacht hat nicht geholfen.
Im CBS.log finden sich Fehler wie Duplicated Manifest etc.
Dumm ist halt das knapp über 800 Clients das Update nicht installieren können :-/
Im Repository für die betreffenden Komponenten ist wohl ein benötigtes Manifest mehrfach vorhanden. Dayst hat bei den Kollegen von deskmodder.de noch einen Auszug aus dem log-File in diesem Thread gepostet. Die log-Datei enthält einen Eintrag:
0x800f080f – CBS_E_MANIFEST_VALIDATION_DUPLICATE_ELEMENT
Die Diskussion bei den Kollegen bringt auch keine wirkliche Erklärung für die Inkonsistenz in den Manifest-Dateien – es meldet sich aber ein weiterer Nutzer mit gleichem Fehler. In der Diskussion findet sich noch der Hinweis, dass es eine Clean-Installation von Windows 10 20H2 über MECM war, die dann mit dem Aktivierungspaket im Dezember 2021 auf 21H2 aktualisiert wurde. Die letzten kumulativen Updates aus dem März 2022 liefen noch fehlerfrei durch.
Thread bei reddit.com
Bei der Suche bin ich dann auf diesen Thread auf reddit.com gestoßen, der die April 2022-Updates von Microsoft für Windows diskutiert. Dort taucht der Nutzer Ram419 auf und bestätigt, dass er ebenfalls den Fehlercode 0x8024200B hat. Das Ganze betrifft bei ihm mehrere Windows 10 Enterprise 20H2 Clients, die über den SCCM mit Updates versorgt werden. Der Benutzer hat ein Ticket bei Microsoft eröffnet – bis zum 21. April 2022 aber noch keine Rückmeldung erhalten.
In diesem Thread finden sich weitere Nutzer, die diesen Fehler bei Clients mit Windows 10 Enterprise 20H2 bestätigen – in den meisten Fällen ist SCCM beteiligt.
Problem: Installationsfehler 0x800f0831
Im Microsoft Answers-Forum gibt es diesen Thread, in dem ein Benutzer den Installationsfehler 0x800f0831 beklagt. Der Fehler 0x800f0831 steht für CBS_E_STORE_CORRUPTION, und kann verschiedene Ursachen haben kann. Eine Ursache ist laut Microsoft, dass Windows den Zugriff auf die Microsoft Update-Server verloren hat (weil z.B. ein VPN, Proxy oder ein Virenscanner diesen Zugriff blockiert).
Laut diesem Microsoft-Dokument kann der Fehler aber auch auftreten, wenn ein Manifest für das zu installierende Update beschädigt ist oder die im Update-Store von Windows vorliegenden Dateien nicht passen. Dort wird vorgeschlagen, das Update aus dem Microsoft Update Catalog manuell herunterzuladen und die Installation erneut zu probieren.
Dieser Ansatz wird aber nur helfen, falls das Manifest des zu installierenden Updates beschädigt ist. Liegen Inkonsistenzen zum Update-Store vor, bringt der Download des Pakets und dessen manuelle Installation nicht. Üblicherweise versucht man die Ansätze, die ich im Blog-Beitrag Windows 8: Komponentenstore reparieren detaillierter beschrieben habe, durchzuführen. Also Reparatur mit DISM und/oder leeren des Update-Store unter C:/Windows/SoftwareDistribution.
Eine mögliche Lösung
Nach Durchsicht der Postings von Betroffenen bin ich im Microsoft Answers-Forum in diesem Thread auf eine mögliche Lösung in einem Post vom 20. April 2022 gestoßen.
Einige Nutzer vermuten .NET 4.8 Updates wie KB4486153 etc. als Ursache, weil dies auf allen betroffenen Client installiert wurde. Zudem handelt es sich bei allen betroffenen Maschinen um Upgrades von früheren Windows 10-Versionen.
Ein erster Hinweis
Benutzer Chuck Kapigian skizziert in diesem Thread im Microsoft Answers-Forum eine Lösung für den Installationsfehler 0x800f0831:
Find all the instances of this reg key and change the current state of all of them to 0
Example:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Package_18_for_KB4486153~31bf3856ad364e35~amd64~~10.0.1.3106
Or run this powershell script
CD HKLM:\
Get-ChildItem 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\' | Where-Object { $_.Name -like "*Package_*_for_KB4486153~31bf3856ad364e35~amd64~~10.0.1.3106*' } | foreach { Set-ItemProperty $($_.Name+"*") -Name CurrentState -Value 0 }
Allerdings ist die Rückmeldung diverser Benutzer, dass das nicht funktioniert. Das kann aber daran liegen, dass die Nutzer schlicht die falschen Einträge korrigiert haben.
Angepasstes PowerShell-Script
In diesem reddit.com-Thread skizziert Benutzer TemporaryUsed seinen Lösungsansatz. Bei ihm waren die Einträge bezüglich des bei der Initialisierung des gescheiterten Update-Pakets in der cbs.log wohl leicht unterschiedlich. Er hat also den Namen des gescheiterten Pakets in obigen PowerShell-Script entsprechend angepasst.
Anschließend musste er mehrere Durchläufe fahren, weil gleich mehrere Pakete betroffen waren. Bei jedem Durchlauf war der Name des betroffenen Pakets im Parameter Where-Object {…} entsprechend anzupassen. Nach sechs Durchläufen schreibt der Betroffene, waren die meisten seiner Clients repariert und konnten das Update KB5012599 installieren.
Ticket-Status vom 25. April: Offen
Der aktuelle Status vom 25. April 2022 auf Tickets, die Administratoren bei Microsoft eröffnet haben, ist eigentlich, dass das Installationsproblem mit einem Fehlerabbruch (0x800f0831 oder 0x8024200B) bisher nicht gelöst ist. Es schaut so aus, als ob Microsoft da ran muss – wobei mir bisher keine Lösungsvorschläge auf ein Support-Ticket bekannt sind. Aber vielleicht kommt ihr mit obigen Hinweisen weiter.
Folgebeitrag: Windows Update KB5012599: Fix für Installationsfehler 0x8024200B und 0x800F0831 kommt
Anzeige
Hallo,
bei mir (WIN 10 21H2, Upgrade von WIN 7 auf zugegeben recht alter Hardware) tritt bei diesem Update KB5012599 der Fehler 0x800f0984 auf. Habe es mist sfc /scannow und den üblichen DISM-Befehlen (Check, Scan, Restore) versucht, leider ohne Erfolg. Das Problem bleibt bestehen. Die Installation bleibt sehr lange bei 20% hängen und dann Auf meinem zweiten Rechner, der etwas neuer, aber auch schon 11 Jahre alt ist wurde das Update KB5012599 vor 12 Tagen ohne Probleme installiert. Ich denke auch mal dass Microsoft da ran muss…
Nur ein kurzes Update:
Nach erfolgreicher Installation gab es nun nach dem Neustart einen BSOD, dann wurde das Update KB5012599 wieder rückgängig gemacht und nun wird Fehler 0x800f0845 angezeigt! Ich bin fassungslos…
Hallo,
ich kann mich nicht beklagen. KB5012599 am 13.4.22 erfolgreich und bisher ohne Probleme auf Win10pro 21H2 per WSUS installiert. Am gleichen Tag auch KB5012117 bisher ohne Fehler.
Chuck liegt richtig aber es müssen alle "duplicate" Ereignisse im CBS.log bearbeitet werden – in meinem Fall:
cd HKLM:\
Get-ChildItem 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\' | Where-Object { $_.Name -like "*Package_*_for_KB4486159~31bf3856ad364e35~amd64~~10.0.1.2752*" } | foreach { Set-ItemProperty $($_.Name+"*") -Name CurrentState -Value 0 }
Get-ChildItem 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\' | Where-Object { $_.Name -like "*Package_for_KB4486159~31bf3856ad364e35~amd64~~10.0.1.2752*" } | foreach { Set-ItemProperty $($_.Name+"*") -Name CurrentState -Value 0 }
Get-ChildItem 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\' | Where-Object { $_.Name -like "*Package_*_for_KB4486153~31bf3856ad364e35~amd64~~10.0.1.3106*" } | foreach { Set-ItemProperty $($_.Name+"*") -Name CurrentState -Value 0 }
Get-ChildItem 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\' | Where-Object { $_.Name -like "*Package_for_KB4486153~31bf3856ad364e35~amd64~~10.0.1.3106*" } | foreach { Set-ItemProperty $($_.Name+"*") -Name CurrentState -Value 0 }
Get-ChildItem 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\' | Where-Object { $_.Name -like "*Package_*_for_KB4054590~31bf3856ad364e35~amd64~~10.0.1.2072*" } | foreach { Set-ItemProperty $($_.Name+"*") -Name CurrentState -Value 0 }
Get-ChildItem 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\' | Where-Object { $_.Name -like "*Package_for_KB4054590~31bf3856ad364e35~amd64~~10.0.1.2072*" } | foreach { Set-ItemProperty $($_.Name+"*") -Name CurrentState -Value 0 }
Get-ChildItem 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\' | Where-Object { $_.Name -like "*Package_*_for_KB4486129~31bf3856ad364e35~amd64~~10.0.1.3106*" } | foreach { Set-ItemProperty $($_.Name+"*") -Name CurrentState -Value 0 }
Get-ChildItem 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\' | Where-Object { $_.Name -like "*Package_for_KB4486129~31bf3856ad364e35~amd64~~10.0.1.3106*" } | foreach { Set-ItemProperty $($_.Name+"*") -Name CurrentState -Value 0 }
Get-ChildItem 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\' | Where-Object { $_.Name -like "*Package_*_for_KB4486135~31bf3856ad364e35~amd64~~10.0.1.2752*" } | foreach { Set-ItemProperty $($_.Name+"*") -Name CurrentState -Value 0 }
Get-ChildItem 'HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\' | Where-Object { $_.Name -like "*Package_for_KB4486135~31bf3856ad364e35~amd64~~10.0.1.2752*" } | foreach { Set-ItemProperty $($_.Name+"*") -Name CurrentState -Value 0 }
Danke für die Ergänzung. FYI: Den doppelten Kommentar habe ich gelöscht – Erstkommentare laufen grundsätzlich in Moderation (siehe Kommentieren im Blog
Dieses Update zerstört die Windows Suche, in Dateien wird kein Text mehr gefunden.
hm.. durch dieses update bootet einer meiner überwachten systeme (hp laptop) nur noch in einen "black screen before login with mouse cursor".
– abgesicheter modus ist nicht möglich
– in der cbs gibts haufenweise logonui.exe fehlereinträge. austausch mit winsxs version hilft nicht.
– starthilfe bringt "remove latest cumulative update" in log
– zwei alte wiederherstellungspunkte brechen auch ab, mit der begründung, dass eine datei (jeweils ne andere) nicht an ihren originalort wiederhergestellt werden kann
– chkdsk, dism und sfc -scan ohne auffälligkeiten
– dism remove-package in recovery console kann kb5012599 mit dem fehler 0x800f0905 nicht deinstallieren
latein am ende.
sowas hab ich noch nie gesehen..
Windows 10 Pro 64 Bit Version 21H2 (Build 19044.1682
Wenn ich das Update KB5012599 installieren möchte bekomme ich immer wieder
die Meldung : Dieses Update ist für Ihren PC nicht geeignet. Ich kann das Update
nicht installieren. Hat ein Teilnehmer hier im Blog eine Erklärung dafür ?
Der Update KB5005463+KB890830+KB5012117+KB5012599+KB4023057 hat bei mir jetzt auf zwei Systemen funktioniert, allerdings fahre ich auch mit 30 Tagen Verzögerung (Win Pro).
Ich gehe aber auch seit einer vor Jahren in Win 7 durch den Updateprozess zerschossenen Dotnet-Umgebung so vor, dass ich alle Fixe innerhalb der "Betriebszeit" installiere, damit kein Auto-Reboot durchgeführt wird. Den Reboot starte ich manuell und zwar einige Minuten später, nachdem ich im Task Manager geprüft habe, dass keine installationsrelevanten Prozesse mehr aktiv sind.
Zum einen wurde (wird ?) z.B. bei Dotnet-Komponenten oft nach dem Fix-Installieren noch ein Compile-Vorgang gestartet, der länger dauert und der es manchmal gar nicht mag, durch Reboot unterbrochen zu werden.
Zum anderen will Windows nach meiner Beobachtung für einen Fix einen Reboot, während aber noch die Installation eines anderen Fix läuft, d.h. der Windows Update Service scheint (zumindest bei mir) mit der Reboot-Anforderung nicht bis zum Ende der letzten Fix-Installation zu warten, das könnte evtl. zu den maladen Dateien führen.