Windows 10 V1703: Fix für DISM Fehler 0x800F081F

[English]Microsoft ist bei der Auslieferung von Windows  10 Creators Update ein Missgeschick passiert. Es sind kaputte Dateien im Installationsabbild enthalten, was zum DISM Fehler 0x800F081F führt. Hier ein paar Hinweise zur Korrektur.


Anzeige

Worum geht es genau?

Wer sein System auf Windows  10 Creators Update aktualisiert oder auch eine Neuinstallation durchführt, bekommt zwar ein funktionierendes System. Aber im Windows Komponentenstore gibt es einen Fehler (siehe auch Windows 10 Creators Update Troubleshooting – Teil 1). Der Fehler zeigt sich, sobald man eine administrative Eingabeaufforderung oder PowerShell (z.B. über das Schnellstartmenü der Schaltfläche Start oder über die Suche und Als Administrator ausführen) aufruft und folgende Befehle eingibt:

DISM.exe /Online /Cleanup-image /Scanhealth
DISM.exe /Online /Cleanup-image /Restorehealth

Der erste Befehl wird in der Regel ohne Fehler durchlaufen – es sei denn, das Feature-Upgrade wurde auf einem System mit beschädigtem Komponentenstore durchgeführt. Aber der zweite Befehl wird am Ende mit einem Fehler 0x800F081F abgebrochen. Ich habe dies bei einem System überprüft (siehe folgender Screenshot).

Der Fehler ist aufgefallen, weil einige Nutzer nach jedem Feature-Upgrade oder nach jedem Patchday vorsorglich die im Beitrag Windows 8: Komponentenstore reparieren beschriebene Prüfung ausführen. Aber die Prüfung mit sfc /scannow fördert keinen Fehler zutage. Es ist übrigens nicht das erste Mal, dass so etwas auftritt.

Die Ursache für den Fehler 0x800F081F in Windows 10 Version 1703

Zur Korrektur des dism-Fehlers müsste man die beschädigten Dateien kennen und ggf. reparieren. Ich hatte im Blog-Beitrag Windows 10: dism-Reparatur erzeugt Fehler 0x800F081F darüber berichtet. Dieser beschreibt, wie man ein korrektes Installationsabbild von DVD als Quelle zur Reparatur verwendet. Aber auch der dort beschriebene Ansatz scheint zu versagen.

DISM liefert zwar eine Protokolldatei und legt diese unter C:\Windows\Logs\DISM\ in der Datei dism.log ab. Bei meiner Inspektion auf einem Testsystem konnte ich keine Ursache herausfinden.

Blog-Leser Gerd hat aber in einem Kommentar den richtigen Fingerzeig und auch den Fix angegeben. Da nicht jeder so fit ist, erläutere ich das Ganze hier etwas ausführlicher. In diesem englischsprachigen Forenthread gibt jemand an, dass die log-Datei beim dism … /scanhealth-Durchlauf die Information liefere, dass die Datei:


Anzeige

Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~amd64~~10.0.15063.0

eine beschädigte MUM (Microsoft Update Manifest) Datei habe (CBS Corrupt MUM). Ich konnte diese Information auf meinem VM-Testsystem zwar nicht verifizieren. Aber der nachfolgende Fix funktionierte.

Ein Fix für den Fehler 0x800F081F in Windows 10 Version 1703

Es gibt also ein Paket, welches Microsoft für Tests (ich tippe: während der Insider Preview) verwendet. Und deren Update-Manifest-Datei ist beschädigt, was den dism in den Fehler zwingt. Der Ansatz besteht nun darin, die Referenz auf die Datei und die Datei selbst zu entfernen. Die Referenzen auf die Dateien des Windows Komponentenstore befinden sich in der Registrierung unter:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\

in den Unterzweigen:

Component Based Servicing\PackageIndex
Component Based Servicing\Package

Um die Referenzen zu entfernen, gehen Sie in folgenden Schritten vor.

1. Rufen Sie den Registrierungs-Editor regedit.exe unter einem Administratorkonto (oder über Als Administrator ausführen bei Standardkonten) über die Suche der Taskleiste auf.

2. Bestätigen Sie die Benutzerkontensteuerung und navigieren Sie zu den nachfolgend genannten Schlüsseln.

3. Weisen Sie volle Zugriffsrechte für das Administratorkonto zu und löschen Sie die Einträge (ggf. vorher über Datei/Export in eine .reg-Datei sichern).

