Windows Sandbox

Windows Sandbox is a new lightweight desktop environment tailored for safely running applications in isolation.

 

How many times have you downloaded an executable file, but were afraid to run it? Have you ever been in a situation which required a clean installation of Windows, but didn’t want to set up a virtual machine?

 

At Microsoft we regularly encounter these situations, so we developed Windows Sandbox: an isolated, temporary, desktop environment where you can run untrusted software without the fear of lasting impact to your PC. Any software installed in Windows Sandbox stays only in the sandbox and cannot affect your host. Once Windows Sandbox is closed, all the software with all its files and state are permanently deleted.

 

Windows Sandbox has the following properties:

• Part of Windows – everything required for this feature ships with Windows 10 Pro and Enterprise. No need to download a VHD!
• Pristine – every time Windows Sandbox runs, it’s as clean as a brand-new installation of Windows
• Disposable – nothing persists on the device; everything is discarded after you close the application
• Secure – uses hardware-based virtualization for kernel isolation, which relies on the Microsoft’s hypervisor to run a separate kernel which isolates Windows Sandbox from the host
• Efficient – uses integrated kernel scheduler, smart memory management, and virtual GPU

 

Prerequisites for using the feature

• Windows 10 Pro or Enterprise Insider build 18305 or later
• AMD64 architecture
• Virtualization capabilities enabled in BIOS
• At least 4GB of RAM (8GB recommended)
• At least 1 GB of free disk space (SSD recommended)
• At least 2 CPU cores (4 cores with hyperthreading recommended)

 

Quick start

1. Install Windows 10 Pro or Enterprise, Insider build 18305 or newer
2. Enable virtualization:
   • If you are using a physical machine, ensure virtualization capabilities are enabled in the BIOS.
   • If you are using a virtual machine, enable nested virtualization with this PowerShell cmdlet:
   • Set-VMProcessor -VMName <VMName> -ExposeVirtualizationExtensions $true
3. Open Windows Features, and then select Windows Sandbox. Select OK to install Windows Sandbox. You might be asked to restart the computer.
4. 
5. Using the Start menu, find Windows Sandbox, run it and allow the elevation
6. Copy an executable file from the host
7. Paste the executable file in the window of Windows Sandbox (on the Windows desktop)
8. Run the executable in the Windows Sandbox; if it is an installer go ahead and install it
9. Run the application and use it as you normally do
10. When you’re done experimenting, you can simply close the Windows Sandbox application. All sandbox content will be discarded and permanently deleted
11. Confirm that the host does not have any of the modifications that you made in Windows Sandbox.

 

 

Windows Sandbox respects the host diagnostic data settings. All other privacy settings are set to their default values.

 

Windows Sandbox internals

Since this is the Windows Kernel Internals blog, let’s go under the hood. Windows Sandbox builds on the technologies used within Windows Containers. Windows containers were designed to run in the cloud. We took that technology, added integration with Windows 10, and built features that make it more suitable to run on devices and laptops without requiring the full power of Windows Server.

 

Some of the key enhancements we have made include:

 

Dynamically generated Image

At its core Windows Sandbox is a lightweight virtual machine, so it needs an operating system image to boot from. One of the key enhancements we have made for Windows Sandbox is the ability to use a copy of the Windows 10 installed on your computer, instead of downloading a new VHD image as you would have to do with an ordinary virtual machine.

 

We want to always present a clean environment, but the challenge is that some operating system files can change. Our solution is to construct what we refer to as “dynamic base image”: an operating system image that has clean copies of files that can change, but links to files that cannot change that are in the Windows image that already exists on the host. The majority of the files are links (immutable files) and that's why the small size (~100MB) for a full operating system. We call this instance the “base image” for Windows Sandbox, using Windows Container parlance.

 

When Windows Sandbox is not installed, we keep the dynamic base image in a compressed package which is only 25MB. When installed the dynamic base package it occupies about 100MB disk space.

 

Smart memory management

Memory management is another area where we have integrated with the Windows Kernel. Microsoft’s hypervisor allows a single physical machine to be carved up into multiple virtual machines which share the same physical hardware. While that approach works well for traditional server workloads, it isn't as well suited to running devices with more limited resources. We designed Windows Sandbox in such a way that the host can reclaim memory from the Sandbox if needed.

 

