Ich wüsste jetzt ehrlich gesagt nicht, wie der Script ctwimage2b-64.bat in irgendeiner Form bei dem Problem hier hätte helfen sollen. Der Script sichert einfach nur C: in eine Install.wim, welche auch vom Setup verarbeitet werden kann. Ist C: beschädigt, ist auch das Image in der Install.wim beschädigt. Repariert wird da nichts. Dazu ist das Tool nicht gedacht.

[quote]1. Falle ein install.wim der Größe 22,7GB und dauert 35min
und im
2. Falle ein install.wim der Größe von nur 19,7GB(!) und dauert 30min.[/quote]
Das liegt einfach nur daran, das im 1. Fall keine [i]Install.wim[/i] am Ziel gefunden wurde und dadurch [i]DISM[/i] mit [i]/capture-image /compress:max[/i] ausgeführt wurde, um eine neue Install.wim zu erstellen. Im 2. Fall wurde eine [i]Install.wim[/i] vorgefunden und [i]DISM [/i]wird jetzt mit [i]/append-image[/i] ausgeführt. Es wird nur ein weiteres neues Image zu den bereits vorhandenen Images hinzugefügt. Hier werden dann nur Dateien in die [i]Install.wim[/i] hinzugefügt, welche in der [i]Install.wim[/i] noch nicht vorhanden sind. Alle bereits vorhandenen Dateien werden, sofern sie identisch sind, werden nur als Link im Image gespeichert. An der Kompression wird hier auch nichts verändert, da die vorhandene [i]Install.wim[/i] die Kompression vorgibt. Die Images im 2. Fall bleiben aber alle voneinander getrennt und eigenständig.

Das macht Sinn und ist nachvollziehbar.
Aber ich habe es bei 2 anderen Notebooks getestet und die Reg hat nicht gefunzt... sprich zerschossen und bei aller Liebe
da hilft tatsächlich nur eine saubere Neuinstallation (vorher bitte unbedingt Format C: machen) alles Andere kostet viel mehr Zeit !

[quote=nohype post_id=340231 time=1581127215 user_id=42402]
[quote]Koperen Sie davon sämtliche Dateien mit Ausnahme von "\sources\install.esd" [bezogen auf die o. a. ISO-Datei muss das "\sources\install.wim" heissen] auf die Partition "USB-Daten" - die Datei ist zwar [i]nicht hinderlich, aber nutzlos und kostet einige Gigabyte Platz[/i](?)[/quote]
Diese Aussage des Autors Axel Vahldiek ist falsch, da eben die Funktion des Scripts je nach vorhandenem bzw. nicht vorhandenem "install.wim" verschieden ist, s. ctwimage2b-64.bat.
[/quote]
Zur Veranschaulichung habe ich folgende Konfiguration getestet:
Systempartition C: auf SSD-Laufwerk, „USB-DATEN“-Partition auf USB-Laufwerk, über USB 3.0 angeschlossen, CPU: i5-4590S. W10=1903-64Bit. Auf C: liegen knapp 45GB (43,9GB) Daten (ohne pagefile.sys) gerechnet.
1. Test auf Basis von nicht vorhandener install.wim (in \sources\) auf der Partition „USB-DATEN“, also wie im c’t-Artikel beschrieben.
2. Test auf Basis von vorhandener install.wim (4,3GB in \sources\) auf der Partition „USB-DATEN“, die dort existiert, wenn die Installations-DVD vollständig kopiert wurde.
Ergebnis:
Die Imageerzeugung mit ctwimage2b-64.bat erzeugt im
1. Falle ein install.wim der Größe 22,7GB und dauert 35min
und im
2. Falle ein install.wim der Größe von nur 19,7GB(!) und dauert 30min.
Wohlgemerkt: entsprechend meiner Erklärung, s. o., sind die beiden Images nur dann gleichwertig, wenn die Installation auf C:\ intakt ist.
Die fehlenden Dateien wie trustedinstaller.exe und andere, "benachbarte", wie bei @boyherre, würden im nach 1. erzeugten image.wim zwar (inkrementell) ergänzt. Aber die Reparatur der Registry ist damit noch nicht erledigt, da die fehlenden Registry-Einträge im 1. Falle wahrscheinlich nicht repariert werden würden (woher sollen die kommen?). Im 2. Falle sind sie allerdings schon im "Basis"-install.wim vorhanden. Im 2. Falle ist deshalb die Wahrscheinlichkeit, dass die Registry des erzeugten install.wim insgesamt funktionieren würde, relativ hoch.

