The Depths of Windows Virtualization (Part 3) — Virtual Machines That Boot in Seconds: Why WSL2, Windows Sandbox, and Containers Are So Light

A full VM is heavy, so why are WSL2 and Windows Sandbox light? The final part of this series explains the difference not only from “what is isolated” but from “what does not have to be duplicated.”

When you create a Windows VM in Hyper-V Manager, it takes tens of seconds to start and reserves several gigabytes of memory. On the same PC, typing wsl returns a Linux shell within seconds, and Windows Sandbox also opens a disposable desktop in seconds.¹

The foundation in every case is the Windows hypervisor we saw in Part 1. In Part 2 we confirmed that this foundation can build isolation stronger than the kernel. This article looks separately at WSL2’s specialization, Sandbox’s sharing, and the isolation modes of containers.

“The Depths of Windows Virtualization” — All 3 Parts

We look at the same Windows hypervisor in the order foundation → security isolation → application to lightweight VMs.

Prerequisites for This Article

How to Read This Article

1. The Bottom Line First

A lightweight VM keeps the isolation line (a dedicated kernel and the hypervisor boundary) and lightens the “copy of a complete guest OS.” Sandbox shares the host’s own Windows, WSL2 replaces the guest with a small, purpose-built Linux, and in both cases memory is not a fixed reservation but is shared dynamically with the host.

The source of a full VM’s weight is not isolation itself but duplication: another OS image on disk, another OS’s worth of pages in RAM, and another full boot every time it starts. The lightweight VMs cut this duplication with two policies: “share what is safe to share” (Sandbox) and “if it cannot be shared, rebuild it small” (WSL2).

flowchart TB
    accTitle: The three kinds of sharing behind lightweight VMs
    accDescr: The OS image a full VM duplicated is cut by sharing in Sandbox and by shrinking in WSL2, memory that is a fixed allocation by default (Dynamic Memory configurations are the exception) becomes dynamic lending and borrowing with the host, and startup is replaced by a lightweight kernel and a minimal configuration, leaving only the isolation boundary
    heavy["The source of a full VM's weight is duplication"] --> d1["Disk: a duplicate OS image"]
    heavy --> d2["Memory: fixed allocation by default"]
    heavy --> d3["Startup: another full boot"]
    d1 -->|replaced by| s1["Sharing (Sandbox) or shrinking (WSL2)"]
    d2 -->|replaced by| s2["Lent and borrowed dynamically with the host"]
    d3 -->|replaced by| s3["Shortened by a lightweight kernel and a minimal configuration"]

Figure 1: They stopped duplicating, not isolating, and that is the skeleton of the answer to “same hypervisor, yet light.”

Below, we look at WSL2, Windows Sandbox, and containers in that order, and at which duplication each of them cuts.

In the diagram a solid line marks a relation that always holds and a dashed line marks a conditional one (the conditions are given per relation on the detail page). The full list of relations (19 in total, with evidence and certainty) and the definitions of the main concepts are collected on the knowledge map detail page (in Japanese). Data: JSON-LD / Turtle

2. What a Full VM Carries

As a baseline for comparison, here is what a traditional VM carries.

• An independent OS image. It holds every file of the guest OS inside a virtual disk. Even if the host runs the same Windows, nothing is shared.
• Coarse memory allocation. A traditional VM allocates host memory at a static size by default. There are mechanisms such as Hyper-V Dynamic Memory that grow and shrink the allocation within a configured range, but the means of adjusting to changes in demand are limited.²
• A general-purpose full boot. Firmware, boot loader, and services start in the same sequence as on a physical machine.

flowchart TB
    accTitle: The three loads a full VM carries
    accDescr: A full VM carries an independent OS image, memory allocation that is static by default, and a general-purpose full boot, and these show up as costs in disk, RAM, and startup time
    fullvm["Full VM"] --> b1["Independent OS image"]
    fullvm --> b2["Memory allocation that is static by default"]
    fullvm --> b3["General-purpose full boot"]
    b1 -.-> c1["Consumes disk for the duplicate"]
    b2 -.-> c2["Tends to hold RAM it is not using"]
    b3 -.-> c3["Takes tens of seconds to start"]

Figure 2: Every item in a full VM’s cost breakdown is paid for generality and duplication, not for isolation.

