Inplace Upgrade geht nicht

[SurgeonX1]

Das ist normal. DIe Dateien werden Systemintern verwaltet und auch geöffnet, wenn benötigt. Eine Zuordnung wäre nur dann sinnvoll, wenn Du über den Explorer die Dateien öffnen möchtest.

Was mich wundert ist da mehr, dass es das da be iDir überhaupt gibt. Wie lautet denn der vollständige Registry Key?

Bei mir gibt es im Pfad HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\~ weder .mui noch .mum als Eintag.

...FileExts\.mui //.mum

Ich dachte nur, da es ja mui und mum-Dateien gibt, dürften diese nicht als nicht registriert / ungenutzt auftauchen !
Die hängen doch gerade mit den Packages /Katalogen /Manifesten zusammen, dachte ich.
Daher hatte ich da eine mögliche Ursache vermutet.

[Tante Google]

[SurgeonX1]

Ok, die CBS.log passt nicht, aber egal. Die setupapi.dev.log überschneidet sich noch mit der alteb CBS.log von weiter oben im Thread.

Gut, da haben wir doch das vermutete Problem:

Code: Alles auswählen

[Boot Session: 2018/08/02 01:01:28.234]

>>>  [Uninstall Driver Updates]
>>>  Section start 2018/08/02 01:00:33.945
      cmd: C:\Windows\servicing\TrustedInstaller.exe
     sto: Driver Update Context:
     sto:      Image State        = Specialized
     sto:      Image Architecture = amd64
     sto:      Transaction        = CbsDriversAndPrimitives
     sto:      Driver Updates     = 22
     inf: Opened INF: 'C:\Windows\System32\DriverStore\FileRepository\netrndis.inf_amd64_neutral_1c5becb2deac08f0\netrndis.inf' ([strings])
     inf: Opened INF: 'C:\Windows\System32\DriverStore\FileRepository\bth.inf_amd64_neutral_de0494b6391d872c\bth.inf' ([strings])
     inf: Opened INF: 'C:\Windows\System32\DriverStore\FileRepository\wudfusbcciddriver.inf_amd64_neutral_5cbd2ae76abeb770\wudfusbcciddriver.inf' ([strings])
     inf: Opened INF: 'C:\Windows\System32\DriverStore\FileRepository\netrndis.inf_amd64_neutral_1c5becb2deac08f0\netrndis.inf' ([strings])
     inf: Opened INF: 'C:\Windows\System32\DriverStore\FileRepository\mshdc.inf_amd64_neutral_552ea5111ec825a6\mshdc.inf' ([strings])
     inf: Opened INF: 'C:\Windows\System32\DriverStore\FileRepository\sti.inf_amd64_neutral_972872c0e59df52d\sti.inf' ([strings])
!!!  sto: Failed to find driver update 'C:\Windows\WinSxS\amd64_input.inf_31bf3856ad364e35_6.1.7601.18199_none_7e4402e836f9bd5c\input.inf' in Driver Store. Error = 0x00000490
<<<  Section end 2018/08/02 01:00:34.194
<<<  [Exit status: FAILURE(0x00000490)]

Aus irgendwelchen Gründen fehlt die input.inf im Driver Store. Das führt dann zum 0x80070490 und schließlich zum Rollback.

Das heißt, wenn es jetzt nur dieser eine Treiber wäre, müsste man ihn wieder in den Driver Store installieren:

Code: Alles auswählen

pnputil -a C:\Windows\WinSxS\amd64_input.inf_31bf3856ad364e35_6.1.7601.18199_none_7e4402e836f9bd5c\input.inf

Windows wird jetzt meckern, dass der Treiber keine Signatur besitzt (stimmt aber nicht), das kann man ignorieren. Ist nur etwas nervig.

Dann ist der Treiber aber wieder mit dem richtigen Verzeichnis im Driver Store und sollte sich deinstallieren lassen.

Problem ist jetzt aber, das nach dem Treiber noch etliche weitere Treiber folgen. Einfach um sicher zu gehen, würde ich das mit allen verbleibenden Treibern auch machen (nervt etwas wegen der fehlenden Signatur):

Code: Alles auswählen