Hallo und vielen Dank für die Mühe!
Nun habe ich gerade gestern einmal mehr ein „Clean Install“ vorgenommen, das allerdings erst dann ohne Fehlermeldung („Platte/Partition nicht gefunden“) funktionierte, nachdem die zu verwendende Platte/Partition im BIOS [b]an die erste Stelle der Platten-Boot-Reihenfolge[/b] gestellt wurde – wo Windows sie sehen will - (Platte1, Partition 2, für Linuxer: sdb2). Verwendet wurde eine Installations-DVD, die mithilfe des „Media Creation Tools“ erstellt wurde (WIN10 1909 64-Bit Home).
Dann im Install-Dialog die alte Partition C: gelöscht und WIN10 angewiesen, in diesen nun „nicht zugeordneten“ Bereich (diese Ex-Partition C:) zu installieren. Das hat problemlos funktioniert! Die restlichen Partitionen der Platte blieben so erhalten, so dass für die nötige Rekonstruktion der Arbeitsumgebung die Quellen erhalten blieben. Immerhin.
Das ist ein gangbarer Kompromiss, mit dem ich leben kann, auch wenn's Arbeit bedeutet. Jedenfalls ist nichts verloren…
Das System läuft schon wieder in den Grundfunktionen…
LG, Boy

K:\sources>"C:\Program Files\7-Zip\7z.exe" l install.wim trustedinstaller.exe -r
7-Zip 19.00 (x64) : Copyright (c) 1999-2018 Igor Pavlov : 2019-02-21

Scanning the drive for archives:
1 file, 4295122745 bytes (4097 MiB)

Listing archive: install.wim

--
Path = install.wim
Type = wim
WARNING = Some files have incorrect reference count
Physical Size = 4295122745
Size = 9635308423
Packed Size = 4216589825
Method = LZX:15
Cluster Size = 32768
Created = 2019-04-02 00:08:14
Modified = 2019-04-02 00:47:51
Version = 1.13
Multivolume = -
Volume = 1
Volumes = 1
Images = 10

   Date      Time    Attr         Size   Compressed  Name
------------------- ----- ------------ ------------  ------------------------
2019-03-19 05:46:36 ....A       143360        59340  1\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:36 ....A       143360        59340  1\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:21 ....A       143360        59340  2\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:21 ....A       143360        59340  2\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:36 ....A       143360        59340  3\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:36 ....A       143360        59340  3\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:21 ....A       143360        59340  4\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:21 ....A       143360        59340  4\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:36 ....A       143360        59340  5\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:36 ....A       143360        59340  5\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:21 ....A       143360        59340  6\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:21 ....A       143360        59340  6\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:36 ....A       143360        59340  7\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:36 ....A       143360        59340  7\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:21 ....A       143360        59340  8\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:21 ....A       143360        59340  8\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:36 ....A       143360        59340  9\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:36 ....A       143360        59340  9\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:21 ....A       143360        59340  10\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:21 ....A       143360        59340  10\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
------------------- ----- ------------ ------------  ------------------------
2019-03-19 05:46:36            2867200      1186800  20 files

Warnings: 1

Der hier allseits verfolgte Ansatz versagt, wie gezeigt, weil sowohl das InplaceUpgrade als auch Backup-/Restores mit den bekannten Tools den defekten TrustedInstaller nicht reparieren können.
Deshalb greife ich mal den auch hier erwähnten älteren Thread im Win10 Forum auf, da mMn @boyherre eine echte Chance hat, sein System mithilfe von c-t-WIMage auf Vordermann zu bringen:
[url]https://www.win-10-forum.de/threads/externe-backup-image-usb-platte-wird-nicht-eingebunden-angezeigt-offline.128664/[/url]
Dort wurde der an sich lohnende Hinweis auf c't-WIMage nicht weiter aufgegriffen.
[quote]
@boyherre, ich verwende paragon backhup & recovery free. Bei Einrichtung wäre PE zu wählen. - null Probeme damit - auch, was die Sicherungsgeschwindigkeit angeht.

