A cumulative update fails, or an optional feature refuses to turn on, and the error is 0x800f081f. Within a minute somebody has mounted an install.wim and started typing /Source:. That reflex is wrong a good share of the time, and the times it is wrong are the times it costs you an afternoon.
0x800f081f is CBS_E_SOURCE_MISSING — "The source files could not be found". Four different faults produce it: a Feature-on-Demand payload that was never on disk, a payload deliberately removed, a device pointed at WSUS (which Microsoft documents cannot serve FoDs at all), and genuine component-store corruption. Only the last one is a /RestoreHealth job. The CBS corruption summary separates them in about ten seconds, and CSI Payload Corruption is the line that does it. Then check build and UBR against your source, because Microsoft documents that a source at a lower patch level than the target fails by design.
The problem: DISM will not tell you which file it wanted
Here is the entire diagnostic value of the error as the tools present it. Microsoft publishes this string verbatim.
The guess is almost always "the store is broken, I need a source", and the action is mounting the nearest ISO. Three things then go wrong, in rising order of cost: the WIM is the wrong build and nothing is repaired; the fault was never corruption, so you spent an hour repairing a healthy store; or somebody escalates to /ResetBase and destroys the evidence and the rollback path while the original fault survives.
That second case deserves measuring. On the device used here, build 26200.9168, a read-only census returned this.
369 absent payloads on a machine with a provably clean store.
Why it happens: four faults, one error code
Microsoft documents this code two ways
First, the inconsistency that explains all the contradictory advice online. The Features on Demand error table calls 0x800F081F a source problem. The Windows Update common errors reference gives the same HRESULT the message "CBS_E_SOURCE_MISSING; source for package or file not found, ResolveSource() unsuccessful" and describes the cause as, flatly, "Component Store corruption".
One page says your source is wrong; another says your store is corrupt. Both are right, for different machines — which is exactly why this code is not a diagnosis. The useful thing in that row is the function name, ResolveSource(), worth grepping CBS.log for.
What the code actually means
Microsoft documents three conditions, and they read as three separate bugs.
| Documented condition | What it means on a real fleet |
|---|---|
| "The location that is specified by the path does not contain the files that are required to install the feature." | Right share, wrong contents — usually the wrong build, or a sources\sxs folder copied incompletely. |
| "The user who tries to install the feature does not have at least READ access to the location and to the files." | A permissions failure in a corruption costume. Common with UNC sources run in SYSTEM context from Intune or SCCM. |
| "The set of installation files is corrupted, incomplete, or invalid for the version of Windows that you are running." | The build/UBR mismatch case. The source is fine; it is not your Windows. |
None of the three is "your component store is corrupt". That is a fourth possibility the same code can surface, and it is the one everybody assumes first.
The source resolution order
This is the most useful documented fact in the topic. When servicing needs a payload it searches in a fixed order, stated identically on two Microsoft pages:
Read that as a fault tree. A 0x800f081f means all three tiers failed — so the question is never "what source should I give it" but "which tiers were reachable, and what did each refuse".
/Source, Microsoft documents that "the files are copied from the first location where they are found and the rest of the locations are ignored." A stale first path does not fall through to a good second one once a file has been located there. Ordering is load-bearing, and a half-populated first share beats a complete second share. Note also that Add-WindowsCapability takes its sources comma-separated while the policy value takes them semicolon-separated.Fault one: it was never there
The FoD case above: 369 capabilities, nothing wrong.
Fault two: something removed the payload
Microsoft's policy description names this case: the setting exists for "enabling optional features that have had their payload files removed". The documented route is feature removal, not cleanup. /Disable-Feature with /Remove takes the payload out but leaves the manifest; the feature "will be listed as Removed when you use /Get-FeatureInfo" and "can be restored and enabled using /Enable-Feature with the /Source option".
Now the part worth being careful about. It is widely repeated that DISM /Cleanup-Image deletes FoD payloads and thereby causes 0x800f081f. I went looking for that claim in Microsoft's documentation and could not find it on any official page. What is documented is narrower: /ResetBase "removes all superseded versions of every component in the component store", after which "all existing update packages can't be uninstalled after this command is completed, but this won't block the uninstallation of future update packages".
Superseded component versions are not FoD payloads. Treat "cleanup ate my payload" as an unproven folk explanation, and treat the documented cost of /ResetBase — losing rollback on everything currently installed — as reason enough not to run it while diagnosing. What the lab device can show is a measurement, not a cause.
Fault three: the device is pointed at WSUS
Not a misconfiguration — a documented platform limitation, and the most under-known fact here. From the Add-WindowsCapability reference:
A WSUS-managed device asking for an FoD is not broken; it is asking a server that was never able to answer. If optional features fail while cumulative updates install fine, stop reading logs — no amount of /RestoreHealth fixes a device asking the wrong server.
Fault four: genuine corruption
The only one of the four that /RestoreHealth fixes.
The policy and its registry backing
Tier 2 is driven by one setting: Computer Configuration → Administrative Templates → System → Specify settings for optional component installation and component repair, backed here:
| Value | Meaning | What to look for |
|---|---|---|
LocalSourcePath | REG_EXPAND_SZ, set by the "Alternate source file path" box. Multiple paths separated by semicolons; a WIM uses the wim: prefix plus image index. | Absent means tier 2 is empty and the device depends entirely on tier 3. Present means every path must resolve and grant read access to the calling identity. The ADMX caps the string at 1023 characters, so long lists truncate silently. |
CountryCode | Observed on the lab device (REG_SZ, GB). Not a source setting. | Ignore it. Changing it will not help. |
I verified that key path and value name against the ADMX Microsoft ships in the box rather than trusting a blog. On this device, C:\Windows\PolicyDefinitions\Servicing.admx declares exactly one element:
Servicing.admx on this Windows 11 build — the excerpt above is the whole file — and searching all of C:\Windows\PolicyDefinitions for the value names commonly quoted for them returned nothing. So do not conclude "the checkbox is not ticked" from a GPO editor that never showed it to you, and treat value names found on forums as unverified. I could not confirm them in an ADMX or in Microsoft's documentation.On the lab device the read is quick: the key exists, LocalSourcePath does not, and there is no WUServer value under the Windows Update policy key. Tier 2 empty, tier 3 open. That device repairs fine; a WSUS-managed sibling with the same empty tier 2 fails every time.
Separately, CBS keeps engine state under HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing. One documented value there is worth reading before you conclude anything about rollback: "to determine when the /ResetBase option was last run, check the LastResetBase_UTC registry entry". If present, somebody already spent your uninstall options. Absent on the lab device.
The binaries involved
Every path, size and version below was read off the live device. The servicing stack does not live in System32 — it lives in a versioned WinSxS component directory, and this device carries 14 of them, which is why people cannot find it.
| Binary | Where it actually lives | Role in a 0x800f081f |
|---|---|---|
CbsCore.dll3,659,248 bytes, 10.0.26100.9156 | C:\Windows\WinSxS\amd64_microsoft-windows-servicingstack_31bf3856ad364e35_10.0.26100.9156_none_HASH\ | The component-based servicing engine. It performs the three-tier resolution and returns CBS_E_SOURCE_MISSING. |
CbsMsg.dll75,256 bytes | Same servicing-stack folder | The CBS message-table resource. The human-readable error text comes from here, which is why the string is identical across tools. |
TiWorker.exe370,160 bytes | Same servicing-stack folder | The worker process hosting CBS. This is what pegs a core for twenty minutes before the error appears. |
wcp.dll4,543,984 bytes | Same servicing-stack folder | The Windows Component Platform — the CSI layer under CBS. The CSI Payload Corruption counter you are about to rely on comes from here. |
TrustedInstaller.exe275,928 bytes, 10.0.26100.7019 | C:\Windows\servicing\ | The Windows Modules Installer service binary. Stopped/Manual when idle is normal — a frequent false alarm. It starts on demand. |
DismCore.dll and dismapi.dllboth 10.0.26100.8457 | C:\Windows\System32\Dism\ and C:\Windows\System32\ | DISM's provider layer. Its version is lower than the servicing stack because DISM is a client of CBS, not the engine. |
Two logs matter. Microsoft's guidance points at %Windir%\logs\CBS and says to "open the last CBS.log, search for , error, and match with the timestamp"; the DISM default is %WINDIR%\Logs\Dism\dism.log. On the lab device those were 11.9 MB and 4.9 MB. The division of labour matters: dism.log records what DISM intended, CBS.log records what the engine did. A 0x800f081f was decided in CBS.log.
How to verify: name the package before the source
C:\Windows\SoftwareDistribution and running /StartComponentCleanup /ResetBase. Clearing SoftwareDistribution discards the downloaded payload and the history that would have told you whether the file ever arrived. /ResetBase removes all superseded component versions and, in Microsoft's words, "all existing update packages can't be uninstalled after this command is completed" — so you trade rollback on everything currently installed for nothing, because it does not address source resolution at all. Both are irreversible. Neither answers a single question below.The decision path
- Get the HRESULT and the package from the event log, not the dialog. The Setup log carries a per-package record with the status embedded — the identity DISM withheld.
- Decide corruption versus absence. Run a detect-only pass and read the CBS summary. Zero corruption plus a source error means the store is intact and the payload was never there. Not a repair job.
- Confirm the capability state.
NotPresentmeans absent by design: you need a source, not a repair. - Establish which tiers exist. Read
LocalSourcePath. Absent means tier 2 is empty. - Establish whether tier 3 can answer. Check for a WSUS policy and for
/LimitAccessin whatever script ran. WSUS-managed and asking for an FoD? Fault found, and it is a design limit rather than corruption. - Only now compare build and UBR against your candidate source. If they differ, stop.
- Verify read access as the executing identity. A UNC path that opens for you interactively may be invisible to
SYSTEM. - Pick the fix from the branch you landed on, not from habit.
Step 1: the Event ID catalog
These are the real event definitions from the Microsoft-Windows-Servicing provider manifest on the lab device, written to the Setup log. I enumerated the provider rather than transcribing a list, so the templates are exact.
| Event ID | Message template | What it tells you |
|---|---|---|
| 3 | Package %1 failed to be changed to the %2 state. Status: %4. | Start here. Package identity and HRESULT together — where you read 0x800f081f against a named package. |
| 5 | The servicing request received for package %1 cannot be satisfied since the package is not applicable. | The build-mismatch signature. The package is not wrong, it is not for this OS. Strongly suggests a source at the wrong patch level. |
| 6 | Package %1 failed to be changed to the %2 state and is now partially installed. Status: %4. | Worse than event 3 — a half-applied package. Do not stack another repair on this before reading CBS.log. |
| 15 | Selectable update %1 of package %2 was successfully turned off with its payload removed. | The receipt for fault two. Something deliberately removed a payload. If this predates your failure, you know why the file is gone. |
| 18 / 20 | START [Resolve]:[%1] / END [Resolve]:[%1] | The resolve phase, where source lookup happens. A 0x800f081f is a resolve-phase failure. No event 18 means nothing even tried. |
| 1013 | Initiating system store corruption detection and repair. Detection Only: %1, Automatically Triggered: %2. | A store scan started. Detection Only: 1 is read-only — what you want while diagnosing. |
| 1014 | System store corruption detection and repair has completed. Status: %1, Total instances of corruption found: %3, total instances of corruption repaired: %2. | The verdict. "found: 0" alongside a live 0x800f081f means your problem is source resolution. Stop planning a repair. |
| 1015 | %2 of %3 instances of system store corruption have been repaired. Unrepaired corruptions may lead to failures in future system servicing. | A partial repair. Genuine corruption remains, and Microsoft's own wording warns it will break later servicing. |
Step 2: the CBS summary that decides everything
A real, unedited detect-only summary from the lab device. Learn to find this block and you skip most of the guesswork.
Six counters, not interchangeable. Manifest and metadata corruption is damage to the store's bookkeeping; CSI Payload Corruption is damage to actual component files. A missing FoD payload shows up as none of the six, because nothing is damaged — the store is correctly recording that it does not have something.
Step 6: the build comparison people skip
Three different version numbers on one machine: running build 26200.9168, servicing stack 10.0.26100.9156, RTM media 26100.1. "The 24H2 ISO is close enough" is an assumption about all three at once.
/Source attempts I see are refresh media, the one option explicitly ruled out.The fix: match the source to the fault
Branch A: absent payload, store clean
Diagnosis: Total Detected Corruption: 0, capability NotPresent. Nothing to repair — supply the payload. Do not run /RestoreHealth; it will spend twenty minutes proving the store is fine.
Add-WindowsCapability exhausts every source tier, "the cmdlet fails silently; no exceptions are thrown." A try/catch catches nothing and your deployment script reports success while installing nothing. Assert the end state by re-reading with Get-WindowsCapability and failing on anything other than Installed. This is how fleets find out months late.dism /export-source. Also add language packs and FODs before installing updates: "if you add an update prior to adding language packs and FODs you'll have to reinstall the update."Branch B: policy or WSUS blocked the only tier that could answer
Two documented routes, and which applies depends on your build.
Route one: send clients to Windows Update for this content only. Microsoft's own recommendation for the WSUS case — "you can enforce a Group Policy setting that tells the clients to download them directly from Windows Update". Updates keep coming from WSUS, FoD payloads from Microsoft. Intended design, not a workaround.
Route two: populate tier 2 via LocalSourcePath. Semicolon-separated, wim: prefix plus index for a WIM — Microsoft's example is wim:\\server\share\install.wim:3. Mind the 1023-character cap. But check your build first, because Microsoft narrows this hard: "starting with Windows 10 version 1809, FOD and language packs can only be installed from Windows Update." On a current fleet a network share is not a supported source for FoDs, though it remains valid for component-store repair — exactly the distinction this article turns on.
SYSTEM and reaches a UNC path as the computer account, so grant that account read access or use a local path. Microsoft lists "does not have at least READ access" as one of only three documented causes of this error, so it earns a real test rather than a glance at the sharing dialog.Branch C: genuine corruption
Diagnosis: non-zero counters in the CBS summary. Now /RestoreHealth is the right tool, and only now does source choice matter the way everyone assumed at the start.
Proof it worked: a real clean servicing report
Do not accept "the operation completed successfully" as proof. Verify in three places, all read-only.
The store reports clean. The lab device shows the shape of a healthy result: Operation result: 0x0, Total Detected Corruption: 0, all six sub-counters zero, Total Operation Time: 242 seconds — long enough to have actually walked the store.
The event log agrees. Event 1014 with "found: 0" is the store's own verdict, independent of what DISM printed. If you repaired something you want found and repaired counts that match, and you do not want event 1015, which warns that unrepaired corruption "may lead to failures in future system servicing".
The original operation now succeeds. The only test that matters, and the one people skip because the repair felt like the goal.
That caution earns its own line: event 2 reporting the Staged state is a normal outcome, and the lab machine logged 240 of them. Staging means the payload arrived and unpacked, not that the package installed. The state named in the message is the state that was reached, so read it rather than skimming for "successfully".
If the capability is still NotPresent and event 3 still carries 0x800f081f, you were not defeated by corruption. Your source does not contain what you think it does — go back to the build comparison, because that is where this error usually ends.
References
- Windows Update common errors and mitigation — the official
0x800f081fentry, theResolveSource() unsuccessfulstring, the "Component Store corruption" description, and the instruction to search CBS.log for, error. - .NET Framework 3.5 installation errors — the
0x800F081F - CBS_E_SOURCE_MISSINGmapping, the verbatim error string, the three documented conditions, and the two checkbox names that no longer exist in the in-box ADMX. - .NET Framework 3.5 deployment errors and resolution steps — the FoD error-code table, and the rule that
/Sourcepoints at\sources\sxsor the Windows folder of a mounted image. - Features On Demand — the three-tier source search order,
/LimitAccesscovering Windows Update and WSUS, the repository-metadata warning, and the ISO-must-match rule. - Configure a Windows Repair Source — the four source types, the
Wim:prefix with index, the RTM-media rule, and the patch-level warning. - Repair a Windows Image —
/RestoreHealthwith/Sourceand/LimitAccess, and the first-match-wins rule for multiple sources. - Add-WindowsCapability (Dism) — comma-separated
-Source,-LimitAccess, the "fails silently; no exceptions are thrown" warning, and the WSUS/FoD limitation from 1709 and 1809. - Enable or Disable Windows Features Using DISM —
/Disable-Feature /Remove, the "Removed" state via/Get-FeatureInfo, and the client-versus-server payload retention difference. - DISM Operating System Package Servicing Command-Line Options — the full
/Cleanup-Imagesyntax and theLastResetBase_UTCregistry tip. - Clean Up the WinSxS Folder — what
/ResetBaseremoves, and the precise uninstall warning including the future-packages qualifier. - Policy CSP — ADMX_Servicing — the friendly policy name, the registry key, and the semicolon-separated multi-path behaviour.
Lab notes: every version, file size, registry state, event definition and log excerpt here was read read-only from one live Windows 11 Enterprise device, build 26200.9168, on 2026-08-23. Console blocks are reconstructions of that captured output, not screenshots. The device was healthy, so nothing here claims to show a real 0x800f081f on it — failure shapes come from Microsoft's documented error strings and event templates.