Why does rebasing corrupt component store so frequently?

O

OpenSource Ghost

Member
I managed to remove a ton of components with NTLite without breaking component store and file integrity, but I had to perform many trials to find out which components could be removed to have component store integrity survive an offline rebase.

- Why is rebasing so sensitive?
- Why can a rebased image pass DISM component store integrity when mounted offline, but fail (error 3) DISM component store integrity health check when online?
 
If checking Compatibility for Windows Store NTL lock the components for removal (Red colored Template option: Not Recommended to remove) and the Online install will work fine.
Checking integrity sfx looks for missing components and replace them from WinSxS folder witch is mandatory to have all components to make Windows Update working unless user want to do a Refresh with every new WU (-Preview), if used the reset parameter on a CleanUp.
 
What exactly do you call a rebase? Would it be ResetBase? How are you doing this? Which version of Windows?

Microsoft disabled resetbase in Windows 10 version 1607 and later. To do this you need to change a value in the registry. Even with the reg tweak, in version 1709 and later Microsoft disabled this in an offline image. You need other reg tweaks for this to work on an offline image in 1709 and later.

And in version 1903 and then doing resetbase breaks the installation of future cumulative updates.
https://forums.mydigitallife.net/threads/windows-10-hotfix-repository.57050/page-411#post-1530237
https://forums.mydigitallife.net/threads/abbodi1406s-batch-scripts-repo.74197/page-39#post-1530461

In short, if you want to install future updates, it is only safe to use full resetbase (with reg tweaks) on Windows 10 version 1809 and earlier.
 

19043.1021 Remove Reinstallation - Bluescreen

Hi Guys, just a report and the Question if I'm alone with this error :). I tried to install the .1021 Update (yes with new ssu before) on .985 but after a restart windows said the update couldnt applied and windows start making it undone. That works well but after that the new edge and...
www.ntlite.com www.ntlite.com
 
Registry tweak to enable resetbase + actual rebase/resetbase always worked with MSDN images + updates. I've used it since early versions of Windows 11 21H2 on my "Golden Image" and as long as "sensitive" components weren't removed, rebasing had no ill effect on integrity and future updates. Removal of some of the "recommended" components caused no issues and many "Gaming" and "Lite" did. I was only curious about why rebasing caused issued. It was supposed to simply replace original/initial OS component store files with the ones from cumulative updates and then purge original component store files.
 
If this is about the traditional Win32 DLL rebasing traditionally (but not always) done with the Microsoft SDK tool rebase.exe, then by definition it invalidates the digital signatures of all changed DLLs and EXEs, thus breaking the validity of the signed cat files provided with operating systems, drivers and updates.

Therefore, any script or tool that does this after the 1996 introduction of code signing needs to skip changing signed files and instead use the already set base addresses of any such files. With the later introduction of cat files for the entire OS, this means that only a few 3rd party program files can really be rebased, and only if the provider of that program hasn't bothered to sign all their files, either directly or via a cat file.

Same principles apply to the related "rebinding" of DLL imports to contain cached references to the installed system DLLs for faster loading.
 
In this discussion, the subject is ResetBase which is the process of picking the WinSxS winners and removing the losing component folders.
 
Could splitting/de-coupling of DISM components/packages be the cause of Component Store corruption after component removal and rebasing? Perhaps a compatibility option to prevent component splitting/de-coupling resolve the issue? Some also mentioned to me that expanding Component Store files before performing a rebase to make it less prone to error. I guess expanding = unpacking/de-compressing.

I still don't understand why some images can be mounted offline and pass DISM Component Store health check, but fail it (DISM Error 3) once deployed. Unlike some errors, error 3 doesn't allow health restoration from source images mounted offline.
 
You must log in or register to reply here.
Back
Top