Additionally, since Windows Sandbox is basically running the same operating system image as the host we also allow Windows sandbox to use the same physical memory pages as the host for operating system binaries via a technology we refer to as “direct map”. In other words, the same executable pages of ntdll, are mapped into the sandbox as that on the host. We take care to ensure this done in a secure manner and no secrets are shared. 

 

Integrated kernel scheduler

With ordinary virtual machines, Microsoft’s hypervisor controls the scheduling of the virtual processors running in the VMs. However, for Windows Sandbox we use a new technology called “integrated scheduler” which allows the host to decide when the sandbox runs. 

 

For Windows Sandbox we employ a unique scheduling policy that allows the virtual processors of the sandbox to be scheduled in the same way as threads would be scheduled for a process. High-priority tasks on the host can preempt less important work in the sandbox. The benefit of using the integrated scheduler is that the host manages Windows Sandbox as a process rather than a virtual machine which results in a much more responsive host, similar to Linux KVM.

 

The whole goal here is to treat the Sandbox like an app but with the security guarantees of a Virtual Machine. 

 

Snapshot and clone

As stated above, Windows Sandbox uses Microsoft’s hypervisor. We're essentially running another copy of Windows which needs to be booted and this can take some time. So rather than paying the full cost of booting the sandbox operating system every time we start Windows Sandbox, we use two other technologies; “snapshot” and “clone.”

 

Snapshot allows us to boot the sandbox environment once and preserve the memory, CPU, and device state to disk. Then we can restore the sandbox environment from disk and put it in the memory rather than booting it, when we need a new instance of Windows Sandbox. This significantly improves the start time of Windows Sandbox. 

 

Graphics virtualization

Hardware accelerated rendering is key to a smooth and responsive user experience, especially for graphics-intense or media-heavy use cases. However, virtual machines are isolated from their hosts and unable to access advanced devices like GPUs. The role of graphics virtualization technologies, therefore, is to bridge this gap and provide hardware acceleration in virtualized environments; e.g. Microsoft RemoteFX.

 

More recently, Microsoft has worked with our graphics ecosystem partners to integrate modern graphics virtualization capabilities directly into DirectX and WDDM, the driver model used by display drivers on Windows.

 

At a high level, this form of graphics virtualization works as follows:

• Apps running in a Hyper-V VM use graphics APIs as normal.
• Graphics components in the VM, which have been enlightened to support virtualization, coordinate across the VM boundary with the host to execute graphics workloads.
• The host allocates and schedules graphics resources among apps in the VM alongside the apps running natively. Conceptually they behave as one pool of graphics clients.

This process is illustrated below:

 

 

 

This enables the Windows Sandbox VM to benefit from hardware accelerated rendering, with Windows dynamically allocating graphics resources where they are needed across the host and guest. The result is improved performance and responsiveness for apps running in Windows Sandbox, as well as improved battery life for graphics-heavy use cases.

 

To take advantage of these benefits, you’ll need a system with a compatible GPU and graphics drivers (WDDM 2.5 or newer). Incompatible systems will render apps in Windows Sandbox with Microsoft’s CPU-based rendering technology.

 

Battery pass-through

Windows Sandbox is also aware of the host’s battery state, which allows it to optimize power consumption. This is critical for a technology that will be used on laptops, where not wasting battery is important to the user.

 

Filing bugs and suggestions

As with any new technology, there may be bugs. Please file them so that we can continually improve this feature. 

 

File bugs and suggestions at Windows Sandbox's Feedback Hub (select Add new feedback), or follows these steps:

1. Open the Feedback Hub
2. Select Report a problem or Suggest a feature.
3. Fill in the Summarize your feedback and Explain in more details boxes with a detailed description of the issue or suggestion.
4. Select an appropriate category and subcategory by using the dropdown menus. There is a dedicated option in Feedback Hub to file "Windows Sandbox" bugs and feedback. It is located under "Security and Privacy" subcategory "Windows Sandbox".
5. 
6. Select Next 
7. If necessary, you can collect traces for the issue as follows: Select the Recreate my problem tile, then select Start capture, reproduce the issue, and then select Stop capture.
8. Attach any relevant screenshots or files for the problem.
9. Submit. 

Conclusion

We look forward to you using this feature and receiving your feedback!

 

Cheers, 

Hari Pulapaka, Margarit Chenchev, Erick Smith, & Paul Bozzay

(Windows Sandbox team)