Fix Error 0x800f081f During Windows 11 Update Using DISM 

Dism /Online /Enable-Feature /FeatureName:NetFx3 /All /Source:D:\sources\sxs /LimitAccess

That single line, run from an elevated Command Prompt with a mounted Windows 11 ISO as drive D:, resolves the large majority of 0x800f081f cases I've run into. It tells DISM exactly where to find the files it's failing to locate on its own, instead of letting it keep trying (and failing) to reach Windows Update for them. The rest of this article is about confirming that's actually your situation, getting the command right when it isn't as simple as swapping a drive letter, and what to do if it still doesn't work.

What the error means

0x800f081f is CBS_E_SOURCE_MISSING — "the source files could not be found." It shows up in three overlapping contexts: enabling .NET Framework 3.5 through Windows Features, running DISM /Online /Cleanup-Image /RestoreHealth, and occasionally during a Windows Update install that depends on one of those underlying operations. In every case it means the same thing — DISM went looking for the payload files it needs (not metadata, the actual binaries) and couldn't find them in any location it checked.

This matters because .NET Framework 3.5 in Windows 10 and 11 is a "Feature on Demand." The feature's metadata ships with Windows, but the files themselves don't — enabling it triggers a download from Windows Update, or a copy from installation media if you point it there. If that download can't complete — blocked network path, restrictive Group Policy, a WSUS server that doesn't host optional content — you get 0x800f081f instead of a working feature.

Confirm the cause before you download an ISO

  • Open C:\Windows\Logs\DISM\dism.log and check the last entries around your failed attempt. A source-missing failure logs clearly as such.
  • If you're on a managed network, check whether Group Policy has "Specify settings for optional component installation and component repair" configured — and specifically whether "Download repair content from Windows Update" is left unchecked. If it's unconfigured or disabled and there's no local source available, this is your cause, full stop.
  • If you're on an unmanaged home PC with a normal internet connection and this still fails, the more likely cause is a version mismatch between what DISM expects and what it's being offered — which the ISO method below also fixes, but for a different underlying reason.

Do this first: Group Policy check (if you're on a managed network)

If a Group Policy is blocking Windows Update as a source, fixing the policy is less invasive than mounting an ISO and often the actual root cause in a domain environment:

  1. Run gpedit.msc and navigate to Computer Configuration > Administrative Templates > System.
  2. Open "Specify settings for optional component installation and component repair."
  3. Set it to Enabled and check "Download repair content and features directly from Windows Update instead of Windows Server Update Services (WSUS)" if that option applies to your environment.
  4. Retry enabling the feature.

If this isn't your environment — you're not domain-joined, or you've confirmed the policy already allows it — skip straight to the DISM command with a local source.

The DISM fix, done right

Get an ISO that matches your installed Windows version. This is the detail that trips people up: a mismatched build (say, mounting a 23H2 ISO on a 25H2 system) will often still throw 0x800f081f even though you've technically "provided a source," because the source doesn't contain a compatible version of the files DISM wants.

Dism /Online /Enable-Feature /FeatureName:NetFx3 /All /Source:D:\sources\sxs /LimitAccess

Swap D: for whatever drive letter your mounted ISO actually got assigned — check File Explorer, don't assume. /LimitAccess tells DISM not to bother contacting Windows Update at all once you've given it a source, which speeds things up and avoids a redundant failed network attempt.

If you're instead trying to fix a general DISM /Online /Cleanup-Image /RestoreHealth failure rather than specifically .NET 3.5, the same principle applies with a different target path:

DISM /Online /Cleanup-Image /RestoreHealth /Source:D:\sources\install.wim /LimitAccess

One gotcha worth knowing before you spend an hour confused: if your ISO's install file is install.esd rather than install.wim, this command will not work as written and will fail again with the same error, regardless of how you phrase the source path. ESD is a compressed, encrypted format DISM can't use directly as a repair source. You have to convert it to WIM first (several free tools do this, or DISM itself can with the right export syntax) before pointing RestoreHealth at it. Skipping this step is the single most common reason people report that "the ISO method didn't work" when it actually would have, with the right file format.

What I would not do

  • Don't run RestoreHealth repeatedly against Windows Update as the source once it's already failed once for this specific error — if the online source were reachable and compatible, it wouldn't have thrown a source-missing error in the first place. Repeating it just burns time.
  • Don't grab a random ISO off a third-party download site to "save time" versus getting one from Microsoft directly. A tampered or mismatched image is a bigger risk than the ten minutes it takes to download the real one, and a subtly wrong build is exactly what causes this error to persist after you thought you'd fixed it.
  • Don't disable your antivirus as a troubleshooting step here unless you have a specific reason to suspect it — 0x800f081f is a source-location problem, not a blocked-execution problem, and antivirus interference isn't a documented cause for this particular code.

If the command still fails after all that

Run sfc /scannow after a successful DISM RestoreHealth, in that order, not before — DISM repairs the image SFC checks against, so running SFC first against a broken image can produce confusing false negatives. If DISM with a correct, matching, WIM-format source still throws 0x800f081f, the installation itself may have deeper corruption beyond what a source file can patch, and a repair install (Settings > System > Recovery > Fix problems using Windows Update, or an in-place upgrade from the same matching ISO) is the next reasonable step rather than continuing to vary DISM's syntax.

Where to go from here

Once .NET Framework 3.5 or your component store is repaired, it's worth checking Windows Update history for the specific update that originally triggered this — if it was a cumulative update rather than a manual .NET installation attempt, retry that update now that the source dependency is resolved, rather than assuming the DISM fix alone completes the original task.

← Newer Posts Older Posts →