pnputil -a C:\Windows\WinSxS\amd64_usbcir.inf_31bf3856ad364e35_6.1.7601.18208_none_fc7c514913160371\usbcir.inf
pnputil -a C:\Windows\WinSxS\amd64_wdma_usb.inf_31bf3856ad364e35_6.1.7601.18208_none_cb4c95aacd6edb39\wdma_usb.inf
pnputil -a C:\Windows\WinSxS\amd64_usbvideo.inf_31bf3856ad364e35_6.1.7601.18208_none_8c30aa8dd127c018\usbvideo.inf
pnputil -a C:\Windows\WinSxS\amd64_iscsi.inf_31bf3856ad364e35_6.1.7601.18386_none_9aa001af0a7d5207\iscsi.inf
pnputil -a C:\Windows\WinSxS\amd64_wpdmtp.inf_31bf3856ad364e35_6.1.7601.18738_none_7dae99669d5cd8af\wpdmtp.inf
pnputil -a C:\Windows\WinSxS\amd64_wdmaudio.inf_31bf3856ad364e35_6.1.7601.19091_none_be33a73631090804\wdmaudio.inf
pnputil -a C:\Windows\WinSxS\amd64_tpm.inf_31bf3856ad364e35_6.1.7601.19146_none_0a2a4c4e1dddf592\tpm.inf
pnputil -a C:\Windows\WinSxS\amd64_disk.inf_31bf3856ad364e35_6.1.7601.19133_none_57d5b2098add6acc\disk.inf
pnputil -a C:\Windows\WinSxS\amd64_usbstor.inf_31bf3856ad364e35_6.1.7601.19144_none_a68baf39ae8b37fd\usbstor.inf
pnputil -a C:\Windows\WinSxS\amd64_usb.inf_31bf3856ad364e35_6.1.7601.23529_none_29a20b403e334e39\usb.inf
pnputil -a C:\Windows\WinSxS\amd64_usbport.inf_31bf3856ad364e35_6.1.7601.23529_none_1c6c03bd334e9c20\usbport.inf
pnputil -a C:\Windows\WinSxS\amd64_usbstor.inf_31bf3856ad364e35_6.1.7601.17577_none_a66e757baea0992f\usbstor.inf
pnputil -a C:\Windows\WinSxS\amd64_nvraid.inf_31bf3856ad364e35_6.1.7601.17577_none_97c2e9ecd5cc2253\nvraid.inf
pnputil -a C:\Windows\WinSxS\amd64_iastorv.inf_31bf3856ad364e35_6.1.7601.17577_none_0cf9793d9e95787b\iastorv.inf
pnputil -a C:\Windows\WinSxS\amd64_amdsata.inf_31bf3856ad364e35_6.1.7601.17577_none_aa54fe0598b884c4\amdsata.inf

Dann sind sie auf jeden Fall im Driver Store.

Zur Info: pnputil -a installiert die Treiber nicht, also keine Bange, sie werden nur in den Driver Store hinzugefügt.

Und jetzt erneut mal die Updatebereinigung durchführen.

ABer das bezieht sich jetzt auf den Lauf vom 2018-08-02.

Nach Durchführen und Neustart Updatebereinigung, dann erneut Neustart, Windows konfiguriert bis 30%, dann Neustart, dann bis 32%, dauert lange,
dann wieder Neustart, 100% (dauert lange),
dann ok.
Dann Datenträgerbereinigung, keine Dateien mehr in der Updatebereinigung ! Also ok !
Nur ist mir immer noch unklar, was genau die Ursache war.

Die input.inf hatte ich allerdings vorher im Driver Store gefunden !

[SurgeonX1]

Ich hoffe nur, es bleibt so, wenn die anfängliche Ursache unklar ist.

[DK2000]

Gut, das es jetzt doch daran lag und es jetzt wieder läuft.

Was der Grund ist, warum da Treiber am System vorbei, aus dem Driver Store entfernt wurden, kann ich Di aber nicht sagen. Eventuell CCleaner oder ein anderes Tool, welches veraltete Treiber entfernt? Da bin ich überfragt. Das geht aus den Logs nicht mehr hervor.

[SurgeonX1]

CCleaner setze ich nur mit wenigen Markierungen ein, also differenziert.
Sonst nichts.
An den Systemordnern mache ich normalerweise auch nicht herum.
Muss das noch mal überlegen.

