For winvos you need to capture the registry key HKEY_LOCAL_MACHINE\syshive\ControlSet001\Control\ProductOptions "ProductPolicy", Microsoft puts it last I think.
I don't know how to compare. Then I replaced SOFTWARE and SYSTEM and it works too. Thanks. I tried it to no avail. Thanks.
When I can sign cat automatic, I do not need wcp.dll patch! I hope this way can use for future! Spoiler: Work with enterpriseG arm64 Code: Deployment Image Servicing and Management tool Version: 10.0.26100.1 Mounting image [==========================100.0%==========================] The operation completed successfully. --------------------------------------------------------------------------- [+] Add cumulative updates... [OK] Certificate injected into image: Z:\UpdateOS_v5\Data\MOUNT\1 - Installing SSU: SSU-28000.1575-arm64.esd Deployment Image Servicing and Management tool Version: 10.0.26100.1 Image Version: 10.0.28000.1 Processing 1 of 1 - Adding package Package_for_ServicingStack_1575~31bf3856ad364e35~arm64~~28000.1575.1.3 [==========================100.0%==========================] The changes due to package Package_for_ServicingStack_1575 requires the current servicing session to be reloaded. All the packages will be processed again. The operation completed successfully. - Installing LCU: Windows11.0-KB5077179-arm64.esd Deployment Image Servicing and Management tool Version: 10.0.26100.1 Image Version: 10.0.28000.1 Processing 1 of 1 - Adding package Package_for_RollupFix~31bf3856ad364e35~arm64~~28000.1575.1.9 [==========================100.0%==========================] The operation completed successfully.
I agree. Safe and easy way and Once done then leave it. Sometimes I wonder, is it M$ who challenges us or are we the ones who challenge M$?
something about last .2330 update for 25398 Code: C:\Users\Administrator\Downloads\mucs>dism /image:mount /add-package:"C:\Users\Administrator\Downloads\Windows11.0-KB5087541-x64\update.mum" Deployment Image Servicing and Management tool Version: 10.0.22621.2792 Image Version: 10.0.25398.1 Processing 1 of 1 - Adding package Package_for_RollupFix~31bf3856ad364e35~amd64~~25398.2330.1.10 [==========================100.0%==========================] The operation completed successfully. dism.log will tell you the truth
Q: What are all the list of restrictions enforced by DISM that an open DISM would not have and feel free to add ideas and suggestions to completely unlock DISM from any Windows versions? A: by ChatGPT If by an “open DISM” you mean a hypothetical open-source reimplementation of Microsoft’s Deployment Image Servicing and Management stack, then there are two categories of restrictions: Actual technical limitations built into DISM Artificial policy/version restrictions imposed by Microsoft Current DISM restrictions Microsoft documents several restrictions: Cannot service Windows images newer than the DISM version itself. Cannot install packages to a remote machine across the network. Does not support multiple servicing commands in a single invocation. Does not support wildcard expansion. Requires strict package dependency ordering. Only certain unattend.xml passes are honored during offline servicing. Some operations only work on offline images, while others only work online. Certain image formats and scenarios are unsupported. Additionally: DISM version checks often prevent servicing newer Windows releases with older ADK versions. Some Windows editions contain features that cannot be enabled unless licensing requirements are satisfied. Certain servicing operations are blocked by Component-Based Servicing (CBS) policy. Some package types require Microsoft catalog signatures. Feature-on-Demand packages may require matching Microsoft manifests and servicing stack versions. Things an Open DISM Could Remove An unrestricted implementation could theoretically: 1. Remove version checks Current: Windows 11 24H2 image + DISM from Windows 10 1607 = Unsupported Open implementation: Any image version + Any host OS = Allowed provided the image structures are understood. 2. Remove CBS policy restrictions Microsoft CBS decides: what can be removed what can be modified what is considered permanent Open DISM could: delete “permanent” packages downgrade updates remove servicing stack packages remove edition locks which DISM currently prevents. 3. Direct Component Store Editing Current DISM operates through: DISM -> CBS -> WinSxS An open implementation could edit: WinSxS Registry Manifests Catalogs directly. This would allow: removing Edge completely removing Defender completely removing Recovery Environment removing telemetry components removing “non-removable” packages 4. Eliminate Edition Restrictions Current: Home Pro Enterprise Education Server have edition packages and licensing enforcement. Open DISM could: convert any edition to any other unlock hidden features merge packages across editions similar to what enthusiasts already do manually. 5. Remove Signature Enforcement Current: .cab .cat mum manifest are validated. Open DISM could: install unsigned packages install custom features install modified Windows components similar to Linux package managers. 6. Support Live Kernel-Level Servicing Current DISM is largely limited by CBS. Open DISM could: patch running component store entries hot-replace system binaries schedule kernel patching without requiring Microsoft’s servicing infrastructure. 7. Cross-Version Package Porting Current: Windows 7 package -> Windows 10 Not supported. Open implementation could: rewrite manifests rewrite dependencies translate package metadata to allow migration between generations. 8. Full Registry Servicing DISM only touches certain registry areas. Open DISM could expose: SYSTEM hive SOFTWARE hive COMPONENTS hive BCD ELAM configuration as first-class objects. 9. Full WIM/VHD/FFU Manipulation DISM supports these formats already, but an open implementation could add: block-level deduplication custom compression algorithms differential images git-like image history image merging beyond Microsoft’s tooling. What Would Be Needed To “Completely Unlock” DISM If the goal is maximum freedom across all Windows versions (NT 5.x through Windows 11), an open project would ideally implement: Layer Replacement DISM CLI OpenDISM DISM API OpenDismApi CBS OpenCBS Package Manager OpenPkg WinSxS Engine OpenSxS WIM Engine OpenWIM Registry Servicing OpenRegistry Driver Store Servicing OpenDriverStore Feature Management OpenFeatureMgr Licensing Checks Optional/Disabled The Biggest Obstacle The real limitation is not DISM itself. The largest barrier is the proprietary Component-Based Servicing (CBS) subsystem: TrustedInstaller CSI (Component Servicing Infrastructure) WinSxS package manifests dependency resolution servicing stack updates DISM is mostly a front-end to CBS. An “unlocked DISM” without an open CBS would still inherit many Microsoft restrictions. To truly unlock Windows servicing, you’d need an open-source reimplementation of CBS, similar in spirit to how ReactOS reimplements Windows NT internals. Given your interest in Windows internals and Volatility work, a practical architecture would be: OpenDISM | +-- OpenCBS | | | +-- WinSxS parser | +-- MUM parser | +-- CAT verifier | +-- Manifest resolver | +-- OpenWIM +-- OpenFFU +-- OpenVHD +-- OpenRegistry That would allow servicing Windows Vista, 7, 8.x, 10, 11, and Server releases without most of the policy restrictions Microsoft currently enforces.
3 fixes for 25398.2330 fix 1 https://forums.mydigitallife.net/th...s-reconstructions.88605/page-155#post-1894823 fix 2 based on fix 1 (client features package 01 en-us) fix 3 based on fix 1 (client assignedaccess wow64 package en-us)
Still no go...I'll keep working on it Deployment Image Servicing and Management tool Version: 10.0.22621.2792 Image Version: 10.0.25398.1916 Processing 1 of 1 - Adding package Package_for_ServicingStack_2273~31bf3856ad364e35~amd64~~25398.2273.1.2 [==========================100.0%==========================] The operation completed successfully. C:\Users\Administrator>Dism /Image:C:\mount /Add-Package /PackagePath:C:\Windows11.0-KB5087541-x64.esd Deployment Image Servicing and Management tool Version: 10.0.22621.2792 Image Version: 10.0.25398.1916 Processing 1 of 1 - Adding package Package_for_RollupFix~31bf3856ad364e35~amd64~~25398.2330.1.10 [==========================100.0%==========================] An error occurred - Package_for_RollupFix Error: 0x80092004