Inplace Upgrade geht nicht

[DK2000]

Ja, gut, im Netzt steht so einiges zum 0x80070490, aber was trifft da genau auf Dein Problem zu.

Es geht mir darum herauszufinden, was genau diesen Fehler bei Dir in der Startphase (startup processing) verursacht. Das ist das entscheidende. Die ersten Phase läft sauber durch. Es werden alle abgelösten Updates gefunden, das Ziel der Updates wird auf 'absend' gesetzt und die Updates werden für das 'startup processing' zur Entfernung markiert. Bis hier hin ist alles sauber. Erst beim anschließenden Neustart, welcher bei Windows 7 leider unerlässlich ist, können die Updates auf einmal nicht mehr entfernt werden, weil nicht gefunden (=0x80070490). Und das bekomme ich bislang nicht reproduziert. Ich weiß nicht, was diesen Fehler nur in der Phase verursachen könnte.

Und was den Fehler 0x800f080d angeht, den zu ermitteln, wird kompliziert, da solange man nicht weiß, um welches Manifest es geht, wird man das nicht lösen können. Und das steht da leider nirgends. Und so geht auch der CBS vor. Kann Manifest nicht lesen, weiß also nicht, um welchen Updates es geht und ignoriert das Ganze.

[Tante Google]

[SurgeonX1]

Ok, das klingt ja mal schon ein wenig nach logischem Ablauf, den ich vorher angefragt hatte.
Könnte das ja mal an Born schicken, oder MS, und da anfragen.
Aber nach meinem Verständnis sind es mehrere Manifeste, nicht nur eins, für die diversen Dateien/ Updates.

Im übrigen war lange vorher mal der BITS defekt und gar keine Updates gingen mehr, irgendwo in diesem Forum hatte ich das geschrieben. Hatte ich irgendwie behoben und repariert bekommen.

[skorpion68]

@SurgeonX1
Da du ja noch etwas forschen möchtest würde ich gern wissen ob es im Ordner C:\Windows\Logs\CBS noch CAB-Dateien wie z. Bsp. CbsPersist_20180727XXXXXX.cab gibt. Wenn ja, dann packe bitte mal die CAB-Dateien für den Zeitraum vom 27.07.2018 bis 29.07.2018 und füge sie an deine nächste Antwort an. Da lt. LOG PackageList.txt seit dem 28.07.2018 keine Veränderungen mehr dokumentiert wurden und du geschildert hattest, dass die Updates auch nach der Windows Update-Bereinigung am 02.08.2018 wiederhergestellt wurden erhoffe ich mir in den gesicherten LOGs CBS.log die Erklärung für dieses Problem.

[DK2000]

Ja, ein paar frische Logs wären da nicht schlecht.

Und zusätzlich noch die Dateien:

C:\Windows\inf\setupapi.dev.log
C:\Windows\WinSxS\pending.xml

Die pending.xml kannst Du dann auch löschen.

[SurgeonX1]

@SurgeonX1
Da du ja noch etwas forschen möchtest würde ich gern wissen ob es im Ordner C:\Windows\Logs\CBS noch CAB-Dateien wie z. Bsp. CbsPersist_20180727XXXXXX.cab gibt. Wenn ja, dann packe bitte mal die CAB-Dateien für den Zeitraum vom 27.07.2018 bis 29.07.2018 und füge sie an deine nächste Antwort an. Da lt. LOG PackageList.txt seit dem 28.07.2018 keine Veränderungen mehr dokumentiert wurden und du geschildert hattest, dass die Updates auch nach der Windows Update-Bereinigung am 02.08.2018 wiederhergestellt wurden erhoffe ich mir in den gesicherten LOGs CBS.log die Erklärung für dieses Problem.

Wirklich ???
Das Problem ist doch mittlerweile unter allen BS bis Win 10 bekannt, und offensichtlich gibt es keine Lösung dafür !

[DK2000]