These are not defects; they are the price of the generality of being able to put anything in the guest. For a use such as running an old Linux next to Windows Server, that generality is exactly the value. But when the need is “run the same OS as the host (or a fixed one) right now, for development or validation,” most of it is dead weight. Lightweight VMs put that baggage down by narrowing their purpose.

3. WSL2 — A Utility VM Carrying a Purpose-Built Kernel

WSL2 is easiest to follow in the order structure → where files live → returning memory. Using a genuine Linux kernel and handling Windows-side files fast are two separate matters.

3.1. Structure: A Managed VM and the Distributions Inside It

WSL2 is a mechanism that runs a genuine Linux kernel inside a lightweight utility VM.³ There are three points.

The Kernel Is Genuine, but Specialized

It is a Linux kernel that Microsoft builds from the Stable branch, tuned in size and performance for WSL2. With the current standard, the WSL distributed through the Microsoft Store, the kernel is updated together with the WSL package itself and applied with wsl --update (the older in-box distribution received it through Windows Update).⁴

Because it is a genuine kernel, system-call compatibility is complete, and tools such as Docker run as they are.

The VM Stays Behind the Scenes

WSL manages creating, starting, and stopping the VM; the user just opens a shell. There is no VM settings screen and no perceptible wait for a boot.⁴

Distributions Are Containers Inside the VM

Each distribution, such as Ubuntu or Debian, runs as an isolated container inside a single managed VM. They share the network namespace and the kernel, while namespaces such as PID, mount, and user are separated.³

flowchart TB
    accTitle: WSL2 architecture
    accDescr: The host Windows and a lightweight utility VM sit side by side on the hypervisor, a Microsoft-built Linux kernel runs inside the VM, and each distribution runs as an isolated container inside it
    hv["Hypervisor"] --> host["Host Windows"]
    hv --> uvm["Lightweight utility VM"]
    uvm --> lk["Linux kernel (Microsoft build, updated with wsl --update)"]
    lk --> u1["Ubuntu (container)"]
    lk --> u2["Debian (container)"]
    host <-->|"Interop (commands, files, network)"| uvm

Figure 3: The answer to “is WSL2 a VM?” is “yes, but a managed VM that stays out of sight,” and even with several distributions installed there is still only one VM.

Here is what happens behind the scenes the moment you type wsl.

flowchart TB
    accTitle: From running the wsl command to a shell returning in seconds
    accDescr: When wsl runs, the lightweight VM and Linux kernel are started if the utility VM is not yet running, the existing VM is used as is if it is, and a shell returns in the distribution's container
    cmd["Run wsl"] --> vmq{"Is the utility VM already running?"}
    vmq -->|No| bootvm["Start the lightweight VM and Linux kernel (seconds)"]
    vmq -->|Yes| reuse["Use the running VM as is"]
    bootvm --> shell["A shell returns inside the container"]
    reuse --> shell

Figure 4: The wait is nothing more than a minimal VM start, and this is where putting down the baggage of a full boot pays off.

3.2. File I/O: Which Side the Files Live On Makes All the Difference

Where files are placed comes up in every discussion of WSL2 performance.

• Operations on files on the Linux side (the ext4 virtual disk) are fast. The Linux kernel handles its own file system directly, and speed-ups of up to 20x over WSL1 for tarball extraction and 2 to 5x for git clone and npm install have been reported.⁴
• Operations on files on the Windows side (/mnt/c and the like) are slower because they go through a file share that crosses the OS boundary. Performance across OS file systems is the one major area where WSL2 falls behind WSL1.⁴

So the rule is: put project files on the same OS side as the tools that operate on them.⁴ A repository handled by Linux build tools goes on the Linux side; a solution built in Visual Studio goes on the Windows side.

flowchart TB
    accTitle: The fork in WSL2 file I/O paths
    accDescr: Access to the Linux-side ext4 virtual disk is fast because the Linux kernel reaches it directly, while access to Windows-side files is slow because it goes through a file share that crosses the OS boundary
    io["File operation inside WSL2"] --> place{"Which side is the file on?"}
    place -->|"Linux side (home directory, etc.)"| ext4["Direct I/O to the ext4 virtual disk"]
    place -->|"Windows side (/mnt/c, etc.)"| p9["Through a share that crosses the OS boundary"]
    ext4 --> fast["Fast (up to 20x over WSL1 in one example)"]
    p9 --> slow["Tends to be slow"]
    slow -.-> fix["Fix: put the file on the OS that uses it"]

Figure 5: What is slow is the path, not WSL2, so simply changing where the files live often makes the performance problem disappear.

