On October 6, 2026 (Japan time), Microsoft released version 3.0.2 of the Windows Subsystem for Linux (WSL), which runs Linux on Windows, as a pre-release. The update fixes a problem that prevented virtual machines with a large number of CPUs from booting. It also re-enables, as an experimental feature, sparse VHD, which makes it easier to return free space in a virtual disk to Windows. The update arrives right after WSL containers became generally available on September 29, but its changes go beyond container features. What matters is how it changes the existing constraints for people running Linux on Windows machines with many CPUs, or managing bloated virtual disks.
As of October 6, the "Latest" label for the stable release on GitHub still points to 3.0.1, while 3.0.2 carries a "Pre-release" tag. The general availability of WSL containers and the pre-release status of 3.0.2 need to be considered separately. Normal updates do not mean every user will move to 3.0.2 right away.
Why 384 logical processors could not boot
The boot failure was triggered by a report from a two-socket Intel Xeon 6 6972P server. With Hyper-Threading enabled on Windows Server 2025, the OS recognizes 384 logical processors. On this system, attempting to start Debian 13 with WSL 2.9.13.0 produced the error "The parameter is incorrect" during virtual machine creation. Limiting the number of processors assigned to WSL to 256 allowed it to start, but setting it back to 384 caused the failure again. The 384 here is not the number of physical cores but the number of logical processors visible to the OS.
Microsoft developer Ben Hillis traced the cause to the virtual machine configuration passed to the Windows Host Compute Service (HCS). Previously, WSL did not specify a NUMA configuration for the virtual machine, and in that case HCS treated the entire VM as a single virtual NUMA node/socket. In the reporter's logs, the attempt to assign 384 logical processors in that state exceeded the limit of 256 per socket.
NUMA refers to a configuration in which memory access speed depends on the physical relationship between CPUs and memory. In systems with multiple CPUs, accessing memory close to a CPU is faster than accessing memory attached to another CPU. Virtual NUMA (vNUMA) communicates this layout to the OS inside a virtual machine, allowing the OS and compatible applications to take CPU and memory placement into account.
With this fix, WSL now passes an empty NUMA configuration to HCS. Rather than WSL specifying the vNUMA layout itself, HCS automatically generates an appropriate vNUMA configuration based on the requested resources and the host's physical topology. This behavior is enabled on Windows build 26100 and later, and applies to both regular WSL and WSL containers (WSLC). Older Windows builds keep the previous configuration.
On October 2, the reporter said Debian booted with a development build containing the fix and that Linux's nproc recognized 384. So, for the boot failure at least, the fix was confirmed on the machine where the problem occurred. However, this was not a re-verification with the official 3.0.2 release, nor was it a performance measurement. For builds and verification workloads that use many CPUs, it will be necessary to separately check how far performance actually scales under load, beyond simply being able to boot.
Sparse VHD is not new, but an experimental re-enablement
WSL's virtual disks have long been designed so that the file size grows with the amount of data stored. The Linux file system is stored in ext4.vhdx on Windows, and the virtual disk expands as needed. It would therefore be inaccurate to describe this change as "previously the maximum capacity was reserved up front, but from now on only the space used is consumed."
The aim of sparse VHD is to make it easier for Windows to reclaim space that is no longer needed after a virtual disk has grown. By treating space freed on the Linux side as space that consumes no physical storage on the host, disk usage as seen from Windows can be reduced.
Microsoft had already introduced sparse VHD in September 2023 as an experimental feature that could automatically shrink WSL VHDs while in use. It is not a feature introduced for the first time now.
The changes included in 3.0.2 show that the earlier code had disabled the creation of new sparse VHDs because of the possibility of data corruption. Enabling sparse mode on an existing virtual disk also required specifying --allow-unsafe. This restriction has now been removed and replaced with a warning stating that this is an experimental feature and that users should report any unexpected problems. The old --allow-unsafe argument is still accepted for compatibility.
However, lifting the restriction does not guarantee that the causes of the previously raised data corruption concerns have been completely resolved. This change simply makes it possible to try the feature again as an experimental one. The release also provides no measured data on how it should be used or how much capacity can be reclaimed.
To use sparse VHD with newly created regular WSL distributions, add the following setting to the .wslconfig file in your Windows user folder. The default value of sparseVhd is false, so updating to 3.0.2 does not automatically switch all virtual disks.
[experimental]
sparseVhd=trueExisting distributions are also not converted automatically by this setting alone. Stop the target distribution, then run, for example for Ubuntu, wsl --manage Ubuntu --set-sparse true.
Changes to .wslconfig also do not take effect until the WSL virtual machine is stopped and restarted. Running wsl --shutdown stops all running WSL distributions, so it is sensible to close any applications running on Linux first and to try this in a test environment initially.
Even in 3.0.2, regular WSL and WSLC are affected differently
Cross-checking primary sources as of October 6, 2026, the vNUMA change applies to both regular WSL and WSLC. The sparse VHD re-enabled in 3.0.2, on the other hand, targets regular WSL distributions, while support for WSLC session storage and named volumes is still being developed in a separate PR.
| Change / target | What changes in 3.0.2 | Conditions and caveats |
|---|---|---|
| vNUMA for regular WSL and WSLC | HCS automatically generates the virtual NUMA configuration | Windows build 26100 or later |
| VHDs of new WSL distributions | Can be created as sparse VHDs | Requires explicit sparseVhd=true; off by default |
| VHDs of existing WSL distributions | --allow-unsafe no longer needed to switch to sparse mode |
Stop the target and change each one individually |
| VHDs created as fixed size | Not covered by the sparse setting | When created as fixed VHDs |
| WSLC session storage and named volumes | Support under development in a separate PR | Not merged as of October 6; release timing undecided |
The table organizes the descriptions and changes in Microsoft's vNUMA PR and sparse VHD PR, cross-checked against the official configuration table and follow-up PR #41742 for WSLC, by target and applicable conditions. It is not a table comparing speed or capacity savings.
The follow-up PR for WSLC proposes making experimental sparse VHD available for session storage and named volumes, and adding a setting to use it for the default session. Even within the same WSL package, the implementation is split between regular Linux distributions and the container-specific storage. It would be a mistake to assume that existing WSLC sessions will shrink automatically just by updating to 3.0.2.
Making container state easier to track, not just run
In WSLC, wslc events --format json now outputs events as one JSON object per line. Because timestamps are included, it is easier for programs to handle events than parsing human-oriented tabular output.
A change was also added that reports container health check results to wslc events. This means that, beyond a feature for checking container status, a mechanism for continuously receiving changes in that status has been put in place.
The events recorded for terminated containers are also more detailed. The die event records the exit code, and stop is treated as a separate event. Events requesting a stop or termination are stored on the session side, so they can be traced even after a container has been automatically removed. This is useful for investigating the cause of abnormal exits or switching follow-up processing depending on the exit code.
However, adopting a Docker-like event format does not guarantee that existing Docker scripts will work as they are. The PR that added JSON output also explicitly states that full compatibility with Docker is not guaranteed. When migrating, you need to check the fields your processing references and the meaning of each event.
On the networking side, a problem was fixed in NAT-mode localhost forwarding, where dual-stack listening that accepts both IPv4 and IPv6 was not recognized correctly and only IPv6 forwarding was created on the Windows side. For dual-stack listeners, IPv4 forwarding is now created as well, a change that affects development environments where services running inside Linux are accessed from the Windows side.
This is, however, a fix for a specific bug in NAT localhost forwarding, and does not mean that WSL networking problems in general, including those involving VPNs, have been resolved.
On large virtual machines, the question is how well the many CPUs can actually be used after the VM can boot. For sparse VHD, it is how much Windows-side storage usage can actually be reduced. For WSLC, it is whether changes in container state can be monitored and tied into automated processing. When evaluating 3.0.2, each of these needs to be verified in your actual environment.
If these changes make their way into the stable release and verification across a variety of environments progresses, they could reduce the effort involved in storage management and troubleshooting for people who use Linux on Windows day to day.