Der erste Schlüssel, zu dem man navigieren muss, lautet:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageIndex\Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~amd64~~0.0.0.0

Der zweite  Schlüssel, zu dem man navigieren muss, lautet:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\Packages\Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~amd64~~10.0.15063.0

Die Schlüssel besitzen diverse Werte, lassen sich aber auch von einem Administratorkonto nicht sofort löschen. Sie erhalten beim Versuch des Löschens eine Fehlermeldung.

Daher sind folgende Zwischenschritte für die beiden angegebenen Schlüssel durchzuführen.

1. Klicken Sie den Schlüssel in der linken Spalte per Rechtsklick an und wählen Sie den Kontextmenübefehl Berechtigungen (siehe Screenshot bei Schritt 4).

2. Wählen Sie auf der Registerkarte Sicherheit die Gruppe Administratoren unter Gruppen- oder Benutzernamen.

3.  Markieren Sie das Kontrollkästchen Vollzugriff in der Spalte Zulassen der Gruppe Berechtigungen für "Administratoren" und schließen Sie die Registerkarte über die OK-Schaltfläche.

Nun lassen sich die Registrierungsschlüssel per Kontextmenü löschen.

4. Klicken Sie den betreffenden Registrierungsschlüssel mit der rechten Maustaste an und wählen Sie den Kontextmenübefehl Löschen.

Entfernen Sie auf diese Weise die beiden oben genannten Registrierungsschlüssel aus der Registrierung. Benutzer Gerd weist in diesem Kommentar darauf hin, dass die fehlerhaften Dateien ebenfalls aus dem Komponentenstore zu löschen seien. In einem weiteren Schritt rufen Sie deshalb den Windows Explorer auf und navigieren zum Ordner:

C:\Windows\Servicing\Packages

Dort löschen Sie die beiden .cat (Katalog) und .mum-Dateien (Manifest):

Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~*.*

Das kann per Kontextmenübefehl oder über das Menüband erfolgen, Sie benötigen aber administrative Berechtigungen, um die Sicherheitsabfrage zu bestätigen. Das habe ich auf meinem System durchgeführt.

