SYSPREP_SPECIALIZE bei Update auf 24H2

[Dieter Wilke]

Ich hatte unter Windows 11 23H2 22631.3880 einige Probleme beim Start des Rechners (z.B. sehr lange Bootzeiten). Zuerst habe ich überprüft, ob Windows selbst der Verursacher ist und eine Inplace Reparatur gestartet, die dann mit der Fehlermeldung KERNEL_SECURITY_CHECK_FAILURE und dem Code 0xC1900101 - 0x30018 abgebrochen wurde.
Ich habe dann alle Maßnahmen durchgeführt, die für diesen Fall vorgeschlagen werden (Sitz aller Komponenten überprüft, Treiber aktualisiert, alle nicht benötigten Geräte abgezogen, SFC und DISM, Virenscanner deinstalliert etc.). Danach lief die Reparaturinstallation einwandfrei durch.
So weit so gut.
Dann kam ich auf die Idee, doch gleich mal auf 24H2 (mit der 22610.1150) per Inplace Update zu gehen.
Irritierender Weise kam ich damit nur bis zu 48% Installation und einem BSOD mit dem Hinweis: SYSPREP_SPECIALIZE und dem gleichen Code wie oben.
Hier komme ich jetzt nicht weiter. Wo liegt jetzt der Unterschied zwischen den beiden Versionen, der zu diesem Problem führt?

[Tante Google]

[Dieter Wilke]

Mein System:
AMD Ryzen 9 7950X, RAM 64GB, AMD Radeon RX 7900 XTX, BenQ PD3200U
kein OC oder ähnliches

[Purgatory]

Der Fehler wird oft ausgelöst wenn inkompatible Treiber im System vorhanden sind. Also ältere Treiber die nicht speziell für Windows 11 gemacht sind. Und wir alle wissen, einen alten Drucker z.B., kann man unter 11 auch noch mit einem 7 Treiber zum Leben erwecken. Oft funktioniert das, aber leider nicht immer.
Hier würde ein "Clean Boot" helfen um einen Treiberkonflikt zu finden, was lange Bootzeiten erklären könnte.

Meine zweite Idee ist der Ram. Ein bereits installiertes Windows kann Ramfehler puffern, bzw. ignorieren ohne gleich abzustürzen. Eine Neuinstallation tut das aber nicht, sie könnte das, bricht aber bei Ramfehlern gleich ab. Jetzt ist die Frage wenn ich 64GB Ram lese, welches Mainboard ist verbaut und viel wichtiger, wieviele Sticks? Sind vier Sticks verbaut kannst Du oft, oder sehr wahrscheinlich, das XMP Profil nicht fahren, die Mainboards kommen damit einfach nicht klar weil sie in "Daisy Chain" verlötet werden. Die Lösung wäre hier entweder die Timings zu entschärfen oder den Takt, oder beides.
Fängt der Ram nämlich an Fehler zu machen (was man im Normalbetrieb nicht unbedingt bemerken muss) entstehen solche Probleme.

[Dieter Wilke]

Die langen Bootzeiten sind durch das Entfernen des "Übeltäters" (USB-Erweiterungskarte) eliminiert. Erst danach hat ja dann auch die Inplace Reparatur von 23H2 funktioniert.
Mich interessiert jetzt, warum bei der 23H2 die Reparatur funktioniert und bei der 24H2 das Update dann nicht. Es hat dazwischen keine anderen Aktivitäten (außer Neustart) gegeben.
Übrigens versteckt sich in dem etc. oben in der Maßnahmenaufführung auch der Speichertest.

[g-force]

Da ich ähnliche Probleme habe: Bezieht sich "lange Bootzeit" auf den Start des Rechners, BEVOR das OS überhaupt geladen wird, oder ist es das tatsächliche STARTEN des OS, was lange dauert?

[Dieter Wilke]

Es bezog sich auf das Starten des OS. Nach der funktionierenden Inplace Reparatur (durch Entfernung der Erweiterungskarte) "flutscht" es nur so durch. Sowohl das BIOS als auch das OS sind jetzt schnell.

[helmar]

Ich habe auch das Problem mit dem Fehler 0xC1900101 0x30018 beim Inplace Upgrade auf 24H2 auf einem Notebook mit älterer Hardware. Die CPU erfüllt aber SSE4.2.
Bin momentan auch ratlos und habe die selben Tests/Prüfungen gemacht wie oben genannt, ohne Erfolg

[Gast]

Das Inplace Upgrade ist immer mit dem genannten Fehlercode gescheitert. Habe da alles probiert und war mit meinem Latein am Ende.
Dank der Zero Limit ISOs konnte ich nun "problemlos", mit Hilfe einer Neuinstallation, auf 10.0.26100.1301 "updaten".

Ich vermute mal das inplace ist wegen inkompatibler Treiber gescheitert
Im Rahmen der Neuinstallation wurde viele Treiber neu installiert (alle via "optionale Updates").

Nur sehr schade, dass man in den Logfiles, die während des Inplace gemacht werden, nur sehr schwer (oder wie bei mir gar nicht) sieht woran es letztendlich tatsächlich scheitert

Vielen Dank an alle die an den Zero Limits beteiligt sind