@ungarnjoker

Probiere es mal damit: [quote]https://www.heise.de/ct/artikel/c-t-WIMage-3863074.html[/quote]

... und machst Du das gegenwärtig regelmäßg damit, dass Du es empfiehlst? Da es ein Script ist, muss es schon sehr aktuell passen.

[/quote]
Um mit c-t-WIMage arbeiten zu können, ist es nicht notwendig, das Script im einzelnen zu verstehen. Allerdings muss man die dort zitierten Artikel der C't sorgfältig studiert und auch mit c'twimage schon ein wenig experimentiert haben.
Im ersten Artikel werden die störenden Probleme mit dem Defender nur am Rande erwähnt, s. dazu meinem Kommentar zu
"c’t-WIMage 2 Windows Backup für Windows 10".
[url]https://www.deskmodder.de/blog/2016/02/24/ct-wimage-2-windows-backup-fuer-windows-10/[/url]
Und auch wenn man dem c'tArtikel dem Buchstaben nach folgt, wird man gerade nicht das Problem von @boyherre lösen können, ein Image mit intaktem TrustedInstaller zu gewinnen, da der C't-Autor empfielt, die Datei "install.esd" des ISO-Images bzw. "install.wim" nach dem Kopieren nach USB-DATEN zu löschen!
Der Clou ist, das nicht zu tun, weil die kopierte Datei "install.wim gerade den hier kritischen TrustedInstaller.exe enthält.
Zum Verständnis: ctwinmage baut inkrementell auf das schon vorhandene "install.wim" auf. Wenn man es vorher gelöscht hat, wird nicht darauf inkrementell aufgebaut, sondern von null ein neues install.wim erstellt. So entstünde ein neues install.wim, das notwendigerweise defekt ist, da es die Fehler der Installation auf "C:" übernimmt!
Zur Info: das Original "install.wim" des ISOs enthält die folgenden Trustedinstaller.exe-Dateien.
[code]K:\sources>"C:\Program Files\7-Zip\7z.exe" l install.wim trustedinstaller.exe -r
7-Zip 19.00 (x64) : Copyright (c) 1999-2018 Igor Pavlov : 2019-02-21

Scanning the drive for archives:
1 file, 4295122745 bytes (4097 MiB)

Listing archive: install.wim

--
Path = install.wim
Type = wim
WARNING = Some files have incorrect reference count
Physical Size = 4295122745
Size = 9635308423
Packed Size = 4216589825
Method = LZX:15
Cluster Size = 32768
Created = 2019-04-02 00:08:14
Modified = 2019-04-02 00:47:51
Version = 1.13
Multivolume = -
Volume = 1
Volumes = 1
Images = 10

Date Time Attr Size Compressed Name
------------------- ----- ------------ ------------ ------------------------
2019-03-19 05:46:36 ....A 143360 59340 1\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:36 ....A 143360 59340 1\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:21 ....A 143360 59340 2\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:21 ....A 143360 59340 2\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:36 ....A 143360 59340 3\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:36 ....A 143360 59340 3\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:21 ....A 143360 59340 4\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:21 ....A 143360 59340 4\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:36 ....A 143360 59340 5\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:36 ....A 143360 59340 5\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:21 ....A 143360 59340 6\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:21 ....A 143360 59340 6\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:36 ....A 143360 59340 7\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:36 ....A 143360 59340 7\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:21 ....A 143360 59340 8\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:21 ....A 143360 59340 8\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:36 ....A 143360 59340 9\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:36 ....A 143360 59340 9\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
2019-03-19 05:46:21 ....A 143360 59340 10\Windows\servicing\TrustedInstaller.exe
2019-03-19 05:46:21 ....A 143360 59340 10\Windows\WinSxS\amd64_microsoft-windows-trustedinstaller_31bf3856ad364e35_10.0.18362.1_none_636aa37fca5f24db\TrustedInstaller.exe
------------------- ----- ------------ ------------ ------------------------
2019-03-19 05:46:36 2867200 1186800 20 files

