Windows Update Error 0x800f081f: What It Means and How to Fix It (2026 Updated Guide)

Quick answer

0x800f081f means Windows tried to install something and couldn’t find the source files it needed. In 2026 the error appears in two distinct situations: enabling the optional .NET Framework 3.5 feature, and installing certain cumulative or security updates. The fix is different for each. The .NET 3.5 case needs a Windows installation ISO mounted as a source. The cumulative update case usually needs an in-place repair install. Don’t apply one to the other.

Before you start

You will need administrator rights for every step.
For the .NET 3.5 fix, you will need a Windows ISO that matches your installed version and build. Don’t use an older or newer ISO — the component store versions need to match.
For the cumulative-update fix, you’ll need around an hour and a recent backup if a repair install becomes necessary.
Don’t run a third-party “Windows update fix” tool. The procedures here are the supported ones; nothing in the third-party tooling does anything materially different.
Work or school device? See If you are on a work or school device before doing anything.

What this error means

0x800f081f is CBS_E_SOURCE_MISSING. The Component-Based Servicing engine that installs Windows components looked for a source file — usually an installer payload or feature data — and couldn’t find it. The frustrating thing about this code is that it doesn’t tell you whether the source is missing because:

The component is a “Feature on Demand” that was never downloaded to your machine.
The Windows component store (WinSxS) is corrupted.
A managed environment is blocking access to Microsoft’s servers.

Each cause has a different fix. Most articles on the first page of search results pick one of the three and present it as the universal answer. That’s why people end up running DISM commands repeatedly without resolving anything — they’re applying the .NET 3.5 fix to a cumulative-update problem, or vice versa.

Where this error appears

You’ll see 0x800f081f most often in two places:

Enabling .NET Framework 3.5. Windows ships .NET 3.5 as an optional feature; it’s not installed by default. When you (or an installer for an old application) try to enable it, Windows fetches the payload from Microsoft Update. If that fetch fails, the error is 0x800f081f.
Installing a recent cumulative or security update. Microsoft has acknowledged this surface in recent Q&A — for example, the April 2026 cumulative update KB5083769 hit 0x800f081f on a meaningful subset of Windows 11 PCs. In this case, the error indicates that the component store can’t find baseline source files needed to apply the update.

Less commonly, the error appears when enabling other optional features (Hyper-V, Windows Subsystem for Linux components, or specific server roles). The fix in those cases follows the .NET 3.5 path.

Common causes

Scenario	Most likely cause
Enabling .NET Framework 3.5 on a fresh install	Source files not cached locally; no internet path to Microsoft Update
Enabling .NET Framework 3.5 on a managed enterprise device	Group Policy directing component repair to a WSUS server that doesn’t host optional features
Installing a cumulative update	Servicing-stack corruption; missing component-store baseline
Manual `.msu` install fails with this code	Same as cumulative — the component store needs repair
Server-side failures during role install	Source files removed from the install image; need to point to a valid source

Fixes to try first

The right fix depends entirely on which scenario you’re in. Identify your scenario before running any commands.

Scenario 1 — You’re trying to enable .NET Framework 3.5

This is the .NET 3.5 case. The fix is to point the installer at a local source.

Get a Windows ISO matching your version. Open Settings → System → About and note your Edition (e.g., Windows 11 Pro) and Version (e.g., 24H2). Download the matching ISO from Microsoft’s Windows download page.
Mount the ISO. Right-click the downloaded .iso file and select Mount. Note the drive letter assigned (often D: or E:).
Run DISM with a local source. Open Command Prompt as administrator and run:
```
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /Source:E:\sources\sxs /LimitAccess
```
Replace E: with the actual drive letter of your mounted ISO. The /LimitAccess flag prevents DISM from trying to also reach Microsoft Update — without it, the same network failure that caused the original error will cause this command to fail too.
Verify .NET 3.5 is now enabled. Press Win+R, type optionalfeatures, press Enter, and confirm the .NET Framework 3.5 (includes .NET 2.0 and 3.0) checkbox is ticked.

If the DISM command itself fails with a different error, the underlying component store is corrupted — see the Advanced fixes section.

Scenario 2 — You’re trying to install a cumulative or security update

This is the harder case. There’s no equivalent “point at a local source” trick — Windows Update is already trying to download the source files it needs, and it’s failing.

Run the Windows Update troubleshooter. Settings → System → Troubleshoot → Other troubleshooters → Windows Update → Run. Allow it to apply fixes. Retry the update.
Check disk space. Windows Update needs around 8 GB of free space on the system drive to stage a cumulative update. Confirm you have at least that.
Try a manual install from the Microsoft Update Catalog. Note the failed KB number from Update History. Search for it at catalog.update.microsoft.com. Download the version matching your Windows architecture and build. Run the .msu file.
If the manual install also fails with 0x800f081f, your component store needs repair. Continue to the Advanced fixes.

Advanced fixes

These are heavier interventions. Run them deliberately.

Run DISM /RestoreHealth

For the cumulative-update variant, this is the canonical first step. From an elevated Command Prompt:

DISM /Online /Cleanup-Image /CheckHealth
DISM /Online /Cleanup-Image /ScanHealth
DISM /Online /Cleanup-Image /RestoreHealth
sfc /scannow

/RestoreHealth will pull replacement files from Microsoft Update. Allow 15–45 minutes. If RestoreHealth itself errors out, point it at a local Windows ISO instead:

DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:E:\sources\install.wim:1 /LimitAccess

Replace E: with your mounted ISO’s drive letter. Note the :1 at the end — this is the index of the Windows edition in the WIM file. Most ISOs have multiple editions; index 1 is usually Home, index 5 or 6 is usually Pro. Use DISM /Get-WimInfo /WimFile:E:\sources\install.wim to see the list.

For more on running these commands safely, see How to run DISM and SFC safely.

Reset Windows Update components

If DISM and SFC complete cleanly but the update still fails, the next step is a full reset. Walk through How to reset Windows Update components carefully — for 0x800f081f specifically, the catroot2 reset (which is part of that procedure) is often the step that resolves it.

In-place repair install

If everything above fails — particularly for the cumulative-update variant — an in-place repair install is the supported fix. Microsoft engineers in their own Q&A platform (April 2026, KB5083769 thread) recommend this as the next step when the standalone .msu also fails.

To do an in-place repair install:

Mount the same Windows ISO you used above.
Run setup.exe from the mounted ISO.
When prompted, choose Keep personal files and apps.
Allow the installer to complete. This takes 60–90 minutes on most hardware.
After the system restarts, retry Windows Update.

The repair install replaces the entire Windows component store while preserving your installed applications, data, and most settings. It’s a heavy procedure but it’s also the procedure that resolves the long tail of 0x800f081f failures the lighter fixes can’t reach.

Group Policy fix (managed environments only)

If you’re on a domain-joined or Intune-managed device and you control Group Policy:

Open gpedit.msc.
Navigate to Computer Configuration → Administrative Templates → System.
Open Specify settings for optional component installation and component repair.
Set it to Enabled.
Tick Download repair content and optional features directly from Windows Update instead of Windows Server Update Services (WSUS).
Click Apply, OK.
From an elevated Command Prompt, run gpupdate /force.
Retry the feature installation or update.

This bypasses a misconfigured WSUS that doesn’t host optional component payloads — a common cause of 0x800f081f for .NET 3.5 in enterprise environments.

If you are on a work or school device

Don’t enable optional features, don’t run DISM, and don’t change Group Policy on a managed device without your administrator’s involvement. If you’re seeing 0x800f081f while trying to install software that requires .NET 3.5, the right action is to:

Note the application that needs .NET 3.5.
Send the request to your IT administrator.
Wait. There may already be a packaged installer that handles the dependency, or there may be a policy reason .NET 3.5 isn’t approved.

For small-business administrators with no separate IT to escalate to, our admin checklist for new M365 sign-in failures covers the equivalent admin-side workflow.

When to stop

Stop and consider an in-place repair install or a clean reinstall when:

You’ve tried the right scenario fix, DISM/SFC, and a Windows Update components reset, and the error still persists.
DISM /RestoreHealth consistently fails — even when pointed at a local ISO. That signals a deep component-store corruption that escalation won’t fix incrementally.
The same code keeps returning across multiple updates and feature enables. Whatever’s broken in the component store is broken at a level individual fixes can’t reach.
The PC is showing other signs of OS-level problems (apps crashing, files vanishing, Windows Defender disabled by something other than you). Address those first.
You’re on a work device. Stop earlier — escalate to IT.

Windows Update error 0x80070643 — generic install failure, related but distinct from the source-missing error.
Windows Update error 0x80070002 — file-not-found error in the update path.
Windows Update stuck at 0%, 33% or 100% — symptom-led companion piece.
How to reset Windows Update components — the canonical reset procedure.
How to run DISM and SFC safely — the system file repair guide.

Official references

Microsoft Learn: .NET Framework 3.5 installation errors
Microsoft Learn: DISM Operating System Package servicing
Microsoft Update Catalog: catalog.update.microsoft.com
Windows ISO downloads: Microsoft’s Windows download page

FAQ

Why are there two completely different fixes for the same error code? Because 0x800f081f is reported by the Component-Based Servicing engine, which handles both feature installation and update installation. The mechanic is the same in both cases — Windows can’t find source files — but the source it can’t find is different. The .NET 3.5 fix tells Windows where to find the feature payload. The cumulative-update fix repairs the component store baseline that updates need to apply against.

Can I just download .NET Framework 3.5 from Microsoft’s website and install it? .NET Framework 3.5 is part of Windows itself; it’s not a standalone download you can install. The “download .NET 3.5” links you’ll find online lead to standalone installers for newer .NET versions or to the .NET 3.5 redistributable, which is meant for offline deployment scenarios and won’t help here. Use the DISM-with-local-source method above.

The DISM /RestoreHealth command itself errors out. What now? Point it at a local source instead, using the WIM syntax shown in the Advanced fixes section. If that also fails, the next step is an in-place repair install — the component store is corrupted at a level DISM can’t reach with online repair.

Can a malware infection cause this error? Indirectly, yes. Malware that has tampered with system files can corrupt the component store and cause 0x800f081f to surface during updates. Run a Microsoft Defender full scan if you have any reason to suspect infection. Don’t, however, treat 0x800f081f itself as a malware indicator — most cases have nothing to do with malware.

Will Windows Update eventually fix this on its own? For the cumulative-update variant, sometimes yes — Microsoft occasionally releases a refreshed version of a problematic update that handles the prerequisite differently. For the .NET 3.5 variant, no — Windows Update will keep failing on the same fetch, indefinitely, until you intervene.

↑ Back to top