Windows Sandbox on Windows 11: Enable, .wsb Config and Errors

Windows Sandbox on Windows 11 gives you a disposable copy of your own Windows that forgets everything the moment you close it. You can run an installer you don’t trust in there and watch what it does. It’s built into Pro, Enterprise and Education, so there’s nothing to download, but it ships switched off, and the first restart after you enable it can take far longer than anyone warns you about.

Original content from computingforgeeks.com - post 180567

This guide shows you how to enable it from Windows Features or PowerShell and write a .wsb config that maps folders and cuts the network. You’ll then test an unknown installer, drive the sandbox with the new wsb command line, and fix the errors that actually came up. I tested every step on Windows 11 24H2 in October 2026, inside a Proxmox VM with nested virtualization, and every output below comes from that machine.

Check that your PC can run Windows Sandbox

Windows Sandbox runs as a small Hyper-V virtual machine, so your PC needs hardware virtualization switched on and an edition of Windows that includes the hypervisor. Microsoft’s install requirements boil down to a short checklist, and the Windows Sandbox overview names Pro, Enterprise and Education as the editions that include it:

• You run Windows 11 Pro, Enterprise or Education, not Home.
• Your 64-bit CPU has virtualization enabled in firmware.
• You have 4 GB of RAM, and 8 GB to stay comfortable.
• You have two CPU cores and 1 GB of free disk.

You do not have to reboot into the firmware to check the first two, because Windows already knows. Open PowerShell as Administrator and ask it.

Get-CimInstance Win32_OperatingSystem | Select-Object Caption,Version,BuildNumber | Format-List
Get-CimInstance Win32_Processor | Select-Object Name,NumberOfCores,NumberOfLogicalProcessors,VirtualizationFirmwareEnabled,VMMonitorModeExtensions,SecondLevelAddressTranslationExtensions | Format-List

On the test machine both questions came back with the answer you want. The three virtualization fields need to read True, and the caption must not say Home:

Caption     : Microsoft Windows 11 Enterprise Evaluation
Version     : 10.0.26100
BuildNumber : 26100

Name                                    : Intel(R) Core(TM) i7-6700 CPU @ 3.40GHz
NumberOfCores                           : 4
NumberOfLogicalProcessors               : 4
VirtualizationFirmwareEnabled           : True
VMMonitorModeExtensions                 : True
SecondLevelAddressTranslationExtensions : True

If VirtualizationFirmwareEnabled says False, turn on Intel VT-x or AMD SVM in the firmware setup and check again. Running Windows 11 itself inside a VM is the part that trips people up, because the guest only sees those extensions when the hypervisor passes them through. On Proxmox that means setting the VM’s CPU type to host, which is how this lab VM was set up, and the VirtIO drivers guide covers the rest of a Windows guest there. On a Hyper-V host, Microsoft’s fix is Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true while the VM is off, plus Update-VMVersion -VMName <VMName> for older VM configurations.

Enable Windows Sandbox on Windows 11

You can enable it from the classic Windows Features dialog or with one PowerShell command, and both install the same optional feature, Containers-DisposableClientVM. For the dialog, press Win + R, type optionalfeatures and press Enter, then:

1. Tick Windows Sandbox and leave the Hyper-V boxes alone.
2. Click OK and restart when Windows asks.

1. 1Windows Sandbox
2. 2OK

If the Windows Sandbox entry is missing from that list, the edition or the virtualization check above is the reason. PowerShell does the same job without clicking through anything, which is handy when you’re setting up more than one machine.

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

The feature files were already on disk, so DISM finished in about two and a half minutes on the test VM. RestartNeeded : True is the line that matters, and the warning is only there because -NoRestart held the reboot back:

WARNING: Restart is suppressed because NoRestart is specified.

Path          :
Online        : True
RestartNeeded : True

It’s worth confirming the state before you restart, and checking what else the command pulled in. Sandbox brings its own pieces of the hypervisor, so the full Hyper-V role doesn’t have to be enabled:

Get-WindowsOptionalFeature -Online -FeatureName Containers-DisposableClientVM | Format-List FeatureName,DisplayName,State,RestartRequired
Get-WindowsOptionalFeature -Online | Where-Object { $_.FeatureName -match 'Hyper|Containers|VirtualMachine|HypervisorPlatform' } | Sort-Object FeatureName | Format-Table FeatureName,State -AutoSize

Only the Sandbox feature flipped to Enabled. Every Hyper-V feature stayed Disabled, which is why you can turn Sandbox on without also installing Hyper-V Manager and the rest of the role:

FeatureName     : Containers-DisposableClientVM
DisplayName     : Windows Sandbox
State           : Enabled
RestartRequired : Possible

FeatureName                                State
-----------                                -----
Containers                              Disabled
Containers-DisposableClientVM            Enabled
Containers-HNS                          Disabled
Containers-SDN                          Disabled
Containers-Server-For-Application-Guard Disabled
HyperV-Guest-KernelInt                  Disabled
HypervisorPlatform                      Disabled
HyperV-KernelInt-VirtualDevice          Disabled
Microsoft-Hyper-V                       Disabled
Microsoft-Hyper-V-All                   Disabled
Microsoft-Hyper-V-Hypervisor            Disabled
Microsoft-Hyper-V-Management-Clients    Disabled
Microsoft-Hyper-V-Management-PowerShell Disabled
Microsoft-Hyper-V-Services              Disabled
Microsoft-Hyper-V-Tools-All             Disabled
VirtualMachinePlatform                  Disabled

Now restart, and plan for this one to be slow. The first boot after enabling Sandbox shows Customizing features for you while containerworker.exe builds the sandbox’s base image out of your own installed packages. Its command line points at C:\WINDOWS\servicing\packages and writes into C:\ProgramData\Microsoft\Windows\Containers\Layers, which is why the sandbox later boots the same build as your host. On the four-core test VM the counter crawled from 57% to 100% over roughly 25 minutes while that process used about 14 minutes of CPU time, so leave the machine alone and do not pull the power while it’s counting.

Restart-Computer

Once you’re back at the desktop, check that the hypervisor is running and the container services are up. All three services should read Running.

(Get-CimInstance Win32_ComputerSystem).HypervisorPresent
Get-Service cmservice,vmcompute,hvhost | Format-Table Name,Status,StartType -AutoSize

The Container Manager service (cmservice) is the one Sandbox depends on, and it’s set to start automatically from now on:

True

Name       Status StartType
----       ------ ---------
cmservice Running Automatic
hvhost    Running    Manual
vmcompute Running    Manual

If HypervisorPresent comes back False after the restart, the hypervisor didn’t load, and Sandbox won’t start until it does. Go back to the virtualization check at the top before you try anything else.

Open Windows Sandbox for the first time

Search for Windows Sandbox in the Start menu and open it. On 24H2 the first launch doesn’t boot a sandbox straight away, because the inbox app fetches a newer version of itself from the Microsoft Store, so you’ll see this small update window first. It took about a minute on the test VM, and it needs internet access plus the Store to be allowed.

You get the wsb command line and the new window menu covered below from that update, and Microsoft documents the CLI for Windows 11 24H2 and later only, so don’t look for it on 23H2. To see which version you ended up with, ask the app package directly.

Get-AppxPackage -AllUsers -Name MicrosoftWindows.WindowsSandbox | Select-Object Version

An empty result means you’re still on the old inbox app, so give the Store update another try. A version number means you’re on the new one:

Version
-------
0.8.107.0

The sandbox desktop appeared about three and a half minutes after that first click, counting the update. It’s the same build as the host, signed in as WDAGUtilityAccount, with Edge, File Explorer and very little else. On this evaluation host the watermark inside the sandbox even says the licence has expired, which is cosmetic and doesn’t stop anything working.

