Infopackets Reader Rick B. writes:

" Dear Dennis,

I administer a Windows Server 2022 machine for a client and the owner reported that Server Manager's Add Roles and Features won't complete without errors. I ran sfc /scannow, but it says Windows Resource Protection found corrupt files and was unable to fix some of them. I also ran DISM /Online /Cleanup-Image /ScanHealth, and it says the component store is repairable. However, when I run DISM /Online /Cleanup-Image /RestoreHealth, it fails with error 0x800f081f and says the source files could not be found.

I also tried resetting Windows Update by stopping the Windows Update service and renaming the SoftwareDistribution folder, but SFC still fails. How can I fix this without rebuilding the domain controller, as that would be extremely painful? "

My Response:

I asked Rick if he would like me to manage this for him and he agreed. Below I will discuss my findings.

Note: if you are looking for help or are struggling with your Windows Server, I can help - contact me here for a callback. You won't be disappointed!

Why 'DISM /RestoreHealth' Fails With 0x800f081f

First and foremost, this is Windows Component Store corruption, not just a broken Windows Update. Windows Update may be failing because it depends on the same underlying servicing system, but resetting the update cache will not fix missing or corrupt WinSxS payloads. When SFC cannot repair files and DISM reports 0x800f081f, Windows is usually telling you it needs a valid repair source - not just a fresh SoftwareDistribution folder.

DISM online repair can fail because it normally tries to repair the component store using Windows Update or whatever repair source you provide. If Windows Update is blocked, broken, or unable to supply the exact payloads required, DISM cannot complete the repair. Even a local ISO or WIM source can fail if it does not match the installed build, edition, language, servicing stack, or optional payloads needed by CBS.

Why 'SFC /scannow' Fails to Repair Corrupt Files

When sfc /scannow says it found corrupt files but cannot repair them, many administrators assume the problem is simply Windows Update. That is sometimes true, but not always. SFC depends on the Windows component store, also known as WinSxS, to find clean copies of protected system files. If the component store itself is damaged, incomplete, or missing payload files, SFC may know that files are corrupt but have no clean source to repair them from.

That is exactly what happened in this case. Windows Server 2022 was able to detect corruption, but it could not automatically repair it. DISM /ScanHealth confirmed that the component store was repairable, but DISM /RestoreHealth failed because the required source files were missing. In plain English, Windows knew what it needed, but it could not find the replacement files.

The reason this is so frustrating is that DISM does not just need "a file from the internet" - it needs the exact matching component payload for that build, edition, language, servicing stack, and feature state, and Windows Update will not always expose or supply that payload in a way CBS can use during repair.

In Rick's case, the server was using Windows Server 2022 Standard Server Core, build 20348.4893, and Microsoft lists KB5078766 as the March 10, 2026 cumulative update for Windows Server 2022, OS Build 20348.4893. This matters because the repair source had to match the installed server build, not just the general Windows Server 2022 version. (Source: support.microsoft.com)

Overview: How the Correct Repair Source Was Built

Before DISM could repair the server, I had to build a repair source that matched the installed Windows Server 2022 system.

The basic process was:

1. Obtain the original Windows Server 2022 installation media.
    
2. Copy the install media files to a temporary working folder.
    
3. Confirm the installed Windows Server edition, installation type, and build number.
    
4. Download the matching cumulative update from the Microsoft Update Catalog.
    
5. Extract the MSU update package to get the servicing stack and cumulative update CAB files, which are needed before the update can be slipstreamed into the Windows Server install.wim file.
    
6. Slipstream those CAB files into the correct install.wim index.
    
7. Verify that the updated WIM index now matches the installed server build.
    
8. Run DISM using the slipstreamed WIM as the repair source.
    
9. Run sfc /scannow afterward to confirm that protected system files can now be repaired.
    
10. Test the affected Windows Server roles, features, Windows Update, and account-related behavior.

Step 1: Obtain the Windows Server 2022 Install Media

The first step is to get a clean Windows Server 2022 installation source that matches the server being repaired. In Rick's case, this meant using the Windows Server 2022 installation media that came with the server. A random ISO may not work if it does not match the correct edition, language, and installation type.

Step 2: Copy the Install Media to a Temporary Folder

Next, copy the contents of the Windows Server 2022 DVD or ISO into a writable folder. This allows the installation files to be modified without touching the original media.

mkdir C:\Temp\slipstream\iso

robocopy D:\ C:\Temp\slipstream\iso /MIR /R:1 /W:1

