Suche iso o. install.wim von Win10 x64 2004 Build 19041.n n=so neu wie möglich, Home oder Multisession

[klamigo]

Hallo zusammen,
für die Inplace-Reparatur via PE und dism suche ich eine möglichst spät erstellte iso oder install.wim oder install.esd von
Win10 x64 2004, Build 19041.n, wobei n heißt: so neu wie möglich, aber die Baisversion darf nicht 19042 oder neuer sein.

Hintergrund:
Habe hier von einer Kundin, die definitiv keine Rumbastlerin ist, sondern normale Anwenderin, einen nicht mehr startbaren PC mit Windows 10 Home in der Version 19041.6216 (nicht 19045, sondern wirklich 19041!).
ntoskrnl.exe, explorer.exe usw. usw. haben alle genau diese Buildnummer 19041.6216 vom 13.08.2025 in den Details stehen, auch in der Registry steht diese Buildnummer.
Seit dem letzten automatisch erfolgten Windows-Update beim Start immer BSOD mit IO1_INITIALIZATION_FAILED. Hexcodes oben links alle 0x00000000. Letzte Updates lassen sich in der Wiederherstellungsumgebung nicht rückgängig machen.
Auch mit dem letzten Wiederherstellungspunkt vom 2. September 2025 ist (natürlich) nichts anzufangen.

Netzteil, Board, RAM und auch die SSD sind alle in Ordnung, Linux und andere Installation auf anderer SSD laufen fehlerfrei.
AsRock-Board ohne UEFI , unverändert mit SATA im AHCI-Mode, Festplatten-MBR und -PBR in Ordnung, chkdsk liefert 0 Fehler in Boot- und Windows-Partition. BCD perfekt (mit bcdedit und BootICE professional mode überprüft).
Auch SafeBoot mit Eingabeaufforderung nicht möglich. Ein bootlog kommt gar nicht erst zustande.
Sobald der Booting-Punkte-Kringel starten will, bleibt er schon beim ersten Pünktchen unten links stehen, danach direkt der BSOD. Auch bcd-Einträge mit nointegritychecks, disableelamdrivers usw. bringen nichts.

Ein aus dem WinPE gestarteter SystemFileCheck (sfc mit offbootdir und offwindir) konnte zwar einige beschädigte Dateien ersetzen, dennoch ist auch ein Offline-DISM notwendig. Dazu müsste ich mir aber eine iso erstellen, die bis Version 19041.6216 per slipstreaming bzw. per virtuelle Maschone upgedatet wird. Habe nur die 19041.1-iso (Super-Multi-XXL von Birkuli) mit Dateiversionen vom 07.12.2019, das heißt, es müssten dutzende KBs integriert werden.
Zudem bietet der Update-Catalog ja Updates bis zur neuesten Subversion 6216 gar nicht für 19041 (= Basisversion 2004/20H1) an.

Auf dem PC ist spezielle Maschinen-Software installiert, die nicht mehr zu beschaffen ist und die Festplatte mit den Updates ist defekt (Datenrettungschancen laut Kroll zu klein). Also worst-case Szenario ...

Ich hoffe, jemand von euch kann helfen ...

LG
Klaus

[Tante Google]

[DK2000]

Was das Update angeht, die 19041 ist schon lange aus dem Support raus.

Die 19045 ist die 19041. Deswegen erscheinen da fast überall in den Versionsinformationen die 19041 in den Dateien. Die 19045 ist nur ein Anzeigename, welches durch das Enablement Package gesetzt wird. Die Basis bleibt aber 19041. Ein Inplace Upgrade mit einer aktuelle ISO sollte also auch passen. Aber nützt Dir alles nichts, da Windows nicht mehr startet.

Rev. 6216 wäre im Übrigen das August Update für die 19044 und 19045. Theoretisch sollte es auch mit der19041, aber nie getestet. Aber wenn das Update automatisch kam, müsste die 19044 oder 19045 installiert sein. Alles davor ist eigentlich raus.

Problem dürfte da eher der BSOD (IO1_INITIALIZATION_FAILED) sein. Der besagt eigentlich nur, dass das I/O Subsystem nicht gestartet werden kann. Dadurch gibt es natürlich keinen Zugriff auf irgendwas. Der Fehler hat auch keine weiteren Parameter, so das es wirklich schwer zu sagen, woran das liegen könnte. Wenn das so einfach plötzlich kam, kann auch eine Komponente auf dem Board defekt sein. Ein Problem mit dem letzten Update auf die Rev. 6216 oder 6332 in diesem Zusammenhang ist mir jetzt nicht bekannt. Ausschließen kann ich es aber auch nicht.

Schwierig jetzt.

[klamigo]

Danke für die Antwort. Wie gesagt läuft die Hardware fehlerfrei, wenn man eine andere SSD einbaut und darauf ein aktuelles Windows 10.0.19045.6332 installiert. Auch unter Linux keinerlei Probleme, daher glaube ich eher nicht an ein Hardwareproblem, sondern dass für das I/O-Subsystem wichtige Dateien aus dem letzten Update auf dem kaputten System fehlerhaft kopiert oder fehlerhaft registriert wurden.
(NB: Tatsächlich zeigen auch auf meinem eigenen aktuellen System ntoskrnl.exe und andere Systemdateien die Versionsnummer 19041.6332)
Das sfc schon einige beschädigte Systemdateien gefunden hat und auch "reparieren" konnte, habe ich noch die Hoffnung, mit einer möglichst passenden Version das beschädigte Kundensystem per WinPE und
dism /image:E:\ /cleanup-image /restorehealth /source:WIM:F:\sources\install.wim:1 /limitaccess
auch weitere Fehler beheben zu können.
Ein Vergleich der gestarteten Services im eingehängten system-Zweig der Registry des Systems mit einer älteren Reg-Sicherung der system des damals laufenden Systems zeigte, dass alle wichtigen services exakt identisch eingestellt sind (auch kein blockierender StartOverride = 3 bei allen I/O-relevanten .sys).
Das System wurde auch nie mit irgendwelchen "Cleaning"-Tools oder Drittanbieter-Antiviren/-Firewallsoftware verbastelt.

[g-force]

Du schreibst "seit dem letzten automatischen Windows-Update", gehst aber von einer sehr veralteten Windows-Version aus. Das passt eigentlich nicht ganz zusammen.

[klamigo]

Du schreibst "seit dem letzten automatischen Windows-Update", gehst aber von einer sehr veralteten Windows-Version aus. Das passt eigentlich nicht ganz zusammen.

Ja, das ist mir natürlich klar, dass das nicht zusammenpasst: winver zeigt an
Windows 10 Version 2004 (Build 19041.6216)
und nicht 22H2 (Build 19045.6216 oder neuer), wie man es eigentlich erwarten würde!
Ich habe keine Idee, wie es zu diesem Status kommen konnte, das war einfach eine saubere 08/15-Standard-Windows-Neuinstallation per MediaCreationTool auf USB-Stick im Jahre 2019 ohne irgendwelchen Schnickschnack.
Also auch keine Altlasten aus älteren Betriebssystemen.
Durch die Kundin gab es auch keinerlei Wiederherstellungs- oder Rücksetzungsprozeduren, bei solchen Problem ruft sie immer(!) direkt mich an.
Es wurden auch definitiv zu keinem Zeitpunkt Registry-Einträge bzgl. TargetReleaseVersion und TargetReleaseVersionInfo vorgenommen, die das System gezwungen hätten, auf der 2004 "hängenzu bleiben". Dennoch sind alle wichtigen .exe wie ntoskrnl.exe, exlorer.exe usw. usw. auf den Stand vom 13.08.2025 (entsprechend Build 6216) durch das letzte Update erneuert worden. Aber seit ebendiesem Update der BSOD mit IO1-Fehler.