Inbox apps such as Notepad, Calculator, Terminal and the Store aren’t available inside the sandbox on 24H2, so bring portable tools in through a mapped folder rather than expecting them to be there. The new window also has a menu you’d easily miss, and it’s worth opening once:

1. Click the More options menu, the three dots in the title bar.
2. Use Share folder to map a host folder in live.
3. Turn Clipboard redirection off before you open untrusted files.

1. 1More options menu
2. 2Share folder
3. 3Clipboard redirection

Look at the defaults in that menu. Clipboard, microphone and camera were all on for a plain launch from the Start menu, even though Microsoft’s docs describe video input as off by default. Networking is on as well, through the Hyper-V default switch. That is fine when you browse a sketchy site, but it’s the wrong starting point for running a file you don’t trust, which is exactly what a config file fixes.

Write a .wsb config file

A .wsb file is a short XML document that tells Sandbox how to start: which folders to map, whether it gets a network, what runs at logon and how much memory it may use. Double-clicking the file starts a sandbox with those settings, so you can keep one per job (an offline one for installers, a networked one for browsing) and never touch the defaults. Start by creating a working folder on the host for scripts and results:

New-Item -ItemType Directory C:\Sandbox\Scripts,C:\Sandbox\Results -Force

Every element you’ll use in practice is in this table, with what each setting did on the test VM:

Element	Values	What it did in the lab
Networking	Enable, Disable, Default	Disable removed the network adapter completely
VGpu	Enable, Disable, Default	Set to Disable; Microsoft says it falls back to software rendering
ClipboardRedirection	Enable, Disable, Default	On by default from the Start menu
MemoryInMB	Number (minimum 2048)	4096 showed up as 4.0 GB inside
MappedFolders	HostFolder, SandboxFolder, ReadOnly	A missing HostFolder stops the launch with 0x80070002
LogonCommand	One command	Ran about 50 seconds after launch
AudioInput, VideoInput, PrinterRedirection, ProtectedClient	Enable, Disable, Default	Not changed in this lab

The full list with every value lives in Microsoft’s Windows Sandbox configuration reference. The docs spell the GPU element both vGPU and VGpu, and the lab file used VGpu. Paths are less forgiving: relative paths aren’t supported, and every HostFolder must already exist. Create the config for offline testing in Notepad.

notepad C:\Sandbox\offline-test.wsb

Paste this configuration, which is the exact file the lab ran. It cuts the network and the clipboard, maps your Downloads folder read-only, maps the scripts folder read-only, maps one results folder you can write to, and runs a probe script as soon as the sandbox user logs on:

<Configuration>
  <Networking>Disable</Networking>
  <VGpu>Disable</VGpu>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <MemoryInMB>4096</MemoryInMB>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\Users\lorna\Downloads</HostFolder>
      <SandboxFolder>C:\Users\WDAGUtilityAccount\Desktop\Downloads</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
    <MappedFolder>
      <HostFolder>C:\Sandbox\Scripts</HostFolder>
      <SandboxFolder>C:\Scripts</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
    <MappedFolder>
      <HostFolder>C:\Sandbox\Results</HostFolder>
      <SandboxFolder>C:\Users\WDAGUtilityAccount\Desktop\Results</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>
  <LogonCommand>
    <Command>powershell.exe -ExecutionPolicy Bypass -File C:\Scripts\probe.ps1</Command>
  </LogonCommand>
</Configuration>

Change lorna in the first HostFolder to your own user name. Microsoft documents environment variables in these paths from Windows 11 23H2 onward, but a literal path is easier to debug when a launch fails. Save the file with the .wsb extension, not .wsb.txt, or double-clicking it will just reopen Notepad.

Map a folder and run a logon script

A config only proves itself when you can see what the sandbox saw, and a sandbox has no easy way to hand you its console output. The trick is to have the logon script write a report into the one writable mapped folder, which you can read on the host after the sandbox is gone. Create the probe script that the config calls.

notepad C:\Sandbox\Scripts\probe.ps1

