A Windows PC where silly mistakes have no consequences sounds like the perfect place to test out shady software. Windows Sandbox comes really close, but every session starts with Microsoft’s generic, unconfigured environment.

VMware snapshots are another route, as they preserve a machine I’ve already configured. Unfortunately, they still rely on me remembering to restore the right one afterward. What I really wanted was the useful parts of both.

My ideal test machine would be a complete Windows 11 PC that’s loaded with my preferred tools but cleans itself automatically. VMware Workstation’s Independent-Nonpersistent disk mode does exactly that. I can install applications, create files, and alter the registry, and be confident that a single shutdown would erase it all and return the vDisk byte-for-byte unchanged.

Windows Sandbox was disposable, but it was never “mine”

I wanted a clean starting point that already contained everything I used for testing

Windows Sandbox is definitely still the quickest option if I only need to test one questionable downloaded file. It launches in seconds, runs a safely isolated Windows environment based on my host’s build, and deletes its entire state when I close it.

A .wsb configuration file can map a folder or run a command at launch, but it doesn’t preserve any applications I installed interactively for the next session. The problem was that once I wanted several tools ready every single time, rebuilding that same environment became so inconvenient I tended just to use a VM snapshot anyway. Right up until I forgot to actually take the snapshot.

To solve the issue once and for all, I built a complete Windows 11 25H2 Pro VM, named it DISPOSABLE-PC, and licensed it with a spare key. It received 8 GB of RAM, four vCPUs, and an 80 GB dynamically allocated vDisk. I created a local account during install rather than signing in to a Microsoft account, then installed VMware Tools, 7-Zip, Notepad++, Process Explorer, and Wireshark.

Before freezing the disk, I created a permanent marker:

New-Item C:Baseline -ItemType Directory "PERMANENT BASELINE" | Set-Content C:BaselineBASELINE.txt 

That file gave me a known, timestamped item that would survive every disposable session. Unlike Windows Sandbox, this created a clean starting point that was forever mine to configure and reuse.

One VMware disk option froze the baseline without freezing Windows

New writes went into a temporary redo file while the clean system disk remained untouched

Once the baseline configuration was to my satisfaction, I shut Windows down and checked VMware’s Snapshot Manager. It was empty, and this was an important step in the process because I wanted to ultimately prove that resets were automatic rather than a sneaky snapshot hiding behind the scenes.

Before freezing the disk in time, I recorded the VMDK’s SHA-256 hash from my host machine:

Get-FileHash "C:VMDisposable Windows 11Windows 11 x64.vmdk" -Algorithm SHA256 

Next, I opened the vDisk’s advanced settings and selected Independent, followed by Nonpersistent. VMware recorded the change, which could be seen directly in the VMX configuration:

nvme0:0.mode = "independent-nonpersistent" 

The next boot created Windows 11 x64.vmdk.REDO_a40316. This was VMware treating my original VMDK as the reference disk while directing any new reads and writes through this temporary redo file.

When I inspected the files, the redo layer occupied only 10 MB beside the original vDisk of roughly 26 GB. Importantly, this wasn’t a snapshot, as independent disks are actually excluded from VMware snapshots altogether.

There is one fairly major maintenance catch here. The frozen disk will need to be treated like a golden image, in that it will need to be unfrozen to apply Windows updates. After verifying any updates work, I will need to return the vDisk to nonpersistent mode again.

OS

64-bit Windows and Linux

CPU

64-bit Intel and AMD x86/x86-64 PCs

VMware Workstation Pro is a desktop hypervisor for running Windows, Linux, and other operating systems as isolated virtual machines. It includes snapshots, cloning, advanced networking, encryption, vTPM, and Secure Boot.

I tried five different ways to make Windows remember me

Files, applications, browsing history, personalization, and registry edits all faced the same test

A clean desktop that returns after shutdown doesn’t prove much by itself. To test it properly, I deliberately contaminated the session in five different ways.

First, PowerShell created a test directory, a marker inside it, and another file placed on the desktop:

New-Item C:Session-Test -ItemType Directory "This file should disappear" | Set-Content C:Session-TestTHIS-SHOULD-DISAPPEAR.txt "Erase me too!!" | Set-Content "$HOMEDesktopTemporary session.txt" 

For an unmistakable visual change, I replaced the lovely default Windows wallpaper with the ugliest red color MS Paint had to offer, labeled TEMPORARY SESSION. I then installed VLC through Winget and launched it manually.

The less visible changes were just as important. I created HKCUSoftwareDisposablePC-Test in the registry and added SessionStatus = THIS SHOULD DISAPPEAR to it. Finally, I visited example.com and wikipedia.org in Edge, so both would appear in its local browsing history.

I had read online that restarting the Windows VM through the Start Menu would preserve the changes made. This was one of the more useful features of this setup because many installers require a reboot after installation. Having my changes disappear after a reboot wouldn’t be ideal, so this warranted a test to see if it worked.

Windows rebooted, but VMware, replicating a real PC, never powered off the virtual machine. That meant the same redo file remained attached. After the reboot, the changes hadn’t disappeared, as the eyesore wallpaper was still there, VLC still launched, and all altered files, browser history, and registry keys remained.

I then selected Start > Power > Shutdown. VMware Workstation deleted the redo layer once the VM was powered off. At the next boot, my static wallpaper and permanent testing tools were returned. VLC had vanished, both temporary files were gone, the registry key no longer existed, and Edge had forgotten both websites.

Most importantly for the test, C:BaselineBASELINE.txt remained exactly where I had left it. The Windows VM had remembered my baseline configuration and apps, and discarded anything that came after.

VMware also let me decide where the disposable PC could connect

Disk rollback handled local traces while virtual networking controlled the machine’s reach

Storage made up one half of the security boundary, and VMware Workstation’s Virtual Network made up the rest. I kept the VM on VMware’s NAT network specifically because I needed internet access to update Windows and download apps. That also kept it from acting as an independently exposed computer on my physical network, though it still meant it could reach devices on my LAN.

VMware gave me several alternatives depending on what I needed to test, which is one of the biggest advantages over Windows Sandbox this setup has:

• Bridged to place the VM directly on the physical network via an adapter on the host.
• Host-only with no virtual host adapter on the host, so VMs can communicate with each other.
• Host-only with a virtual host adapter, so VMs can communicate with the host as well.

If an application no longer needs the internet, unchecking Connected in the settings menu is the simplest virtual equivalent of pulling out its Ethernet cable.

Windows Sandbox can enable and disable networking, which is fine for simple one-off tests. VMware’s additional network topologies become so much more useful when I need the disposable PC to join my homelab or just another VM.

To further facilitate isolation, I also disabled shared folders, drag and drop, clipboard, and automatic USB connections. This removes a lot of convenience, but these settings sit outside the protection of the nonpersistent VMDK, so they need to be locked down.

The automatic reset is super convenient, but it is not an invincible malware prison

My baseline VM takes up roughly 25 GB of disk space and uses 8 GB of my host’s RAM while running. It also takes far longer to prepare than a Windows Sandbox session. Any updates installed while in nonpersistent mode will also disappear, so maintenance means making the disk writable again, installing, and then refreezing it.

The boundary also stops right at the VMDK. Malware could target VMware Tools, attempt a hypervisor escape if it’s clever enough, or attack devices reachable over the network. Websites, DNS resolvers, and routers also don’t just forget activity created by the VM. Anything copied to the host’s shared folder, clipboard, or USB drive also survives to live another day. Though disabling those integrations does significantly reduce the risk.

The nonpersistent feature isn’t something unique to VMware either. VirtualBox also offers immutable disks. Windows Sandbox remains my choice for one unknown file, and snapshots are still better when I need multiple named recovery points.

For repeatable software and configuration tests, this VM setup suits me much better. Guest reboots preserve the session, and shutdown cleans it automatically.

The final SHA-256 hash matched the baseline value I took before testing it. This proves that the VM didn’t merely look restored. Its system vDisk returned byte-for-byte. I’ll be using it for disposable testing and browsing, but I’ll seriously consider online platforms like Hybrid Analysis that allow you to detonate malware in a truly isolated environment.