Windows 10 May 2019 Update Feature Focus: Light Themes And Sandboxes

Windows Sandbox

One of the more exciting feature additions to Windows 10 May 2019 Update is Windows Sandbox, which is a containerized version of Windows which runs in a lightweight virtualized environment, and allows you to open a pristine version of Windows every single time. There are many scenarios where this would be useful, and by default the VM is isolated, allowing less than trustworthy applications to be run without having to fire up a new virtual machine to do it. It would also be great for application testing, and many IT functions would benefit from a quick and easy to use VM without having to deal with the complexities and heft of Hyper-V. The VMs are also disposable, so every time you turn open Windows Sandbox you’ll get a new, pristine VM.

Windows Sandbox is an optional component which has to be turned on through the “Turn Windows Features on or off” menu, and it is only available in Windows 10 Pro and Enterprise, so unfortunately home users are out of luck.

There’s actually a lot under the hood that makes Windows Sandbox special. When you think about running a virtualized instance of another operating system, it generally requires hardware dedicated to the machine, such as RAM, and a large footprint for the virtual hard disk, either dedicated up-front as a single large block on your storage, or one that is dynamically increased as the storage is consumed within the virtual machine.

Windows Sandbox doesn’t work like this, although unsurprisingly it is based on Hyper-V. Windows Sandbox leverages technologies used in Windows Containers, meaning it is designed to use the minimal amount of hardware it can.

Windows Sandbox gets a 40 GB virtual hard disk to play in, but Microsoft uses a dynamically generated image for Windows Sandbox that reduces its footprint on the host OS to just 25 MB when compressed, or 100 MB when Windows Sandbox is enabled. Rather than have a unique VHD file that it launches from, Windows Sandbox uses the copy of Windows 10 on the host machine as its base image. It uses clean copies of files that can change, so if you modify some of your Windows files on the host PC the Sandbox version won’t be affected, and the same thing happens in reverse. If Windows files are changed in the Sandbox machine, they don’t write to the original files, but instead to a new copy of the file. Then, when the Sandbox is closed, all of those changed files are discarded, so the next time it is opened it’s a clean version again.

Memory is another key component, but like with the disk, since both the host and guest are running the same operating system, there is plenty of overlap in memory as well, meaning the impacted memory on the host can be dramatically reduced. Since much of the in-memory data will be the same for the same processes, Windows Sandbox can direct map the guest VM to the host VM’s copy of the data to reduce how much memory is required. If one or the other tries to change that same location in memory, a new copy of the new data will be created for whichever one made the request, so the other is not affected. These are typical ways to save memory in a virtualized environment, but when the host and guest are running the same version of an operating system, the RAM savings are dramatic. Running Windows Sandbox with no applications open offers the Sandbox VM 4 GB of memory, but on my test machine it only consumed 237 MB of memory on the host. In addition, the host gets priority if memory is required, so it can reclaim memory from the guest if needed.

That same principle applies to the kernel scheduler. Unlike a full hypervisor, Windows Sandbox uses what Microsoft calls an integrated scheduler to decide when the Sandbox VM gets compute time. If high-priority tasks need to be run on the host, it can pre-empt the Sandbox and jump it in the CPU queue. The major benefit here is that the host remains responsive at all times, even if the Sandbox is using a lot of CPU.

If you’ve used virtualization in the past, you’ll know of the term snapshot, which allows you to save the state of a virtual machine exactly how it is, including the memory state. This is what Sandbox uses to launch. The VM can be loaded as an already booted and logged in version of Windows 10, cutting down on the start-up time required when launching Sandbox. On my machine, launching a new instance of Sandbox takes about ten seconds, and once it’s loaded it’s ready to go, since it’s already logged in to the desktop.

The Sandbox also gets access to some of the other hardware on the host, such as the GPU, which allows for hardware accelerated rendering, and it also is aware of the host battery state, so if you are running this on a laptop, the VM can cut its power usage when on battery just like a normal version of Windows.

You will also be able to customize the Sandbox experience with Config files soon, allowing you to launch the Sandbox with a specific configuration. Sandbox uses XML configuration files with the .wsb extension, and allow you to control whether or not the Sandbox gets access to the virtualized GPU, networking, shared folders with the host computer, and a startup script so you can have it automatically launch an application or run a script.

Windows Sandbox, in my eyes, is one of the most exciting features to come to Windows in a while, and is something that I will likely use quite often. Having an always pristine version of Windows to do application testing on, while being able to easily control its access to files and folders on the host, is going to be valuable for many, I think. The implementation is very well thought out, and leans heavily on the serious work done on Windows Containers for cloud computing. It’s great to see a feature that was targeted at Azure trickling down into consumer-level Windows 10. The small footprint it takes up means that even if you rarely use Windows Sandbox, having it enabled is almost zero cost, with it only consuming about 100 MB of space for its VHD.