It records who and where it is, lists network adapters, tries to reach the internet, tries to write into the read-only Downloads folder, and lists what it can see there:

$out = 'C:\Users\WDAGUtilityAccount\Desktop\Results\report.txt'
"== Sandbox report $(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')" | Out-File $out
"User: $(whoami)" | Out-File $out -Append
"Computer: $env:COMPUTERNAME" | Out-File $out -Append
$os = Get-CimInstance Win32_OperatingSystem
"OS: $($os.Caption) build $($os.BuildNumber)" | Out-File $out -Append
"Memory GB: {0:N1}" -f ($os.TotalVisibleMemorySize / 1MB) | Out-File $out -Append
"== Adapters" | Out-File $out -Append
Get-NetAdapter -ErrorAction SilentlyContinue | Format-Table Name, Status -AutoSize | Out-String | Out-File $out -Append
"== Internet test" | Out-File $out -Append
try { $r = Invoke-WebRequest -Uri 'https://www.microsoft.com' -UseBasicParsing -TimeoutSec 10; "HTTP $($r.StatusCode)" | Out-File $out -Append } catch { "FAILED: $($_.Exception.Message)" | Out-File $out -Append }
"== Write test on the read-only Downloads folder" | Out-File $out -Append
try { 'test' | Out-File 'C:\Users\WDAGUtilityAccount\Desktop\Downloads\write-test.txt' -ErrorAction Stop; 'write OK' | Out-File $out -Append } catch { "FAILED: $($_.Exception.Message)" | Out-File $out -Append }
"== Files visible in Downloads" | Out-File $out -Append
Get-ChildItem 'C:\Users\WDAGUtilityAccount\Desktop\Downloads' | Format-Table Name, Length -AutoSize | Out-String | Out-File $out -Append

Now start the sandbox from the config. You can double-click offline-test.wsb in File Explorer, or run the same thing from PowerShell, which is what the lab used.

Start-Process C:\Sandbox\offline-test.wsb

On this second launch the logon command had already run 50 seconds after the click. The first launch took three and a half minutes just to reach a desktop, because it also downloaded the app update, which is now in place along with the base image. You’ll see both mapped folders on the sandbox desktop:

1. You see Downloads (read-only), your host folder that nothing inside can change.
2. You see Results (writable), which keeps what the sandbox saves.
3. You see No network in the tray, because the adapter is gone.

1. 1Downloads (read-only)
2. 2Results (writable)
3. 3No network

Back on the host, read the report the logon script left behind. You don’t need to close the sandbox first, since the folder is shared live.

Get-Content C:\Sandbox\Results\report.txt

Every guard did its job. There’s no adapter at all, the web request fails at DNS, and the write into Downloads is refused, while the installer sitting in your Downloads folder is still visible and readable:

== Sandbox report 2026-10-30 21:41:32
User: 62dd8cfd-734a-4\wdagutilityaccount
Computer: 62DD8CFD-734A-4
OS: Microsoft Windows 11 Enterprise Evaluation build 26100
Memory GB: 4.0
== Adapters

== Internet test
FAILED: The remote name could not be resolved: 'www.microsoft.com'
== Write test on the read-only Downloads folder
FAILED: Access to the path 'C:\Users\WDAGUtilityAccount\Desktop\Downloads\write-test.txt' is denied.
== Files visible in Downloads

Name            Length
----            ------
7z2301-x64.exe 1589510

For comparison, the same probe in a sandbox with default networking listed an Ethernet adapter as Up and got HTTP 200 back from the same URL. The computer name was the same 62DD8CFD-734A-4 on every launch in the lab, so don’t count on it to tell sessions apart, and Memory GB: 4.0 matches the MemoryInMB value. On the host, the sandbox’s vmmemWindowsSandbox process held only about 1 GB while it idled, because Sandbox hands memory to the guest as it asks for it.

Test an unknown installer safely

