Error 0x800f081f shows up in two situations that look different but share one cause. You’ll see it when a cumulative update fails to install, and you’ll see it when you try to add an optional feature like .NET Framework 3.5. In both cases Windows is telling you the same thing: it went looking for the files it needed and couldn’t find them.
The internal name for this code is CBS_E_SOURCE_MISSING. Once you read it that way, the fix becomes obvious — give Windows a valid source, or repair the store it normally pulls from. This guide covers both paths: the quick fix when it’s a feature payload, and the deeper repair when the component store itself is damaged.
What 0x800f081f actually means
Windows installs features and updates through a component called CBS (Component-Based Servicing). When CBS needs files it doesn’t already have on disk, it tries to fetch them — usually from Windows Update, sometimes from a local source you provide. If neither is available or valid, it stops and reports 0x800f081f.
So there are really only three reasons you hit this:
- The feature payload isn’t on the machine and Windows Update is unreachable or blocked.
- The online component store is corrupted, so even a repair attempt can’t find good files.
- A Group Policy is steering feature repair away from Windows Update without giving it a local alternative.
Step 1: Confirm the build and gather media
Before any repair, find out exactly which Windows version you’re on. The source you supply later has to match it closely, and a mismatched ISO is the most common reason a “correct” fix still throws 0x800f081f.
Run this from any prompt:
winverNote the version (for example 23H2) and build number. Then download or locate a Windows installation ISO that matches — same edition and a build at or near your current one. Mount it by double-clicking the ISO in File Explorer and note the drive letter it gets (this example uses D:).
Before you start
- Confirmed your Windows version and build with winver
- A matching Windows ISO downloaded or available
- ISO mounted and its drive letter noted
- You can open a prompt as administrator
Step 2: Fix 0x800f081f when installing a feature
If the error came from adding .NET Framework 3.5 (or another Feature on Demand), the payload simply isn’t on disk and Windows can’t pull it down. The clean fix is to install it straight from the mounted media.
Open an elevated PowerShell window and run:
Enable-WindowsOptionalFeature -Online -FeatureName "NetFx3" -Source "D:\sources\sxs" -LimitAccess-Source points at the sources\sxs folder on the mounted ISO, and -LimitAccess tells Windows not to bother contacting Windows Update. If you prefer DISM, this does the same job:
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /Source:D:\sources\sxs /LimitAccessIf you’re managing many machines, it’s worth checking whether a Group Policy is the real blocker rather than fixing each PC by hand. Open gpedit.msc and go to Computer Configuration → Administrative Templates → System → Specify settings for optional component installation and component repair. If it’s enabled, either point it at a valid source share or tick Contact Windows Update directly so feature payloads can download normally.
Step 3: Fix 0x800f081f on a failing Windows Update
When the error comes from a cumulative update rather than a feature, the component store is usually the problem. DISM can repair it — but by default DISM pulls its repair files from Windows Update, and if that’s exactly what’s broken, the repair fails with the same 0x800f081f. The trick is to give DISM a local source.
First, try the standard online repair:
DISM /Online /Cleanup-Image /RestoreHealthIf that completes, run SFC to fix protected files using the now-healthy store, then retry the update:
sfc /scannowIf DISM fails with 0x800f081f, point it at the mounted media instead. You need the install.wim (or install.esd) from the ISO and the right image index:
DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:1 /LimitAccessReplace the :1 index with the one matching your edition. If your media has an install.esd instead of a .wim, swap WIM: for ESD:. To list the available indexes:
DISM /Get-WimInfo /WimFile:D:\sources\install.wimDISM source switches
| /Source:WIM:D:\sources\install.wim:1 | Repair from a .wim image, index 1 |
|---|---|
| /Source:ESD:D:\sources\install.esd:1 | Repair from an .esd image, index 1 |
| /Source:D:\sources\sxs | Feature payload source (for /Enable-Feature) |
| /LimitAccess | Don't contact Windows Update for files |
After DISM reports success, run sfc /scannow, reboot, and check for updates again. The reasoning behind running DISM before SFC — and how to read their logs — is covered in our guide on using DISM and SFC to repair Windows.
Step 4: Reset Windows Update if it was a bad download
Occasionally 0x800f081f on an update is just a corrupted download, not a damaged store. If Step 3 didn’t stick, clear the update cache so Windows fetches the files fresh.
From an elevated prompt:
net stop wuauserv
net stop bits
ren %systemroot%\SoftwareDistribution SoftwareDistribution.old
net start wuauserv
net start bitsRenaming SoftwareDistribution rather than deleting it keeps the old cache as a fallback; Windows rebuilds it on the next check. This won’t touch your files or programs — it only clears cached downloads and update history. The full reset routine, including the catroot2 signature store, is in our walkthrough on fixing a stuck Windows Update.
When the repair still won’t take
If you’ve supplied a matching source and the error persists, work through these before reinstalling anything:
- Re-verify the media version. It’s easy to mount an ISO that’s a build or two off. Confirm again with
winverand compare it to the ISO’s edition. - Check the CBS log. Look in
C:\Windows\Logs\CBS\CBS.logfor the package that failed — the line near the 0x800f081f entry usually names the exact component missing. - Install the update manually. If a single cumulative update keeps failing, grab its KB from the Microsoft Update Catalog and run the standalone package, which bypasses some of the servicing path.
- Confirm policy isn’t blocking repair. On managed machines, the optional-component policy from Step 2 is a frequent culprit even for update repairs.
Wrapping up
0x800f081f is a missing-source error, not a mystery. Pin down which trigger you hit: a feature install needs the payload from matching media (-Source ...\sources\sxs), while a failed update needs a healthy component store, which means DISM with a local /Source and /LimitAccess when Windows Update can’t supply the files.
The two mistakes that keep people stuck are using an ISO that doesn’t match the installed build, and letting DISM fall back to a Windows Update connection that’s the broken part in the first place. Match the media, point DISM at it directly, and the error clears in most cases.
