![\"\"](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2013\/03\/winb.jpg\")
Bei der Installation von Windows 8.1 Update laufen manche Anwender ja in b\u00f6se Installationsprobleme. Ein Update-Paket kann nicht erfolgreich installiert werden und dabei geht der Update Servicing Store (Update-Speicher) oder der Komponentenspeicher kaputt. In einem kurzen Beitrag m\u00f6chte ich auf das Problem eingehen und einen m\u00f6glichen Reparaturansatz vorstellen.<\/p>\n
<\/p>\n
Windows 8.1 Update erfordert ja die Installation diverser MSU-Pakete die \u00fcber Windows Update oder auch manuell installiert werden k\u00f6nnen. Das Update KB2919355 greift dabei tief in das System ein und ersetzt viele Kernkomponenten, sollte aber auf einem sauberen Windows erfolgreich installiert werden k\u00f6nnen. In der Praxis kommt es jedoch immer wieder zu Installationsfehlern, weil Fremdvirenscanner oder \u00c4hnliches, verschobene Benutzerprofile, gel\u00f6schte Startmen\u00fcordner und so weiter den Update-Vorgang blockieren.<\/p>\n
So weit so schlecht. In diesem Beitrag<\/a> habe ich Ans\u00e4tze zur Vorbereitung auf die Installation des Update KB2919355 beschrieben und auch auf die M\u00f6glichkeit hingewiesen, die ben\u00f6tigten .msu-Dateien manuell herunterzuladen und zu installieren. Leider gibt es einen Show-Stopper in diesem Szenario, den ich bisher nicht wirklich ber\u00fccksichtigt habe. Wird eines der Pakete f\u00fcr Windows 8.1 Update nicht vollst\u00e4ndig installiert oder bricht die Installation ab, kann es zur Besch\u00e4digung des Update Store bzw. des Komponentenspeichers kommen. Beim Versuch, das Update-Paket erneut (ggf. aus einem .msu-Paket) zu installieren, werden dann die Fehler 0\u00d780070002<\/em> und 0\u00d780070003<\/em> o. \u00e4. gemeldet. Dann geht nichts mehr.<\/p>\n Hier habe ich mehrere Testmaschinen erfolgreich auf Windows 8.1 Update aktualisiert. Aber dann hat es eine meiner virtuellen Maschinen getroffen. Bei der Aufzeichnung eines Videotrainings wurde mir gemeldet, dass einzelne Update-Pakete bereits vorhanden seien. Und weil die manuelle Installation eines Update-Pakets aus einer .msu-Datei recht lange dauerte, habe ich das Dialogfeld \u00fcber die Abbrechen<\/em>-Schaltfl\u00e4che den Vorgang beenden lassen. Dabei trat ungewollt das Szenario auf, dass das Update-Paket den Komponentenspeicher besch\u00e4digt hat.<\/p>\n Konkret bekam ich beim n\u00e4chsten Installationsversuch des Pakets den Fehler 0\u00d780070003<\/em> gemeldet. Das System kann offenbar den angegebenen Pfad nicht finden. Beim Abbruch des Installationsvorgangs ist offenbar kr\u00e4ftig etwas kaputt gegangen.<\/p>\n Der in diesem Artikel<\/a> erw\u00e4hnte Windows Update Troubleshooter, der beim Fehler\u00a0 0\u00d780070003<\/em> helfen soll, meldete gleich besch\u00e4digte Dateien und konnte verschiedene Probleme nicht l\u00f6sen.<\/p>\n Also habe ich eine administrativen Eingabeaufforderung<\/a> aufgerufen, um nach dem Vorgaben dieses Artikels Windows 8: Komponentenstore reparieren<\/a> das System manuell auf besch\u00e4digte Dateien pr\u00fcfen und den Komponentenspeicher reparieren zu lassen.<\/p>\n Die Pr\u00fcfung auf defekte Systemdateien mittels sfc \/scannow <\/em>endete bereit mit der Meldung, dass besch\u00e4digte Dateien gefunden, aber nicht repariert werden konnten. Mit dem DISM-Befehl konnte ich auch keinen erfolgreichen Scan des Komponentenspeichers mehr durchf\u00fchren.<\/p>\n Genau in diese Notlage geraten viele Anwender, die beim ersten Update-Installationsversuch in Probleme laufen und dann mit einem besch\u00e4digten System enden. Wer viel Gl\u00fcck hat, kann die Systemwiederherstellung aufrufen und findet einen Wiederherstellungspunkt, \u00fcber den man das System auf einen Zustand vor der Installation des ersten Update-Pakets zur\u00fccksetzt. Dieser Ansatz hat einigen Anwendern in den Microsoft Answers-Foren geholfen. Im Anschluss gilt es, die Ursachen f\u00fcr den Installationsfehler zu beseitigen und dann das Update erneut auszuf\u00fchren.<\/p>\n Wenn das nicht mehr m\u00f6glich ist, bleibt die Hoffnung, dass sich die Ursache f\u00fcr den Installationsabbruch in einem der teilweise installierten und nun besch\u00e4digten Update-Pakete befindet. Eine manuelle Deinstallation \u00fcber die Systemsteuerung und Windows Update ist dann nicht m\u00f6glich. Man kann aber eine administrative Eingabeaufforderung<\/a> aufrufen und dann folgenden Befehle zur Deinstallation des Pakets eingeben (siehe auch<\/a>).<\/p>\n dism \/online \/remove-package \/packagename:[paketname] dism \/online \/cleanup-image \/startcomponentcleanup<\/em><\/p>\n Der erste Befehl entfernt das Paket, w\u00e4hrend der zweite Befehl dann das Abbild in WinSxS bereinigt (ich hatte hier bereits darauf hingewiesen<\/a>). Bleibt noch die Frage nach dem genauen Namen der jeweiligen Pakete. Die Namen der Update-Pakete lassen sich (gem\u00e4\u00df diesem Artikel<\/a>) mit dem Befehl:<\/p>\n Dism \/Online \/Get-Packages<\/em><\/p>\n in der administrativen Eingabeaufforderung abrufen. Um sich nicht durch endlose Listen der Ausgabe k\u00e4mpfen zu m\u00fcssen, l\u00e4sst sich diese in Tabellenform organisieren und dann per DOS-Pipe-Befehl auch gezielt nach dem gew\u00fcnschten Paket durchsuchen. Der folgende Befehl:<\/p>\n DISM \/online \/get-packages \/format:table | findstr KB2919355<\/em><\/p>\n ruft die Pakete ab und erzwingt die Formatierung in Tabellenform. Das Ergebnis wird per Pipe weiter an findstr<\/em> geleitet und dann nach dem Namen des KB-Pakets durchsucht. Hier die Namen f\u00fcr einige Update-Pakete (KB2919355, KB2919442, KB2932046, KB2937592, KB2938439).<\/p>\n Package_for_KB2919355<\/strong>~31bf3856ad364e35~x86<\/strong>~~6.3.1.14\u00a0 (32 Bit) Package_for_KB2919442<\/strong>~31bf3856ad364e35~x86<\/strong>~~6.3.1.8 (32 Bit) Package_for_KB2932046<\/strong>~31bf3856ad364e35~x86<\/strong>~~6.3.1.5 (32 Bit)<\/em> Package_for_KB2937592<\/strong>~31bf3856ad364e35~x86<\/strong>~~6.3.1.0\u00a0 (32 Bit)<\/em> Package_for_KB2938439<\/strong>~31bf3856ad364e35~x86<\/strong>~~6.3.1.0\u00a0 (32 Bit)<\/em> Wichtig ist, dass die f\u00fcr die 32- oder 64-Bit-Windows-Version passenden Paketnamen verwendet werden. Der Befehl f\u00fcr die 32-Bit-Version von Windows 8.1 sieht f\u00fcr KB2919355<\/em> dann folgenderma\u00dfen aus:<\/p>\n dism \/online \/remove-package \/packagename:Package_for_KB2919355~31bf3856ad364e35~<\/em>x86~~6.3.1.14 M\u00f6glicherweise muss in der besch\u00e4digten .mum-Datei gem\u00e4\u00df diesem Forenposting<\/a> mittels eines mit administrativen Rechten laufenden Editors der Eintrag:<\/p>\n permanence=\"permanent\"<\/em><\/p>\n gel\u00f6scht werden, ehe die DISM-Befehle ausgef\u00fchrt werden. Die besch\u00e4digten .mum-Dateien finden sich im Ordner<\/p>\n c:\\windows\\servicing\\packages<\/em><\/p>\n Mit etwas Gl\u00fcck l\u00e4uft der DISM-Befehl dann durch und kann das Paket entfernen, so das die Besch\u00e4digung des Komponentenspeichers behoben wird. Dann sollte sich das Paket im Anschluss erfolgreich installieren lassen.<\/p>\n Wenn etwas schief gehen kann, geht es meist gr\u00fcndlich schief. Auf der Testmaschine hatte ich ja nach einem manuell abgebrochenen Installationsversuch eines Update-Pakets den Fehler 0\u00d780070003<\/em>. Also habe ich nacheinander alle Update-Pakete von Windows 8.1 Update mittels der obigen Anweisungen deinstallieren lassen (denn sfc \/scannow <\/em>lieferte den Hinweis auf besch\u00e4digte Dateien und dism \u2026. \/scanhealth <\/em>lief \u00fcberhaupt nicht durch). Die Deinstallation der Update-Pakete lief auch durch, erforderte aber jeweils einen Neustart. Also ich dann den Befehl:<\/p>\n dism \/online \/cleanup-image \/startcomponentcleanup<\/em><\/p>\n ausf\u00fchren lie\u00df, sah auch alles gut aus. Der Befehl werkelte so vor sich hin, brauchte aber irre lange. Weil ich nicht so lange warten wollte, habe ich den Host in den Ruhemodus versetzt. Und da ich momentan (zur Anfertigung von Videoaufnahmen) den Rechner per HDMI-Kabel in ein anderes Zimmer verbannt habe, muckt der NVidia-Grafiktreiber und wirft gelegentlich Bluescreens oder schaltet mir den Monitor schwarz. Dieser Bluescreen trat auch prompt beim Herunterfahren auf, so dass ich das System ausschalten musste. Dadurch kam auch die virtuelle Maschine aus dem Tritt \u2013 und VMware meldete, dass das Image neu zu booten w\u00e4re. Hat mich zun\u00e4chst alles nicht gest\u00f6rt, weil sowohl der Host mit Windows 7 als auch das Gastbetriebssytem mit Windows 8.1 problemlos hochfuhren. Nur als ich den obigen Befehl zum Bereinigen des Image ausf\u00fchren wollte, wurde ich mit dem Fehler 0x800f0806 begr\u00fc\u00dft (siehe unterer Befehl in folgendem Screenshot).<\/p>\n Die Meldung, dass noch Vorg\u00e4nge ausst\u00fcnden gab mir R\u00e4tsel auf. Die Suche nach einer Datei Pending.xml <\/em>(siehe hier) im Windows-Ordner verlief negativ. Ich f\u00fchrte den Fehler auf die abgebrochene Aktion beim Bluescreen zur\u00fcck. Nun war guter Rat teuer \u2013 eine Pr\u00fcfung des Komponentenstore per DISM mit \/ScanHealth meldete, dass der Komponentenspeicher repariert werden k\u00f6nne. Also habe ich erfolgreich den DISM-Befehl mit \/RestoreHealth ausf\u00fchren lassen (siehe oben).<\/p>\n Das cleanup des Komponentenspeichers bzw. von WinSxS mittels DISM lief aber nicht durch. Ein Blick in die dism.log<\/em> zeigte mir, dass im tempor\u00e4ren Ordner bestimmte DLLs nicht gefunden wurden. Also habe ich eine Datentr\u00e4gerbereinigung der Systemdateien durchgef\u00fchrt, wo ich die tempor\u00e4ren Ordner l\u00f6schen lie\u00df. Half aber nicht.<\/p>\n Nach einer Recherche im Internet stie\u00df ich auf diesen Post<\/a> von Andr\u00e9 Ziegler, der mich auf die richtige Spur brachte. Andr\u00e9 postete:<\/p>\n The error 0x800F0806 = CBS_E_PENDING Als ich dann einen Neustart einleiten wollte, sah ich schon, dass Aktualisierungen anst\u00fcnden. Da ich das automatische Update noch aktiviert hatte, waren schon wieder Updates heruntergeladen worden und harrten der Installation. Ich habe dann die Updates installieren lassen.<\/p>\n Nach dem Neustart habe ich dann das automatische Update deaktiviert und konnte den Befehl:<\/p>\n dism \/online \/cleanup-image \/startcomponentcleanup<\/em><\/p>\n erneut ausf\u00fchren. Die \u00dcberpr\u00fcfung mit sfc \/scannow ist nun erfolgreich durchgelaufen \u2013 die besch\u00e4digten Pakete im Komponentenstore sind \u2013 wie erwartet, entfernt worden. Ich versuche nun eine erneute Installation der Update-Pakete f\u00fcr Windows 8.1 Update. Sofern sich neue Erkenntnisse ergeben, trage ich diese hier nach.<\/p>\n \u00c4hnliche Artikel:<\/strong> b1: Windows 8.1 Update: Probleme und Troubleshooting<\/a> Bei der Installation von Windows 8.1 Update laufen manche Anwender ja in b\u00f6se Installationsprobleme. Ein Update-Paket kann nicht erfolgreich installiert werden und dabei geht der Update Servicing Store (Update-Speicher) oder der Komponentenspeicher kaputt. In einem kurzen Beitrag m\u00f6chte ich auf … Weiterlesen Nun hat's mich auch erwischt<\/h3>\n
![\"_Error-01\"](\"https:\/\/borncity.com\/blog\/wp-content\/uploads\/2014\/04\/Error-01_thumb.jpg\" "\\"_Error-01\\"")
<\/a><\/p>\nSystemwiederherstellung kann helfen<\/h3>\n
Defekte Update-Pakete deinstallieren<\/h3>\n
\n<\/em><\/p>\n
\n<\/em>Package_for_KB2919355~31bf3856ad364e35~amd64<\/strong>~~6.3.1.14 (64 Bit)<\/em><\/p>\n
\n<\/em>Package_for_KB2919442~31bf3856ad364e35~amd64<\/strong>~~6.3.1.8 (64 Bit)<\/em><\/p>\n
\nPackage_for_KB2932046~31bf3856ad364e35~amd64<\/strong><\/em>~~6.3.1.5 (64 Bit)<\/em><\/p>\n
\nPackage_for_KB2937592~31bf3856ad364e35~amd64<\/strong><\/em>~~6.3.1.0\u00a0 (64 Bit)<\/em><\/p>\n
\nPackage_for_KB2938439~31bf3856ad364e35~amd64<\/strong><\/em>~~6.3.1.0 (64 Bit)<\/em><\/p>\n
\n<\/em>dism \/online \/cleanup-image \/startcomponentcleanup<\/em><\/p>\nNachtrag: DISM liefert Fehler 0x800f0806<\/h3>\n
![\"\"](\"https:\/\/i.imgur.com\/vrMQrII.jpg\")
<\/p>\n
\nYou can't use the command if there is reboot required.<\/p><\/blockquote>\n![\"\"](\"https:\/\/i.imgur.com\/4YjYBaq.jpg\")
<\/p>\n
\na1: Neues zu Windows 8.1 Update<\/a>
\na2: B\u00fccher f\u00fcr\/zu Windows 8.1 Update<\/a>
\na3: Windows 8.1 Update 1: Apps an Taskleiste anheftbar<\/a>
\na4: Info-Splitter: Windows 8.1 Update 1 zeigt App-Vorschau in Taskleiste
\na5: Windows 8.1 Update 1 verwendet Desktop als Standard und App Schlie\u00dfen-Option
\na6: Windows 8.1 Update 1: Weitere Neuerungen in OneDrive, Diskbelegung, IE<\/a>
\na7: Windows 8.1 Update 1: Installation zusammengefasst<\/a>\u2013Teil 1
\na8: Windows 8.1 Update 1: Neuerungen im \u00dcberblick<\/a>\u2013Teil 2
\na9: Windows 8.1 Update bringt WIMBoot f\u00fcr schwache Hardware<\/a>
\na10: Media Feature Pack f\u00fcr Windows 8.1 N Update erh\u00e4ltlich<\/a>
\na11: Microsoft habe fertig! Keine Updates mehr f\u00fcr Windows 8.1<\/a>
\na12: Windows 8.1: Doch Updates bis August<\/a><\/p>\n
\nb2: Windows 8.1 Update kann WSUS 3.2 blockieren<\/a>
\nb3: Windows 8.1 Update: Das Schlie\u00dfen einer App aktiviert den Desktop<\/a>
\nb4: Windows 8.1 Update: hide\/show Power button on start screen<\/a>
\nb5: Windows 8.1 Update: Liefert Fehler 80240442 bei Update-Suche<\/a>
\nb6: Windows 8.1 Update-Bereinigung zerst\u00f6rt DISM<\/a>
\nb7: Patch KB293908 f\u00fcr Windows 8.1 Update-Probleme<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"