This is what most people want Windows Sandbox for: you’ve downloaded a setup file you’re not sure about, and you want to see what it does before it touches your real system. With the offline sandbox still running, put a second script next to the probe.

notepad C:\Sandbox\Scripts\install-test.ps1

It hashes the installer and checks its signature, copies it out of the read-only folder, installs it silently, and records whether the install landed and whether it added a startup entry. It picks the first .exe in Downloads, and the lab used a 7-Zip installer saved there beforehand. For your own file, keep only that installer in Downloads, swap the /S silent flag for whatever it expects, and change the two C:\Program Files\7-Zip paths. The Run key check covers startup entries only, not services:

$log = 'C:\Users\WDAGUtilityAccount\Desktop\Results\install-test.txt'
$installer = Get-ChildItem 'C:\Users\WDAGUtilityAccount\Desktop\Downloads\*.exe' | Select-Object -First 1
"Installer: $($installer.Name)" | Out-File $log
"SHA256: $((Get-FileHash $installer.FullName).Hash)" | Out-File $log -Append
$sig = Get-AuthenticodeSignature $installer.FullName
"Signature: $($sig.Status) $($sig.SignerCertificate.Subject)" | Out-File $log -Append
Copy-Item $installer.FullName $env:TEMP
$p = Start-Process "$env:TEMP\$($installer.Name)" -ArgumentList '/S' -Wait -PassThru
"Installer exit code: $($p.ExitCode)" | Out-File $log -Append
"Installed: $(Test-Path 'C:\Program Files\7-Zip\7z.exe')" | Out-File $log -Append
"== New services and Run keys after install" | Out-File $log -Append
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Run' | Out-String | Out-File $log -Append
"== Files the installer wrote" | Out-File $log -Append
Get-ChildItem 'C:\Program Files\7-Zip' | Measure-Object | Select-Object -ExpandProperty Count | Out-File $log -Append

Because C:\Scripts is a live mapping, the new file shows up inside the running sandbox straight away. Run it from the host with wsb exec as the signed-in sandbox user, and the next section explains the CLI in more detail.

$id = (wsb list --raw | ConvertFrom-Json).WindowsSandboxEnvironments[0].Id
wsb exec --id $id -c 'powershell.exe -ExecutionPolicy Bypass -File C:\Scripts\install-test.ps1' -r ExistingLogin

wsb exec waits for the process to finish, which took about 30 seconds here, and only returns the exit code. A non-zero code would mean the script itself failed, and its log would say where:

Process exited with code: 0

An exit code alone tells you very little about an installer, so the script logged the details to the results folder. Read them on the host.

Get-Content C:\Sandbox\Results\install-test.txt

The installer ran cleanly and left 15 files and folders in its Program Files folder, and the empty Run key section means it didn’t register anything to start with Windows. Note the NotSigned line too. The 7-Zip installer carries no Authenticode signature, so the hash is the only thing you can compare against the value the publisher lists, and that’s the kind of file this workflow exists for:

Installer: 7z2301-x64.exe
SHA256: 26CB6E9F56333682122FAFE79DBCDFD51E9F47CC7217DCCD29AC6FC33B5598CD
Signature: NotSigned
Installer exit code: 0
Installed: True
== New services and Run keys after install

== Files the installer wrote
15

Close the sandbox window when you’re done. Windows asks you to confirm, because closing it really does throw away everything inside, the installed program included. There’s no snapshot or undo, so copy anything you want to keep into Results first:

After clicking Ok, check the host. The program never existed here, while both reports in the writable folder are still there:

Test-Path 'C:\Program Files\7-Zip\7z.exe'
Get-ChildItem C:\Sandbox\Results | Select-Object Name,Length

False on the host means the install never left the sandbox, and both reports survived in the writable folder:

False

Name             Length
----             ------
install-test.txt    492
report.txt         1096

That’s the result you want to see before you install anything for real. The 7-Zip build in this test is an old release with known CVEs, so on the host you’d install the current version instead, for example through winget.

