Windows Update install or uninstall fails because Windows Sandbox is enabled

Windows Sandbox is an optional Windows feature implemented through the component-servicing stack. In three retained Windows 11 cases, a particular update install or uninstall failed while Sandbox was enabled and succeeded after Sandbox was disabled or removed and Windows restarted. One case involved KB5058411 and 0x800F081F; one involved the removal of KB5063878 and 0x800F0825; a third involved a specific Windows 11 24H2 repair sequence around KB5049622 and KB5053598.

This is a narrow dependency/isolation writeup. 0x800F081F normally indicates missing servicing source content, and 0x800F0825 means a package cannot be uninstalled; neither code identifies Windows Sandbox by itself. The article applies only after Windows confirms the Sandbox feature is enabled and the same servicing action changes result when that feature is removed.

Searchable Windows codes, feature names, and updates

Use this procedure when:

• the computer runs an edition of Windows 11 that supports Windows Sandbox;
• Get-WindowsOptionalFeature or DISM reports Containers-DisposableClientVM as Enabled;
• the exact update install or uninstall fails repeatedly with the same result;
• the update is applicable to the installed release and architecture;
• the current Sandbox session has been closed and any needed files have been copied out; and
• no stronger cause has been demonstrated by CBS logs, component-store health, free-space checks, or update applicability.

The strongest match is one of the exact retained combinations: KB5058411 with 0x800F081F, KB5063878 removal with 0x800F0825, or the recorded Windows 11 24H2 KB5049622 then KB5053598 sequence after repair. A different update may be tested by the same reversible feature-isolation method, but its result is new evidence and should not inherit those KB-specific claims.

Do not use this procedure when Windows Sandbox is already disabled/not present, the computer runs an edition that does not support it, or the update fails in the same way after Sandbox is removed and Windows restarted.

It does not apply when 0x800F081F is already traced to missing repair-source files, when 0x800F0825 reflects a permanent/non-removable package, when the component store reports corruption, or when policy/virtualization management prohibits feature changes. Do not disable Hyper-V, Virtual Machine Platform, Windows Hypervisor Platform, WSL, Credential Guard, or virtualization in firmware merely to test this page; the retained action removed Windows Sandbox itself.

The precise internal package relationship between Sandbox and the failing update may remain unknown. A successful feature-off/update/feature-on sequence can establish a practical dependency without proving which servicing manifest was wrong.

The following may not remain unknown:

• Windows edition, release, build, and architecture;
• exact update KB and operation: install or uninstall;
• exact displayed HRESULT and failure phase;
• current state of Containers-DisposableClientVM;
• whether a restart is pending;
• whether Sandbox contains disposable work that must be copied out;
• whether the update remains applicable and, for removal, actually exposes a supported uninstall action; and
• for Branch C, the installed feature release and full build plus the selected media image index's feature-release build line and repair level.

• Administrator access
• Verified backup of important files
• Stable power
• A closed Windows Sandbox session; its internal state is disposable and will not survive feature removal
• Exact update identifier, error code, and failed-attempt time
• Enough free space for servicing and any repair install used by the specific branch
• For the repair branch, official Windows 11 media matching edition, default system UI language, architecture, and the same Windows feature release; the selected image index's build/repair level must not be older than the installed OS, and Setup must offer Keep personal files and apps

Create an evidence directory on the actual online Windows system drive. From an elevated PowerShell window, record feature and Windows state:

$evidence = Join-Path $env:SystemDrive 'UpdateEvidence\FIX-075'
New-Item -ItemType Directory -Path $evidence -Force | Out-Null

Get-WindowsOptionalFeature -Online -FeatureName Containers-DisposableClientVM |
  Format-List * | Out-File (Join-Path $evidence 'sandbox-before.txt')

Get-ComputerInfo -Property WindowsProductName,WindowsVersion,OsBuildNumber,OsArchitecture |
  Format-List | Out-File (Join-Path $evidence 'windows-before.txt')

$cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
[pscustomobject]@{
  DisplayVersion     = $cv.DisplayVersion
  CurrentBuildNumber = $cv.CurrentBuildNumber
  UBR                = $cv.UBR
  EditionID          = $cv.EditionID
  InstallationType   = $cv.InstallationType
} | Format-List | Out-File (Join-Path $evidence 'installed-release-build-before.txt')