In this example, D:\ is the mounted Windows Server 2022 DVD or ISO. The copied files in C:\Temp\slipstream\iso become the working repair source.

Step 3: Confirm the Installed Windows Server Edition and Build

Before slipstreaming anything, confirm the exact edition, installation type, and build of the broken server. DISM repair sources need to match the installed system closely.

ver

dism /Online /Get-CurrentEdition

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v InstallationType

reg query "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion" /v UBR

In Rick's case, the server was Windows Server 2022 Standard Server Core, build 20348.4893. That meant the repair source had to be updated to the same build.

Step 4: Check the Available install.wim Indexes

The Windows Server install media contains an install.wim file inside the sources folder. That WIM file can contain multiple editions and installation types, each stored as a separate index.

dism /Get-WimInfo /WimFile:C:\Temp\slipstream\iso\sources\install.wim

In this case, index 1 was Windows Server 2022 Standard Server Core, and index 2 was Windows Server 2022 Standard with Desktop Experience. Since Rick's server was Server Core, index 1 was the primary match.

Step 5: Download the Matching Cumulative Update

After confirming the installed build, download the matching cumulative update from the Microsoft Update Catalog. In Rick's case, the matching update was KB5078766 for Windows Server 2022 build 20348.4893.

The update file was saved into the updates folder:

C:\Temp\slipstream\updates\KB5078766.msu

This update was needed because the original install media was older than the server being repaired.

Step 6: Extract the MSU Update Package

The MSU package needs to be extracted so DISM can apply the CAB files directly to the WIM image.

mkdir C:\Temp\slipstream\updates\KB5078766-expanded

expand -F:* C:\Temp\slipstream\updates\KB5078766.msu C:\Temp\slipstream\updates\KB5078766-expanded

For this repair, the important extracted files were:

SSU-20348.4880-x64.cab

Windows10.0-KB5078766-x64.cab

The servicing stack update should be applied first, followed by the cumulative update.

Step 7: Mount the Correct install.wim Index

Next, mount the matching WIM index so the update packages can be added. Since Rick's server was Windows Server 2022 Standard Server Core, index 1 was mounted first.

mkdir C:\Temp\slipstream\mount

dism /Mount-Wim /WimFile:C:\Temp\slipstream\iso\sources\install.wim /Index:1 /MountDir:C:\Temp\slipstream\mount

Step 8: Slipstream the Servicing Stack and Cumulative Update

With the WIM mounted, apply the servicing stack CAB first, then the cumulative update CAB.

dism /Image:C:\Temp\slipstream\mount /Add-Package /PackagePath:C:\Temp\slipstream\updates\KB5078766-expanded\SSU-20348.4880-x64.cab

dism /Image:C:\Temp\slipstream\mount /Add-Package /PackagePath:C:\Temp\slipstream\updates\KB5078766-expanded\Windows10.0-KB5078766-x64.cab

This updates the WIM image so it matches the installed Windows Server build.

Step 9: Commit the Updated WIM Image

After the updates are applied, unmount the WIM and commit the changes.

dism /Unmount-Wim /MountDir:C:\Temp\slipstream\mount /Commit

dism /Cleanup-Wim

This saves the updated repair source back into install.wim.

Step 10: Verify the Updated WIM Build

Before using the WIM as a repair source, verify that the WIM index now matches the installed server build.

dism /Get-WimInfo /WimFile:C:\Temp\slipstream\iso\sources\install.wim /Index:1

The goal was to see:

ServicePack Build : 4893

That confirmed index 1 had been slipstreamed to the same build as the installed server.

Step 11: Run DISM Using the Slipstreamed WIM Source

Once the repair source matched the installed server build, DISM could be pointed at the updated WIM.

DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:C:\Temp\slipstream\iso\sources\install.wim:1 /LimitAccess

In many cases, that command is enough. However, Rick's server still had missing component payloads that were not present in the Server Core WIM index.

Step 12: Slipstream the Desktop Experience Index if Needed

In Rick's case, DISM repaired some of the corruption but still failed because several payloads were missing from the Server Core index. The fix was to also slipstream index 2, Windows Server 2022 Standard with Desktop Experience, to the same build.

dism /Mount-Wim /WimFile:C:\Temp\slipstream\iso\sources\install.wim /Index:2 /MountDir:C:\Temp\slipstream\mount

dism /Image:C:\Temp\slipstream\mount /Add-Package /PackagePath:C:\Temp\slipstream\updates\KB5078766-expanded\SSU-20348.4880-x64.cab

