When Windows Update refuses to deliver a specific KB, the Microsoft Update Catalog has the same package as an MSU. Expand it, install it with DISM, and check the result in the servicing log rather than guessing.
Download the **.msu** from the Update Catalog, install it with **dism /online /add-package /packagepath:...**, reboot and confirm with **Get-HotFix**. DISM writes the reason into **C:\Windows\Logs\DISM\dism.log** when it fails.
**Get-HotFix** and the package list tell you what is already installed. Installing a package that is present returns an error that looks like a failure but means nothing was needed.
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 6
Get-WindowsPackage -Online | Where-Object PackageName -like '*5063878*' | Select-Object PackageName,PackageState,ReleaseTypeThe catalog lists a separate file per architecture and per Windows version. A file for 23H2 does not install on 24H2, and the 32-bit variant does not install at all.
Get-ComputerInfo -Property OsName,OsVersion,OsBuildNumber,OsArchitecture
New-Item -ItemType Directory C:\update -Force | Out-Null
Get-ChildItem C:\update | Select-Object Name,LengthAn MSU is a small container around one or more CAB files. **expand -F:** unpacks them, which lets DISM work on the CAB directly when the MSU wrapper causes trouble.
New-Item -ItemType Directory C:\update\x -Force | Out-Null
expand -F:* C:\update\windows11.0-kb5063878-x64.msu C:\update\x
Get-ChildItem C:\update\x | Select-Object Name,Length**/add-package** accepts the MSU or the CAB. Exit code 0 is success, 3010 means a reboot is pending, and anything else is a real failure worth reading in the log.
dism /online /add-package /packagepath:C:\update\windows11.0-kb5063878-x64.msu /norestart
$LASTEXITCODE
Get-Content C:\Windows\Logs\DISM\dism.log -Tail 40The package only becomes active after the pending servicing operation completes. **Get-HotFix** shows the KB, and **winver** shows the build that the update was supposed to raise.
Restart-Computer
# after the reboot
Get-HotFix -Id KB5063878 | Select-Object HotFixID,InstalledOn,InstalledBy
[System.Environment]::OSVersion.Version
Get-WindowsPackage -Online | Where-Object PackageName -like '*5063878*' | Select-Object PackageState**0x800f081e** means the package does not apply to this build, **0x80073712** means the component store is damaged. The second one is fixed with a restore, not with a second install attempt.
dism /online /cleanup-image /restorehealth
sfc /scannow
Get-WinEvent -LogName Setup -MaxEvents 20 | Select-Object TimeCreated,Id,MessageWrong build or architecture. Compare OsBuildNumber with the catalog listing and download the file for the exact build.
Component store corruption. Run dism /online /cleanup-image /restorehealth with an internet connection, reboot, then retry the package.
That is wusa responding to a double-click. Install from an elevated shell with the dism command instead so the output stays visible.
The next scan may supersede it with a newer cumulative update. That is normal; the newer package contains the same fixes.
Yes, it is the same package. The difference is the delivery path: the catalog serves the file directly, and Windows Update skips its own eligibility checks.
One /add-package call per file, in release order. Stacking packages out of order creates servicing conflicts that are painful to unwind.
Yes, on a machine where the package is already downloaded. Copy the MSU over and run the same DISM command.
Remove the package again with dism /online /remove-package /packagename:<name> /norestart and reboot. Get the exact package name from Get-WindowsPackage before removing it.
Free · no account needed · tracks your progress