dism /Online /Get-Intl |
  Out-File (Join-Path $evidence 'international-settings-before.txt')

Get-WinUserLanguageList | Format-List * |
  Out-File (Join-Path $evidence 'user-language-list-before.txt')

Copy %SystemRoot%\Logs\CBS\CBS.log after a failed attempt, when readable, to a timestamped file in the evidence folder. Do not edit or clear the live log.

Close Windows Sandbox. Copy out anything needed first; closing or removing Sandbox discards its internal files. Complete any already-requested Windows restart before testing. Do not begin during another feature, language-pack, .NET, cumulative-update, or repair-install transaction.

Open Settings > Windows Update > Update history and record the update's result. If the target is an uninstall, open Update history > Uninstall updates and confirm the exact KB exposes an uninstall control. A missing uninstall button is not permission to force package removal.

1. In an elevated PowerShell window, query Sandbox:

   Get-WindowsOptionalFeature -Online -FeatureName Containers-DisposableClientVM
   

   Continue only if State is Enabled. If the feature name is unknown or the state is disabled, stop.

2. Cross-check with DISM:

   dism /online /Get-FeatureInfo /FeatureName:Containers-DisposableClientVM
   

   The two tools must describe the same online Windows installation.

3. Record the exact update and HRESULT from Windows Update history or the uninstall result. Do not translate a percentage or “failed” label into a code that was not displayed.

4. Check servicing health without modifying it:

   dism /online /Cleanup-Image /CheckHealth
   chkdsk %SystemDrive%
   

   Stop if storage is unstable or DISM reports non-repairable corruption. Route repairable corruption deliberately rather than assuming Sandbox is the cause.

5. Confirm adequate free space and no pending restart. Restart once and repeat the exact servicing action no more than one additional time with Sandbox still enabled. Preserve the newest CBS log.

6. Establish the threshold: Sandbox is proven enabled, the same exact KB operation fails twice, the update is applicable, and no stronger cause is visible. The decisive test is the result after Sandbox is disabled and Windows restarts.

Branch A — Disable Sandbox through Windows Features, retry, then restore it

1. Press Windows+R, enter:

   optionalfeatures.exe
   

2. In Windows Features, clear Windows Sandbox only. Do not clear adjacent virtualization features.

3. Select OK and let Windows complete the feature change.

4. Restart Windows even if the dialog does not make the restart appear mandatory.

5. Run the PowerShell query again and require State : Disabled before retrying the update.

6. For an install failure, open Settings > Windows Update and retry the exact KB.

7. For an uninstall failure, open Settings > Windows Update > Update history > Uninstall updates, select the exact KB, and retry its supported uninstall action.

8. Complete all requested restarts and verify the update result before restoring Sandbox.

9. Run optionalfeatures.exe, select Windows Sandbox, choose OK, and restart.

10. Confirm the feature returns to Enabled and perform section 12.

Branch B — Disable and restore Sandbox with PowerShell

1. Close Sandbox and open PowerShell as Administrator.

2. Disable only the Sandbox feature:

   Disable-WindowsOptionalFeature -Online -FeatureName "Containers-DisposableClientVM" -NoRestart
   

3. Read the returned RestartNeeded value. Restart regardless before servicing.

4. Confirm the feature state:

   Get-WindowsOptionalFeature -Online -FeatureName Containers-DisposableClientVM
   

5. Retry only the identified update install or supported uninstall. Complete its restart and verify success.

6. Re-enable Sandbox:

   Enable-WindowsOptionalFeature -Online -FeatureName "Containers-DisposableClientVM" -All -NoRestart
   

7. Restart, confirm State : Enabled, and test one fresh Sandbox launch.

Branch C — Exact Windows 11 24H2 recurring-update case involving KB5049622 and KB5053598

Use this branch only when those exact updates are applicable and ordinary Sandbox removal/retry did not restore servicing. Do not install superseded packages merely to imitate the historical sequence.

1. Back up files and record Windows edition, default system UI language, architecture, feature release, full build, and activation. For this exact branch, winver and the DisplayVersion value captured in section 5 must identify Windows 11 24H2; do not use this branch to move to another feature release.

2. Close and disable Windows Sandbox using Branch A or B, then restart. Although the retained report changed Sandbox before Setup rebooted, this public procedure removes it before launching Setup so a feature change is not initiated during an active repair transaction. That ordering is a safety adaptation, not a lab-verified reproduction.