Warnings: 1
[/code]
"K:" ist hier der Laufwerksbuchstabe das virtuell geöffneten ISO-Datei: Win10_1903_V1_German_x64.iso, deren Inhalt [b]komplett[/b] in die zu erstellende Partition "USB-DATEN" kopiert wird - entgegen der Anweisung, s. c't 2016 Heft 5, S. 130 :
[quote]Koperen Sie davon sämtliche Dateien mit Ausnahme von "\sources\install.esd" [bezogen auf die o. a. ISO-Datei muss das "\sources\install.wim" heissen] auf die Partition "USB-Daten" - die Datei ist zwar [i]nicht hinderlich, aber nutzlos und kostet einige Gigabyte Platz[/i](?)[/quote]
Diese Aussage des Autors Axel Vahldiek ist falsch, da eben die Funktion des Scripts je nach vorhandenem bzw. nicht vorhandenem "install.wim" verschieden ist, s. ctwimage2b-64.bat.

[quote=DK2000 post_id=339218 time=1579503737 user_id=39966]
Nur um sicher zu sein: auf dem Laptop ist auch die 18363.476 installiert und nicht die aktuelle Revision 18363.592?
[/quote]

Laut „winver“ ist seit vorgestern (Update) die Laptop-Version Build 18363.592, also die aktuelle Version.
Passt also nicht? Oje!
Fühlt sich an wie ein Labyrinth ohne Ausgang…
LG, Boy

Nur um sicher zu sein: auf dem Laptop ist auch die 18363.476 installiert und nicht die aktuelle Revision 18363.592?

[quote=DK2000 post_id=339213 time=1579501228 user_id=39966]
wenn das System identisch mit dem kaputten System ist, also selbe Architektur, Edition, Version, Revision und aller weiteren Updates. Und kopieren würde auch nur gehen, wenn Du selbst das mit den Rechten des TrustedInstallers gemacht hast und am Ende alle Rechte angepasst hast.

Müsste ich mal selber testen, ob das geht. Im Moment bezweifele ich das etwas.

Das SFC und DISM immer noch nicht laufen, deutet darauf hin, dass der TrustedInstaller nicht akzeptiert wird oder nicht laufen kann, weil alles nicht zusammen passt. Eventuell steht dazu etwas in der DISM.log.
[/quote]

Die Systeme sind identisch (eben für den Notfall), Rechte, ja da könnte was sein.
Die DISM.log schaue ich mir nachher an. Den Trusted Installer kann man auch singulär runterladen und verwenden…
DISM läuft in Teilen, nicht aber cleanup (!).
Bis später, LG, Boy

Die Frage ist, wie Du den Ordner rekonstruiert hast? Mir fällt da so nichts auf die Schnelle ein. Das Kopieren vom Laptop würde eventuell nur gehen, wenn das System identisch mit dem kaputten System ist, also selbe Architektur, Edition, Version, Revision und aller weiteren Updates. Und kopieren würde auch nur gehen, wenn Du selbst das mit den Rechten des TrustedInstallers gemacht hast und am Ende alle Rechte angepasst hast.

Müsste ich mal selber testen, ob das geht. Im Moment bezweifele ich das etwas.

Das SFC und DISM immer noch nicht laufen, deutet darauf hin, dass der TrustedInstaller nicht akzeptiert wird oder nicht laufen kann, weil alles nicht zusammen passt. Eventuell steht dazu etwas in der DISM.log.

