Jetzt ist ja die nächste Insider draußen. Die 18727. Mal testen, ob es mit der geht.
Und ob in der Fehler 'gnadenlos' Verfolgen wird, glaube ich da weniger. Der wird sich genauso verflüchtigen wie der Installationsfehler des NetFX3 bis zur 18262. Kann auch sein, wenn er ohne Netzwerk von der ISO aus installiert (= keine Telemetrie), das Upgrade durchläuft. Das Selbe Problem hat man ja derzeit auch mit der 17763.1, dessen Setup über den Austausch der Telemtrie-Daten gesperrt wurde. Die lässt sich derzeit über die ISO nur noch dann installieren, wenn man das Netzwerk trennt.
---
Der Code 0x4000c (OOBE_BOOT/APPLY_IMAGE) kann da an der Stelle schon stimmen, wenn man über das Windows Update geht. Microsoft hat da fast alle Phasen und dessen untergeordnete Vorgänge neu angeordnet. Vieles, was vorher während der Phasen SAFE_OS, FIRST_BOOT und OOBE_BOOT (SECOND_BOOT) ausgeführt wurde, ist jetzt in der Phase DOWNLEVEL enthalten, also die Phase vor dem aller ersten Neustart. Dadurch reduziert sich die Zeit zwischen Neustart und Fertigstellung des Upgrades signifikant. Das führt allerdings dazu, das die eigentlichen Phasen 0 - 5 nicht mehr zwangsläufig in der Reihenfolge abgearbeitet werden. Im Grunde genommen befindet sich vor dem ersten Neustart das fast schon komplett fertige neue Windows im Ordner NewOS.
Und der Fehlercode 0xc1900209 - 0x4000c hat nichts mit dem Windows Update zu tun. Das ist ein reiner Fehlercode der 'Modern Setup Platform', welche im Ordner C:\$WINDOWS.~BT ausgeführt wird. Die selben Fehlercodes erhält man auch, wenn man das Upgrade von der ISO aus startet. Das Windows Update fungiert hier nur noch als passiver Auftraggeber und da das Setup mit dem Parameter
/ReportId <CLSID> gestartet wurde, wird über die Windows Update GUI nur noch der Fortschritt und ggf. Fehlermeldungen des Setups angezeigt. Selbst die Anzeige des Downloads ist nur eine Weiterleitung des Setups, da dieses für den Download aller weiteren Komponenten verantwortlich ist. Das Windows Update führt ab hier nur noch Aufträge des Setups aus. Ansonsten läuft das Setup komplett im Quiet Modus im C:\$WINDOWS.~BT Ordner.
Es ist im Übrigen das selbe Setup, welches auch auf der ISO enthalten ist. Da hier dann aber die Phasen 'Vorbereiten des Downloads' und 'Download' wegfallen, unterscheidet sich der Ablauf in der ganz frühen Phase. Ab einem gewissen Zeitpunkt laufen beide Upgrades aber identisch ab.
---
Zu a: Das ist immer eine gute Idee mit der ISO, da das ggf. den erneuten Download der Pakete erspart und man hier dann auch komplett offline (=kein Netzwerk) installieren kann. Allerdings in der Insider Phase sollte man auch das Windows Update verwenden, um halt auch solhe Probleme wie hier zu bekommen und diese dann ggf. im Feedback-Hub zu hinterlegen.
Zu b: Kann man machen, wenn es Probleme mit dem Windows Update an sich gibt. Aber das ist hier nicht der Fall. Lt. seinen Logs wurden alle für das Upgrade benötigte Dateien einschließlich Treiber für den Drucker einwandfrei heruntergeladen und stehen bereit. Hier gab es keine Fehler.
Zu c: Der Komponentenspeicher des gerade installierten Windows ist derzeit für das Upgrade vollkommen uninteressant, da dieser währen der Upgrades komplett ersetzt wird. Daher lassen sich auch unreparierbare Fehler im Komponentenspeicher durch ein Inplace Upgrade beheben, da man am Ende des Upgrades eine neuen Komponentenspeicher hat.
zu d: Was immer das auch ist, das dürfte im Moment auch noch keine Rolle spielen. Es erscheint zwar im Invertar, wurde aber mit keinem Block versehen und steht somit erst einmal für die Migration bereit.
zu e: Ja, das kann man machen, hat aber meist keine Auswirkung auf ein Upgrade, da solange die deaktivierten Dienste als Dateien vorgefunden werden, das Upgrade dennoch bei inkompatiblen Sachen abgebrochen wird. Daher scheitert das Upgrade ja auch schon mal, wenn es z.B. auf D: ein Setup eines nicht installierten Virenscanners finden, welches inkompatibel ist. Sehr nervig dieses Verhalten. Dienste deaktivieren bringt daher nur bedingt etwas, meistens muss man identifizierte Inkompatibilitäten komplett entfernen.
zu f: Das ist eine sehr gute Idee, da seine Inkompatibilität eindeutig von einem Gerät aus geht. Leider konnte ich bislang nicht ermitteln, um welches Gerät es sich handelt. Aber es ist eindeutig ein Gerät:
Code: Alles auswählen
MOUPG CDlpResponseInstallReq::GenerateCompatReport: Device HardBlock found.
Das führt dann automatisch zu dem Fenster aus dem Screenshot vom Anfang des Threads. Wenn man das Fenster dann schließt, führt das zu
Und das wiederum ist an der Stelle der Grund für den Code 0xc1900209:
Code: Alles auswählen
MOSETUP_E_COMPAT_INSTALLREQ_CANCEL
The user has chosen to cancel because the system does not pass the compat scan to install the update.
Daher sagte ich ja auch, dass der Code im Grunde genommen nichts aussagt, außer das Offensichtliche: Der Benutzer hat das Upgrade selber an der Stelle abgebrochen.
Bis hier hin ist soweit das Log verständlich. Nur das Problem ist, das ich gerade nicht so genau weiß, wo das blockierte Gerät aufgelistet ist. Die dazugehörige Datei ist auch nicht wirklich 'HumanReadable', jedenfalls nicht unbedingt einfach. Aber das muss da drin stehen.
Jetzt ist ja die nächste Insider draußen. Die 18727. Mal testen, ob es mit der geht.
Und ob in der Fehler 'gnadenlos' Verfolgen wird, glaube ich da weniger. Der wird sich genauso verflüchtigen wie der Installationsfehler des NetFX3 bis zur 18262. Kann auch sein, wenn er ohne Netzwerk von der ISO aus installiert (= keine Telemetrie), das Upgrade durchläuft. Das Selbe Problem hat man ja derzeit auch mit der 17763.1, dessen Setup über den Austausch der Telemtrie-Daten gesperrt wurde. Die lässt sich derzeit über die ISO nur noch dann installieren, wenn man das Netzwerk trennt.
---
Der Code 0x4000c (OOBE_BOOT/APPLY_IMAGE) kann da an der Stelle schon stimmen, wenn man über das Windows Update geht. Microsoft hat da fast alle Phasen und dessen untergeordnete Vorgänge neu angeordnet. Vieles, was vorher während der Phasen SAFE_OS, FIRST_BOOT und OOBE_BOOT (SECOND_BOOT) ausgeführt wurde, ist jetzt in der Phase DOWNLEVEL enthalten, also die Phase vor dem aller ersten Neustart. Dadurch reduziert sich die Zeit zwischen Neustart und Fertigstellung des Upgrades signifikant. Das führt allerdings dazu, das die eigentlichen Phasen 0 - 5 nicht mehr zwangsläufig in der Reihenfolge abgearbeitet werden. Im Grunde genommen befindet sich vor dem ersten Neustart das fast schon komplett fertige neue Windows im Ordner NewOS.
Und der Fehlercode 0xc1900209 - 0x4000c hat nichts mit dem Windows Update zu tun. Das ist ein reiner Fehlercode der 'Modern Setup Platform', welche im Ordner C:\$WINDOWS.~BT ausgeführt wird. Die selben Fehlercodes erhält man auch, wenn man das Upgrade von der ISO aus startet. Das Windows Update fungiert hier nur noch als passiver Auftraggeber und da das Setup mit dem Parameter [i]/ReportId <CLSID>[/i] gestartet wurde, wird über die Windows Update GUI nur noch der Fortschritt und ggf. Fehlermeldungen des Setups angezeigt. Selbst die Anzeige des Downloads ist nur eine Weiterleitung des Setups, da dieses für den Download aller weiteren Komponenten verantwortlich ist. Das Windows Update führt ab hier nur noch Aufträge des Setups aus. Ansonsten läuft das Setup komplett im Quiet Modus im C:\$WINDOWS.~BT Ordner.
Es ist im Übrigen das selbe Setup, welches auch auf der ISO enthalten ist. Da hier dann aber die Phasen 'Vorbereiten des Downloads' und 'Download' wegfallen, unterscheidet sich der Ablauf in der ganz frühen Phase. Ab einem gewissen Zeitpunkt laufen beide Upgrades aber identisch ab.
---
Zu a: Das ist immer eine gute Idee mit der ISO, da das ggf. den erneuten Download der Pakete erspart und man hier dann auch komplett offline (=kein Netzwerk) installieren kann. Allerdings in der Insider Phase sollte man auch das Windows Update verwenden, um halt auch solhe Probleme wie hier zu bekommen und diese dann ggf. im Feedback-Hub zu hinterlegen.
Zu b: Kann man machen, wenn es Probleme mit dem Windows Update an sich gibt. Aber das ist hier nicht der Fall. Lt. seinen Logs wurden alle für das Upgrade benötigte Dateien einschließlich Treiber für den Drucker einwandfrei heruntergeladen und stehen bereit. Hier gab es keine Fehler.
Zu c: Der Komponentenspeicher des gerade installierten Windows ist derzeit für das Upgrade vollkommen uninteressant, da dieser währen der Upgrades komplett ersetzt wird. Daher lassen sich auch unreparierbare Fehler im Komponentenspeicher durch ein Inplace Upgrade beheben, da man am Ende des Upgrades eine neuen Komponentenspeicher hat.
zu d: Was immer das auch ist, das dürfte im Moment auch noch keine Rolle spielen. Es erscheint zwar im Invertar, wurde aber mit keinem Block versehen und steht somit erst einmal für die Migration bereit.
zu e: Ja, das kann man machen, hat aber meist keine Auswirkung auf ein Upgrade, da solange die deaktivierten Dienste als Dateien vorgefunden werden, das Upgrade dennoch bei inkompatiblen Sachen abgebrochen wird. Daher scheitert das Upgrade ja auch schon mal, wenn es z.B. auf D: ein Setup eines nicht installierten Virenscanners finden, welches inkompatibel ist. Sehr nervig dieses Verhalten. Dienste deaktivieren bringt daher nur bedingt etwas, meistens muss man identifizierte Inkompatibilitäten komplett entfernen.
zu f: Das ist eine sehr gute Idee, da seine Inkompatibilität eindeutig von einem Gerät aus geht. Leider konnte ich bislang nicht ermitteln, um welches Gerät es sich handelt. Aber es ist eindeutig ein Gerät:
[code]MOUPG CDlpResponseInstallReq::GenerateCompatReport: Device HardBlock found.[/code]
Das führt dann automatisch zu dem Fenster aus dem Screenshot vom Anfang des Threads. Wenn man das Fenster dann schließt, führt das zu
[code]MOUPG User cancel confirmed[/code]
Und das wiederum ist an der Stelle der Grund für den Code 0xc1900209:
[code]MOSETUP_E_COMPAT_INSTALLREQ_CANCEL
The user has chosen to cancel because the system does not pass the compat scan to install the update.[/code]
Daher sagte ich ja auch, dass der Code im Grunde genommen nichts aussagt, außer das Offensichtliche: Der Benutzer hat das Upgrade selber an der Stelle abgebrochen.
Bis hier hin ist soweit das Log verständlich. Nur das Problem ist, das ich gerade nicht so genau weiß, wo das blockierte Gerät aufgelistet ist. Die dazugehörige Datei ist auch nicht wirklich 'HumanReadable', jedenfalls nicht unbedingt einfach. Aber das muss da drin stehen.
