0x800f081f (Missing Payload): How to Point DISM to a Working Source

If you’re seeing error 0x800f081f with messages like “The source files could not be found” or “Missing payload” while running DISM or installing features such as .NET Framework 3.5, you’re dealing with a Windows servicing error, not a crash or BSOD. It typically appears when Windows can’t find the files it needs to repair the component store (WinSxS) or to add optional components. This guide goes beyond generic advice and shows you exactly how to point DISM to a working source, how to choose the right ISO or Features on Demand repository, and how to fix stubborn cases in both home and enterprise environments.

This walkthrough applies to Windows 10 and Windows 11 and uses natural variations like “DISM error 0x800f081f,” “CBS_E_SOURCE_MISSING,” “missing payload,” and “Windows Update error 0x800f081f” to help you find the most relevant content through search.

Understanding the Error

Technically, 0x800f081f maps to CBS_E_SOURCE_MISSING. In plain language: Windows tried to repair the component store or install a feature, but it couldn’t locate the required source files locally, on Windows Update, or on your organization’s update infrastructure (e.g., WSUS).

Typical triggers:

• Running DISM with /RestoreHealth without a valid source or with a mismatched source
• Installing .NET Framework 3.5 or other optional features without the payload locally available or accessible
• Using a corporate device configured to use WSUS where Features on Demand are not available
• Language/edition/build mismatches between your OS and the repair source
• Corrupt component store or incomplete Windows update history (SSU/LCU mismatches)

Quick Reference Table

Cause	Symptom	Recommended Fix
Missing or mismatched source (ISO/ESD/WIM)	DISM returns 0x800f081f “source files could not be found”	Mount a matching ISO, identify correct index, run DISM with /Source and /LimitAccess
WSUS blocks Features on Demand	.NET 3.5 install fails with 0x800f081f or 0x800f0954	Point to FoD ISO or enable “Contact Windows Update directly” in Group Policy
Language/edition mismatch	DISM runs but fails with source missing	Use an ISO matching your edition, language, architecture, and build; choose correct index
Component store inconsistency	SFC fails, DISM cannot restore	Install latest SSU/LCU, then run DISM with a correct source; consider in-place repair
Network/proxy constraints	Online repair fails even with internet	Use /LimitAccess with mounted ISO, or configure proxy exceptions for Windows Update
Old or N-Edition image used as source	DISM says source missing	Verify ISO build and edition; use DISM /Get-WimInfo to pick the exact index

Common Causes

• Wrong or incomplete source media
  • Using an ISO from a different build (e.g., 21H2 image for a 22H2 system)
  • Using install.esd without specifying ESD format (or not converting it)
  • Selecting the wrong image index (e.g., Pro source while your PC runs Home)
• Features on Demand not present
  • .NET Framework 3.5 and other FoD are not on the device or on WSUS; Windows Update access is blocked
• Servicing stack misalignment
  • Missing latest SSU/LCU for your version leads to inconsistent component store
• Language/edition/architecture mismatch
  • ISO/source doesn’t match system language pack, edition (Home/Pro/Enterprise), or architecture (x64/ARM64)
• Enterprise policy interference
  • Group Policy enforces WSUS without FoD, or doesn’t allow contacting Windows Update directly
• Network/proxy and security tools
  • Proxies or security software block DISM/WU content retrieval
• Disk corruption or file system issues
  • Underlying storage errors can cause payload fetching to fail

Preliminary Checks

Before doing deeper work, complete these quick safety and health checks.

• Boot to Safe Mode (optional if other software interferes)

  • Settings > System > Recovery > Advanced startup > Restart now > Troubleshoot > Advanced options > Startup Settings > Restart > Press 4 (Safe Mode)

• Back up important data

  • Copy key files to OneDrive or an external drive. Repairs are safe, but an in-place upgrade (last resort) still warrants a backup.

• Run basic health checks

  • Open an elevated Command Prompt or PowerShell (Run as administrator), then:

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

  • If SFC reports errors it cannot fix, you’ll rely on DISM with a proper source in the next sections.

Step-by-Step Troubleshooting

Follow these steps in order. The heart of fixing 0x800f081f is supplying DISM with a working, matching source.

1. Identify your OS version, edition, language, and architecture

• Press Win+R, type winver, note the Version and OS Build (e.g., 22H2, Build 19045.4568).
• Open Settings > System > About to confirm Edition (Home/Pro/Enterprise) and System type (x64/ARM64).
• Note your display language and any installed language packs (Settings > Time & Language > Language & region).

2. Install latest Servicing Stack Update (SSU) and Cumulative Update (LCU)

• Go to Settings > Windows Update and install all pending updates. This often resolves component store inconsistencies.
• If offline, download the latest SSU/LCU for your exact version from the Microsoft Update Catalog and install.

3. Mount a matching Windows ISO

• Download the ISO via Microsoft’s Media Creation Tool or from Volume Licensing Service Center if you’re in enterprise, ensuring the same Version/Build and Edition.
• Right-click the ISO > Mount. Note the new drive letter (e.g., X:).
• Check whether your source is WIM or ESD:
  • X:\sources\install.wim or X:\sources\install.esd