The writable mapping is the one hole in that wall. Anything malicious inside the sandbox can write to Results just as your script can, and that folder stays on your disk afterwards. Treat its contents as untrusted, and never map a folder you care about with ReadOnly set to false.

Drive Windows Sandbox from the wsb command line

The Store version of Sandbox ships wsb.exe, documented in Microsoft’s Windows Sandbox CLI reference, which lets you start, script and stop sandboxes from PowerShell. It’s an app execution alias, so run it from your own signed-in session. Its built-in help lists every command.

wsb --help

Each command has a long name and a short alias, and --raw switches the output to JSON for scripts:

Description:
  Windows Sandbox Command Line Interface (CLI)

Usage:
  wsb [command] [options]

Options:
  --raw           Formats all outputs in JSON format.
  -?, -h, --help  Show help and usage information
  --version       Show version information

Commands:
  StartSandbox, start         Starts an instance of Windows Sandbox.
  ListRunningSandboxes, list  List the IDs of all running Windows Sandbox environments.
  Execute, exec               Execute a command in the running Windows Sandbox environment.
  ShareFolder, share          Shares a folder from the host to the Windows Sandbox session.
  StopSandbox, stop           Terminates a running Windows Sandbox.
  ConnectToSandbox, connect   Starts a remote session for a Windows Sandbox environment.
  GetIpAddress, ip            Gets the IP address of the Windows Sandbox environment.

Apart from start and list, every command needs a sandbox ID. With a sandbox already open from the Start menu, wsb list shows it, and --raw returns the same thing as JSON for scripts.

wsb list
wsb list --raw

One running sandbox gives you one ID, and that’s all the JSON holds. Parse it once into a variable and every later command can reuse it:

a587c1c9-1da8-47bc-9e7e-0ee618426a74
{
  "WindowsSandboxEnvironments": [
    {
      "Id": "a587c1c9-1da8-47bc-9e7e-0ee618426a74"
    }
  ]
}

With the ID you can find the sandbox’s address and share a writable folder into it while it runs. You can also run commands as SYSTEM or as the logged-in sandbox user. wsb exec does not pass the command’s output back, so redirect it into a shared folder. Use an empty one, not Results, so the files are easy to tell apart:

New-Item -ItemType Directory C:\Sandbox\Exec -Force | Out-Null
$id = (wsb list --raw | ConvertFrom-Json).WindowsSandboxEnvironments[0].Id
wsb ip --id $id
wsb share --id $id -f C:\Sandbox\Exec -s C:\Exec --allow-write
wsb exec --id $id -c 'cmd.exe /c whoami > C:\Exec\exec-system.txt' -r System
wsb exec --id $id -c 'cmd.exe /c whoami > C:\Exec\exec-user.txt' -r ExistingLogin

The sandbox got an address on the default switch’s internal range, share printed nothing and exited 0, and both exec calls returned exit code 0:

172.17.35.17
Process exited with code: 0
Process exited with code: 0

Comparing the two files on the host shows you the difference between the run-as modes. System works even when nobody is looking at the sandbox, while ExistingLogin runs as WDAGUtilityAccount and needs the sandbox’s desktop session to exist, which is why Microsoft suggests running wsb connect first on a headless sandbox:

Get-Content C:\Sandbox\Exec\exec-system.txt, C:\Sandbox\Exec\exec-user.txt

One line per identity, both written from inside the sandbox:

nt authority\system
62dd8cfd-734a-4\wdagutilityaccount

When you’re finished, wsb stop tears the sandbox down in seconds (2 to 8 in the lab), with no confirmation prompt, so double-check the ID before you run it:

wsb stop --id $id
wsb list

An empty wsb list confirms nothing is left running. You can also start sandboxes from the CLI: wsb start takes the same XML as a .wsb file through --config, so you can reuse files you’ve already written. Here’s a small one that maps a tools folder read-only:

notepad C:\Sandbox\tools.wsb