3. Obtain official Windows 11 media matching the installed edition, architecture, and system/default UI or install language shown by DISM /Online /Get-Intl. The media must be from the same Windows feature release, and its selected image index's full build must be equal to or newer than the installed full build. If only different-release media is available, treat that as a feature-upgrade decision with separate compatibility and safeguards, not as this repair branch.

4. From the running Windows desktop, mount the ISO. Record its drive letter, but do not run Setup yet.

5. Open an elevated PowerShell window. Substitute the actual mounted-media drive for M:\, then locate the install image and list its indexes:

   $evidence = Join-Path $env:SystemDrive 'UpdateEvidence\FIX-075'
   $mediaRoot = 'M:\'
   $mediaImage = @(
     (Join-Path $mediaRoot 'sources\install.wim')
     (Join-Path $mediaRoot 'sources\install.esd')
     (Join-Path $mediaRoot 'sources\install.swm')
   ) | Where-Object { Test-Path $_ } | Select-Object -First 1
   
   if (-not $mediaImage) {
     throw 'No install.wim, install.esd, or install.swm was found in the mounted media.'
   }
   
   & dism.exe /English /Get-WimInfo "/WimFile:$mediaImage" |
     Tee-Object -FilePath (Join-Path $evidence 'media-indexes.txt')
   

6. In media-indexes.txt, identify the candidate index whose edition name matches the installed Windows edition. Substitute that number for <index> and capture its detailed metadata; if more than one index appears to match, inspect each candidate separately rather than guessing:

   $mediaIndex = <index>
   $mediaDetail = & dism.exe /English /Get-WimInfo "/WimFile:$mediaImage" "/Index:$mediaIndex"
   $mediaDetail | Out-File (Join-Path $evidence 'selected-media-index-detail.txt')
   $mediaDetail
   

   In the detailed output, confirm that edition, architecture, and default language match the installed values recorded in section 5. Stop if any differs.

7. Compare the installed full build with the selected image's Version and ServicePack Build. The Version build component must equal the installed CurrentBuildNumber; for this exact 24H2 branch, equality establishes the same feature-release build line. The combined media version must be equal to or newer than CurrentBuildNumber.UBR:

   $cv = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows NT\CurrentVersion'
   $installedFull = [version]("10.0.{0}.{1}" -f $cv.CurrentBuildNumber, $cv.UBR)
   $detailText = $mediaDetail -join "`n"
   $versionMatch = [regex]::Match($detailText, '(?m)^\s*Version\s*:\s*(\d+\.\d+\.\d+)\s*$')
   $servicePackMatch = [regex]::Match($detailText, '(?m)^\s*ServicePack Build\s*:\s*(\d+)\s*$')
   
   if (-not $versionMatch.Success -or -not $servicePackMatch.Success) {
     throw 'DISM did not return a comparable Version and ServicePack Build for the selected image.'
   }
   
   $mediaFull = [version]("{0}.{1}" -f $versionMatch.Groups[1].Value, $servicePackMatch.Groups[1].Value)
   [pscustomobject]@{
     InstalledFeatureRelease = $cv.DisplayVersion
     InstalledFullBuild      = $installedFull
     MediaImage              = $mediaImage
     MediaIndex              = $mediaIndex
     MediaFullBuild          = $mediaFull
   } | Format-List | Tee-Object -FilePath (Join-Path $evidence 'installed-versus-media-build.txt')
   
   if ($mediaFull.Build -ne $installedFull.Build) {
     throw 'Stop: the media is not from the installed Windows feature-release build line.'
   }
   if ($mediaFull -lt $installedFull) {
     throw 'Stop: the selected media image is older than the installed Windows repair level.'
   }
   

   Do not proceed when either stop condition is returned. Do not infer feature-release compatibility from the ISO filename alone.

8. Run setup.exe from the mounted media while still in the normal Windows desktop. Do not boot from the media.

9. At Ready to install, confirm the displayed Windows edition, select Change what to keep, and require Keep personal files and apps. The media-metadata comparison in steps 6–7 is the feature-release gate; the Ready page might not print the release label. If the edition differs or the keep option is unavailable, greyed out, or changes to Nothing, cancel.