4. Find the correct image index in the ISO

• Use DISM to list images within the WIM/ESD:

  • If WIM:

    DISM /Get-WimInfo /WimFile:X:\sources\install.wim

  • If ESD:

    DISM /Get-WimInfo /WimFile:X:\sources\install.esd

• Identify the index that matches your installed edition (e.g., Windows 11 Pro might be Index 6; the exact number varies per ISO).

5. Run DISM with the correct source and index

• For install.wim:

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

  Replace INDEX with the number from step 4.

• For install.esd:

  DISM /Online /Cleanup-Image /RestoreHealth /Source:ESD:X:\sources\install.esd:INDEX /LimitAccess

• /LimitAccess ensures DISM uses only your source and not Windows Update.

6. Re-run SFC to finalize repairs

sfc /scannow

• Expect SFC to now repair remaining files using the restored component store.

7. Installing .NET Framework 3.5 (common 0x800f081f scenario)

• If your goal is enabling .NET 3.5, use the sxs folder from the mounted ISO or the Features on Demand ISO:

  DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:X:\sources\sxs

• If you still get 0x800f081f or 0x800f0954 in corporate networks, see the WSUS/Group Policy section below.

8. Configure Group Policy for alternate source (enterprise-friendly)

• Open gpedit.msc and navigate to:
  Computer Configuration > Administrative Templates > System > Specify settings for optional component installation and component repair
• Enable the policy and:
  • Specify an alternate source path (e.g., a network share with \sources\sxs or a local path).
  • Optionally check “Contact Windows Update directly to download repair content” if your org allows it.
• Apply the policy and try the DISM/feature installation again.

9. Use PowerShell equivalents if preferred

• Repair the image:

  Repair-WindowsImage -Online -RestoreHealth -Source “X:\sources\install.wim:INDEX” -LimitAccess

• Enable .NET 3.5:

  Enable-WindowsOptionalFeature -Online -FeatureName NetFx3 -All -LimitAccess -Source “X:\sources\sxs”

• Install a capability with source:

  Add-WindowsCapability -Online -Name “Language.Basic~~~en-US~0.0.1.0” -LimitAccess -Source “X:\”

10. If you only have an ESD and it won’t work

• Either point DISM to ESD using /Source:ESD as shown above, or convert ESD to WIM with DISM:

  DISM /Export-Image /SourceImageFile:X:\sources\install.esd /SourceIndex:INDEX /DestinationImageFile:C:\install.wim /Compress:max /CheckIntegrity

• Then use C:\install.wim in the /Source:WIM command.

11. Address language and edition mismatches

• If your Windows has additional language packs or is a different edition than the ISO, your source will still fail.
• Download an ISO that matches:
  • Windows edition (Home/Pro/Enterprise)
  • Architecture (x64 or ARM64)
  • Language (match installed language packs)
  • Build (e.g., 19045.x for Windows 10 22H2; 22621.x for Windows 11 22H2/23H2)

12. Reset Windows Update components (if online repair is desired)

• Run in an elevated Command Prompt:

  net stop wuauserv
  net stop bits
  net stop cryptsvc
  ren C:\Windows\SoftwareDistribution SoftwareDistribution.old
  ren C:\Windows\System32\catroot2 catroot2.old
  net start cryptsvc
  net start bits
  net start wuauserv

• Then retry DISM without /LimitAccess (or allow WU access via Group Policy).

13. Enterprise-only: Features on Demand ISO and WSUS

• Many orgs block Windows Update and do not mirror FoD content on WSUS. In this case, use the version-matched Features on Demand ISO.
• Mount it and use /Source pointing to the FoD media (e.g., \sources\sxs for .NET 3.5).
• Or stage FoD to a file share and set the alternate source path in Group Policy.

14. Persistent failures: perform an in-place repair upgrade

• Mount a matching Windows ISO and run setup.exe.

• Choose “Keep personal files and apps.”

• After the in-place upgrade, run:

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

• This method refreshes Windows while preserving your data and applications and fixes even deep servicing issues.

Log Analysis for Stubborn Cases (CBS/DISM)

Minidumps don’t apply to servicing errors. Instead, analyze servicing logs:

• CBS.log

  • Location: C:\Windows\Logs\CBS\CBS.log

  • Look for “CBS_E_SOURCE_MISSING” or “0x800f081f”

  • Example filter:

    findstr /i /c:”0x800f081f” C:\Windows\Logs\CBS\CBS.log

• DISM.log

  • Location: C:\Windows\Logs\DISM\DISM.log
  • Search for “Error” and source path issues

• WindowsUpdate.log (if online repair is attempted)

  • Generate: run PowerShell as admin:

    Get-WindowsUpdateLog

  • Open the generated WindowsUpdate.log on your Desktop to find policy/proxy/content errors

Use these logs to confirm whether the failure is due to source mismatch, policy, or network constraints.

Advanced Diagnostics