3.3. Memory: It Grows, It Shrinks, but It Does Not Return Everything

WSL2’s memory usage (visible as the vmmem process in Task Manager) is not a fixed reservation; it grows and shrinks with use.

Returning Memory That Processes Have Released

Memory that processes have released is returned to Windows automatically under the pageReporting setting, which is enabled by default.⁵

Reclaiming the File Cache

Pages held as file cache once did not return to Windows until the VM shut down.⁴ In current WSL, the experimental .wslconfig setting autoMemoryReclaim (default dropCache) reclaims the cache automatically as well.⁵

In environments where this setting is disabled, or on older WSL, the cache from a long session can remain until the VM shuts down and put pressure on host memory.

flowchart TB
    accTitle: How WSL2 memory grows, shrinks, and is returned
    accDescr: Growing demand inside WSL2 raises the VM's memory usage, memory released by processes is returned to Windows under pageReporting which is enabled by default, the file cache is reclaimed automatically by autoMemoryReclaim by default, but with these disabled or on older WSL it remains until the VM shuts down, and wsl shutdown returns everything
    grow["Memory demand grows inside WSL2"] --> vm["vmmem usage grows"]
    vm --> freed{"Has that page been released?"}
    freed -->|"Released by a process (with pageReporting enabled)"| ret["Returned to Windows automatically"]
    freed -->|Held as file cache| amr["Reclaimed automatically by autoMemoryReclaim (default)"]
    amr -.-> old2["Remains until the VM shuts down if disabled or on older WSL"]
    old2 --> sd["wsl --shutdown returns everything"]

Figure 6: What looks like “it only ever grows” is mainly the cache (with pageReporting disabled, memory released by processes stays too), so learn the return paths before you call it a leak.

Setting a Memory Ceiling

If you want an explicit ceiling, %UserProfile%\.wslconfig controls the memory, processor count, and swap of the VM as a whole.⁵

# %UserProfile%\.wslconfig
[wsl2]
memory=8GB
processors=4
swap=2GB

After changing the settings, restart the VM with wsl --shutdown for them to take effect. This dynamic allocation, where a setting decides the ceiling and demand decides the actual usage, is taken even further by Windows Sandbox, which comes next.

4. Windows Sandbox — Using the Host’s Windows One More Time

Sandbox’s lightness breaks down into three parts: sharing OS files on disk, sharing OS pages in RAM, and coordinating memory allocation with the host.

4.1. Dynamic Base Image: A Complete Windows in 500 MB

Windows Sandbox is a disposable Windows desktop isolated by the hypervisor. Close it and everything disappears; the next time, it starts in seconds from a pristine state.¹

The first puzzle is the disk. It can boot a complete Windows, yet Sandbox’s base image is only about 500 MB after installation and 30 MB compressed for distribution.² The secret is the dynamic base image.

• Most OS files are immutable and can be shared as they are from the host.
• Only the small number of mutable files cannot be shared, so a clean copy of them is kept inside the base image.
• At startup, the host’s immutable files and the local copies of the mutable files are combined into a complete Windows image.²

In other words, Sandbox neither downloads nor stores a copy of Windows; it starts by reusing the Windows already installed on the host.

flowchart TB
    accTitle: How the dynamic base image is assembled
    accDescr: The immutable OS files of the host's Windows are shared, only the mutable files are kept as a clean copy in the base image, and the two are combined into the Sandbox's complete Windows image
    hostw["The host's complete Windows"] --> imm["Immutable OS files (the vast majority)"]
    hostw --> mut["Mutable OS files (a few)"]
    imm -->|shared as is| img["Sandbox boot image"]
    mut -->|clean copy kept| img
    img --> boot["Boots as a complete Windows"]
    img -.-> size["Only about 500 MB needs to be stored"]

Figure 7: Not “keep another Windows” but “assemble one from the host’s Windows” is what giving up disk duplication looks like.

This composition is exactly what makes the following lifecycle possible.

Note that what is discarded is the local state inside the Sandbox.

If you map a writable folder from the host in the .wsb configuration file, changes made there remain on the host side.⁶

flowchart TB
    accTitle: The Windows Sandbox lifecycle
    accDescr: Starting prepares a pristine Windows in seconds, after app validation or experiments closing discards all state inside the Sandbox so the next start is pristine again, but changes to a host folder mapped as writable remain
    launch["Start (seconds)"] --> clean["A pristine Windows"]
    clean --> work["App validation or experiments"]
    work --> close2["Close"]
    close2 --> discard["Discard all state inside the Sandbox"]
    discard -.-> mapped["Changes in a mapped writable folder remain on the host"]
    discard -->|next start| launch

Figure 8: It can return to a pristine state every time because the mutable part is a disposable copy, and discarding it is part of the design.

4.2. Direct Map: The Same ntdll.dll Is the Same Physical Page

Not only the disk but RAM is shared as well. Because Sandbox runs the same OS image as the host, a technique called “direct map” is used so that, for OS binaries, it uses the same physical memory pages as the host. When ntdll.dll is loaded into memory inside the Sandbox, it points at the same physical pages as the same binary loaded on the host.

This achieves a much smaller memory footprint than a traditional VM without exposing the host’s secrets to risk.²

“Share the same physical page among several users” is the same idea as DLL sharing through section objects, which we followed in Part 3 of the memory series (“Section Objects and Copy-on-Write”). That mechanism shared between processes; Sandbox does it across the VM boundary.

flowchart TB
    accTitle: Physical page sharing through direct map
    accDescr: An app on the host and an app inside the Sandbox share the same physical memory pages for OS binaries such as ntdll, reducing memory usage
    happ["App on the host"] --> hva["Host-side virtual address"]
    sapp["App inside the Sandbox"] --> sva["Sandbox-side virtual address"]
    hva --> phys["The same physical page (OS binaries such as ntdll.dll)"]
    sva --> phys
    phys -.-> save["No need to duplicate the OS's share of RAM"]

Figure 9: Direct map takes the page-sharing idea long used between processes and applies it across the VM boundary.

4.3. Lending and Borrowing Memory: More Like a Process Than a VM

In contrast to a traditional VM’s static memory allocation, the container technology underneath Sandbox decides resource allocation dynamically in coordination with the host. If the host runs short of memory, it can reclaim memory from the container just as it reclaims it from an ordinary process.² Hyper-V Dynamic Memory also grows and shrinks a VM’s allocation within a configured range, but Sandbox goes a step further: it shares memory on the same footing as the host’s own memory management.

flowchart TB
    accTitle: Memory coordination between the host and Sandbox
    accDescr: A traditional VM reserves a static size by default with limited means of adjustment, whereas Sandbox becomes a reclaim target in response to host memory pressure and shares memory on the same footing as ordinary processes
    pressure["Host memory pressure rises"] --> from{"Where to reclaim from?"}
    from --> proc["The Working Sets of ordinary processes"]
    from --> sbx["What the Sandbox (container) is using"]
    proc --> relief["Free memory is secured"]
    sbx --> relief
    relief -.-> contrast["A traditional VM has limited means of adjustment"]

Figure 10: When it comes to sharing memory, Sandbox stands on the side of processes rather than VMs, and gives memory up when the host is under pressure.

In Part 1 we said that a VM’s performance also depends on the host side; with lightweight VMs this goes one step further, and memory allocation itself becomes a joint effort with the host. This coordination is why Sandbox feels less like “heavy virtualization software” and more like just another app.

The concrete steps for using Sandbox to validate business apps are covered in the earlier article “How to Speed Up App Validation with Windows Sandbox”. This article covers the mechanism underneath it.

5. Containers — Where to Draw the Isolation Line

Here we do not judge safety by the name “container” alone; we check whether the container shares the kernel with the host or has a kernel of its own.

5.1. Process Isolation and Hyper-V Isolation

Windows containers have two runtime isolation modes. The image is the same; you choose the mode with a flag at startup.⁷

• Process isolation: several containers share the kernel with the host and are isolated by per-namespace virtualization of the file system, registry, network ports, process ID space, Object Manager namespace, and so on. This is almost the same approach as Linux containers.
• Hyper-V isolation: each container runs inside a highly optimized VM and has what is effectively a dedicated kernel. The presence of the VM puts hardware-level isolation between containers and between them and the host.⁷

Namespace-based isolation can be seen as the thoroughgoing version of the technique from the registry virtualization article (“Registry Redirection and Virtualization on Windows”): showing a different entity under the same API.