dism /Image:C:\Temp\slipstream\mount /Add-Package /PackagePath:C:\Temp\slipstream\updates\KB5078766-expanded\Windows10.0-KB5078766-x64.cab

dism /Unmount-Wim /MountDir:C:\Temp\slipstream\mount /Commit

This did not convert the server to Desktop Experience. It simply created a second matching repair source that contained additional component payloads DISM needed.

Step 13: Run DISM With Both WIM Sources

The final successful repair used both the Server Core index and the Desktop Experience index as sources.

DISM /Online /Cleanup-Image /RestoreHealth /Source:wim:C:\Temp\slipstream\iso\sources\install.wim:1 /Source:wim:C:\Temp\slipstream\iso\sources\install.wim:2 /LimitAccess

This command succeeded because index 1 matched the installed Server Core system, while index 2 supplied payloads that were missing from the Server Core image.

Step 14: Run SFC After DISM Completes

After DISM repairs the component store, run SFC again. SFC depends on the component store, so it usually cannot finish repairing files until DISM is successful.

sfc /scannow

The ideal result is:

Windows Resource Protection did not find any integrity violations.

If SFC says it repaired files, reboot and run sfc /scannow again.

Step 15: Test Windows Server Roles, Features, and Account Behavior

After DISM and SFC complete, test the original symptoms. That means checking Windows Update, optional Windows Server roles and features, and any account-related behavior that was broken before the repair.

In Rick's case, this final testing confirmed the repair worked. SFC no longer failed, Windows Server roles and features could be installed again, and the broken logoff buttons on the workstation machines started working properly. That confirmed the issue was not just a bad Windows Update cache - it was deeper Windows Component Store corruption that had to be repaired with a matching slipstreamed DISM source.

Common Mistakes to Avoid

Here are some common mistakes to avoid during if you need to repair Windows Server under similar circumstances:

1. Do not assume that resetting Windows Update fixes component store corruption. It may help update downloads, but it will not replace missing WinSxS payloads.
    
2. Do not use a random Windows Server 2022 ISO or even the evaluation version which can be obtained from Microsoft. The repair source needs to match the installed edition and build closely.
    
3. Do not assume the correct WIM index is enough. In this case, Server Core was the installed edition, but the repair still required payloads from the matching Desktop Experience index because that was the current installed version on the server.
    
4. Do not apply the MSU file directly if DISM fails. An MSU file is more like a wrapper or container for the actual update files. In this case, DISM had trouble using the MSU directly, so the better approach was to extract the MSU file first and apply the CAB files inside it. The servicing stack CAB should be applied first because it updates the part of Windows that installs and manages updates. After that, apply the cumulative update CAB, which contains the actual Windows fixes and replacement files needed for the repair source. In simple terms: update the updater first, then apply the main update.
    
5. Do not keep running SFC over and over before DISM is fixed. SFC depends on the component store. If the component store is damaged, SFC cannot finish the repair.

Conclusion

The fix was not a normal Windows Update reset. The server needed a build-matched local repair source. The original slipstream source was too old, so it had to be updated to the same Windows Server 2022 build as the installed system. After the Server Core WIM index was updated, DISM still failed because some needed payloads were not present in the Server Core image.

The final solution was to slipstream both Windows Server 2022 Standard Server Core and Windows Server 2022 Standard Desktop Experience to the same build, then run DISM with both WIM indexes as sources. Once both sources were available, DISM successfully repaired the component store, allowing SFC to be run afterward.

Additional 1-on-1 Support: From Dennis

If all of this is over your head, or if you need help fixing your Windows Server machine that won't run Roles and Features or fails with sfc /scannow, or if DISM /Online /Cleanup-Image /RestoreHealth doesn't work (or as with this case, error 0x800f081f) - I can help. Simply contact me, briefly describing the issue, and I will respond as soon as I can.

About the Author

Dennis Faas is a Senior DevOps / Infrastructure Engineer and Platform Systems Architect with more than 30 years of hands-on experience across Windows, Windows Server, Linux, server infrastructure, networking, virtualization, security, and advanced systems troubleshooting. As the owner and operator of Infopackets.com, Dennis specializes in diagnosing difficult real-world failures that standard repair tools often miss - including Windows Update failures, SFC and DISM repair problems, component store corruption, server role issues, and complex Active Directory environments. He is known for translating deep technical problems into clear, practical repair steps that administrators and business owners can actually follow. You can review Dennis' full resume here.