Roughly one in three malware infections on Windows machines starts with a file the user chose to open, according to widely cited industry threat reports. That single number explains why Windows Sandbox matters. It is a throwaway desktop that lives inside your PC, runs sketchy software, and vanishes the moment you close it. Nothing you install inside survives. Nothing you click inside can quietly rewrite your real system files.
This guide walks through what the feature actually does, how to switch it on, and the practical habits that separate a smooth experience from a frustrating one. It also covers the mistakes people make most often, because the sandbox is simple but not foolproof.
What Windows Sandbox Actually Is
Windows Sandbox is a lightweight, isolated desktop environment built into certain editions of Windows. It uses Windows Containers and Hyper-V virtualization to create a separate copy of Windows that runs alongside your normal session. Microsoft introduced the feature with Windows 10 version 1903 in May 2019 and has carried it forward into Windows 11.
The key word is disposable. When you close the sandbox window, everything inside it is destroyed: installed programs, downloaded files, browser history, registry changes, all of it. The next launch starts from a clean image. That is the whole point.
What it is not: a permanent virtual machine. You cannot save state, and you should not treat it as a place to keep work. If you need a VM that persists, use Hyper-V Manager or a third-party hypervisor instead.
Which editions support it
This is where most people hit a wall. Windows Sandbox is not available on Windows Home. It requires:
| Edition | Supported |
|---|---|
| Windows 10 Pro | Yes (version 1903 or later) |
| Windows 10 Enterprise | Yes |
| Windows 11 Pro | Yes |
| Windows 11 Enterprise | Yes |
| Windows 11 Education | Yes |
| Any Home edition | No |
If you are on Home, the honest answer is that you need an edition upgrade or a different isolation tool. Microsoft documents the full requirements on its Windows Sandbox overview page.
Prerequisites Before You Start
Three things must be true before the feature will work.
First, your CPU must support virtualization, and it must be turned on in BIOS or UEFI. Most modern machines ship with it enabled, but some OEM builds disable it. If the sandbox refuses to start, this is the first thing to check.
Second, the Hyper-V and Containers optional features need to be available. Enabling Windows Sandbox usually pulls them in automatically, but a locked-down corporate image may block them.
Third, you need enough RAM. Microsoft recommends at least 4 GB total, but in practice 8 GB is the realistic floor and 16 GB is comfortable. The sandbox takes memory from your host machine while it runs, so a 4 GB laptop will feel painful.
One more practical note: if you are already running another hypervisor that grabs the virtualization extensions, such as some configurations of third-party VM software, the sandbox may fail to launch. Disabling nested virtualization conflicts is usually the fix.
How to Enable Windows Sandbox
There are two routes, and both end with a restart.
The Settings route
- Open Settings and go to Apps.
- Click Optional features (on Windows 11) or Programs and Features then Turn Windows features on or off (on Windows 10).
- Find Windows Sandbox in the list and tick the checkbox.
- Click OK and restart when prompted.
The PowerShell route
If you prefer the command line, open PowerShell as administrator and run:
`Enable-WindowsOptionalFeature -FeatureName “Containers-DisposableClientVM” -All -Online`
The `-All` switch pulls in parent features automatically. You will be asked to reboot. Microsoft documents the underlying cmdlet on its Enable-WindowsOptionalFeature reference.
After the restart, search the Start menu for “Windows Sandbox.” A plain window opens with a bare desktop. That is your isolated environment, ready to use.
A Realistic Workflow for Testing a Suspicious File
Here is where practical experience beats documentation. The sandbox is easy to open; using it well takes a little discipline.
Step 1: Decide what belongs inside
Good candidates: installers from unfamiliar vendors, cracked software you have been handed, macro-enabled documents from unknown senders, and anything a colleague forwarded with the phrase “just open it.” Bad candidates: your banking session, anything tied to a work account with single sign-on, and files you actually need to keep.
Step 2: Get the file in
You cannot drag a file from your desktop into the sandbox by default, because the two environments do not share a clipboard or filesystem unless you configure it. The simplest method is to copy the file to a shared folder first, then map that folder using a configuration file (covered below). Alternatively, download the file directly inside the sandbox from its source.
Step 3: Run it and watch
Install or open the file. Pay attention to what it tries to do. Does it demand administrator rights immediately? Does it attempt to reach the network? Does it drop files in unusual locations? The sandbox lets you observe all of this without risk to your real machine.
Step 4: Close the window
Click the X. The entire environment is gone. No cleanup, no uninstaller, no lingering registry keys. This is the feature’s best quality, and it is worth trusting rather than second-guessing by trying to preserve anything.
If you want to capture evidence before closing, take a screenshot. Learning how to take a screenshot on Windows properly saves you from scrambling later.
Using.wsb Configuration Files
The real power of Windows Sandbox lives in `.wsb` files, which are plain XML documents that tell the sandbox how to behave at launch. Double-click one and the sandbox starts with your settings applied.
Common options include:
- Mapped folders – share a host directory read-only or read-write
- Networking – enabled by default; can be disabled entirely
- vGPU – share the host GPU for graphics-heavy testing
- Clipboard redirection – allow copy and paste between host and sandbox
- Logon command – run a script automatically at startup
A minimal example that maps a downloads folder and disables networking looks like this in structure: a “ root element, a “ block pointing at your path, and a `Disable` line. Microsoft publishes the full schema on its.wsb configuration reference page.
Two cautions from experience. First, disable networking when testing anything you suspect is malicious, because a network-enabled sandbox can still reach the internet and, in rare cases, interact with exposed services on your local network. Second, map folders as read-only unless you genuinely need write access, since a malicious program inside the sandbox can modify anything in a read-write mapped folder.
Common Mistakes and What Actually Works
A handful of problems come up again and again.
Mistake one: assuming the sandbox is a security boundary against everything. It isolates the guest from the host, but it is not designed to contain a determined attacker exploiting a hypervisor vulnerability. For everyday risk, it is excellent. For nation-state-grade threats, it is not the right tool.
Mistake two: forgetting that clipboard sharing cuts both ways. If clipboard redirection is on, copying text out of the sandbox is convenient, but it also means a malicious program could, in principle, place content on your host clipboard. Turn it off for high-risk tests.
Mistake three: ignoring the error codes. The most common failure is a message about virtualization not being enabled, or error `0x80070057`. Both usually trace back to BIOS settings or conflicting hypervisor software. Checking those two things resolves the majority of launch failures.
Mistake four: trying to install a full productivity suite. The sandbox is not fast enough for heavy workloads, and everything is lost on close anyway. Keep sessions short and focused.
Mistake five: skipping the basics on the host. A sandbox does not replace ordinary hygiene. Knowing how to check for viruses on a Windows PC and keeping a decent free virus removal tool on hand matters just as much, because the sandbox only protects what you choose to put inside it.
Sandbox vs. Virtual Machines vs. Browser Sandboxing
People often confuse three different things. Here is the honest comparison.
| Approach | Isolation strength | Persistence | Setup effort | Best for |
|---|---|---|---|---|
| Windows Sandbox | Strong, kernel-level | None (disposable) | Low | Quick tests of untrusted files |
| Full VM (Hyper-V, VirtualBox) | Strong, configurable | Full snapshots | Medium to high | Long-term isolated work |
| Browser tab isolation | Moderate | Session-based | None | Suspicious links, not installers |
The pattern that works: use browser sandboxing for links, Windows Sandbox for installers and documents, and a full VM when you need to keep something around. Each layer catches what the others miss.
When the Sandbox Is the Wrong Choice
It is worth being clear about limits. Windows Sandbox cannot help you test hardware drivers that need a real device, cannot run software that requires a persistent license activation tied to hardware, and cannot serve as a permanent development environment. It also will not run on Home editions, and it will not start on machines where virtualization is locked down by policy.
For those cases, a full virtual machine or a dedicated spare PC is the better answer. The sandbox is a scalpel, not a Swiss Army knife.
If you enjoy tinkering with isolated environments for fun rather than security, the same instinct shows up in games that reward experimentation, and there are plenty of best sandbox games built around exactly that freedom.
Conclusion
Windows Sandbox is one of the most underused features in modern Windows. It costs nothing beyond a restart, it requires no third-party software, and it gives you a genuinely disposable environment for the files you would otherwise open with a nervous click. The setup is a checkbox. The discipline is in what you choose to put inside, how you configure the `.wsb` file, and remembering that closing the window is the entire cleanup process.
Enable it once, keep a short `.wsb` file with networking disabled for suspicious tests, and treat mapped folders as read-only by default. Those three habits cover most of what the feature offers. Everything else is detail.
Frequently Asked Questions
Is Windows Sandbox available on Windows 11 Home?
No. Windows Sandbox requires Windows 10 Pro or Enterprise (version 1903 or later) or Windows 11 Pro, Enterprise, or Education. Home editions do not include the feature, and there is no official workaround short of upgrading the edition or using a separate virtual machine tool.
Does Windows Sandbox slow down my PC permanently?
No. The feature only consumes memory and CPU while a sandbox window is open. Once you close it, the resources return to the host. The optional Windows feature itself sits dormant until launched, so leaving it enabled costs essentially nothing at idle.
Can malware escape Windows Sandbox?
In normal use, no. The sandbox is built on Hyper-V isolation, and closing it discards all changes. That said, it is not marketed as a hardened boundary against advanced hypervisor exploits, so it should be treated as strong everyday protection rather than an absolute guarantee against a determined, sophisticated attacker.
Why does Windows Sandbox fail to start with an error?
The most common causes are virtualization disabled in BIOS or UEFI, conflicting hypervisor software already running, or insufficient RAM. Error `0x80070057` and messages about virtualization not being enabled almost always trace back to one of those three. Check BIOS settings first, then close other VM software.
Can I copy files between my PC and the sandbox?
Only if you enable it. By default the two environments are separate. You can map a host folder using a `.wsb` configuration file, or turn on clipboard redirection. For suspicious files, map folders as read-only and consider leaving the clipboard off entirely to reduce risk.
Is Windows Sandbox the same as a virtual machine?
No, though they are related. A virtual machine persists between sessions and lets you save snapshots. Windows Sandbox is disposable by design and always starts fresh. Use the sandbox for quick tests of untrusted software, and a full VM when you need an environment you can return to.