flowchart TB
    accTitle: Process isolation versus Hyper-V isolation
    accDescr: Under process isolation, containers share the kernel with the host and are isolated by namespaces, whereas under Hyper-V isolation each container has a dedicated kernel inside an optimized VM
    subgraph pi ["Process isolation"]
        c1["Container A"] --> sk1["Kernel shared with the host"]
        c2["Container B"] --> sk1
    end
    subgraph hi ["Hyper-V isolation"]
        c3["Container C"] --> k3["Dedicated kernel (inside an optimized VM)"]
        c4["Container D"] --> k4["Dedicated kernel (inside an optimized VM)"]
    end
    sk1 ~~~ c3

Figure 11: Even with the same container image, whether the isolation line is drawn above the kernel or the kernel itself is separate is chosen at startup.

5.2. Which One Can Be Called a “Security Boundary”

The difference between the two modes is not just about performance. Microsoft does not consider process-isolated containers a robust security boundary. The containers maintained as a security boundary (with vulnerability servicing) are the hypervisor-isolated ones, and in hostile multi-tenant scenarios Hyper-V isolation is the mode to choose.⁸

The VBS we saw in Part 2 was likewise designed on the premise that “the kernel can be compromised,” retreating to the hypervisor boundary. The same criterion holds in the container world. The line that confines untrusted code is drawn at the hypervisor boundary, not inside a shared kernel.

flowchart TB
    accTitle: Choosing isolation by how far the code can be trusted
    accDescr: A trusted workload takes density and performance with process isolation, while untrusted code or someone else's code gets a hypervisor boundary such as a Hyper-V isolated container, a hardened Windows Sandbox with networking and the like disabled, or an isolated VM
    trust{"Can that code be trusted?"} -->|Yes| dens["Process isolation (density and speed first)"]
    trust -->|"No, or someone else's code"| bound["Choose a hypervisor boundary"]
    bound --> opt1["Hyper-V isolated container"]
    bound --> opt2["Hardened Sandbox or isolated VM"]

Figure 12: Isolation mode is a security matter before it is a performance matter, and the level of trust decides where the line goes.

Note: Inside a VM, Check the Requirements for Nested Virtualization

Running Hyper-V isolated containers inside a Hyper-V VM means two layers of hypervisor: nested virtualization.

One level of nesting is supported in production on environments that meet the conditions (a Windows 10 / Windows Server 2016 or later host for Intel processors, a Windows 11 / Windows Server 2022 or later host for AMD processors, plus the corresponding VM configuration version in each case), and it additionally requires the setting that exposes the virtualization extensions to the outer VM (ExposeVirtualizationExtensions on Set-VMProcessor for Hyper-V).

Running WSL2 inside a VM is supported in the same way.⁹ Whether you can use WSL2 or Docker on a development VM in the cloud likewise depends on whether that VM size and configuration expose nested virtualization.

flowchart TB
    accTitle: The structure of nested virtualization
    accDescr: A cloud VM sits on the physical host's hypervisor, and inside it another hypervisor (nesting is supported for one level only) runs to support WSL2 and Hyper-V isolated containers
    phys3["The physical host's hypervisor"] --> cvm["Cloud VM (development machine)"]
    cvm --> nhv["Hypervisor inside the VM (first level of nesting)"]
    nhv --> w2["WSL2"]
    nhv --> hvc["Hyper-V isolated container"]
    nhv -.-> limit["Nesting is supported for one level only"]

Figure 13: The reason wsl runs inside a cloud VM is that nested virtualization is officially supported for exactly one level.

5.3. The Spectrum of Isolation and Lightness

Lining up everything covered so far on a single axis gives the following.

flowchart TB
    accTitle: The spectrum of isolation strength and lightness
    accDescr: Process-isolated containers are the lightest but share the kernel, WSL2, Sandbox, and Hyper-V isolated containers are lightweight VMs with a dedicated kernel (Sandbox lightened by host sharing, WSL2 by a purpose-built kernel), and a full VM is the heaviest but general-purpose
    ax["Light ← → Heavy"] ~~~ p1
    p1["Process-isolated container (shared kernel)"] --> p2["WSL2, Sandbox, Hyper-V isolation (lightweight VMs with a dedicated kernel)"]
    p2 --> p3["Full VM (runs anything, holds every duplicate)"]
    p1 -.-> n1["Boundary: namespaces"]
    p2 -.-> n2["Boundary: hypervisor"]
    p3 -.-> n3["Boundary: hypervisor + complete independence"]

Figure 14: The lightweight VMs are the middle ground that kept the hypervisor boundary while cutting duplication; how they cut it differs, with sharing for Sandbox and a purpose-built kernel for WSL2.