10. Complete the in-place repair with stable power. Do not interrupt its restarts.

11. After sign-in, confirm the feature release, full build, activation, applications, and files.

12. Let Windows Update determine applicability. If KB5049622 and KB5053598 are still separately applicable to that exact build, install the .NET update KB5049622 first, restart if requested, then install KB5053598 and restart. If either is superseded or not applicable, do not force it from an arbitrary package.

13. Re-enable Windows Sandbox, restart, and verify subsequent update scanning.

• Expected install pass: The exact KB installs while Sandbox is disabled, survives restart, and remains installed after Sandbox is re-enabled.
• Expected uninstall pass: The supported removal of the exact KB completes without 0x800F0825, and Sandbox can then be restored.
• Same error with Sandbox disabled: Sandbox is not isolated as the decisive dependency. Re-enable it and investigate the component store, package applicability, servicing logs, or update-specific issue.
• Feature disable itself fails: Preserve DISM/CBS output and stop. A component-store repair problem now precedes the update test.
• Sandbox cannot be re-enabled: Do not call the update repair complete. Record the feature error and repair that feature before publication.
• Update returns after removal: Windows Update may reoffer a current/security package. Removal success and policy about reinstalling it are separate decisions.

• Do not delete Sandbox virtual-disk or component-store files manually.
• Do not disable Hyper-V, virtualization in firmware, WSL, Credential Guard, or every virtualization feature as a group.
• Do not use DISM /StartComponentCleanup /ResetBase before an uninstall attempt; it can make installed updates non-removable.
• Do not force-remove a package whose uninstall control is absent.
• Do not install KB5049622, KB5053598, KB5058411, or KB5063878 on a build or architecture for which it is not applicable.
• Do not run Branch C with media from a different Windows feature release or with a selected image index whose full build is older than the installed OS.
• Do not change Windows features after in-place Setup has entered an active restart transaction.
• Do not claim 0x800F081F or 0x800F0825 universally means “disable Sandbox.”
• Do not forget that Sandbox contents are disposable; copy required work out before closing it.

If disabling Sandbox does not change the update result, re-enable it with Windows Features or the Enable-WindowsOptionalFeature command, restart, and verify it launches. That returns the optional-feature state but does not undo a separate update install/uninstall.

If the update installs and then causes a new problem, use its documented uninstall/recovery path only when Windows exposes one. If the update was uninstalled for diagnostic reasons and must be restored for security, use Windows Update after the root issue is corrected.

An in-place repair cannot be assumed to have a one-click rollback. The verified backup or system image is the recovery boundary if Branch C causes a material regression. Do not promise that Windows.old will exist or support a same-version repair rollback.

1. Confirm the target update's final state in Settings > Windows Update > Update history.

2. For an installed package, query relevant packages and retain the output:

   dism /online /Get-Packages /Format:Table > "%SystemDrive%\UpdateEvidence\FIX-075\packages-after.txt"
   

3. Confirm Sandbox state:

   Get-WindowsOptionalFeature -Online -FeatureName Containers-DisposableClientVM |
     Format-List * | Out-File (Join-Path $env:SystemDrive 'UpdateEvidence\FIX-075\sandbox-after.txt')
   

4. Launch Windows Sandbox once after re-enabling it. Confirm a fresh Sandbox desktop appears, then close it normally.

5. Restart Windows again, scan for updates, and confirm the repaired update state does not immediately fail again.

6. Review the newest CBS log for a repeated occurrence of the original HRESULT during the verification window.

7. For the exact Branch C case, confirm both applicable KBs are installed in the intended order or document that a newer cumulative update superseded them.

Confidence is approximately 80% for the exact retained combinations when Sandbox is independently confirmed enabled, the same update action fails repeatedly, and that action succeeds after Sandbox alone is disabled and Windows restarts. Three records contain explicit successful outcomes, including two confirmations for the KB5063878 removal path. The cases were not independently reproduced in the lab.

Confidence is lower for any other KB, for 0x800F081F without a Sandbox-specific before/after test, or for Branch C's adjusted safer ordering. Stop when the feature cannot be disabled cleanly, DISM reports non-repairable corruption, storage is unstable, the package is not applicable/removable, organizational policy owns the feature, Branch C media fails the edition/language/architecture/release/build comparison, or Sandbox cannot be restored after the update.