[quote=Purgatory post_id=339207 time=1579468376 user_id=40740]
[…] Wie DK schon sagte, nicht rumfrickeln, einfach neu machen.
Und von der alten Platte retten was noch zu retten ist...
[/quote]
Ja, danke, alles richtig. Derzeit kann ich mich (noch) nicht von meinem ansonsten funktionierenden WIN10 und der Arbeitsumgebung trennen; ich muss leider noch ein wenig zu meiner Rente dazuverdienen…
Es kristallisiert sich wohl heraus, dass es hauptsächlich um den Ordner „servicing“ mit dem „Trusted Installer“ geht, der komplett „verschwunden“ war. Den konnte ich samt Inhalt mitsamt „Trusted Installer“ rekonstruieren, mithilfe einer parallelen, gleichartigen WIN10-Installation auf einem Not-Laptop (über LAN). Auch der dazuhörende Registry-Eintrag, der korrekt aussieht, in HKEY_LOCAL_MACHINE\System\Current Control Set_ Services\Trusted Installer ist vorhanden …
Auch der Dienst „Windows Module Installer“ bzw. „Trusted Installer“ ist aktiviert (automatisch) in services.msc bzw. msconfig. Also woran könnte es noch liegen, wenn sfc /scannow bzw. DISM cleanup-Befehle weiterhin nicht funktionieren?
Updates funktionieren nicht.
Andere DISM-Befehle funktionieren indes…
Aber das Reparatur-Inplace-Upgrade bricht reproduzierbar immer bei 79% ab, mit Fehlermeldung.
Ich kann mir da keinen Reim machen…
Danke für Deinen Beitrag…
LG, Boy

Zitat:
Hardware:
Eine defekte Platte wurde ausgetauscht gegen eine heile exakt gleichen Typs.
Zum Erhalt der Arbeitsfähigkeit wurde der geklonte Inhalt der defekten Platte (einige defekte Sektoren laut „Clonezilla“) auf die heile Platte gespiegelt. Ergebnis: Ein „normal“ reagierendes WIN10 1909 64-Bit Home, Build 18362.19h1_release 190318-1202 – bis auf die korrumpierten System-Anwendungen „sfc /scannow“ und „DISM“.
Zitat Ende.

Es hätte auch eine nicht baugleiche Platte sein können und dasselbe wäre herausgekommen. (Außer Raid natürlich^^)
Die alte Platte hatte fehlerhafte Sektoren und die wurden 1:1 auf die neue rüberkopiert. Nicht dass die neue Platte jetzt defekt wäre, neinnein, aber sie kann nichts dafür wenn fehlende Daten nicht reinkopiert werden.
Fakt ist die alte Platte war altersschwach, hat Fehler gemacht, was Checkdisk so nicht mehr lösen konnte. Ergo wurde ein Umzug gemacht. Leider zu spät. Wie DK schon sagte, nicht rumfrickeln, einfach neu machen.
Und von der alten Platte retten was noch zu retten ist...

[quote]Kann das durch „chkdsk /f /r“ verursacht worden sein?[/quote]

Abgesehen davon, dass ich selbst mit diesem Syntax chkdsk so nicht anwende,
ist mir selbst bei 1 bis 2 Anwendungen von chkdsk bei HDDs und SSHDs im halben Jahr nichts Erwähnenswertes aufgefallen.
Hatte insbes. bei den ersten Win 10 -Versionen den Eindruck, dass es dem System gut tat,
Fehlermeldungen nicht aufgefallen, wobei bei "C" kein Protokoll gecheckt wurde bei Routine – Ausführung.
Soweit ich das überhaupt mitbekommen hatte und ich mich erinnere, gab es da mal vor längerer Zeit mit KB4032188 diverse Korrekturen.

Wohl aber liest man im Web von „Unfällen“, wobei verschiedenartige Ursachen dahingestellt sein mögen.

Im Falle Verdacht, dass im zeitlichen Zusammenhang mit chkdsk (egal was eigentlich ursächlich) etwas im Argen ist, soll es ja spezielle Ordner geben, wo Gelöschtes gespeichert ist oder sein kann, ebenso Berichtsdateien i.Z.m. chkdsk. Wenn Du dem nachgehen möchtest, vlt. in dieser Richtung im Web recherchieren (man wird schnell fündig), inkl. zur etwaigen Wiederherstellung. Für Letzteres wird sicherlich die größte Chance bei ohne jeglichem Zeitverzug sein und für die Brauchbarkeit käme es wieder drauf an.
„Wer nicht wagt, der nicht gewinnt.“

[quote=DK2000 post_id=339158 time=1579382388 user_id=39966]
Dann existiert ja das ganze Servicing nicht. Das ist sehr schlecht. Den TrustedInstaller und die dazugehörigen Dateien könnte man ja noch aus der ISO bekommen, aber die Datenbank und die ganzen Pakete der installierten Windows Komponenten, das wird schwierig.
Aber so ist das System im Moment komplett unbrauchbar, was Updates/Upgrades angeht.

Gerade mal in der VM getestet. Habe mal den Ordner komplett entfernt (gar nicht so einfach) und das Upgrade endet mit:

[code]2020-01-18 22:42:14, Error CONX 0x8007051a GetDeviceMap failed
2020-01-18 22:42:14, Error CONX 0x8007051a CDevInventory::CreateDevInventoryToCache failed[/code]
Also selber Fehler wie bei Dir. 0x8007051a beim ermitteln der installierten Treiber.

Ich würde das System aufgeben und eine Neuinstallation vornehmen. Das ist mir da irgendwie zu kaputt. Ob die Flickerei da noch etwas bring, steht in den Sternen.
[/quote]

OK, danke für Deine Mühe! Da ist also die Ursache… Würde gern wissen, wodurch das zustande gekommen ist?!
Kann das durch „chkdsk /f /r“ verursacht worden sein?
Was anderes ist ja nicht passiert…
Ich hatte aufs Reparatur-Inplace-Upgrade gehofft…
Erst mal ein großes Dankeschön fürs Engagement!
LG, Boy

2020-01-18 22:42:14, Error                 CONX   0x8007051a GetDeviceMap failed
2020-01-18 22:42:14, Error                 CONX   0x8007051a CDevInventory::CreateDevInventoryToCache failed

Dann existiert ja das ganze Servicing nicht. Das ist sehr schlecht. Den TrustedInstaller und die dazugehörigen Dateien könnte man ja noch aus der ISO bekommen, aber die Datenbank und die ganzen Pakete der installierten Windows Komponenten, das wird schwierig.

Könnte eventuell noch funktionieren, wenn man diese Anleitung auf die normale 1903/1909 anpasst:

https://www.deskmodder.de/blog/2019/10/12/slow-ring-ohne-upgrade-zur-windows-10-18362-18363-wechseln/

Aber das weiß ich nicht, ob das so ohne weiteres geht. Müsste ich mal testen.

Aber so ist das System im Moment komplett unbrauchbar, was Updates/Upgrades angeht.

[hr][/hr]

Gerade mal in der VM getestet. Habe mal den Ordner komplett entfernt (gar nicht so einfach) und das Upgrade endet mit:

[code]2020-01-18 22:42:14, Error CONX 0x8007051a GetDeviceMap failed
2020-01-18 22:42:14, Error CONX 0x8007051a CDevInventory::CreateDevInventoryToCache failed[/code]
Also selber Fehler wie bei Dir. 0x8007051a beim ermitteln der installierten Treiber.

Ich würde das System aufgeben und eine Neuinstallation vornehmen. Das ist mir da irgendwie zu kaputt. Ob die Flickerei da noch etwas bring, steht in den Sternen.

[quote=DK2000 post_id=339156 time=1579380851 user_id=39966]
Sieht so aus, als ob es daran liegt:
DISM hat da Probleme, den Servicig Stack aufrufufen. Ohne diesen können die installierten Treiberpakete nicht ermittelt werden. Da ich so einen Fehler noch nicht gesehen habe, vermute ich da gerade mal, das liegt am fehlenden TrustedInstaller. Müsste ich aber mal testen.

Gehe mal in den Ordenr: [i]C:\Windows\servicing[/i]
Wie sieht es da aus? Gibt es da die [i]TrustedInstaller.exe[/i]?
[/quote]

Uih! Dieser Ordner existiert nicht?!

LG, Boy