6. See It for Yourself

Lightness and sharing can be observed on your own machine.

6.1. WSL2 Startup Time and Memory Growth and Shrinkage

With Task Manager open, try the following.

# Perceived startup time (the first run starts the VM; later runs are faster still)
Measure-Command { wsl -e true }

# Memory usage of the WSL2 VM (vmmem / Virtual Machine Memory)
Get-Process -Name vmmem* | Select-Object Name, WorkingSet64

# Shut down the whole VM and watch the memory come back
wsl --shutdown

Run a large build or file operation inside WSL2 and vmmem grows; wsl --shutdown returns it all at once, and you can watch it happen.

6.2. Speed Differences from WSL2 File Placement

Put the same repository on the Linux side (~/repo) and on the Windows side (/mnt/c/repo), compare the time taken by git status or an extraction, and the difference from Section 3.2 shows up as numbers.

6.3. Host-Side Memory Increase When Sandbox Starts

Start Sandbox and watch the memory increase in the host’s Task Manager. That it stays far smaller than “a whole second Windows” would suggest is the effect of sharing.

To dig further into the host-side memory breakdown, the Sysinternals tools article that covers how to use RAMMap and VMMap (“Process Explorer / Handle / VMMap in Practice”) is a useful reference.

These, however, are tools for classifying host-side processes and physical memory; they do not directly observe the sharing with the guest itself.

6.4. Differences Between Windows Container Isolation Modes

If you have a Windows container environment, start the same image with docker run --isolation=process and with --isolation=hyperv, then compare the startup time and what Task Manager shows (under process isolation, the processes inside the container appear in the host’s process list) to get a feel for where the isolation line sits.⁷

Process isolation, however, requires the host and image versions to match, and on a client OS it is limited to development and test use. Hyper-V isolation allows a wider range of combinations, so make the comparison with a compatible pair.¹⁰

7. Three Misreadings to Avoid in Practice

7.1. “WSL2 Is Slow”

What is slow is not WSL2 but the file I/O path that crosses the OS boundary. In many cases, simply moving the project to the Linux side transforms the experience.⁴ Conversely, placing files that Windows tools touch on the Linux side is a disadvantage for the same reason. Decide by “put it on the same OS as whatever uses it.”

7.2. “vmmem Growing Large Is a Memory Leak”

WSL2’s memory grows and shrinks with demand, and released memory is returned. On current WSL, autoMemoryReclaim (default dropCache) also reclaims the file cache automatically, so “it stayed large” usually resolves itself over time.⁵

If it still remains, check that autoMemoryReclaim is not disabled and that pageReporting, which returns released memory, has not been turned off (and that you are not on an older WSL); then either set an explicit ceiling with memory in .wslconfig or return everything with wsl --shutdown at the end of a session.

The approach to deciding whether it is a leak is the same as in the introductory part of the memory series, “What Does Windows’ “Memory Usage” Actually Mean?”.

7.3. “It’s in a Container, So It’s Safe”

Process-isolated containers share the kernel, and by Microsoft’s standard they are not a security boundary.⁸ For running untrusted code or samples, choose isolation that has a hypervisor boundary: a Hyper-V isolated container, Windows Sandbox, or a dedicated VM.

A hypervisor boundary, however, is not a universal free pass.

Windows Sandbox’s default settings have networking enabled, which can expose an untrusted app to your internal network.¹ If you use it to run samples, either strengthen the isolation by disabling networking and clipboard redirection in the .wsb configuration file, or use a dedicated VM on an isolated network.

8. Summary — Closing the Series

The key points of Part 3.

• The lightness of lightweight VMs is the result of “stopping duplication,” not of “weakening isolation.”
• WSL2 runs a genuine Linux kernel in a managed lightweight utility VM, and distributions are isolated as containers inside that VM.³ The performance rule is to put files on the OS that uses them; memory grows and shrinks dynamically, and .wslconfig controls the ceiling.⁴⁵
• Windows Sandbox shares the host’s immutable OS files through the dynamic base image and the physical pages of the applicable OS binaries through direct map, so it holds no copy of a complete Windows.² The roughly 500 MB of mutable files and the memory of the apps you run inside it are still needed separately.
• Container isolation mode is chosen at startup, and the side that can be called a security boundary is Hyper-V isolation.⁷⁸

And putting the whole series on one page gives this.

