How I Repaired Windows Update and Microsoft Store Without Resetting Windows

Windows Update and Microsoft Store failed on the same PC. The Store would not open, Windows Update could not scan, and even Reset this PC was unavailable. There was no recent backup, so a reset or clean installation was out of the question unless every safer option failed first.

The usual advice for a broken Store is to clear its cache or reinstall the app. That was not the right starting point here. Store, Windows Update, and Windows recovery all depend on parts of the Windows servicing stack. When several of them break together, it is worth checking that shared foundation before changing individual apps.

This article follows the repair in the order I actually used: establish a rollback point, check Windows integrity, prove whether the update service is crashing, and only then remove the update responsible for the bad state.

Quote

This is not a recipe for removing any update that causes an annoyance. The rollback section is specific to a machine where the same service crashed repeatedly after a known update. Confirm the package and build on your own PC before removing anything.

What was broken

The affected machine was running Windows 11 Pro 25H2, build 26200.8655. It had enough free disk space, no proxy, and a working internet connection. Windows Recovery Environment was enabled, and the Microsoft Store package was still installed.

The first useful clue came from the built-in repair tools:

DISM.exe /Online /Cleanup-Image /CheckHealth
sfc.exe /verifyonly

DISM reported that the component store was repairable. SFC found integrity violations. That explained why resetting the Store alone was unlikely to solve the whole problem.

Before changing anything

Open Windows Terminal or PowerShell as Administrator. Record the Windows build, available space, recovery status, and service configuration:

Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumber
Get-PSDrive C | Select-Object Used,Free
reagentc /info
Get-Service wuauserv,bits,cryptsvc,DoSvc,InstallService,AppXSvc |
  Select-Object Name,Status,StartType
netsh winhttp show proxy

Do not assume that wuauserv is broken merely because it says Stopped. On current Windows releases it normally uses a manual, trigger-based start. The important test is whether it starts when requested and remains alive.

I also created a restore point:

Checkpoint-Computer -Description "Before Windows Update Repair" -RestorePointType MODIFY_SETTINGS

You can confirm it exists with:

Get-ComputerRestorePoint |
  Sort-Object SequenceNumber -Descending |
  Select-Object -First 3 SequenceNumber,Description,CreationTime

A restore point does not protect documents and photos, but it gives you a way back from a bad system-level change. If you have an external disk, back up irreplaceable files as well.

Start with the supported repair tools

DISM repairs the Windows component store. SFC then uses that store to repair protected system files. For that reason, run the repair version of DISM before the final SFC scan:

DISM.exe /Online /Cleanup-Image /RestoreHealth
sfc.exe /scannow

Microsoft documents the same order in its System File Checker guidance. DISM may download replacement components through Windows Update, so it needs both a working network path and a functioning update service.

It is common for DISM to sit on one percentage for several minutes. Before cancelling it, check whether Windows servicing is still active:

Get-Process dism,dismhost,TiWorker,TrustedInstaller -ErrorAction SilentlyContinue |
  Select-Object ProcessName,CPU,StartTime,Responding

Get-Content "$env:windir\Logs\CBS\CBS.log" -Tail 20

If the log is advancing or TiWorker is doing work, leave it alone. Starting another DISM process at the same time only makes diagnosis harder.

On this machine, DISM reached the download stage and then logged 0x80080005 while trying to obtain the Windows Update services collection. That moved the investigation away from Microsoft Store and toward the update service itself.

Check whether Windows Update is actually crashing

Start the service and give it a few seconds:

sc.exe start wuauserv
sc.exe queryex wuauserv

If it returns to Stopped, inspect recent Application events:

Get-WinEvent -FilterHashtable @{
  LogName='Application'
  StartTime=(Get-Date).AddHours(-2)
  Id=1000,1001
} | Where-Object {
  $_.Message -match 'svchost.exe_wuauserv|wuaueng.dll'
} | Select-Object -First 10 TimeCreated,Id,ProviderName,Message

The repeated failure in this case was unambiguous:

• Application: svchost.exe_wuauserv
• Faulting module: wuaueng.dll
• Exception: 0xc0000409
• Service Control Manager reported repeated unexpected terminations

The file was correctly signed by Microsoft and matched the copy in WinSxS byte for byte. Replacing the DLL manually would therefore have been both risky and pointless. The problem was the installed component state around it, not an unsigned DLL dropped into System32.

Rebuild the update caches without deleting them

Corrupt update databases can cause similar symptoms, so I tested that possibility next. I renamed the cache directories instead of deleting them. This lets Windows build fresh copies while keeping the old data available until the repair is proven.

$stamp = Get-Date -Format 'yyyyMMdd-HHmmss'

