Error 0x800f081f: Fix DISM Source Files Not Found

Logeshwaran.C

Error 0x800f081f means DISM or Windows Update went looking for the exact files it needs to repair or install a component, and came up empty — it isn't proof your system is corrupted, just proof the repair source is missing or unreachable. The real fix is handing DISM a matching install.wim or install.esd from official Windows media using the /Source option. Here's the part almost nobody tells you: the /LimitAccess switch that shows up in almost every copy-pasted fix command is the one thing that guarantees the error comes back, because it turns off the one source that was actually working — Windows Update — without giving DISM a real replacement.

⚡ Quick Answer

Try this first → Run DISM /Online /Cleanup-Image /RestoreHealth with no /Source and no /LimitAccess — let it use Windows Update.

If that fails → Mount a matching Windows ISO and run DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:1 /LimitAccess, matching the index to your edition. See the full ISO steps.

Getting the error again after that? The cause is almost always a mismatched ISO, a wrong index, or /LimitAccess used without a valid source — see the /LimitAccess trap and why DISM still fails.

What Error 0x800f081f Actually Means

You'll see this error in three places that all point back to the same root cause: a failed Windows Update install, a DISM /RestoreHealth command, or an attempt to turn on an optional Windows feature. In every case, the text underneath the code is the same: "The source files could not be found. Use the 'Source' option to specify the location of the files that are required to restore the feature." The DISM log confirms it at C:\Windows\Logs\DISM\dism.log, and the deeper record of what was actually missing sits in C:\Windows\Logs\CBS\CBS.log, where CBS stands for Component-Based Servicing — the subsystem underneath DISM and Windows Update that actually swaps files in and out of your system.

Two different things can trigger it. The first is real component-store damage: a file DISM needs to replace has gone missing or doesn't match what the servicing stack expects. The second — and the more common one — is that the file isn't damaged at all, it's just not being offered from anywhere DISM is allowed to look. Windows Update is the default place DISM looks for repair files, and if you don't specify a source at all, that's exactly what it falls back to. If that connection is blocked, if a Group Policy setting has redirected it elsewhere, or if you've told DISM (deliberately or by copying a command) not to use Windows Update, you get exactly this error even on a perfectly healthy machine.

The One Question That Tells You Which Fix You Need

Jake had a laptop on the bench that a customer needed back by Saturday afternoon — a quick "just install the pending updates before I give it back" job that turned into three hours of the same failed install, over and over, with 0x800f081f at the end every time. He'd promised it free of charge because it had seemed so simple. That's the trap: the error looks identical everywhere it appears, but the fix depends entirely on where you're seeing it.

Before you run anything, answer one question: where did the error show up? If it was during a normal Windows Update install (a quality update or feature update that failed and rolled back), skip to letting DISM use Windows Update again. If you were already running DISM /RestoreHealth on purpose — usually because SFC found problems it couldn't fix on its own — you're already in repair territory and should go straight to the ISO method. If it happened while turning on a feature like .NET Framework 3.5 through "Turn Windows features on or off," the fix is different again and lives in its own section further down.

🙋‍♂️ Jake's Reality Check

"I've already run that DISM command four times. Why would running it a fifth time do anything different?"

It won't. If the command failed with 0x800f081f once, it will fail the same way every time you repeat it unchanged. DISM isn't randomly missing the file — it's consistently not being given a place to find it. Repeating the command is the single most common way people waste an afternoon on this error.

Start Cheap: Let DISM Use Windows Update as the Source

Windows Update is the default repair source. Unless something has changed that on purpose, DISM will try to pull the files it needs from there automatically — no /Source, no /LimitAccess, nothing extra. Open an elevated command prompt or PowerShell window and run it plain:

DISM /Online /Cleanup-Image /RestoreHealth

Let it sit even if the percentage counter looks frozen — that's normal while it's negotiating with Windows Update. If it finishes without the error, follow it with sfc /scannow and a restart, then retry whatever update or feature install triggered the original problem. If it still ends in 0x800f081f, that's your signal Windows Update either can't be reached for repair files or a policy is pointing it somewhere else — move on to the ISO method below rather than repeating this command a second or third time.

It's also worth running the built-in troubleshooter alongside this, since it checks a few things DISM doesn't — corrupted update cache folders, stuck services, and clock drift that can silently break the handshake with Windows Update's servers. It won't fix a missing-source DISM error by itself, but it clears out the noise so you know DISM is the actual problem, not something upstream of it.

✅ Why this is the one to try first

It costs nothing, changes nothing on the system, and it's the option Microsoft's own repair-source documentation treats as the baseline — the ISO method exists specifically for when this one is blocked or unavailable, not as a substitute for it.

Give DISM a Real Source: The ISO Method