• Part 1: Beneath Windows there is a hypervisor layer, and the host OS itself runs as the root partition. That layer arbitrates CPU and memory (SLAT) directly, and I/O for synthetic devices is mediated by the root partition (VSP) at the far end of VMBus.
• Part 2: That layer is used not only to isolate VMs from one another but also to draw a boundary stronger than the kernel (VTL) inside the same OS. Windows 11’s default security is built on top of it.
• Part 3: On the same layer, cutting duplication is what makes “a virtual machine that boots in seconds” possible. The isolation line is kept, and it has become an everyday tool.

flowchart TB
    accTitle: The whole series in one picture
    accDescr: The hypervisor directly on the hardware is Part 1, the separation of VTL0 and VTL1 inside the host Windows is Part 2, and the lightness of WSL2, Sandbox, and Hyper-V isolation on the same layer is Part 3, with process-isolated containers sharing the host kernel, Sandbox lightened by sharing, and WSL2 by a purpose-built kernel
    hw3["Hardware"] --> hv3["Hypervisor (Part 1)"]
    hv3 --> rp3["Host Windows (VTL separation is Part 2)"]
    hv3 --> lw3["WSL2, Sandbox, Hyper-V isolation (Part 3)"]
    rp3 --> pc3["Process-isolated container (shared kernel)"]
    lw3 -.-> mech3["Sandbox lightened by sharing, WSL2 by a purpose-built kernel"]

Figure 15: Stack the three parts and you have the overall picture of what lies beneath today’s Windows.

Virtualization is no longer a server-room technology, nor one only for people who stand up VMs. Beneath your Windows, it quietly supports both security and the development experience. That is where things stand today.

Related Articles

• The Depths of Windows Virtualization (Part 1) — Where Is Your Windows Actually Running? The Hypervisor and Partitions
• The Depths of Windows Virtualization (Part 2) — Memory Even the Kernel Cannot See: How VBS, HVCI, and Credential Guard Work
• The Depths of Windows Memory (Part 3) — Section Objects and Copy-on-Write
• How to Speed Up App Validation with Windows Sandbox
• Registry Redirection and Virtualization on Windows

Related Consulting Areas

KomuraSoft LLC handles setting up development environments that use WSL2 and containers, designing validation environments for Windows apps, and investigating performance and compatibility in virtualized environments.

• Windows Application Development
• Bug Investigation and Root-Cause Analysis
• Legacy Asset Reuse and Migration Support
• Contact Us

References

Related Articles

Recent articles sharing the same tags. Deepen your understanding with closely related topics.

Related Topics

These topic pages place the article in a broader service and decision context.

Where This Topic Connects

This article connects naturally to the following service pages.

Frequently Asked Questions

Common questions about the topic of this article.

Is WSL2 a VM?

Yes. WSL2 runs a genuine Linux kernel built by Microsoft inside a lightweight utility VM. WSL manages the VM behind the scenes, however, so the design never makes the user think about VM settings or wait for a boot. Each Linux distribution runs as an isolated container inside this managed VM.

Why are file operations under /mnt/c slow in WSL2?

Because access from the WSL2 Linux kernel to the Windows-side file system goes through a file share that crosses the OS boundary. Operations on the Linux file system (an ext4 virtual disk) are fast, so the rule is to keep project files on the same OS side as the tools that work on them.

Is the large memory usage of the vmmem process a leak?

In most cases it is not. WSL2 memory grows and shrinks with use, and memory that processes have released is returned to Windows under the pageReporting setting, which is enabled by default. The file cache, too, is reclaimed automatically by autoMemoryReclaim in .wslconfig (default dropCache) on current WSL. In environments where these settings are disabled, or on older WSL, the memory can remain until the VM shuts down; in that case set a ceiling with the memory setting or return it with wsl --shutdown.

How can Windows Sandbox boot a complete Windows from a few hundred megabytes of disk?

Through a mechanism called the dynamic base image. It shares the immutable OS files of the Windows already installed on the host and keeps a clean copy of only the small number of mutable files. That assembles a complete, bootable image without storing a full copy of Windows.

Are containers safer than VMs?

It depends on the isolation mode. Process-isolated containers share the kernel with the host, and Microsoft does not consider this a robust security boundary. When handling hostile code, you need to choose Hyper-V isolation, which gives each container a dedicated kernel.

Author Profile

Profile page for the article author.

Go Komura

Representative of KomuraSoft LLC

Focused on Windows software development, technical consulting, and investigations into failures that are difficult to reproduce.