• Event Viewer

  • Open Event Viewer > Applications and Services Logs > Microsoft > Windows > Servicing
  • Also check WindowsUpdateClient operational log
  • Errors here often mirror CBS/DISM logging with clearer timestamps

• Servicing stack and packages

  • Enumerate installed packages:

    DISM /Online /Get-Packages /Format:Table

  • Check the version alignment of SSU/LCU to your OS build

• Verify edition and target image info

  • Confirm current edition:

    DISM /Online /Get-CurrentEdition

  • If you’re repairing an offline image, use /Image:C:\ instead of /Online across all commands

• Proxy/firewall considerations

  • If you want online repair, ensure Windows Update endpoints are allowed and bypass deep inspection for Windows Update content
  • If that’s not possible, stick with /LimitAccess and a mounted ISO/FoD source

Post-Fix Checklist

• Re-run health tools

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

• Test the original failing action

  • If you were adding .NET Framework 3.5, try again
  • If you were running DISM /RestoreHealth, confirm it reports no corruption

• Check Event Viewer and logs

  • Ensure Servicing and WindowsUpdateClient logs are clean of new critical errors

• Apply pending updates

  • Install the latest cumulative updates; then reboot

• Optional: Create a local FoD/source repository

  • Keep a copy of the correct ISO/FoD media accessible for future repairs

When to Seek Professional Help

• Repeated 0x800f081f failures even with a correct, matching ISO/Index and FoD media
• Evidence of storage issues (SMART alerts, CHKDSK errors), or recurring corruption after successful repairs
• Complex enterprise policy or WSUS/SCCM issues outside your admin scope
• You cannot determine the correct language/edition/build match for your environment
• You’ve tried an in-place repair upgrade and failures persist (possible hardware or low-level file system problems)

Prevention Tips

• Maintain a version-matched repository
  • Keep a current ISO and, for enterprises, the Features on Demand repository for your exact Windows build
• Configure Group Policy smartly
  • Set an alternate source path for optional components
  • Allow contacting Windows Update directly when appropriate to reduce failures
• Apply SSUs and LCUs promptly
  • Regularly update the Servicing Stack and cumulative updates to minimize store corruption
• Mind language and edition drift
  • Align installed language packs and editions with available sources
• Use SFC and DISM proactively
  • Periodically run sfc /scannow and DISM /ScanHealth, especially after major updates
• Protect the system state
  • Keep backups, use restore points, and avoid aggressive cleanup of WinSxS with unsupported tools
• Document your environment
  • Record OS build numbers, language packs, and source repositories for faster future recovery

Conclusion

Error 0x800f081f, also known as CBS_E_SOURCE_MISSING or “missing payload,” almost always comes down to Windows not having access to the correct source files. The fix is straightforward once you supply DISM with a working, matching source—typically a mounted ISO with the correct edition, language, and build—and specify it with /Source and /LimitAccess. For .NET 3.5 and other optional components, pointing to the FoD media or enabling direct Windows Update access via Group Policy resolves most issues. If all else fails, an in-place repair upgrade restores servicing health without sacrificing your files or apps.

You’ve got this—most 0x800f081f errors can be fixed in minutes once the right source is in place.

FAQ

What causes DISM error 0x800f081f “The source files could not be found”?

This happens when Windows cannot find compatible repair files for your exact OS version, edition, language, and architecture. Common reasons include using a mismatched ISO, lacking Features on Demand files (like .NET 3.5), WSUS policies blocking Windows Update, or component store inconsistencies.

How do I point DISM to a working source correctly?

Mount a matching Windows ISO, find the correct image index with DISM /Get-WimInfo, and run:
DISM /Online /Cleanup-Image /RestoreHealth /Source:WIM:X:\sources\install.wim:INDEX /LimitAccess
If the ISO has install.esd, use /Source:ESD:…:INDEX instead.

Can I use install.esd instead of install.wim?

Yes. Use /Source:ESD:X:\sources\install.esd:INDEX and /LimitAccess. If tools don’t accept ESD, export it to WIM:
DISM /Export-Image /SourceImageFile:X:\sources\install.esd /SourceIndex:INDEX /DestinationImageFile:C:\install.wim /Compress:max

Why does .NET Framework 3.5 fail with 0x800f081f or 0x800f0954 on corporate PCs?

Enterprises often use WSUS without mirroring Features on Demand. Configure Group Policy to specify an alternate source path (FoD media or a network share), or allow “Contact Windows Update directly.” Then run:
DISM /Online /Enable-Feature /FeatureName:NetFx3 /All /LimitAccess /Source:X:\sources\sxs

What if matching sources still don’t work?

Install the latest SSU/LCU, re-run SFC and DISM with the correct index, check CBS.log/DISM.log for “CBS_E_SOURCE_MISSING,” and ensure language/edition alignment. If the issue persists, perform an in-place repair upgrade from a matching ISO. If failures continue afterward, investigate hardware or storage issues and consider professional support.

Stay patient and methodical—supplying the right source and following these steps nearly always resolves 0x800f081f.