Nach sfc bleiben aber immer noch Fehler übrig, siehe cbs.log, und in Pending renames danach von 0 auf 1877 Elemente(vorher zeitweise 3000 bis 5000 und mehr).

CBS.log

PackagesList 3.txt

[SurgeonX1]

Sollte ich da noch mal ein IU probieren ??

[DK2000]

Die Dateien, welche er nicht reparieren kann, stammen aus dem KB3125574. Das müsste man jetzt wieder mit dem CheckSUR Tool reparieren.

Was allerdings auffällig ist, sind die vielen CBS_E_INVALID_PACKAGE, CBS_E_MANIFEST_INVALID_ITEM usw. Normaler Weise ignoriere ich die, aber das wirklich viel bei Dir. Habe aber auch noch nicht herausgefunden, wie man ermitteln kann, an welchen Dateien das liegt.

Was mich interessieren würde, ob wenn Du nach *0684284_4177543353* oder *30684284_4177543351* suchst, ob Du da irgendwelche Dateien findest.

Ansonsten, IU wäre da immer eine gute Idee. U.U. läuft es jetzt sogar. Falls nicht, dann etwas überlegen, wie man an die gelöschte setupact.log ran kommt (z.B. mit einem Tool, welches gelöschte Dateien wieder herstellt.)

[SurgeonX1]

Unter den Nummern finde ich nichts. Das sind wohl virtuelle Sessionnummern.

Mir ist aber immer noch nicht klar, wie das invalid manifest item /invalid package entsteht.
Born konnte das auch nicht genau erklären.
Kann das jemand hier ??
Es ist ein Problem da, aber was heisst das genau, was ist invalid ??

Manifest Dateien liegen im xml Format vor.

Manifest-Dateien sind Dateien, die von Microsoft in Windows XP eingeführt wurden. Sie enthalten optionale Metadaten zu ihrer zugehörigen EXE-Datei und liegen im XML-Format vor. Das Manifest kann als Ressource in die EXE-Datei eingebunden sein oder als separate gleichnamige Datei mit der Endung .exe.manifest existieren.

In Windows XP sorgten diese Dateien hauptsächlich dafür, dass die Steuerelemente der zugehörigen Programme im Design von Windows XP dargestellt wurden,[1] anstatt im alten Design, das von Windows 95 bis 2000 verwendet worden war. Besaß eine EXE-Datei keine Manifest-Datei, und war sie nicht für Windows XP neu kompiliert worden, so wurden alle Steuerelemente im alten Design gezeichnet.

Mit Windows Vista (und der darin neu eingeführten Benutzerkontensteuerung) konnte in der Manifest-Datei auch angegeben werden, in welcher Sicherheitsstufe das Programm laufen soll sowie einige weitere Privilegien, die das Programm erhalten kann.[2]

Unter Windows 7 bekamen die Manifest-Dateien eine weitere Bedeutung: in ihnen konnte angegeben werden, für welches Windows die Datei entwickelt wurde, sowie einige weitere Einstellungen bezüglich der Rückwärtskompatibilität;[3] Windows führte die Datei dann automatisch mit den von den Entwicklern gewählten Kompatibilitäts-Einstellungen aus. Ist keine Manifest-Datei vorhanden, verhält sich die Datei wie unter Windows Vista. Windows Vista und XP ignorieren diesen Abschnitt der Manifest-Datei.

Weiterhin wird in Manifest-Dateien (besonders bei solchen, die gegen das .NET Framework kompiliert wurden) die eindeutige ID der Assembly angegeben, sowie Informationen zu Schnittstellen und Abhängigkeiten von anderen Assemblies.[4]

Unter manchen älteren Windows-Versionen ab XP gab es ein Sicherheitsproblem, das direkt mit den Manifest-Dateien zusammenhing: Windows suchte bei jeder ausgeführten EXE-Datei nach einer zugehörigen Manifest-Datei, auch bei Dateien aus dem Windows-Systemverzeichnis. Ein Angreifer konnte die Manifest-Datei einer Systemdatei mit Schadcode präparieren, der dann beim Aufrufen der Systemdatei automatisch ausgeführt wurde.[5]

[SurgeonX1]

