Quick answer
0x800f0805 is CBS_E_INVALID_PACKAGE (HRESULT −2146498555) — “the package is invalid”. Windows opened an update package and rejected it before installing anything, almost always because the file does not match the machine: wrong architecture, wrong Windows version, or a download that finished incomplete. In 2026 the most common cause is grabbing the x64 package for an ARM64 device, or a Windows 10 package for a Windows 11 build. Fix chain, cheapest first: verify build and architecture → re-download → install the servicing stack update first → clear the update cache → DISM /Add-Package → DISM /RestoreHealth.
Which fix do I need?
This error is nearly always about the file, not the machine. Confirm what you downloaded before repairing anything.
| When you see it | Most likely cause | Go to | Time | Difficulty |
|---|---|---|---|---|
| Double-clicking a downloaded .msu | Wrong version or architecture | Fix 1 | 5 min | Easy |
| The download was slow or interrupted | Truncated file | Fix 2 | 10 min | Easy |
| Installing a recent cumulative update | Servicing stack too old | Fix 3 | 15 min | Medium |
| During Windows Update, not a manual install | Corrupt update cache | Fix 4 | 10 min | Easy |
| Adding a .cab with DISM | Wrong DISM syntax for the file type | Fix 5 | 10 min | Medium |
| Every package now fails | Component store damage | Fix 6 | 30–45 min | Medium |
What does 0x800f0805 mean?
Windows defines 0x800F0805 as CBS_E_INVALID_PACKAGE, decimal −2146498555. The 0x800F prefix marks it as coming from CBS — Component Based Servicing, the subsystem that installs Windows updates — rather than from Win32.
“Invalid” here does not mean the file is damaged in the sense of unreadable. It means CBS read the package’s manifest, compared what the package declares it applies to against what this machine actually is, and found they do not match. A package built for Windows 10 22H2 x64 is a perfectly valid file; it is simply not valid for a Windows 11 24H2 ARM64 device, and CBS refuses it.
The distinction matters because it tells you where to look. 0x800f0805 is a mismatch error far more often than a corruption error. Most people who hit it have downloaded the wrong file, and no amount of system repair will change that.
Where you’ll see it
- Running a .msu downloaded from the Update Catalog — by far the most common case.
- Adding a package with DISM —
DISM /Online /Add-Packagereturns it directly. - During Windows Update — less common, and usually points at a corrupt cache rather than a mismatch.
- Installing a servicing stack update out of order.
- Enabling a Windows feature from a mounted ISO where the ISO does not match the installed build.
- On Windows Server — applying a rollup meant for a different Server release.
If the package you are installing is a specific KB, the Microsoft Update Catalog guide covers how to identify the correct build and architecture before downloading — which is the step most people skip.
Root causes, diagnosed
1. Architecture mismatch
An x64 package on an ARM64 device, or an x86 package on x64. Surprisingly common now that ARM64 Windows laptops are mainstream and the Catalog lists all architectures together.
Confirm it: press Windows+R, run winver for the build, then check Settings → System → About → System type for the architecture. Compare both against the package title.
Get-ComputerInfo -Property OsName,OsVersion,OsBuildNumber,OsArchitecture2. Wrong Windows version
The package targets a different release — a Windows 10 update on Windows 11, or a 23H2 package on a 24H2 install.
Confirm it: the package title in the Catalog names the version explicitly. Match it character for character against your winver output.
3. Incomplete download
The file finished but is truncated. A partial .msu still opens and still fails validation.
Confirm it: compare the file size on disk against the size shown in the Update Catalog listing. A mismatch of even a few KB means re-download.
4. Servicing stack behind the package
The package needs a newer servicing stack than the machine has, so CBS cannot parse it correctly.
Confirm it: check C:\Windows\Logs\CBS\CBS.log around the failure for lines naming a required package version.
Select-String -Path C:\Windows\Logs\CBS\CBS.log -Pattern "0x800f0805","Invalid package","not applicable" | Select-Object -Last 25Quick fixes for 0x800f0805
Fix 1 — Verify build and architecture, then get the right package (Easy · 5 min)
Use this when: you downloaded the file manually — causes 1 and 2. Do this before anything else.
- Get your build. Press Windows+R, type
winver, press Enter. Note the version (24H2, 23H2) and the OS build number. - Get your architecture. Settings → System → About → System type. It reads x64, ARM64 or x86.
- Match the package title exactly. On the Update Catalog, the title states the product and architecture — “Windows 11 Version 24H2 for x64-based Systems”. All three must match.
Success looks like: the correct package installs without the error appearing.
This resolves the clear majority of 0x800f0805 reports, because the error is a mismatch error by design. Five minutes here saves an hour of pointless system repair.
Fix 2 — Re-download the package (Easy · 10 min)
Use this when: the download was interrupted, or the file size does not match — cause 3.
- Delete the existing file rather than letting the browser append a duplicate.
- Download again on a stable connection, and let it finish completely.
- Compare the size against the figure the Catalog listed before running it.
Success looks like: the file size matches and the installer proceeds past validation.
Fix 4 — Clear the Windows Update cache (Easy · 10 min)
Use this when: the error appears during Windows Update rather than a manual install.
net stop wuauserv
net stop bits
ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
net start wuauserv
net start bitsSuccess looks like: the rename succeeds and the update re-downloads cleanly.
Renaming rather than deleting is deliberate — Windows rebuilds the folder on the next check, and the original stays recoverable.
Intermediate fixes for 0x800f0805
Fix 3 — Install the servicing stack update first (Medium · 15 min)
Use this when: you are applying a recent cumulative update to a machine that has been offline — cause 4.
- Search your build number on the Update Catalog and find the servicing stack update for it.
- Install the SSU and reboot.
- Then install the original package.
Success looks like: the SSU installs cleanly and the cumulative update then validates.
Order matters and is not optional. On Windows 11 the SSU is usually bundled into the cumulative update, so this fix applies mainly to Windows 10 and Server.
Fix 5 — Use the right DISM syntax for the file type (Medium · 10 min)
Use this when: DISM returns the error while adding a package.
DISM handles .cab and .msu differently, and using the wrong form produces 0x800f0805 even when the file is correct.
DISM /Online /Add-Package /PackagePath:"C:\path\to\update.cab"For a .msu, run the file itself with the Windows Update Standalone Installer instead:
wusa.exe C:\path\to\update.msuSuccess looks like: DISM reports the operation completed successfully.
If you need DISM specifically for a .msu, extract it first — expand -f:* update.msu C:\extracted — then add the .cab it contains.
Fix 6 — Repair the component store (Medium · 30–45 min)
Use this when: the package is verified correct and every package now fails.
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannowSuccess looks like: “The restore operation completed successfully.”
Reach for this last, not first. If the store is genuinely damaged you will usually see 0x80073712 as well, and that guide covers store repair in more depth.
When to stop and escalate
If the correct package for the correct build and architecture still fails after a store repair, stop treating it as a package problem. Collect a zip of C:\Windows\Logs\CBS\, the exact package filename, your winver output and your System type before asking for help — those four identify a mismatch in seconds.
Preventing 0x800f0805
- Read the full package title before downloading. The Catalog lists every architecture together and the titles differ by a few words.
- Check the file size after downloading against the Catalog figure. It costs a moment and catches truncated files.
- Install servicing stack updates before cumulative ones on machines that have been offline.
- Keep a note of your build and architecture if you manage several machines. Most mismatches happen when one person patches a mixed fleet.
Related error codes
| Code | What it means | How it differs from 0x800f0805 |
|---|---|---|
| 0x80073712 | A component manifest is missing from the store | Genuine store damage; 0x800f0805 usually means the file is wrong for the machine, not that the machine is broken |
| 0x800f081f | Source files could not be found | The source is unreachable; 0x800f0805 means the source was read and rejected |
| 0x80070002 | File not found | A file is missing entirely; 0x800f0805 means the file is present but does not apply |
A full index of the codes covered on this site is at Windows error codes.
Frequently asked questions
What does error 0x800f0805 mean?
It is CBS_E_INVALID_PACKAGE, HRESULT −2146498555. Component Based Servicing read an update package and rejected it as not applicable to this machine — usually wrong architecture, wrong Windows version, or an incomplete download.
Is 0x800f0805 a sign my PC is broken?
Usually not. It is a mismatch error far more often than a corruption error. Verify the package matches your build and architecture before running any system repair.
How do I find my Windows build and architecture?
Press Windows+R and run winver for the version and build number. Then open Settings → System → About and read System type for x64, ARM64 or x86.
Why does the same package work on another PC?
Because that PC is a different build or architecture. A package is tied to a specific Windows version and processor type, and CBS enforces that strictly.
Can I install a Windows 10 update on Windows 11?
No. They are separate servicing branches and CBS will reject the package with this error every time.
Why does DISM give 0x800f0805 for a .msu file?
/Add-Package expects a .cab. Run a .msu with wusa.exe instead, or extract it with expand -f:* update.msu C:\extracted and add the .cab inside.
Do I need to install the servicing stack update first?
On Windows 10 and Server, often yes — a cumulative update can require a newer servicing stack than the machine has. On Windows 11 the SSU is usually bundled in.
Will re-downloading the file fix it?
Only if the download was incomplete. If the package is the wrong architecture or version, re-downloading the same file changes nothing — get the right one instead.
