Irgendwann während der Lebensdauer meines PC-Desktop-Systems bekam ich beim Spielen von Videospielen zwei Bluescreens hintereinander. Anschließend konnte ich das System vor dem Absturz bewahren, indem ich die gesamte Hardware neu verkabelte, aber aus irgendeinem Grund schlug die Installation aller Windows-Updates, die das System betrafen, wie das jährliche Upgrade von 1803 auf 1903 und ein zufälliges Update des .NET-Frameworks auf 4.8 für die Windows-Version 1803, fehl. Da sie jedoch nicht obligatorisch waren, schenkte ich ihnen keine Beachtung, da die regulären Sicherheitsupdates für Windows Defender weiterhin funktionierten. Irgendwann führte ich die Problembehandlung für Windows Update aus, die besagte, dass einige Fehler gefunden wurden, aber ein Neustart eine Korrekturroutine ausführen würde.
Irgendwann habe ich beschlossen, die Updates wieder zum Laufen zu bringen. Die Update-Fehler waren 0x8000ffff für das .NET-Update und 0x800700C12 für das Windows-Upgrade.
Wenn man danach sucht, findet man im Internet eine Menge Mist, denn wir alle wissen, dass jeder Windows-Fehler für anfällige Personen eine ideale Quelle für die Installation von Malware ist.
Auch das Herunterladen des MediaCreationTools und die Aufforderung, ein manuelles Upgrade auf 1903 durchzuführen, schlug mit einem „kritischen Fehler“ fehl, obwohl das System anscheinend nicht betroffen war und einfach keine Änderungen vorgenommen wurden. Allerdings keine Protokolle (DANKE MICROSOFT FÜR DIESE HILFREICHEN FEHLERMELDUNGEN)
Das Auslesen des Windows Update Logs über den Powershell-Befehl GetWindowsUpdateLog hat mir dabei geholfen ... nicht viel herauszufinden. Das Lesen dieser Fehlerprotokolle ist mühsam und kompliziert und die Unterscheidung zwischen Fehlern und Ausfällen sowie die schlichte Tatsache, dass Systeme beteiligt sind, von denen man im Normalbetrieb nie etwas gehört hat (zumindest unter Linux weiß man, welche Systeme man verwendet und installiert, wenn man das System einrichtet), haben nicht geholfen.
Ich habe dann versucht, das .NET 4.8 Framework manuell zu installieren. Auch das hat mit dem normalen Installationsprogramm nicht funktioniert, aber immerhin hat es eine durchsuchbare XML-Datei an einem zufälligen Ort auf meinen Laufwerken abgelegt (aus irgendeinem Grund hat es die Installationsdateien beispielsweise auf meine langsame 2-TB-Festplatte abgelegt, anstatt irgendwo auf die SSD, auf der das System installiert war. Aber hey! Windows und temporäre Dateien! Was kann schon schiefgehen, wenn die temporären Dateien nie bereinigt werden?). Als ich mir das genauer ansah, fiel mir auf, dass ein während der letzten Schritte der Installation ausgeführtes Befehlszeilenprogramm fehlschlug und mit demselben Fehlercode 0x8000ffff zurückkehrte: wusa.exe
Wenn man die Fehlermeldungen vergleicht, stellt dies zumindest einen häufigen Fehler während der Installation dar: Der Finalisierungsteil schlägt fehl.
Als ich nach Möglichkeiten suchte, Windows-Updates zu reparieren, fand ich Ratschläge bei dem Versuch, Folgendes zu verwenden:
sfc /scannow
Und
dism.exe /online /cleanup-image /restorehealth
sfc schlug fehl mit der Meldung, dass noch Änderungen am System anstehen und ich den PC neu starten soll. Das habe ich die letzten 6 Monate täglich gemacht, das kann also nicht die Lösung sein.
dism.exe schlug bei etwa 82,6 % fehl und gab mir zumindest den Hinweis, dass es Protokolle gibt, die ich mir ansehen könnte. Obwohl sie in ihrem Format auch nicht sehr hilfreich waren, schlugen sie auch bei einem Abschlussschritt fehl.
Als ich nachschaute, wie ich sfc wieder zum Laufen bekomme, stieß ich auf einen zufälligen Forumsbeitrag, in dem der Benutzer aufgefordert wurde, die Datei pending.xml im WinSxS-Verzeichnis zu löschen. Als ich in dieses Verzeichnis schaute (wofür auch immer es verwendet wird), fand ich die Datei pending.xml – sie ist fast 300 MB groß. Irgendetwas scheint nicht zu stimmen.
Das Löschen der Datei als Administrator funktioniert nicht. Ich erhalte immer wieder Zugriffsverweigerungsfehler. Sogar wenn ich die PSTools herunterlade und die Power Shell als SYSTEM-Benutzer öffne, werden mir die Rechte zum Löschen verweigert. Es gibt keine Prozesse, die einen Handle für die Datei besitzen.
Wie behebe ich dieses Durcheinander und wie hängen all diese Fehler zusammen?
Antwort1
Es stellte sich heraus, dass das Ganze ein Wirrwarr von Fehlern zu sein scheint.
Der Bluescreen (der erste seit etwa 10 Jahren), den ich beim Spielen von Videospielen bekam, schien aufgetreten zu sein, während Windows Update im Hintergrund etwas installierte. Ob das Update selbst dafür verantwortlich war, weiß ich nicht, aber ich musste einige Hürden überwinden, um mein System wieder zum Laufen zu bringen, da es meldete, dass das Boot-Skript beschädigt war. Damals habe ich wohl ein einfaches Befehlszeilentool aus dem erweiterten Boot-Menü zur Problembehandlung ausgeführt, um das Boot-Problem zu beheben. Dann habe ich alles neu verkabelt, weil mir Fehlerprotokolle sagten, dass beim Schreiben von Daten auf die Festplatte etwas Seltsames passiert sei, also dachte ich, dass aus irgendeinem Grund die Kabelverbindung zur System-SSD unterbrochen wurde, während das System lief. Nachdem das behoben war, lief das System wieder reibungslos, aber die Updates funktionierten nicht mehr.
Es stellte sich heraus, dass die „Dateibeschädigung“ tiefer ging. Es scheint, als ob in der Datei pending.xml eine Liste von Updates vorhanden ist, die beim Neustart des PCs angewendet werden sollen. Diese XML-Datei war jedoch irgendwie beschädigt, sodass Windows ihren Inhalt nicht erfolgreich LESEN konnte, aber dennoch alle Updates, die es anwenden sollte, der beschädigten Datei HINZUFÜGEN konnte. Auf diese Weise wurde eine beliebige Datenmenge aus der Datei gelesen und dann bei jedem Neustart alle diese Daten an das Ende angehängt, wodurch die Datei immer größer und größer wurde und fast GB-Anteile an Metadaten über ausstehende Updates erreichte.
Da das Windows-Upgrade und das .NET-Installationsprogramm dem System während ihres Abschlussschritts ebenfalls mitteilen möchten, dass beim nächsten Neustart des Geräts etwas getan werden muss, konnten selbst die Standalone-Installationsprogramme und das manuelle Upgrade mit dem Medienerstellungstool die Datei pending.xml nicht richtig analysieren und ergänzen. Da dies alles nicht funktionierte, schien ComponentBasedServicing für einige Programme verantwortlich zu sein, sodass CBS hier und da in Fehlerprotokolldateien auftauchte.
Nun zur Lösung:
Zuerst musste ich von einem USB-Stick, den ich mit dem Tool zur Medienerstellung eingerichtet hatte, in den Fehlerbehebungsmodus booten.
Dort habe ich eine Befehlszeile gestartet und die ausstehende Datei (pending.xml) manuell im WinSxS-Verzeichnis gelöscht.
Danach konnte ich einen ausführen sfc /scannowund erhielt endlich einen Bericht, dass einige Dateien beschädigt waren und einige Dinge behoben wurden, aber nicht alles.
Danach konnte ich einen dism /online /cleanup-image /restorehealthFehler ausführen, da ich keine Quelle zum Bereinigen finden konnte.
Danach konnte ich einen ausführen, dism /online /cleanup-image /startcomponentcleanupum den Komponentendienst zu bereinigen
Danach konnte ich einen weiteren Lauf /restorehaltherfolgreich absolvieren.
Danach konnte ich den Windows Update-Cache zurücksetzen und alle ausstehenden Updates und Upgrades erneut herunterladen.
Danach konnte ich das 1903-Upgrade sowie das .NET Framework-Update installieren.
Jetzt SCHEINT alles in Ordnung zu sein.
Ich würde es begrüßen, wenn Windows den Benutzern – und nicht nur den Superusern – klarere Informationen darüber geben würde, was im System kaputt ist und was nicht, wenn IRGENDWAS kaputt geht.
Diese Suche war die Hölle. Und ich bin da rausgekommen.