Windows Update Failed with “Something Went Wrong” (KB5089549 / build 26200.8457)

I hit one of those wonderfully useless Windows Update errors where Windows basically says: “Something went wrong”. Very helpful. Cheers, Microsoft. In my case, the failing update was: KB5089549 / build 26200.8457. The update downloaded, started installing, then failed and rolled back. No clear explanation in the normal Windows Update screen. Just the usual vague message that tells you absolutely nothing useful. After digging into the logs, the real issue turned out to be very specific: The App Readiness service was disabled. That broke the AppX registration phase of the Windows update.

The actual error in the logs

The useful clue was in CBS.log. The update was failing with this kind of error:

Failed execution of queue item Installer: AppX Registration Installer
HRESULT_FROM_WIN32(1058)

Installer: AppX Registration Installer
Binary Name: appxreg.dll
ErrorCode: 80070422

The important bits are:

AppX Registration Installer
appxreg.dll
80070422
1058

Error 0x80070422 usually means a required service is disabled or cannot be started. In my case, the guilty service was:

AppReadiness
App Readiness
START_TYPE : 4 DISABLED

That was enough to make the Windows update fail.

Why this happens

Windows Update is not just replacing a few system files. During some cumulative or security updates, it also performs AppX package registration work. That means Windows may need services related to modern Windows apps, the Microsoft Store app model, and package deployment. The services I checked were:

StateRepository
AppXSvc
ClipSVC
AppReadiness
InstallService

Most of mine were fine. But AppReadiness was not. It was disabled. That is the problem. This can happen after using a debloating script, privacy hardening tool, manual service cleanup, or one of those “make Windows less annoying” scripts. I get the temptation, honestly. Windows ships with a lot of rubbish. But disabling the wrong service can come back later and punch Windows Update in the face.

How to check if this is your problem

Open PowerShell as Administrator.

Then run:

PowerShell$services = @(
  "StateRepository",
  "AppXSvc",
  "ClipSVC",
  "AppReadiness",
  "InstallService"
)

foreach ($s in $services) {
    Write-Host "`n=== $s ==="
    sc.exe qc $s
    sc.exe query $s
}

Now look carefully at the output for AppReadiness. If you see this:

SERVICE_NAME: AppReadiness
START_TYPE : 4 DISABLED

then you have probably found the issue. For comparison, this is bad:

AppReadiness
START_TYPE : 4 DISABLED
STATE      : STOPPED

This is what you want instead:

AppReadiness
START_TYPE : 3 DEMAND_START

Manual start is fine. It does not need to be running all the time.

The fix

Open PowerShell as Administrator and run:

PowerShellsc.exe config AppReadiness start= demand

Pay attention to the space here:

start= demand

Yes, the space after start= matters. Classic Windows nonsense. Then try starting the service:

PowerShellsc.exe start AppReadiness

If it starts and then stops again, do not panic. Some Windows services only run when needed. Now reboot the machine. After reboot, I recommend running:

PowerShellDISM /Online /Cleanup-Image /RestoreHealth

Then:

PowerShellsfc /scannow

Once that is done, try Windows Update again.

How to verify the service is fixed

Run:

PowerShellsc.exe qc AppReadiness
sc.exe query AppReadiness

You want to see something like:

START_TYPE : 3 DEMAND_START

The important thing is that it should not say:

START_TYPE : 4 DISABLED

If you want to collect the useful logs

If Windows Update is still failing, do not just guess. Grab the logs.

Run this in PowerShell as Administrator:

PowerShell$dest = "$env:USERPROFILE\Desktop\WindowsUpdate-Debug"
New-Item -ItemType Directory -Force -Path $dest | Out-Null

Get-ComputerInfo | Select-Object OsName, OsVersion, OsBuildNumber, WindowsVersion, WindowsBuildLabEx |
  Format-List | Out-File "$dest\system-info.txt"

Get-HotFix | Sort-Object InstalledOn -Descending |
  Select-Object -First 40 | Out-File "$dest\recent-hotfixes.txt"

Get-WindowsUpdateLog -LogPath "$dest\WindowsUpdate.log"

Copy-Item "$env:windir\Logs\CBS\CBS.log" "$dest\" -ErrorAction SilentlyContinue
Copy-Item "$env:windir\Logs\CBS\CBS.persist.log" "$dest\" -ErrorAction SilentlyContinue
Copy-Item "$env:windir\Logs\DISM\dism.log" "$dest\" -ErrorAction SilentlyContinue

wevtutil epl System "$dest\System.evtx"
wevtutil epl Application "$dest\Application.evtx"
wevtutil epl Setup "$dest\Setup.evtx"
wevtutil epl Microsoft-Windows-WindowsUpdateClient/Operational "$dest\WindowsUpdateClient-Operational.evtx"

Compress-Archive -Path "$dest\*" -DestinationPath "$env:USERPROFILE\Desktop\WindowsUpdate-Debug.zip" -Force

The most useful file in this case was:

C:\Windows\Logs\CBS\CBS.log

That is where the real failure showed up.

What I would not do first

I would not immediately start deleting SoftwareDistribution, resetting Windows Update, reinstalling random components, or throwing every generic repair command at the machine. Those steps may help in other cases, but here the update was already getting far enough into the install process to hit CBS servicing and then fail during AppX registration. So the problem was not really “Windows Update cannot download the update”. The problem was:

Windows Update needed App Readiness/AppX registration support,
but a required service was disabled.

Final takeaway

If a Windows update fails with a useless “something went wrong” message, check the logs before wasting hours. In my case, the fix was simply:

PowerShellsc.exe config AppReadiness start= demand

Then reboot, run DISM/SFC, and retry the update. The update installed properly after that. So yes, sometimes the big scary Windows Update failure is caused by one little disabled service. Very Windows.