Windows Subsystem for Linux September 2023 update

Craig Loewen

There is a new release for the Windows Subsystem for Linux (WSL) with new features and bug fixes! Check out the summary below, and read on to learn more about new experimental features, and some significant quality improvements.

Experimental features

We know that WSL is used for a wide array of workflows and we want to help you get the best performance and quality experience from these workflows. That’s why we are introducing new features listed below as experimental features, so you can try them and provide us feedback and we will make the features you love as default! Here’s the summary of what we’re adding:

  • Added support for new opt-in experimental features
    • autoMemoryReclaim – Makes the WSL VM shrink in memory as you use it by reclaiming cached memory
    • Sparse VHD – Automatically shrinks the WSL virtual hard disk (VHD) as you use it
    • Mirrored mode networking – A new networking mode for WSL that adds new features and improves network compatibility
    • dnsTunneling – Changes how WSL resolves DNS requests to improve network compatibility
    • firewall – Applies Windows firewall rules to WSL, and allows for advanced firewall controls for the WSL VM
    • autoProxy – Makes WSL automatically use the proxy information from Windows to improve network compatibility

To use these, create a .wslconfig file in your Windows home directory (e.g: C:\Users\<yourusername>\.wslconfig) and ensure it has an [experimental] section with each setting below it, such as this:

“` [experimental] autoMemoryReclaim=gradual

The new feature settings are explained below, please see this docs page to learn more about advanced configurations for WSL.

Automatic memory reclaim

Setting name Value Default Notes
autoMemoryReclaim string disabled Automatically releases cached memory after detecting idle CPU usage. Set to gradual for slow release, and dropcache for instant release of cached memory.

When this is set to gradual, after being idle for 5 minutes, WSL will slowly start to release cached memory in Linux and make it available as free memory back to the Windows host. This means that your WSL VM will automatically shrink in memory size when you’re not using it!

This works by WSL detecting that you’re idle by seeing if CPU usage is continuously low for 5 minutes, and then we start reclaiming cached memory by using the cgroup memory.reclaim feature. We reclaim a fixed portion of your VM’s memory size, which is calculated so that if your VM was full of cached memory it would go to zero cached memory after 30 minutes (e.g: If you have 3000MB of memory, we reclaim 100MB every minute). The memory.reclaim cgroup feature allows us to intelligently reclaim a portion of memory over time, striking a balance between performance and memory usage. However, this feature does require disabling cgroups v1 in WSL, which can cause some issues. In early testing we noticed that this will break the docker daemon when running it as a service in WSL, and so if you’re using this feature we recommend you use Docker Desktop for your docker needs. We are working with the Docker team to address this in the future.

If you’d like to customize your idle detection thresholds and more, we’d recommend doing so by not enabling this feature and creating a bash script, see this GitHub gist for instructions.

You can also set this to dropcache which will instead drop caches entirely after detecting idle, and will not require any cgroup changes.

Automatic disk space clean up (Set sparse VHD)

Setting name Value Default Notes
sparseVhd bool false When set to true, any newly created VHD will be set to sparse automatically.

WSL virtual hard disks (VHDs) grow in size as you use them, and now with this feature enabled they will automatically shrink in size too! This new setting automatically sets any new VHD to be a sparse VHD, which can automatically reduce their size. Additionally, we’ve added the wsl --manage <distro> --set-sparse <true/false> command to allow you to set your existing distros to be sparse or not if you’d like.

New Networking Mode – Mirrored

Setting name Value Default Notes
networkingMode string NAT If the value is mirrored then this turns on mirrored networking mode. Default or unrecognized strings result in NAT networking.

Networking improvements are a consistent top ask for WSL, and this feature aims to improve the networking experience in WSL! This is a complete overhaul on the traditional NAT networking architecture of WSL, to an entirely new networking mode called “Mirrored”. The goal of this mode is to mirror the network interfaces that you have on Windows into Linux, to add new networking features and improve compatibility.

Here are the current benefits to enabling this mode:

  • IPv6 support
  • Connect to Windows servers from within Linux using the localhost address 127.0.0.1
  • Connect to WSL directly from your local area network (LAN)
  • Improved networking compatibility for VPNs
  • Multicast support

There are some initial known issues, so as you explore this mode please file feedback on any bugs at the WSL GitHub repo!

Current known issues:

  • Running VS Code Remote Dev containers can result in “Address already in use” errors when binding to a port.

Please note this feature is currently only available to Windows Insiders canary and Release Preview Channel with the latest Windows 11, version 22H2 update here. You can get access now by joining the Windows Insider Program and choosing to opt in your device into the Release Preview Channel.

DNS Tunneling

Setting name Value Default Notes
dnsTunneling bool false Changes how DNS requests are proxied from WSL to Windows

One contributing factor to when WSL can’t connect to the internet, is that the DNS call to the Windows host is being blocked. This is because the networking packet for DNS sent by the WSL VM to the Windows host was being blocked by the existing networking configuration. DNS tunneling fixes this by instead using a virtualization feature to communicate with Windows directly. This allows us to resolve the DNS name request without sending a networking packet, which will allow you to get better internet connectivity even if you have a VPN, specific firewall setup, or other networking configurations. This feature should improve network compatibility, making it less likely for you to have no network connection inside of WSL.

Please note this feature is currently only available to Windows Insiders canary and Release Preview Channel with the latest Windows 11, version 22H2 update here. You can get access now by joining the Windows Insider Program and choosing to opt in your device into the Release Preview Channel.

Hyper-V Firewall

Setting name Value Default Notes
firewall bool false Setting this to true allows the Windows Firewall rules, as well as rules specific to Hyper-V traffic, to filter WSL network traffic.

Hyper-V Firewall allows you to specify firewall settings and rules that will apply to WSL. Additionally, by default all of the existing firewall settings and rules that you have on Windows will be automatically applied to your WSL distros. After you’ve enabled this, you can test it by creating new firewall rules in Windows firewall settings and seeing that they instantly apply to WSL, or you can create a new rule that applies only to WSL directly by running this in PowerShell: New-NetFirewallHyperVRule

If you’d like to learn more about firewall rules and settings, please see the help message for that command by running: New-NetFirewallHyperVRule -?.

Please note this feature is currently only available to Windows Insiders canary and Release Preview Channel with the latest Windows 11, version 22H2 update here. You can get access now by joining the Windows Insider Program and choosing to opt in your device into the Release Preview Channel.

autoProxy

Setting name Value Default Notes
autoProxy bool false Enforces WSL to use Windows’ HTTP proxy information

This feature aims to increase your network compatibility when using an HTTP proxy. Currently, if you are using an HTTP proxy on Windows it will not directly apply to your WSL distros. Normally if you’d like to set up an HTTP proxy with WSL you’d need to set it up using the same way you would on a Linux machine, else you could experience connectivity issues. This feature aims to fix that, by automatically using the HTTP proxy information on Windows to set the HTTP proxy inside of Linux.

Please note this feature is only available on Windows 11 22H2.

Fixes and improvements

This release also has some significant bug fixes:

  • GH 9231 Store WSL isn’t accessible from Session 0
    • Please note to do this you will need to call C:\Program Files\WSL\wsl.exe directly, we are working on a change to fix the inbox wsl.exe behavior in a future Windows build
  • WSL GUI apps now have Windows snapping with the keyboard (Press WIN + an arrow key to snap to the side)

To see a full and complete list of all fixes, please see the official release notes.

Getting access, feedback and questions

To get access to this new version, just run this command in PowerShell: wsl --update; wsl --update --pre-release, or you can download it manually from the WSL GitHub repository.

Please file any issues at the WSL GitHub repository, or view the WSL docs to learn more. If you have further questions you can reach out to Craig or WSL team members on Twitter. We look forwards to hearing your feedback, thank you for supporting us and happy coding!

27 comments

Comments are closed. Login to edit/delete your existing comments

  • Sebastiaan Dammann 0

    Which Windows versions are supported by this WSL update? Can I run this on Windows 10 22H2?

    • anonymous 0

      this comment has been deleted.

    • h947136 0

      Release Preview 22621.2359

      • ssxw 0

        My Windows version has been upgraded to 23H2 22631.2271, and I have also executed “wsl –update –pre-release”. However, when I open WSL, it still prompts “wsl: The Hyper-V firewall is not supported.”

        • Steve 0

          22631.2338 is working.

          • Andrew “Tallahassee” McFly 1

            I came to concur. It’s not working on me either. 23550.1000

            wsl: Hyper-V firewall is not supported
            wsl: Mirrored networking mode is not supported, falling back to NAT networking
            wsl: DNS Tunneling is not supported

    • monkeyboythom 2

      AFAIK – these features only work with Insider’s Builds, so updating WSL doesn’t get you anything at this point.

      • Andrew “Tallahassee” McFly 0

        I am on insider 23550.1000. I also ran wsl –update. Still doesn’t work.
        wsl:Hyper-V firewall is not supported
        wsl: Mirrored networking mode is not supported, falling back to NAT networking
        wsl: DNS Tunneling is not supported

  • Steven Roodhorst 1

    Looks like the ‘drop’ option is not correct for autoMemoryReclaim and it should be ‘dropcache’…

  • Ganesh Krishnan 1

    Looks like this breaks the docker due to cgroups upgrade (to v2?)

    Docker daemon has this error “failed to start daemon: Devices cgroup isn’t mounted”

    since WSL doesnt have grub, I cant find a workaround to use cgroups v1

    • Matthew Rutledge 0

      yeah cant seem to get around this either

    • Olivier BRIAT 2

      As said in the article: “The memory.reclaim cgroup feature allows us to intelligently reclaim a portion of memory over time, striking a balance between performance and memory usage. However, this feature does require disabling cgroups v1 in WSL, which can cause some issues. In early testing we noticed that this will break the docker daemon when running it as a service in WSL, and so if you’re using this feature we recommend you use Docker Desktop for your docker needs. We are working with the Docker team to address this in the future.”
      So do not use the

      autoMemoryReclaim

      option until this bug is fixed

  • Joseph Koch 3

    I’m very exited about the network mirroring feature. Do we have confirmation that this will be coming to Windows 10 as well? It appears to only be available on Windows 11 at the moment.

  • monkeyboythom 2

    Any timeline for releasing these features in the Windows 10 (especially) and Windows 11 main builds/update packages? I can’t tell users to update Win10 to an Insider’s Build.

  • Johan Töpel 0

    Question 1: I’m using both wsl1 and wsl2. I wonder if it’s still better to use wsl1 when I’m using rsync with the windows file system?
    Question 2: Is there any problems using wsl1 and wsl2 at the same time, now when they have the same ip adress?

    /Johan

  • Marcin Rybak 1

    I can confirm: the Mirrored mode works! This is a huge improvement over the Bridged mode + HyperV switch that I used before. Many thanks!
    Just one issue remains then for me: USB support in WSL2, please… 🙂

    For USB support I used usbipd, but with the Mirrored mode, it now doesn’t work:

    usbipd wsl attach -i=0403:6001
    usbipd: info: Device with hardware-id '0403:6001' found at busid '4-1'.
    usbipd: error: The selected WSL distribution cannot be reached via the WSL virtual switch; try restarting the WSL distribution.

    UPDATE: I found a workaround. In WSL2 (Ubuntu), type:

    sudo usbip attach -r localhost --busid=4-1
    • Piotr Stachów 0

      I see that You have polish name i surname, so sorry but can I write polish? I have question about problem with “mirrored”.

      • Marcin Rybak 0

        You can, if you have no other choice! :-)… but most non-Poles would be disappointed…

        • Piotr Stachów 0

          I would want create vpn connection between WSL2 and another computer in LAN. Do You help me? I installed OpenVPN server on Ubuntu in WSL2 but it is in network 10.8.0.0 and other computers 192.168.x.x. Do I must create port forward or routing or ??? OpenVPN server on WSL2 work right. I can connect from Windows host as client.

          • Marcin Rybak 0
            1. In your .wslconfig file:
            [experimental]
            networkingMode=mirrored
            firewall=true
            

            and shut wsl down and restart. You should see all your physical network cards (NICs) in Ubuntu (ip a) with the same IP addresses as you assigned in Windows.
            2. In your firewall, enable incoming traffic from the other computers on your LAN (see https://github.com/microsoft/WSL/issues/10535)
            3. Make sure the remote computers are on the same LAN! (if your NIC is on 10.x.x.x/8 then the remote computers should be on the same subnet, not 192.168.x.x/16).

    • Richard McCrae 0

      Just adding that I have the same issue, so hopefully this gets escalated. After enabling network mirrored mode, usbipd yields the same error that you have shown above.

      • Marcin Rybak 0

        The usbipd wsl attach command indeed does not work anymore, but it is merely a convenience – what it really does is to execute some command inside the wsl VM. So, to enable usbip, open your Ubuntu and type sudo usbip attach -r localhost --busid=<your-bus-id>. It definitely works for me. In Ubuntu you can also list the shared USB devices:

        ~$ usbip list -r localhost
        

        I submitted a feature request to the creators of usbipd: https://github.com/dorssel/usbipd-win/issues/714

        Also, if you have firewall issues, see https://github.com/microsoft/WSL/issues/10535

        BTW: Thanks to the above, plus Mirrored mode I can now develop Linux kernel entirely from VS Code, with NFS boot and KGDB over serial. Awesome, many thanks MS!

  • Hamed 0

    Thanks for these exciting features!

  • John Daly 0

    C:\Users\john>wsl
    Access is denied.
    🙁

  • Son Le 0

    a great post

    However, this feature does require disabling cgroups v1 in WSL, which can cause some issues. In early testing we noticed that this will break the docker daemon when running it as a service in WSL

    • Mostafa Mostafa 1

      Thank you very much for your great website
      https://motorsavaran.com
      nice work!

Feedback usabilla icon