Also das Dynamic SafeOS KB5074108 vom 13.01. enthält das "Package_for_SafeOSDU~31bf3856ad364e35~amd64~~26100.
7618.1.3" und das ist bei mir in WinRE schon drin.
Ich kann aber gerne noch einmal das SafeOS KB5072537 vom 09.12. aufspielen und das dortige Build prüfen. /
edit: Builddowngrade geht nicht, kann nur die Cab auslesen!
ps: Build .7447 ist das SafeOS vom 09.12., hab es gerade geprüft. Es wird auch nur SafeOSDU geupdatet, ServicingStack bleibt auf Build .7295 vom 09.12., alle anderen Packages auf Stand 01.04.24.
..neue Belegung WinRE ist (bei mir) nun 681.76MB, vorsorgehalber schon auf 5GB erweitert (ansonsten würde WinCry irgendwann einmal aus Platzmangel eine zweite WinRE Partition irgendwo auf den Storage erstellen was bedeuten würde, Chaos wäre vorprogrammiert).
pps zur Info, vieleicht auch für den TE: Wenn es die WinRE (aus welchen Gründen auch immer) wo zerlegt hat, ein Inplace-Setup repariert das wieder und stellt alle diesbezgl. Pfade so her wie es sein soll.
Hat man vor den Inplace die WinRE Partition erweitert (z.b. wie bei mir auf 5GB) und entsprechende Part-ID plus GPT Attribut erstellt,wird das so auch 1:1 vom Inplace übernommen.
Ich kenne das Problem des TE, denn auch ich habe mich mal mit den Mounten und falscher Attributvergabe verhauen, danach wollte die WinRE nicht mehr von da laufen wo sie sollte (Part4).
Denn es bringt wenig, wenn die WinRE auf der Partition liegt die ja eigentlich wiederhergestellt werden soll (C/Part3) und warum ist das so: WinRE ist ein eigenständiges Windows PE System.
Würde das nun auf der gleichen Partition wie Windows liegen (üblicherweise Partition3) und das OS/Partition nun Dateisystem- bzw. Dateistrukturfehler aufweisen, dann könnte auch Windows PE nicht mehr geladen werden. Außerdem würde sich ja Windows PE im Falle einer Wiederherstellung selbst überschreiben, was bekanntlich schwer möglich sein dürfte, da es zu diesen Zeitpunkt ja aktiv ausgeführt wird.
Dürfte dann einen 0x8007042B Phase Safe_OS Migrate_Data BS verursachen.