Paste the mapping, which keeps networking at its default. It’s the smallest useful config, one read-only folder and nothing else, so it’s a good one to test the CLI with.

<Configuration>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\Tools</HostFolder>
      <SandboxFolder>C:\Tools</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
</Configuration>

The host folder has to exist before the sandbox starts (the errors section shows what happens when it doesn’t), so create it, then start the sandbox from the file:

New-Item -ItemType Directory C:\Tools -Force | Out-Null
wsb start --config (Get-Content C:\Sandbox\tools.wsb -Raw)

The CLI starts the sandbox headless, with no window, and hands back the new ID within seconds:

Windows Sandbox environment started successfully:
Id: ede0b9df-fad8-499b-a18b-f8179b9b2a8e

To see it, run wsb connect --id with that ID. The command doesn’t return until you close the window it opens, so don’t put it in the middle of a script. Stop it with wsb stop as before, using this new ID (re-run the $id line first, because the old value points at the sandbox you already stopped). If you’re after a disposable Linux environment instead, WSL covers that ground better; the wslc container commands and RHEL and Fedora on WSL are the closer fit.

Fix Windows Sandbox errors

These are the errors that came up on the test VM, each with the exact text Windows printed and the fix that cleared it. Two that people search for, HELPER_UNKNOWN_ERROR and the 0x80070005 access-denied error Microsoft lists for mapping a folder onto the sandbox Desktop, didn’t appear on this build. Mapping straight onto C:\Users\WDAGUtilityAccount\Desktop actually started fine and simply replaced the desktop with the host folder’s files, read-only, so they aren’t covered here.

Windows Sandbox failed to initialize: The system cannot find the file specified (0x80070002)

This one appeared the moment a .wsb file pointed at a host folder that didn’t exist. Double-clicking tools.wsb before C:\Tools had been created gave this dialog, and no sandbox started:

The CLI reports the same failure as The system cannot find the file specified. (0x80070002). Check every HostFolder in the file, create the one that’s missing, and launch again. In the lab that was a single command, after which the same config started normally:

New-Item -ItemType Directory C:\Tools -Force

Microsoft’s troubleshooting table also lists ERROR_FILE_NOT_FOUND for a .wsb path that doesn’t exist, so if every mapped folder is there, check the path of the file you double-clicked or passed to the CLI.

The configuration file was invalid

Sandbox validates the XML before it starts anything. A config missing its closing </Configuration> tag produced this message from wsb start, with exit code -2146232000 and no sandbox. The message doesn’t say which line is wrong, so look for an unclosed tag or a misspelled element name, and compare the file against the working offline-test.wsb above.

Application cannot be run more than once (0x800401F6 CO_E_APPSINGLEUSE)

Only one sandbox can run at a time, and asking for a second one gives you this error in about a second. In the lab a sandbox opened from the Start menu blocked wsb start, so the limit covers the CLI too. Run wsb list to find the one that’s still running, which may be a headless sandbox you started and forgot about, and stop it with wsb stop --id before you start the next.

Stuck on “Customizing features for you” at 100%

After the restart that enables Sandbox, the test VM reached 100% and then sat there for six minutes with no CPU or disk activity from the servicing processes. The base image build had already finished by then. A normal restart (it took a few minutes to shut down) cleared it, and the next boot reached the desktop in about a minute with Sandbox working. Give it real time first, because the counter crawls on slower disks, but once nothing has moved for several minutes at 100%, a restart is what cleared it in the lab.

Program ‘wsb.exe’ failed to run: The file cannot be accessed by the system

This happens when wsb is called from the SYSTEM account, which is how remote management tools and deployment agents usually run. The lab hit it through the VM’s guest agent. wsb.exe is an app execution alias in your profile’s WindowsApps folder, and those only resolve for a signed-in user. Run it from your own PowerShell window, or from a scheduled task set to run as your account and only when you’re logged on. If you need a Windows VM you can fully script from a server, a regular Hyper-V virtual machine is the better tool.