Die Dateien, welche er nicht reparieren kann, stammen aus dem KB3125574. Das müsste man jetzt wieder mit dem CheckSUR Tool reparieren.

Was allerdings auffällig ist, sind die vielen CBS_E_INVALID_PACKAGE, CBS_E_MANIFEST_INVALID_ITEM usw. Normaler Weise ignoriere ich die, aber das wirklich viel bei Dir. Habe aber auch noch nicht herausgefunden, wie man ermitteln kann, an welchen Dateien das liegt.

Was mich interessieren würde, ob wenn Du nach *0684284_4177543353* oder *30684284_4177543351* suchst, ob Du da irgendwelche Dateien findest.

Ansonsten, IU wäre da immer eine gute Idee. U.U. läuft es jetzt sogar. Falls nicht, dann etwas überlegen, wie man an die gelöschte setupact.log ran kommt (z.B. mit einem Tool, welches gelöschte Dateien wieder herstellt.)

Immerhin geht ja nun die Updatebereinigung wieder !

[DK2000]

Das lag ja an mindestens einem fehlenden Treiber, was da die Updatebereinigung blockiert hatte.

Was die Manifeste angeht, das CBS kann halt den Inhalt nicht lesen:

Code: Alles auswählen

2018-08-15 11:47:15, Info                  CBS    Warning: Unrecognized packageExtended attribute.
2018-08-15 11:47:15, Info                  CBS    Expecting attribute name [HRESULT = 0x800f080d - CBS_E_MANIFEST_INVALID_ITEM]

Er öffnet die Datei, der Attribute Name wird erwartet, aber nicht gefunden. Und damit ist das Manifest ungültig.

Aber das ist im Grunde genommen nutzlose Information solange man nicht weiß, um welche Datei es da genau geht. Das verschweigt einem ja das CBS.

Aber wie gesagt, in dem meisten Fällen stört das nicht.

Und verwechsele jetzt nicht diese Manifest-Dateien für Updates (*.mum/*.manifest) mit dem Manifest-Dateien für Anwendungen (*.manifest). Die haben zwar größtenteils den selben grundlegenden Aufbau, aber unterschiedliche Aufgaben.

Die *.mum und die *.manifest Dateien sind 'Berschreibungen' für den CBS, wie das Update heißt, wie die Zugehörigkeiten sind, welche Voraussetzungen erfüllt sein müssen, wie es zu installieren/Deinstallieren ist usw. Die *.manifest Dateien werden nach der Installation in ein Binärformat übertragen, so dass sie nicht mehr lesbar sind.

[SurgeonX1]

Ich hatte früher auf diesem PC und einem anderen mit XP Berechtigungsprobleme.
Warum auf diesem, war mir völlig unklar.
Ich habe das soweit überprüft, Systemdateien, aber nichts Falsches gefunden.
Nicht dass es irgendwo daran liegt.

[SurgeonX1]

Aber immerhin dieses:

CheckSUR.log

!

[SurgeonX1]

Also Updatebereinigung geht, checksur ist sauber, Updates gehen auch,
dennoch ist sfc nicht sauber.
Irgendwie komisch.

@DK2000:
Du hattest mir ja mal bei sfc in einem anderen Forum geholfen,
das Problem wurde gelöst und das System dann sauber.

Diese Manifeste sind ein Ding, was noch zu lösen ist, vor allem MS sollte hier mal Lösungen anbieten
und die Dinge auch für normale User reparierbar machen.

[skorpion68]

@SurgeonX1
Öffne bitte die Eingabeaufforderung (cmd.exe) mit erhöhten Rechten und gib folgenden Befehl ein:

Code: Alles auswählen

findstr /c:"[SR]" %windir%\Logs\CBS\CBS.log >"%userprofile%\Desktop\sfcdetails.txt"

Füge die LOG sfcdetails.txt an deine nächste Antwort an.

Anleitung von Microsoft
Verwenden des Systemdatei-Überprüfungsprogramms (SFC.exe) zur Problembehandlung bei fehlenden oder beschädigten Systemdateien

[DK2000]

Vermutlich immer noch die paar Dateien aus dem KB3125574, wenn da zwischenzeitlich nicht was gemacht wurde.

Wundert mich bloß, dass CheckSUR das nicht sieht und versucht zu reparieren.