This is the method for a machine that's offline, on a managed network where Windows Update is blocked for repairs, or one that's already failed the plain command above. You need installation media that matches your edition, and ideally a build close to what you're running.

  1. Download the matching Windows ISO from Microsoft's software-download page for your version (Windows 11 or Windows 10), choosing the edition and architecture that matches your PC.
  2. Right-click the downloaded .iso file and choose Mount. Windows assigns it a drive letter — check File Explorer to see which one (this guide uses D: as the example).
  3. Open the mounted drive's sources folder. You'll find either install.wim or install.esd — which one you have depends on how the ISO was built, and the command below only changes by that filename.
  4. Open an elevated command prompt and run: DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:D:\sources\install.wim:1 /LimitAccess — replacing the drive letter with yours, and the index number (the ":1" at the end) with the one matching your edition.
  5. If you're not sure which index is your edition, run Get-WindowsImage -ImagePath D:\sources\install.wim in PowerShell first — it lists every edition in the file with its index number so you're not guessing.
  6. When it finishes without error, run sfc /scannow, restart, then retry the update that originally failed.

Two conditions matter more than people expect. First, the source has to be close in version to your current install — mixing a much older ISO with a heavily patched system means the files DISM finds won't match what your Component Store is asking for, and you'll fail again a few percent further along than before. Second, only use full retail or volume-license media for this — media that's been trimmed down (some "lite" or refreshed builds strip files out deliberately) is missing exactly the files a repair source needs to contain.

You can also point /Source at more than one location in the same command if you have several candidate sources — a mounted ISO, a network share, a copied install.wim on a USB drive. DISM will use whichever location it finds the required file in first and simply ignore the rest, so listing extras doesn't hurt, but it also won't help if none of them actually contain the missing file.

The /LimitAccess Mistake Almost Everyone Copies

Here's the reveal from the top of this post, in full. /LimitAccess does exactly one thing: it stops DISM from contacting Windows Update while it searches for repair files. That's useful and correct when you're also giving it a valid /Source — it just means "don't bother checking online, I've given you what you need locally." The mistake is pasting a command that includes /LimitAccess but skips a working /Source, or points at a source that turns out not to have the file DISM actually needs. At that point you haven't given DISM an alternative — you've just removed its only working option.

⚠️ What this actually breaks

Running /LimitAccess with no /Source, or with a /Source path that's mistyped, doesn't just fail — it fails in a way that looks identical to real corruption, and it's the exact scenario behind most "I tried everything and nothing works" reports. If you're not certain your source path is correct, drop /LimitAccess and let DISM fall back to Windows Update instead of guessing.

Ethan's flat about it when Jake asked why the fourth attempt failed the same way as the first three: "It's the switch that ruins more repairs than the corruption ever did. Every tutorial online treats it as part of the command instead of an option you add once you know your source is good."

Fixing It on Windows 11

The DISM and SFC commands above are identical on Windows 11 — this is one of the places where the steps really are the same on both versions. What changes is where you find the built-in troubleshooter: Settings > System > Troubleshoot > Other troubleshooters, then Run next to Windows Update.

Windows 11's condensed right-click menu doesn't affect any of this since everything here runs from an elevated terminal, not File Explorer — but if you go looking for the mounted ISO drive afterward to eject it and only see icon buttons when you right-click, the option sits under Show more options, not on the shortened top-level menu.

If the failure started right after a specific cumulative update, it's worth checking whether that update's own known-issues list mentions servicing problems before you assume the fault is local to your machine — our rundown of the August 2026 update covers what changed in the most recent servicing stack, which is exactly the kind of thing that can shift what a repair source needs to contain.

Fixing It on Windows 10

Same DISM and SFC commands, same ISO method — the underlying servicing stack works the same way. The troubleshooter lives at Settings > Update & Security > Troubleshoot > Additional troubleshooters, then Windows Update, instead of under System.

One honest thing worth saying plainly: Windows 10 reached the end of free security support on October 14, 2025. It still runs, still activates, and DISM still works exactly as described here — none of that changes. But if you're chasing this error because a security update keeps failing and the machine isn't enrolled in Extended Security Updates, you may be fighting to install something that no longer arrives for that device. Consumer ESU enrollment is still open through Settings > Windows Update, and coverage currently runs into October 2027 for enrolled devices — worth checking before you spend more time on a repair for an update that was never going to land.

Windows Server 2022 (and 2019): What's Different

Same error, same DISM commands, same /Source syntax — the difference on Server editions is mostly about how you get there and what's watching in the background. Server builds are more often managed by Group Policy that redirects the repair source to an internal network share instead of Windows Update, especially in domain environments. If your organization uses that setup, the network path is already the "correct" source and pointing DISM at a public ISO instead can actually make things worse by mixing sources with different patch levels.