Stop-Service wuauserv,bits,cryptsvc,DoSvc -Force -ErrorAction SilentlyContinue

Rename-Item "$env:windir\SoftwareDistribution" "SoftwareDistribution.before-repair-$stamp"
Rename-Item "$env:windir\System32\catroot2" "catroot2.before-repair-$stamp"

Start-Service cryptsvc,bits,DoSvc
Start-Service wuauserv

In this case, the caches were not the cause: wuauserv still crashed in the same module. That result was useful because it ruled out a common failure without destroying the original cache.

Find the update that changed the system

The failures appeared after the June 2026 cumulative update. I used DISM to list the installed rollups and confirm the package rather than relying on memory or a forum post:

DISM.exe /Online /Get-Packages /Format:Table

PowerShell can provide a second view of recent updates:

Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 15

The active package was KB5094126, corresponding to build 26200.8655. Microsoft lists that KB as the June 9, 2026 cumulative update for Windows 11 24H2 and 25H2.

Before removing it, I checked the exact package identity:

DISM.exe /Online /Get-PackageInfo /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.8655.1.20

The evidence now lined up: the timing, installed build, repeatable service crash, failed online repair, and exact installed rollup all pointed to the same update state. A restore point was available, and BitLocker was not active on the system drive.

Roll back the confirmed package

I removed only that package and prevented DISM from restarting the computer automatically:

DISM.exe /Online /Remove-Package /PackageName:Package_for_RollupFix~31bf3856ad364e35~amd64~~26100.8655.1.20 /NoRestart

The package identity above belongs to this particular case. Do not paste it into another PC. Get the identity from DISM /Get-Packages on the machine you are repairing.

DISM finished successfully and reported the package as Uninstall Pending. I then closed open applications and restarted Windows normally.

After reboot, Windows reported build 26200.8457, the previous cumulative-update level. More importantly, wuauserv started and stayed running. Event Viewer showed no new crash.

Repair the component store after rollback

Removing the bad rollup fixed the service, but DISM still reported repairable corruption. With Windows Update working again, the standard repair could finally download the missing payload:

DISM.exe /Online /Cleanup-Image /RestoreHealth
DISM.exe /Online /Cleanup-Image /CheckHealth
sfc.exe /scannow

This time DISM completed its download and repair. The final checks returned:

• No component store corruption detected.
• Windows Resource Protection did not find any integrity violations.

Those two results matter more than seeing Store open once. They show that the underlying Windows repair source and protected files are consistent again.

Verify Store and Windows Update

I launched Store directly and checked that its process remained responsive:

Start-Process 'ms-windows-store:'
Start-Sleep -Seconds 10
Get-Process WinStore.App -ErrorAction SilentlyContinue |
  Select-Object ProcessName,Id,Responding

Then I opened Windows Update:

Start-Process 'ms-settings:windowsupdate'

The final validation was straightforward:

• Microsoft Store opened and stayed responsive.
• Windows Update Settings opened.
• An update scan completed successfully.
• wuauserv remained running during the scan.
• No new AppX or Windows Update service crash appeared in Event Viewer.

The scan immediately offered KB5094126 again, so I hid that one update temporarily. I did not disable Windows Update or hide unrelated security patches. Once Microsoft publishes a cumulative update that supersedes it, that newer package should be reviewed and installed rather than leaving the PC on an older security level indefinitely.

When this procedure is not enough

Do not keep removing packages if the evidence is unclear. An in-place repair install is the safer escalation when:

• DISM still cannot repair the component store;
• SFC continues to find files it cannot fix;
• the suspected package is permanent or cannot be removed; or
• Settings, Store, and recovery components remain broken after integrity checks pass.

Download an official Windows ISO that matches the installed edition, language, and architecture. Mount it, run setup.exe, and choose Keep personal files and apps. An in-place repair is not the same operation as Reset this PC, although a separate backup is still strongly recommended.

Avoid third-party DLL downloads, manual ownership changes under WinSxS or WindowsApps, and scripts that remove every AppX package. Those actions create new variables before the original fault has been understood.

The short version

The Store was only one visible symptom. The actual failure was a Windows Update service crash in a damaged cumulative-update state. Cache rebuilding ruled out the update databases; Event Viewer identified the crashing service; DISM identified the installed rollup; and rolling back that exact package restored the update service. Only then could DISM and SFC finish the repair.

That order is what kept the repair controlled: observe first, preserve rollback options, change one layer at a time, and verify the system after every reboot.

References

• Microsoft: Using System File Checker in Windows
• Microsoft Learn: Guidance for troubleshooting Windows Update issues
• Microsoft Support: KB5094126 for Windows 11 24H2 and 25H2
• ElevenForum: Repair the Windows image component store