Windows Sandbox can't be disabled - CSI "Container Installer" fails with ERROR_FILE_NOT_FOUND at reboot, changes rolled back (sandbox itself fails with 0x80070490)

Data point from another 26300 machine, in case it helps. The "file not found" in container servicing seems to be the 26100.1742 baseline. CBS asks for C:\Windows\WinSxS\amd64_microsoft-windows-professional-config_31bf3856ad364e35_10.0.26100.1742_none_9641b89b272960cc\Professional.xml and then logs:

Failed to recreate container base images: HRESULT_FROM_WIN32(ERROR_PATH_NOT_FOUND)
Container Servicing failed hrCreateContainerCtrl = 0 hrContainerSvc = -2147024893

• No *_10.0.26100.1742_* component folders exist in WinSxS, only manifests.
• The official 26300.9457 install.wim doesn't have them either, so DISM /RestoreHealth, SFC and a repair install from that ISO can't restore them.
• C:\ProgramData\Microsoft\Windows\Containers\BaseImages didn't exist.

On my machine this broke KB5127936 (0x80070003 / 0x80070306). Unlike yours, disabling Windows Sandbox (Containers-DisposableClientVM) through optionalfeatures did go through: one restart, no rollback. After that KB5127936 installed fine, and the build is now 26300.9818. If yours keeps rolling back, check CBS.log for the same 26100.1742 path. It may be the same root cause hitting the disable path.

Write-up with logs: https://github.com/microsoft/Windows-Sandbox/issues/144

Welcome to Microsoft Q&A!

Thank you for providing such a detailed description of the issue and, especially, the relevant CBS.log entries.

Based on the CBS entries you shared, this does not appear to be simply a missing WindowsSandbox.exe or WindowsSandboxClient.exe file. The failure occurs later, during the boot-time Component-Based Servicing (CBS) transaction, when the Container Installer attempts to remove its registered container client.

The important sequence is:

Container AI couldn't mark client {b24d5b54-1cb5-4d74-b50e-**} for deletion with status -2147024894

Followed by:

HRESULT_FROM_WIN32(ERROR_FILE_NOT_FOUND)

Because the Container Installer reports this failure, CBS rolls back the servicing transaction. This is consistent with what you are seeing: the disabled operation initially completes, but after the required restart Windows reports that the changes could not be completed and Containers-DisposableClientVM remains enabled.

The most likely cause is an inconsistent or missing servicing state associated with the Windows Sandbox/container feature.

The fact that the corresponding WinSxS component directory exists does not necessarily mean that all servicing information required to service the feature is intact.

DISM checks not only files under locations such as %SYSTEMROOT%\Servicing\Packages and %SYSTEMROOT%\WinSxS\Manifests, but also Component Based Servicing registry data when checking and repairing a Windows image.

In this case, the CBS log is particularly useful because it shows that the failure occurs when Container AI attempts to mark the referenced client for deletion, rather than reporting that WindowsSandbox.exe itself is missing.

Regarding {b24d5b54-1cb5-4d74-b50e-**}, I would not recommend manually creating a registry key, directory, or other object for this GUID. The available public Microsoft documentation does not document this Container AI client identifier or provide a supported mapping showing where this particular identifier should be stored or what data its registration should contain.

For the same reason, although the empty C:\ProgramData\Microsoft\Windows\Containers directory is an important observation, I would not manually populate or reconstruct this directory. Without documentation defining its expected servicing state, creating files or registry entries based on assumptions could leave CBS in a more inconsistent state.

At this stage, I recommend using the supported Windows image repair process rather than attempting to reconstruct the Container AI registration manually.

• Open Command Prompt as Administrator and run:

DISM.exe /Online /Cleanup-Image /RestoreHealth

• Allow DISM to complete fully. If it reports that the restore operation completed successfully, run:

sfc /scannow

• After both commands complete, restart Windows.

DISM /RestoreHealth checks the Windows image for corruption and can replace incorrect servicing manifests, files, or registry data with corrected versions. By default, DISM can use Windows Update to obtain files required for the repair.

• After Windows restarts, retry disabling Windows Sandbox:

DISM.exe /Online /Disable-Feature /FeatureName:Containers-DisposableClientVM /NoRestart

• Restart Windows again and then check the feature state:

DISM.exe /Online /Get-FeatureInfo /FeatureName:Containers-DisposableClientVM

The expected result is:

State : Disabled

If the feature returns to Enabled again and the new CBS.log records the same "Container AI couldn't mark client ..." for deletion / ERROR_FILE_NOT_FOUND failure, that would indicate that the documented component-store repair did not resolve the servicing state responsible for the rollback.

At that point, I would not recommend manually recreating the GUID, registry entries, or files under the Containers directory.

Moreover, I want to set the right expectation about what can reasonably be investigated through Microsoft Q&A.

Microsoft Q&A is a community-based technical forum. We can help interpret the symptoms and relevant CBS entries, correlate documented error codes, and recommend troubleshooting steps that are supported by Microsoft documentation. However, a case involving an undocumented Container Installer/Container AI registration failure requires a different level of investigation.

In particular, determining exactly what internal object {b24d5b54-1cb5-4d74-b50e-****} represents, where that registration should exist, why it disappeared, or what data would be required to reconstruct it cannot be established safely from the documented information currently available.

Although CBS.log excerpts are very useful for identifying where the transaction fails, reviewing excerpts in a forum is not equivalent to a full servicing investigation. This type of problem may require correlation of the complete servicing logs and system state rather than interpreting an isolated CBS entry.

Therefore, if DISM /RestoreHealth completes successfully but the same Container Installer failure and rollback remain, the appropriate next step would be to engage Microsoft Support and provide the CBS logs covering the disabled operation and subsequent reboot. Support can investigate the servicing failure in the context of the affected system rather than relying only on excerpts posted publicly.

I realize this may not provide the specific explanation you were hoping for regarding the GUID and the empty Containers directory. However, without a documented schema for that internal registration, recommending that you manually recreate it would involve guesswork and could make the servicing state more difficult to recover. For that reason, I would stay with the supported image-repair path above and move to Microsoft Support if the same boot-time failure remains.

References:

Fix Windows Update corruptions and installation failures - Windows Server | Microsoft Learn

Repair a Windows Image | Microsoft Learn

Windows Sandbox execution - Windows apps | Microsoft Learn

Repair-WindowsImage (Dism) | Microsoft Learn

If you find it useful, please click Accept Answer.

Thank you for choosing Microsoft Q&A.