Check with whoever manages Group Policy before improvising on a production server — the setting lives under Computer Configuration > Administrative Templates > System > "Specify settings for optional component installation and component repair," and it's not something you should override on a single machine without knowing why it was set that way in the first place.

Server Manager doesn't have a Windows Update troubleshooter the way desktop Settings does, so the elevated-terminal DISM route is usually the fastest path on Server, not a fallback you reach for after other options fail.

When It's Not Windows Update: Enabling .NET Framework 3.5

A lot of people land on 0x800f081f without touching Windows Update at all — they were turning on .NET Framework 3.5 for an older program through "Turn Windows features on or off," and it's not there because it's an optional feature that isn't installed by default and has to be fetched, either from Windows Update or from installation media, the same way any other optional component does.

  1. Mount your Windows ISO as above and note the drive letter.
  2. Open an elevated command prompt and run: DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /Source:D:\sources\sxs /LimitAccess — pointing at the sxs folder inside sources, not the install.wim directly.
  3. Restart if prompted, then check "Turn Windows features on or off" to confirm .NET Framework 3.5 shows as enabled.

Because this is a different kind of source (a folder of loose cab files rather than a WIM index), the earlier warning about matching the source's edition to your PC's edition still applies, but the index-number step doesn't — the sxs folder isn't split by edition, so there's nothing to select there. The /All flag matters here too: it tells DISM to enable any parent features NetFx3 depends on at the same time, so you don't end up needing a second pass.

Why DISM Still Fails After You Point It at a Correct ISO

This is the part that costs people the most time, and it's worth naming each symptom separately instead of treating "still fails" as one problem.

What you see Likely cause What to check
Same error, same percentage every time Source path never reached DISM — typo, wrong drive letter, or the ISO didn't mount Re-check the drive letter in File Explorer before re-running the command
Fails further along than before, different percentage Source is real but doesn't match — wrong index, older build, wrong edition List indexes with Get-WindowsImage; use a build closer to your current one
"Invalid hash" or similar file-mismatch message Source patch level doesn't match your system's patch level Use media patched to your current cumulative update level, not an older ISO
DISM completes but the original update still fails afterward Component store repaired, but the update itself has a separate problem Treat the update failure as its own issue — the source problem is resolved

Two more things worth knowing before you keep experimenting. If you list more than one /Source path in the same command, DISM uses only the first one where it finds what it needs and ignores the rest — it isn't combining files from several locations into one repair. And if a DISM operation gets interrupted partway through — a forced shutdown, a crash, closing the terminal window mid-run — it can leave a mounted image behind in a corrupted state that then blocks later attempts with unrelated-looking errors. DISM /Cleanup-Mountpoints exists specifically to clear that stuck state out before you try again — it deletes the leftover resources tied to a corrupted mount without touching your actual Windows installation.

When Nothing Above Works

If you've tried the plain command, a correctly matched ISO with the right index, and you're still getting 0x800f081f, say this plainly to yourself: no combination of DISM commands or source files is going to fix damage that goes deeper than a missing file. Sometimes the underlying servicing metadata itself is inconsistent in a way that these matched-version sources simply can't supply. That's not a moral failing on your part and it's not a sign you did the steps wrong. It's the point where an in-place upgrade repair — reinstalling Windows over itself while keeping your files and apps — is the honest next move, not a last resort to feel bad about reaching for.

  1. Back up anything irreplaceable first, even though an in-place upgrade is designed to keep your files and apps in place.
  2. Download the Media Creation Tool or ISO for your current version and run setup.exe from inside Windows rather than booting from USB.
  3. Choose "Keep personal files and apps" when prompted.
  4. Let it run to completion and retry the original update or feature install afterward.

If an in-place upgrade repair also fails, that's a different and more serious problem than 0x800f081f, and it's worth treating it as one rather than continuing to search for a source-file fix that was never going to reach it. At that point, the honest answer is that you're past what a repair source can solve, whatever it is.

Six Fixes, Ranked from Cheapest to Most Drastic

Method Works on Home edition? Use it when
Windows Update troubleshooter Yes First thing to try, costs nothing
Plain DISM /RestoreHealth (no Source) Yes Machine is online and Windows Update itself isn't blocked
DISM with ISO /Source + /LimitAccess Yes Offline machine, or plain DISM already failed
sfc /scannow after DISM Yes Always, right after a successful DISM run
Reset Windows Update components (SoftwareDistribution) Yes Update history shows repeated download failures, not just this one code
In-place upgrade repair Yes Everything above has been tried with a genuinely matched source and still fails

For IT admins: the same error at fleet scale

