WSL 2.9.9 Fixes WSLC Stalls; 2.7.12 Remains Stable

The 2.9.9 release is only nine commits beyond 2.9.8, but its contents are unusually concentrated around correctness boundaries that routinely cause expensive support incidents: command handling, filesystem targets, container stop/delete races, machine-readable output, and guest networking results. Microsoft’s GitHub release notes list the changes; the underlying pull requests show why calling this a routine “minor fixes” build would understate its value for preview users.

Microsoft Learn separately documents that WSL Containers require WSL 2.9.3 or later and are available only through the pre-release channel. That makes 2.9.9 a maintenance release for an already-public preview, rather than the debut of a new container platform. The distinction matters when planning a pilot: this update improves a moving target, and it does not turn WSLC into a production-certified replacement for Docker Desktop, Podman, or an existing enterprise container runtime.

The security fixes are real, but Microsoft assigned no new CVE​

The largest cluster of fixes comes from Microsoft’s “batch of minor issues” pull request. Despite that modest label, the list includes prevention of command injection through --set-default-user, validation intended to stop malicious input driving oversized socket-address allocations, and a filesystem fix to prevent WSL’s mini-init path from overwriting a distribution symlink target.

It also corrects acceptance of conflicting distribution-export formats, preserves the Guest Network Service virtual-machine identifier, and cleans up an HNS network endpoint during move assignment. These are security-relevant and reliability-relevant fixes, particularly in environments where WSL commands are wrapped by provisioning tools, developer portals, or elevated automation.

There is an important limit on what can be said: Microsoft did not assign a WSL 2.9.9-specific CVE in the release material. Administrators should treat the fixes as hardening and bug remediation, not report a named vulnerability disclosure that does not exist. Likewise, CVEs addressed by dependencies in earlier 2.9 releases are historical context, not evidence of a newly disclosed 2.9.9 issue.

Container lifecycle work removes several ways WSLC could stall​

The engineering centerpiece is a substantial redesign of WSLC container lifecycle coordination. Microsoft’s pull request for the change says Start, Stop, and Delete operations now use a shared StateTransition object instead of separate stop and destroy events guarded by conflicting locks.

The old arrangement could leave a second lifecycle operation waiting behind a Stop request, including a stop configured to wait indefinitely. Delete and auto-remove paths also relied on fixed 60-second waits. In container automation, that is exactly the kind of behavior that turns a simple cleanup failure into a stalled CI job, a stuck service session, or an operator reaching for a full WSL shutdown.

The new approach lets callers join an identical transition already under way while serializing conflicting operations. Microsoft also moved Docker event callbacks outside the tracker lock. The code review record describes a lock-order inversion between Exec and event delivery that could wedge the event stream for an entire session, plus an iterator-invalidating callback-unregistration path during container shutdown.

For a developer manually starting and stopping a single test image, these changes may be invisible. For anyone running concurrent stop, kill, delete, exec, auto-remove, or test-harness cleanup operations, they are the strongest reason to prefer 2.9.9 over an earlier 2.9 preview. They are also a reason to pilot it narrowly: a 52-commit lifecycle redesign deserves adversarial concurrency testing before it is placed underneath build agents or shared developer infrastructure.

Mirrored networking will now report guest failures instead of hiding them​

WSL 2.9.9 changes how Windows interprets callbacks from the Guest Network Service in mirrored networking mode. Previously, Windows could see that communication with the Linux guest succeeded and mark a requested networking change successful even when Linux returned an error applying the address, route, interface, or DNS update.

Microsoft’s implementation now separates the two outcomes. A transport failure remains a failure. A successful transport combined with a zero Linux result remains successful. But a successful transport plus a nonzero Linux result is now reported as an operation failure; the special ConnectTest behavior remains unchanged.

This is a correctness fix, not evidence that 2.9.9 breaks networking. It may, however, make an existing guest-side configuration fault visible for the first time and trigger retries that did not occur on earlier preview builds. That makes enterprise network canaries essential, especially where mirrored mode meets VPN clients, DNS tunneling, proxy propagation, Hyper-V firewall rules, managed endpoint security, or split-DNS policies.

Microsoft’s WSL networking documentation positions mirrored networking, DNS tunneling, auto-proxy propagation, IPv6, and multicast as advanced capabilities for Windows 11 22H2 and later. A Windows 11 22H2-or-newer canary is therefore a more defensible enterprise test target than treating every Windows 10 or Windows Server configuration as equivalent. WSL 2 can run on those platforms, but feature availability is not the same thing as a formal WSLC support matrix.

CLI compatibility improves, but automation needs a schema and time audit​

Microsoft is also making wslc act more like Docker’s command-line tooling in two places that scripts frequently depend on: timestamps and JSON output.

For wslc logs and related --since and --until options, 2.9.9 consolidates timestamp parsing and accepts epoch seconds, Go-style durations such as 10m, 1h30m, and 1.5h, partial local timestamps, date-only input, RFC3339 timestamps, and dates before 1970. It rejects invalid duration units and impossible calendar dates rather than silently trying to accommodate them. The change also corrects a path that treated a UTC value as local time.

That wider grammar is helpful for Docker-oriented operators, but the safe choice for automation remains explicit RFC3339 with a timezone:

wslc logs mycontainer --since 2026-08-25T22:00:00Z

Zone-less dates are intentionally interpreted in local time. A script that worked by accident across a single time zone can therefore still create ambiguous monitoring windows when it lands on geographically distributed build agents.

The wslc volume list --format json change is more likely to break a brittle pipeline than the timestamp work. It expands output from Name and Driver to Docker’s ten-key JSON shape, including Availability, Labels, Mountpoint, Scope, Size, and Status. Microsoft says the volume tests passed, and the public WSLC compatibility interface was not changed. But public API compatibility does not protect scripts that assert an exact two-property JSON object or snapshot-test the full serialized output.

Before broad deployment, teams using WSLC should test their JSON consumers against the new result. Parsers that select named properties or ignore unknown keys should gain information without trouble. Validators that enforce an exact schema need updating.

Deploy it as a versioned pilot, not as an estate-wide update​

The default recommendation is straightforward. Keep general developer machines on stable WSL 2.7.12 unless they have a specific need for WSL Containers. The pre-release label is not cosmetic: Microsoft Learn still requires the pre-release channel for WSLC, and Microsoft has not published a formal Docker Desktop coexistence matrix or a dedicated 2.9.9 certification matrix for Windows Server SKUs.

For a controlled pilot, begin by recording the current state:

wsl --version
wsl --status
wsl --list --verbose
wsl --shutdown

Export valuable distributions before changing the application package. A tar export is broadly portable:

wsl --export Ubuntu D:\WSL-Backups\Ubuntu-before-2.9.9.tar

A WSL 2 VHD-style export can preserve the virtual disk format:

wsl --export Ubuntu D:\WSL-Backups\Ubuntu-before-2.9.9.vhdx --vhd

wsl --update --pre-release is Microsoft’s documented way to enter the preview channel, but it follows the newest preview rather than pinning a workstation permanently to 2.9.9. Reproducible enterprise testing should instead use the architecture-appropriate installer from the specific 2.9.9 GitHub release, then repeat the version, status, and distribution checks after wsl --shutdown.

Validate the feature that justified the pilot. Run wslc version, start a disposable container, check image and container listings, expose a local web port, and verify that curl.exe reaches it from Windows. Exercise wslc volume list --format json in the same pipeline that consumes it, and test wslc logs with both relative durations and UTC timestamps.

For mirrored-mode canaries, inspect ip addr, ip route, /etc/resolv.conf, DNS resolution, outbound HTTPS, VPN behavior, and Hyper-V firewall policy. Apply .wslconfig changes only after wsl --shutdown; otherwise, testing can accidentally measure the previous virtual-machine configuration.

WSL 2.9.9 is small by feature count and consequential by engineering depth. It is a sensible upgrade for teams already evaluating WSLC, particularly where container lifecycle automation or mirrored networking has been unreliable. It remains a pilot build, however, and stable 2.7.12 is still the right baseline for the broader Windows developer estate.