Naja, Problem ist, das die Lösung meist individuell ist und es für viele Sachen kein allgemeine Lösung gibt.

Vermute da auch im Moment das Problem an einer ganz anderen Stelle und nicht im Komponentenspeicher. Aber dazu bräuchte ich mal frische Logs, welche im Anschluss an die Datenträgerbereinigung erstellt wurden:

C:\Windows\logs\cbs\CBS.log
C:\Windows\inf\setupapi.dev.log
C:\Windows\WinSxS\pending.xml

[SurgeonX1]

Habe ich oben schon gelesen.
Aber das Problem existiert genauso haufenweise im Netz !

[DK2000]

Aber offensichtlich ohne Lösung, welche bei Dir anwendbar ist. Ansonsten wäre es ja schon gelöst.

Hänge einfach mal die Dateien ran und mal schauen.

[SurgeonX1]

Gerade das verwundert.
Aber das Problem scheint eher komplexer Natur zu sein.
MS selbst ist hier eher verantwortlich; wenn DISM so etabliert wäre wie unter 8 oder 10, wäre es vllt. damit lösbar.
Ansonsten sollte MS was anbieten.
Das Problem existiert vielfach im Netz, mit Teillösungen oder nicht funktionierenden oder schwer zu verstehenden.
Wie bereits gesagt, Born spricht u.a. von schlechter Programmierung der Updates.
Und bei einem länger laufenden BS scheint dann irgendwann ein Fehler aufzutreten, der sich summiert.

[DK2000]

Das wäre mit DISM in Deinem Falle auch nicht lösbar, wenn ich mit meiner Vermutung richtig liege, da das Problem außerhalb des Komponentenspeichers liegt. Aber um das zu bestätigen bräuchte ich wirklich zum. mal die C:\Windows\inf\setupapi.dev.log von Dir, um da mal was nachzuschauen. Optimaler wäre es, die passende CBS.log noch dazu, Dann könnte ich Dir u.U. eine Lösung anbieten.

[SurgeonX1]

Gut, ich schau mal, aber mein Gefühl ist da eher negativ, dass das was bei rauskommt.

Die pending xml gibt es weder auf dem defekten Win 7 noch auf einem intakten bei mir.
Auf dem Intakten ist nur der Ordner pending renames leer,
auf dem Defekten schwankt der zwischen 2000 und mehr Einträgen,
aktuell 5688.

Cbs.log hatte ich ja schon mal gepostet.

setupapi.dev.log

CBS.log

[SurgeonX1]

@SurgeonX1
Da du ja noch etwas forschen möchtest würde ich gern wissen ob es im Ordner C:\Windows\Logs\CBS noch CAB-Dateien wie z. Bsp. CbsPersist_20180727XXXXXX.cab gibt. Wenn ja, dann packe bitte mal die CAB-Dateien für den Zeitraum vom 27.07.2018 bis 29.07.2018 und füge sie an deine nächste Antwort an. Da lt. LOG PackageList.txt seit dem 28.07.2018 keine Veränderungen mehr dokumentiert wurden und du geschildert hattest, dass die Updates auch nach der Windows Update-Bereinigung am 02.08.2018 wiederhergestellt wurden erhoffe ich mir in den gesicherten LOGs CBS.log die Erklärung für dieses Problem.

Die Persist habe ich nur vom 1.8. bis 10.8.
Die sind teils sehr groß bis 400 MB entpackt, ich weiss nicht, was man hier anhängen kann, daher nur eine erst mal.
Nee, läßt sich selbst mit 15 MB nicht anhängen !

[DK2000]

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.

[SurgeonX1]

Vor weiteren Ausführungen noch ein Einwurf.
Zufällig per CCleaner gesehen, dass
mum und mui als nicht registriert gelten.
Normal ist das wohl nicht, oder ??
Es wurde nur gesehen, nichts geändert.

mui + mum Win 7 1 ungenutzt !.jpg

[DK2000]

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.