On domain-joined machines, 0x800f081f is very often not a broken machine at all — it is the repair source being redirected. WSUS and Windows Update for Business clients cannot fetch on-demand repair content from Microsoft unless policy allows it: the Group Policy Specify settings for optional component installation and component repair (Computer Configuration → Administrative Templates → System) is the switch — either point Alternate source file path at a maintained network share of the current build’s \sources\sxs, or tick "Download repair content and optional features directly from Windows Update instead of WSUS," and the error disappears fleet-wide without touching a single ISO. Keep one share per build and update it when the servicing baseline moves — a stale share reproduces this error with extra steps. For imaging pipelines, running DISM /Cleanup-Image /RestoreHealth against the mounted image during servicing catches store corruption before deployment, which is cheaper than catching it on 400 laptops afterward.

Frequently Asked Questions

What is error 0x800f081f?

It's a Windows servicing error meaning DISM or Windows Update couldn't find the source files it needs to install or repair a component. It doesn't by itself mean anything is broken beyond repair — it means the repair source wasn't reachable or didn't contain the right files.

Why does DISM say "source files could not be found" even after I mount the ISO?

Usually one of three things: the drive letter in your command doesn't match where the ISO actually mounted, the index number points to the wrong edition inside install.wim, or the ISO's build is far enough from your current patch level that the files don't match.

Should I use /LimitAccess or not?

Only add it once you've confirmed your /Source path is correct and actually contains the files. Used alone, or with a bad path, it removes DISM's working fallback (Windows Update) without replacing it, which reproduces the same error.

What's the difference between install.wim and install.esd?

They're both Windows image containers with the same purpose; the command only changes by filename — swap "wim" for "esd" in the /Source prefix depending on which one your specific ISO includes in its sources folder.

How do I find the right index number in install.wim?

Run Get-WindowsImage -ImagePath followed by the full path to install.wim in PowerShell. It lists every edition contained in the file along with its index number, so you can match it to your installed edition instead of guessing.

Does this error mean my Windows installation is corrupted beyond repair?

Not usually. Most cases are a missing or unreachable source, not damage. Genuine, unfixable component-store damage is possible but far less common than a source-path problem, and it's the last thing to suspect, not the first.

Is 0x800f081f the same on Windows 10 and Windows 11?

Yes — the error code, the DISM commands, and the underlying cause are identical on both. Only the location of the built-in troubleshooter in Settings differs between the two versions.

Why do I get this error only when installing .NET Framework 3.5?

.NET Framework 3.5 is an optional feature that has to be fetched from a source when you enable it, the same as any other on-demand component. If Windows Update can't supply it, you'll see 0x800f081f until you point DISM at the sxs folder on installation media.

Can I fix 0x800f081f without an ISO?

Yes, if the plain DISM command (no /Source) succeeds using Windows Update as the source. The ISO is only necessary when that route is blocked, whether by network policy, lack of internet access, or a Windows Update service that isn't functioning.

What causes 0x800f081f on Windows Server 2022?

The same causes as desktop Windows, but Group Policy redirecting the repair source to an internal network share is more common on Server. Check that policy before assuming a public ISO is the right source on a managed server.

I ran DISM /RestoreHealth /Source and it still fails at a different percentage — why?

A different failure percentage usually means the source was found and used up to a point, but didn't contain everything needed — often because the build doesn't match your current patch level closely enough, or the index selected doesn't fully match your edition.

Does sfc /scannow fix 0x800f081f, or do I need DISM first?

Run DISM first. SFC repairs individual protected files using your local component store as its source, but if that store itself is what's damaged, SFC can't fix it — DISM has to repair the store before SFC's repairs will hold.

Can antivirus or a VPN cause this error?

Anything that blocks DISM's connection to Windows Update can produce the same symptom as a genuinely missing file, since DISM can't tell the difference between "blocked" and "not there." If a plain DISM run fails on an otherwise healthy, online PC, it's worth temporarily checking whether third-party security software or a VPN is interfering before assuming corruption.

Will resetting Windows Update components (SoftwareDistribution folder) help?

It can, if the broader symptom is repeated download failures across multiple updates, not just this one servicing error. For an isolated 0x800f081f with everything else about Windows Update working normally, it's not usually the fix that matters.

Is it safe to use an ISO from a different Windows build than mine?

Only if it's close — ideally the same feature update version, fully patched. A much older or much newer ISO is one of the most common reasons the ISO method still fails after everything looks correctly set up.

When should I give up on DISM and do an in-place upgrade repair?

Once you've tried a plain DISM run and a correctly matched, correctly indexed ISO source and both still fail. At that point the problem is likely deeper than a missing file, and an in-place upgrade repair addresses that more directly than repeating the same DISM command with small variations.

Revision note. Written August 2026, covering Windows 11 (25H2/24H2), Windows 10 (post-EOL, with and without ESU), and Windows Server 2022/2019. This will need a refresh if Microsoft changes how DISM sources repair files by default or renames the relevant Group Policy setting in a future release. If you've been stuck on this error for a while, you're not doing anything wrong — the fix really is this specific, and you're closer to done than it feels.

Related