Die anschließende Prüfung mit dism lief dann fehlerfrei durch (siehe obiger Screenshot. Mein Dank an Blog-Leser Gerd für die Hinweise im Kommentarbereich. Ich gehe davon aus, dass Microsoft den Fehler irgendwann mit einem Patch behebt.

Ergänzung: Achtung bei einem 64-Bit-Windows

Ich habe die Tests an einer 32-Bit-Windows 10-Installation in einer virtuellen Maschine vorgenommen. In diesem Kommentar weist mich ein englischsprachiger Nutzer darauf hin, dass bei seinem Windows 10 (offenbar ein 64-Bit-System) weitere (abweichende) Einträge in der Registrierung:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageIndex\Microsoft-Windows-TestRoot-and-FlightSigning-WOW64-Package~31bf3856ad364e35~amd64~~0.0.0.0

und vier .cat/.mum-Dateien existieren. Also das ggf. in eurer Umgebung berücksichtigen, falls das zutrifft.

Ähnliche Artikel:
Windows 10 V1703 Wiki/FAQ
Windows 8: Komponentenstore reparieren
Windows 10 Creators Update Troubleshooting – Teil 1
Windows 10: dism-Reparatur erzeugt Fehler 0x800F081F
Windows 10 V1703: SuperFetch geht nicht mehr


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Problemlösung, Windows 10 abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

13 Antworten zu Windows 10 V1703: Fix für DISM Fehler 0x800F081F

  1. Ach du scheiße da gehts ja schon wieder los mit der Frickelei, bekommt das Microsoft irgendwann mal gebacken ein Update oder Upgrade fehlerfrei so auszuliefern das der User selbst nicht nach bessern muss, ich hoffe doch sehr das zumindest das Upgrade nun Fehlerfrei installiert wenn ich die Woche irgendwann in der Firma damit beginne ich will da nicht noch mal 2 Tage beschäftigt sein um für Microsoft nach zu arbeiten, sonst sende ich denen mal eine Rechnung für meine zusätzliche Arbeitsstunden zu die ich mit Windows 10 bereits hatte.

  2. riedenthied sagt:

    Interessant, danke für den Tipp. :-)

  3. deo sagt:

    Danke für den Tipp, wobei ich damit rechne, dass MS die Fehlerbehebung in Kürze selbst über ein kumulatives Update erledigt bei dem offensichtlichen Fehler. So hat der Workarround nur für eine kurze Zeit Bestand. Das hebt die Motivation nicht gerade. Der "kleine Mann" erarbeitet Workarrounds, um Windows 10 wieder nutzbar zu machen und MS heimst die Lorbeeren ein, indem sie sich mit der Fehlerbehebung rühmen, die ihnen kostenlos zugearbeitet werden.
    Sie schludern das Windows zusammen und lassen die Deppen äh Anwender, die Drecksarbeit machen.
    So sehe ich das.

  4. tomto-07 sagt:

    Zitat:
    Wer sein System auf Windows 10 Creators Update aktualisiert oder auch eine Neuinstallation durchführt, bekommt zwar ein funktionierendes System. Aber im Windows Komponentenstore gibt es einen Fehler
    Hatte auch den Fehler, Betonung liegt auf "Hatte".
    Nachdem ich nun nach dieser Anleitung die Registrierung bearbeitet habe ist er weg.
    Klasse, vielen Dank.

  5. Chardonnens sagt:

    So eine ähnliche Anleitung hab ich auch bei Deskmodder gefunden:

    https://www.deskmodder.de/blog/2017/04/24/dism-restorehealth-fehler-in-der-windows-10-15063-und-hoeher-beheben/

    Aber ihre Herr Born ist viel übersichtlicher. Und funktioniert! Dankeschön

    • Günter Born sagt:

      Die Kollegen haben es etwas eher veröffentlicht. Mein Beitrag entstand am Wochenende (Samstag), wurde aber auf Konserve zur Veröffentlichung für heute gelegt. Ich brauche ja täglich Futter für meine Blog-Leser – und so ein Beitrag schreibt sich ja nicht in 10 Minuten, speziell, wenn noch getestet werden muss ;-).

  6. Jo sagt:

    Danke für die ausführliche Anleitung.
    Hat genau wie beschrieben funktioniert.

  7. fierychill sagt:

    kann es denn sein, dass nach "KB4016240" det janze bereits behoben ist?
    weil, bei Schlüssel
    (1) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageIndex\Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~amd64~~0.0.0.0
    hier 1x DWORD32 "Microsoft-Windows-TestRoot-and-FlightSigning-Package~31bf3856ad364e35~amd64~~10.0.15063.0", Wert=0
    dito bei
    (2) HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\PackageIndex\Microsoft-Windows-TestRoot-and-FlightSigning-WOW64-Package~31bf3856ad364e35~amd64~~0.0.0.0

    sonst keine weiteren Einträge (mehr?) bei/mit "HKLM\Microsoft\Windows\…PackageIndex\Microsoft-Windows-TestRoot-and-FlightSigning…".

    • Günter Born sagt:

      Kann ich nicht beurteilen, da der Artikel vor dem Patch geschrieben wurde und ich aktuell kein System mehr auf dem Ausgangszustand habe. Ich überprüfe es aber mal bei Gelegenheit.

      Nachtrag: Ich habe es an einer Maschine mit Build 15063.250 (mit installiertem KB4016240) getestet. Der Fehler tritt dort auch auf.

  8. Also ich ändere jetzt erst mal nichts am System, hab nämlich heute morgen gelesen das Microsoft selbst was bastelt was den Fehler beheben soll und da warte ich lieber erst mal ab.
    Im Ernstfall hab ich ja noch mein 1603 Backup 19.03 und 05.03 was ich zurück setzen könnte.

    Aber trotzdem vielen dank

  9. Freitag sagt:

    Hallo,
    habe die Schritte entsprechend Vorgabe durchgeführt (beide Schlüssel sind auch nicht mehr vorhanden) aber Fehlermeldung uvä (Quelldateien nicht gefunden / Fehler 0x800f081f).
    mit freundlichen Grüßen
    Fred

  10. Freitag sagt:

    Hallo,
    habe nochmal die Schritte entsprechend Vorgabe durchgeführt (mein Fehler beim Ersten mal). Fehlermeldung endlich weg (keine Komponentenspeicherfehler mehr). Danke

    mit freundlichen Grüßen
    Fred

Schreibe einen Kommentar zu fierychill Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.