Skip to content
WinBookUnofficial

Windows Sandbox: the right way to open a suspicious file

Verified 2 min read

What the sandbox isolates, what still leaks through, and when a full VM is the better answer.

Tested onPro (26H2) · Build 26300.9457 · x64
E1
Build
26300.9457
Edition
Pro (26H2)
Architecture
x64
Support
Documentation (E1)
Evidence
E1Official documentation
Verified
2026-10-29
Page type
Setup

The short answer

Section titled “The short answer”

Windows Sandbox is a disposable, isolated desktop built on the same virtualisation stack as Hyper-V. Close the window and everything in it is gone.

It is the right tool for “I need to open this installer and see what it does”:

  • it starts in seconds (no OS install);
  • it shares nothing with the host by default;
  • closing it discards the entire state.

It is the wrong tool for “I want to test a driver” or “I need a persistent test machine”.

Requirements

Section titled “Requirements”
Requirement Detail
Edition Pro, Enterprise, Education (not Home)
Virtualisation enabled in firmware (VT-x/AMD-V, and SLAT)
Feature Windows Sandbox in Optional features
Nested virtualisation the sandbox itself cannot host another hypervisor
Terminal window
Get-WindowsOptionalFeature -Online -FeatureName Containers-DisposableClientVM |
  Select-Object FeatureName,State
# enable if disabled (reboot required)
# Enable-WindowsOptionalFeature -Online -FeatureName Containers-DisposableClientVM -All

What leaks through

Section titled “What leaks through”
Channel Default Risk
Clipboard shared with host text/files can cross — not isolated
Mapped folder off unless configured a mapped folder is writable from the sandbox
Network enabled malware can reach the internet/LAN
Audio/printing limited usually off
Host filesystem not mounted the point of the sandbox

That first and third row are why “open it in Sandbox” is not a guarantee: a clipboard-shared, network-enabled sandbox can still exfiltrate what you paste, and can still attack your router.

A .wsb configuration file controls this:

<Configuration>
  <Networking>Disable</Networking>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\Users\me\Downloads\suspect</HostFolder>
      <SandboxFolder>C:\work</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
</Configuration>

Save as test.wsb, double-click to launch with those settings.

Sandbox versus VM

Section titled “Sandbox versus VM”
Windows Sandbox Full VM
Start time seconds minutes
Persistence none full
Snapshot/rollback no (it is disposable by design) yes
Custom OS no (same build as host) any
GPU basic passthrough possible
Good for one-shot inspection repeatable testing

For anything you will do twice, a VM with snapshots is better. For a single suspicious installer, the sandbox is faster and safer than a dirty test machine.

A safe procedure

Section titled “A safe procedure”
  1. Put the file in its own folder.
  2. Launch a .wsb with networking and clipboard disabled, folder read-only.
  3. Open the file, observe, do not enter credentials.
  4. Close the sandbox window — state is discarded.
  5. If you need the “result”, copy it out through a read-write mapping you created deliberately.
Section titled “Related”

Lab boundary

Section titled “Lab boundary”

E1. Sandbox requirements and isolation behaviour are documented by Microsoft. The lab VMs are themselves virtualised without nested support for the sandbox feature, so it was not run here.

Sources