Upgrade von Windows 10 hängt: Blockierende Komponenten finden


    Tags: , , ,

    Rollback nach gescheitertem Feature-Update von Windows 10Es kommt vor, dass bei einem Feature-Update von Windows 10 die Fort­schritts­anzeige über Stunden bei der gleichen Prozent­angabe stehen bleibt. Nach dem Ab­bruch und einem Neu­start kehrt das Sys­tem auf die alte Ver­sion zurück. Vor dem näch­sten Ver­such geht es darum, die Ursache für das Scheitern zu finden.

    Bei dem beschrie­benen Verhalten handelt es sich um keinen Absturz des Setup. Vielmehr ist es in diesem Fall auf Hardware- oder Software-Komponenten gestoßen, die ein erfolgreiches Upgrade ver­hindern. Allerdings erfährt man nicht, woran das Update gescheitert ist. Windows 10 begnügt sich nach dem Rollback auf die alte Version mit einem allgemeinen Hinweis.

    Bevor man sich, wie hier beschrieben, an die Fehlersuche macht, kann man ein erneutes Update versuchen und dieses mit Hilfe einer setupconfig.ini so konfigurieren, dass Kompati­bilitäts­warnungen unterdrückt werden (siehe dazu: Installation von Funktions-Updates anpassen mit setupconfig.ini).

    Mehrere verstreute Log-Dateien

    Nun kann man sich dort auf die Suche nach den Ursachen begeben. Windows Update schreibt aber eine ganze Reihe von Log-Files in ver­schiedenen Formaten an mehreren Orten, was die Analyse des ge­scheiterten Upgrades erschwert.

    Get-WindowsUpdateLog hilft in der Regel bei der Suche nach Upgrade-Blockern nicht weiter.

    Auf den ersten Blick verspricht hier das PowerShell-Cmdlet Get-WindowsUpdateLog Abhilfe, weil es die binären .etl-Dateien aus allen möglichen Verzeichnissen zu einem lesbaren Log-File zusammen­führt.

    Allerdings zeigt sich schnell, dass deren Einträge für die meisten Anwender nicht verständlich sind und eher dem Microsoft-Support dienen. Hinweise auf den Grund für das gescheitere Upgrade dürfte man hier nicht finden.

    Suche nach Kompatibilitätsproblemen

    Vielver­sprechender sind die Logs im Verzeichnis

    c:\$windows.~bt\sources\panther

    Auch hier finden sich mehrere Dateien in unter­schiedlichen Formaten, darunter auch welche in XML. Ihr Name beginnt mit CompatData und enthält zudem noch Datum und Uhrzeit, so dass man sie dem misslungenen Upgrade-Versuch zuordnen kann.

    Log-Files, die das Setup während des Upgrades schreibt

    In ihnen zeichnet das Setup unter anderem auf, ob und welche Kompatibilitäts­probleme aufgetreten sind. Anstatt jede Datei zu öffnen und nach einem entsprechenden Hinweis zu suchen, ist es einfacher, diese Aufgabe mit PowerShell zu erledigen:

    Get-ChildItem CompatData*.xml | Select-String 'BlockMigration="True"'

    XML-Logdateien nach dem Attribut 'BlockMigration' durchsuchen

    Grundsätzlich könnte man für die Log-Analyse auch das Microsoft-Tool SetupDiag verwenden, das relativ umfangreiche Reports generiert, aber auch alle erfolgreich absolvierten Abschnitte anzeigt.

    In unserem Beispiel finden sich gleich zwei Vorkommen dieses Ausdrucks, sie verweisen auf die Dateien oem45.inf und oem46.inf. Im nächsten Schritt untersucht man folglich diese Dateien, um heraus­zufinden, welche Komponenten Probleme bereiten. Dazu wechselt man in das Verzeichnis %systemroot%\inf.

    Blockierendes Feature aus inf-Datei auslesen

    Wie man aus den Screenshots schnell entnehmen kann, handelt es sich dabei um zwei wohl­bekannte Übeltäter, an denen ein Upgrade von Windows 10 häufig scheitert, nämlich "Microsoft XPS Document Writer" und "Microsoft Print To PDF".

    Über die .inf-Dateien lässt sich schnell herausfinden, welche Komponente das Update blockiert

    Vor dem nächsten Anlauf für das Feature-Update muss man daher diese beiden optionalen Features entfernen. Das kann man über die System­steuerung unter Programme erledigen oder mit Hilfe von PowerShell:

    Disable-WindowsOptionalFeature -Online -FeatureName Printing-PrintToPDFServices-Features

    Disable-WindowsOptionalFeature -Online -FeatureName Printing-XPSServices-Features

    Microsoft XPS Document Writer und Microsoft Print To PDF in der Systemsteuerung deaktivieren

    Als zusätzliche Maßnahme sollte man die Datei compatscancache.dat löschen. Nun kann man sich daran machen, das Upgrade auf die nächste Version von Windows 10 erneut zu starten, entweder über die App Einstellungen oder den Update Assistent.

    Weitere Schritte für nächsten Update-Versuch

    Allerdings kann es sein, dass Windows Update bereits den nächsten Versuch im Hintergrund gestartet hat, während Sie nach dem Fehler suchen. In diesem Fall kommt das Beseitigen der Update-Blocker wahr­scheinlich zu spät und das Upgrade wird erneut scheitern. Daher sollte man es gleich abbrechen und neu anstoßen.

    Bei dieser Gelegenheit sollte man sicherheits­halber auch gleich alle USB-Laufwerke entfernen, weil sie in der Ver­gangenheit immer wieder zum Abbruch des Upgrades geführt haben. Nach dem erfolgreichen Installieren der neuen Windows-Version kann man sie erneut anhängen, wie man auch die beiden oben genannten optionalen Features wieder aktivieren darf.

    PC bootet nach Rollback nicht mehr

    Das Fehlschlagen eines Feature-Updates führt oft zu einem weiteren Problem, das der Fehlersuche erst einmal im Weg steht. Ein unvollständiges Rollback auf die alte Version verhindert dann nämlich, dass sich der Rechner wieder starten lässt.

    Stattdessen erscheint ein blauer Bildschirm mit dem Titel Wiederherstellung und der Meldung, dass der PC repariert werden muss:

    Ein erforderliches Gerät ist nicht verbunden, oder es kann nicht darauf zugegriffen werden.

    Fehlercode: 0xc0000225

    Nach dem gescheiterten Upgrade von Windows 10 lässt sich der Rechner oft nicht mehr booten.

    Die Empfehlung, die Eingabetaste oder F8 zu drücken, um es erneut zu versuchen bzw. die Startein­stellungen aufzurufen, führen zu nichts. Einzig das Betätigen der ESC-Taste funktioniert, um das UEFI-Setup zu öffnen.

    Durch Umstellen der Boot-Reihenfolge lässt sich der Rechner meistens wieder flottmachen.

    Hier hilft es in der Regel, wenn man die Reihenfolge bei den Boot-Devices umstellt, weil Windows Setup offenbar die Einträge im Boot Manager ändert und beim Rollback nicht mehr zurücksetzt.

    Täglich Know-how für IT-Pros mit unserem Newsletter

    Wir ver­wenden Ihre Mail-Adresse nur für den Ver­sand der News­letter.
    Es erfolgt keine per­sonen­be­zogene Auswertung.

    Bild von Wolfgang Sommergut

    Wolfgang Sommergut hat lang­jährige Erfahrung als Fach­autor, Berater und Kon­ferenz­sprecher zu ver­schie­denen Themen der IT. Da­ne­ben war er als System­ad­mi­ni­stra­tor und Con­sultant tätig.
    // Kontakt: E-Mail, XING, LinkedIn //

    Verwandte Beiträge

    Weitere Links

    6 Kommentare

    Hallo, wie haben Sie es geschafft mittels Powershell in das Verzeichnis c:\$windows.~bt\ zu kommen? Mit CMD klappt das, aber wenn ich in der Powershell cd "c:\$windows.~bt" eingebe dann erscheint immer:

    PS C:\> cd $windows.~bt
    In Zeile:1 Zeichen:13
    + cd $windows.~bt
    + ~
    Eigenschaftsname fehlt nach dem Verweisoperator.
    + CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
    + FullyQualifiedErrorId : MissingPropertyName

    Bild von Wolfgang Sommergut

    Aufgrund des $-Zeichens wird der Pfad von PowerShell als Variable definiert. Daher muss man ihn in einfache Anführungszeichen setzen.

    Danke, hat geklappt!

    Super Anleitung.

    Hallo Herr Sommergut, vielen Dank für diese ausführliche Anleitung. Ich konnte fast allen Treibern, die das Upgrade von Win7 auf Win10 blockierten, das Handwerk legen. Nur bei den XPS-Treibern gelingt mir das nicht, obwohl die XPS-Dienste in den Windows-Funktionen deaktiviert sind. Einen anderen Lösungsansatz habe ich nirgends gefunden. Haben Sie hier evtl. einen Tipp für mich?

    Das Problem mit verbleibenden XPS-Diensten trotz Deaktivierung konnte ich mit DriverStoreExplorer lösen. Hier müssen die Treiber (unter der Gruppe Drucker) deaktiviert werden.