Microsoft’s latest Windows Subsystem for Linux preview releases are small on the surface, but WSL 2.7.5 carries a kernel jump that developers and administrators should not ignore. WSL 2.7.7, released on May 19, 2026, appears to be a narrow package-version correction, while WSL 2.7.5, released on May 15, 2026, introduces Microsoft’s first 6.18-based WSL kernel package in the 2.7.x preview line. Both releases are marked as pre-release builds on Microsoft’s WSL GitHub page, so they should be treated as preview/test builds rather than quiet production rollouts for every Windows user.
WSL 2.7.7 is a very small release. Microsoft’s public changelog lists only one item: “Update Microsoft.WSL to version 1.0.73.2” by Ben Hillis.
The underlying pull request is more specific than the release-note wording. It describes a WSLg NuGet dependency version change, with
That makes WSL 2.7.7 look less like a feature release and more like a servicing or packaging fix. There is no public evidence in the 2.7.7 changelog of a new WSL kernel, new command-line option, networking change, or major user-facing behavior change. For most users, that means WSL 2.7.7 is not something to chase unless they are already tracking preview builds or were affected by the package issue Microsoft was correcting.
The WSL2 Linux kernel repository describes
The new logic attempts to call
That will not matter to every WSL user, but it matters for advanced and managed setups: custom kernels, custom kernel module VHDs, private system distro VHDs, enterprise-managed images, or scenarios where VHDs live outside the default WSL storage paths.
Microsoft maintainer Ben Hillis noted in the WSL 2.7.5 GitHub discussion that this is the first WSL release with a 6.18 kernel and asked users to report issues with the new major kernel version.
That warning matters because WSL sits underneath a lot of developer workflows. Docker Desktop, dev containers, local Kubernetes tools, custom networking setups, filesystem workflows, and enterprise Linux images can all depend on low-level behavior that users rarely think about until it changes.
There is already community concern around Docker Desktop compatibility. In the 2.7.5 discussion, one user reports that Docker Desktop’s WSL2 backend can fail with a netlink-related error when running against a 6.18.x WSL kernel, and Hillis responded that he would “figure out a story here.” That does not necessarily mean every Docker Desktop user will hit the issue, but it is enough reason for developers and IT admins to test before adopting these previews in daily workflows.
Developers, Docker users, custom-kernel testers, and IT administrators should pay closer attention. The 6.18 kernel transition is the kind of change that can fix old issues while also surfacing new compatibility problems.
To check the installed WSL version, run:
To test the latest WSL preview without moving the whole PC to a Windows Insider channel, Microsoft documents:
Microsoft’s WSL documentation describes WSL as a way to run GNU/Linux environments, command-line tools, utilities, and applications directly on Windows without the overhead of a traditional virtual machine or dual-boot setup.
WSL 2.7.7 Is Mostly a Packaging Correction
WSL 2.7.7 is a very small release. Microsoft’s public changelog lists only one item: “Update Microsoft.WSL to version 1.0.73.2” by Ben Hillis.The underlying pull request is more specific than the release-note wording. It describes a WSLg NuGet dependency version change, with
Microsoft.WSLg moving from 1.0.74.1 to 1.0.73.2 in packages.config. The PR discussion also notes that this WSLg package is identical to the previous one but has the correct version number.That makes WSL 2.7.7 look less like a feature release and more like a servicing or packaging fix. There is no public evidence in the 2.7.7 changelog of a new WSL kernel, new command-line option, networking change, or major user-facing behavior change. For most users, that means WSL 2.7.7 is not something to chase unless they are already tracking preview builds or were affected by the package issue Microsoft was correcting.
WSL 2.7.5 Is the More Important Release
WSL 2.7.5 is the meaningful update in this pair. Microsoft lists two changes for the release:- The WSL kernel package was updated to
Microsoft.WSL.Kernel 6.18.26.1. - The WSL service gained a best-effort fix to grant VMWP access to user-supplied VHDs.
6.18.26.1-1 and includes test changes for Linux 6.18 behavior, including eventfd validation, lxtfs writev expectations, and /proc/mounts output where 9p filesystem cache formatting now appears in hexadecimal form.The WSL2 Linux kernel repository describes
linux-msft-wsl-6.18.26.1 as an update to stable kernel version v6.18.26, with an additional patch to catch malformed packets sent from the hypervisor. That same kernel repository also shows linux-msft-wsl-6.18.26.2 released on May 15 with a patch allowing HV PCI to reserve specific memory. The WSL 2.7.5 application release itself, however, explicitly references Microsoft.WSL.Kernel 6.18.26.1.The VHD Access Fix Targets Advanced WSL Setups
The second WSL 2.7.5 change is aimed at users who work with custom or user-supplied VHDs. Microsoft’s PR explains that HCS could fail withE_ACCESSDENIED when starting a VM whose user-supplied kernelModules or systemDistro VHDs were located somewhere the Virtual Machine Worker Process could not read, such as under a user profile.The new logic attempts to call
HcsGrantVmAccess on those paths while impersonating the user before the VM starts. If access still cannot be granted, WSL should continue to surface a clear E_ACCESSDENIED error.That will not matter to every WSL user, but it matters for advanced and managed setups: custom kernels, custom kernel module VHDs, private system distro VHDs, enterprise-managed images, or scenarios where VHDs live outside the default WSL storage paths.
The 6.18 Kernel Is the Real Story
The move to a 6.18-based WSL kernel is the biggest technical shift in these two releases. A newer kernel can bring upstream Linux fixes, newer subsystem behavior, and better alignment with modern Linux tooling, but it can also expose compatibility problems in software that assumes older kernel behavior.Microsoft maintainer Ben Hillis noted in the WSL 2.7.5 GitHub discussion that this is the first WSL release with a 6.18 kernel and asked users to report issues with the new major kernel version.
That warning matters because WSL sits underneath a lot of developer workflows. Docker Desktop, dev containers, local Kubernetes tools, custom networking setups, filesystem workflows, and enterprise Linux images can all depend on low-level behavior that users rarely think about until it changes.
There is already community concern around Docker Desktop compatibility. In the 2.7.5 discussion, one user reports that Docker Desktop’s WSL2 backend can fail with a netlink-related error when running against a 6.18.x WSL kernel, and Hillis responded that he would “figure out a story here.” That does not necessarily mean every Docker Desktop user will hit the issue, but it is enough reason for developers and IT admins to test before adopting these previews in daily workflows.
What Windows Users Should Do
Casual WSL users do not need to rush into these preview releases. The 2.7.7 release is tiny, and the 2.7.5 release is important mainly because of a low-level kernel transition and a VHD access fix that affects more advanced configurations.Developers, Docker users, custom-kernel testers, and IT administrators should pay closer attention. The 6.18 kernel transition is the kind of change that can fix old issues while also surfacing new compatibility problems.
To check the installed WSL version, run:
Code:
wsl --version
Code:
wsl.exe --update --pre-releaseThe Practical Takeaway
The two releases should not be treated as equal in importance.- WSL 2.7.7 appears to be a small WSLg package-version correction, despite the broader wording in the public release note.
- WSL 2.7.5 introduces
Microsoft.WSL.Kernel 6.18.26.1, making it the major technical change to watch. - The VHD access fix is mainly relevant to advanced setups using custom or user-supplied VHDs.
- Developers using Docker Desktop or other WSL2-dependent tooling should test carefully before relying on the new preview kernel.
- Regular users can stay on stable WSL builds unless they specifically need to test the preview branch.
References
- Official source: Microsoft/WSL releases
- Official source: WSL PR #40585: Update Microsoft.WSL to version 1.0.73.2
- Official source: WSL 2.7.3...2.7.5 comparison
- Official source: WSL PR #40485: Best-effort grant of VMWP access to user-supplied VHDs
- Official source: Microsoft WSL2 Linux kernel releases
- Official source: WSL 2.7.5 GitHub discussion
- Official source: Microsoft Learn: Install WSL
- Official source: Microsoft Learn: WSL documentation
Last edited:
