Dism Registry Repair

[Sanna Pospicil]

Clientwith Server 2019 Standard. Had a drive fail in RAID 5 array (which shouldn't have caused corruption, but it did). I had to rollback/restore registry hive including COMPONENTS from prior to any corruption. This rolled it back to Dec. 15 2022 timeframe, whereas drive and corruption occurred between this date and Jan. 1 2023. Server works fine, minus seeing that I can't run Windows update, it fails it can't connect to update service, as though not connected for internet (server has full internet access, shows that status AOK, however also has strange issue showing "Not connected" to any networks in the Network & Internet overview.

Started with SFC /scannow and DISM online with basic start of repairhealth and both for most part fail or had failed. I've gotten to the point of where I have been trying to run DISM using an ISO, mounted ISO drive path, and also a restored local copy of the C:\Windows folder from backup, to point to as a source. But consistently fails indicating it can't see/find the source. (even though am explicitly pointing it to valid sources). Consistently appear to be getting 800F081F as error.

Scanhealth level checks with DISM, state component store is repairable. Basically something within WinSXS, component store, possibly at file level there is corruption. (or remnants of files in there that still exist, but since I had to rollback to a day or two prior to December patching, this is also factoring in)

Chkdsk scan comes up clean. I am just seeking some way to simply repair the component store without any level of starting a new install for the client, as this is a production server. I could just leave it functional as-is, but it won't ever get new Windows updates. If I run most recent cumulative update for the server version, it simply fails to install. I can't install updates manually.

My next options I guess, is a full on recovery restore of the C: drive, Windows drive, but I shouldn't be having to do this if the component store should be able to be repaired. (plus kind of hard to tell a client that they won't be functional for a day for a recovery install to take place)

However, server thought this was installed (shows in installed updates list) but was erroring on it missing within SXS basically. I ran a DISM to add-package from CAB, figuring that would install this missing one's packages again without a possible failure installing it as a MSU executable. It completed successfully. Now scheduled server for reboot, and will then try to apply latest cumulative update that was previously failing, which should bring server completely back up to level it was prior to corruption and restore.

It seems to want to replace the corrupt files, but each one it states "Missing replacement payload". I'm confused, as I have DISM pointing to a mounted ISO of Server 2019 that is perfectly valid/functional.

TThe error code 0x800F081F usually indicates that a required component could not be found. This could be caused by corruption in the component store, or it could be due to missing or damaged files in the Windows installation.

If none of these steps help, you may need to perform a full repair install of Windows. This will involve reinstalling Windows and potentially losing any data that has not been backed up. If you do choose to do this, make sure to back up any important data before starting the repair install.

Thank you. I've somewhat gotten a bit further in this. So yes, component store is corrupt, indicates in logs that there are CSI corruptions. I did a comparison of what it indicated in way of files in manifest as corrupt and essentially these files are missing from the folder. This may be due to the server having had a possible cumulative update between the last good backup (Dec. 15) and the date of repair using registry rollback to that date, so at some level it knows there should be files and they are missing. I'm copying all files from manifest folder from the Dec. 15 restore copy, to the live running folder and will run DISM again to see if component store repair completes.

I had tried a restorehealth using WIM and it failed consistently, at some level it still wanted to fallback on checking Windows Update (which is broken due to the corruption in Windows, but possibly fixed when component store is repaired). Also used an ISO or mounted ISO as a source as well, with errors/failure. I've been successful to point to the restored copy of the WinSXS folder as the source, modifying the Specify settings for optional component installation and component repair policy, restricting it to this location as the source and check to never allow payload download from Windows Update.

The Windows Registry is a hierarchical database of settings used by Windows components, drivers, and applications. It was introduced in 1992 to replace the messy practice of using separate configuration files for each user and application on the machine. The registry consists of hives, keys, and values. Hives are a collection of keys and are generally built around a unifying concept like a particular user or computer. Keys are roughly analogous to folders, while values are somewhat similar to individual files. All of these elements are organized into a hierarchical tree-like structure.

While the implementation has changed over time, every version of Windows since 3.1 has included a registry. Third-party developers also frequently make use of the registry, although there is no requirement to do so. The Varonis agent, for example, stores certain low-level configuration settings as registry values. As with other internal components in Windows, Microsoft has added a number of features over the years to make the registry both more reliable and more secure. The modern registry does not require regular cleaning or maintenance.

Even misidentified or damaged hardware can cause broken registry items. The most recent versions of Windows can dynamically create registry items at or even after boot time to support features like Plug and Play. If the system fails to accurately identify the hardware, it may result in inaccurate registry entries.

Prior to making any attempt at repairing broken registry items, you should be sure there is a highly compelling reason to do so. Changes to the registry have the potential to render a computer completely inoperable, requiring a complete reinstallation of Windows. Other possibilities include unstable operation, nonfunctional applications, data loss, and more.

Microsoft developed the registry as an internal component of Windows and never intended for end-users to access or edit its contents. Registry changes for the sake of optimization or performance gains are not recommended and are likely to do more harm than good. Processor speeds, memory capacity, and storage space have all increased at a much faster rate than the size or complexity of the registry. Even with the millions of keys found in newer versions of Windows, the complete size of the registry will only be a small fraction of the size of a single HD movie. Removing broken registry items to free up more storage space is, therefore, akin to dealing with a flooded basement one airline-sized water bottle at a time.

This method will not have an impact on personal files and has the potential to correct broken registry items for third-party applications. Entries added by malware or hackers can also be removed, provided the restore point dates to a time before the infection.

As applying incorrect registry settings via this method has the potential to render an entire group of computers inoperable, you should exercise extreme care when using GPOs to deal with broken registry items.

In some unusual cases, you may be aware of a specific registry key that does not match a known desired parameter. Incident Responders may also manually have to remove entries created by malware or threat actors. This method has a high potential to produce adverse effects, as even a small typo in a registry value could dramatically change the behavior of the machine. It is advisable to create a system restore point or even export the current registry before making any changes.

I used the registry cleaner feature a few days ago and it definitely messed up my computer: basically, there are times I turn it on and it turns off immediately. Also, many times it doesn't start Windows, it sends me straight to some weird Bios menu.

Anyway, I saved the registry copy when I did it, but when I right click on it and select "merge" to try to restore it I get an error message: "All data wasn't written correctly in the registry. The system or other processes have some keys opened or you lack enough privileges to do this operation". (I'm translating from Spanish, since my computer is in that language).

We recommend that you don't regularly use the Registry Cleaner with Windows 10, only use it if you have a specific problem.

Windows 10 changes the registry often which can give false results.

For the official Piriform advice on using the Registry Cleaner see this: -i-get-a-registry-error-on-ccleaner-on-windows-10-i-have-scanned-5-times/?tab=comments#comment-326804

Firstly, try using the DISM and SFC commands to repair the system image.

(Note that many articles, including the one I link below, say to run SFC first. That's just to save time, its always better to run DISM before SFC if you have the time because SFC uses the files that DISM updates, so doing DISM first takes longer but does make sure SFC is using valid and up to date files).

Again that will take some time to scan the system files and repair any errors it finds.

It will report if it found nothing wrong, or tell you what it has fixed, it may tell you to reboot if it fixed something.

Open the start menu and type "rstrui.exe" (without the quote marks), click on 'Run as Administrator'.

That opens the System Restore dialogue where you can pick a Restore point and return your computer to how it was when that RP was made.

It's fairly simple to use just follow the prompts.

3a8082e126