4

I'm using Ubuntu 18.04 on WSL2 and when I run an .exe from the Windows file system, it executes normally. But when I copy the .exe to the Linux file system it is excruciatingly slow. See example below:

(18.04)geert@SEA-WIN10-02:~$ time /mnt/c/Windows/system32/whoami.exe
geert

real    0m0.071s
user    0m0.000s
sys     0m0.003s
(18.04)geert@SEA-WIN10-02:~$ cp /mnt/c/Windows/system32/whoami.exe .
(18.04)geert@SEA-WIN10-02:~$ time ./whoami.exe
geert


real    0m10.198s
user    0m0.002s
sys     0m0.000s

The same happens when I use Ubuntu 20.04 or 22.04.

It started doing this recently, after my WSL2 upgraded (beyond my control).

I'm using Linux on WSL2 to cross-compile for ARM. I'm using a Windows tool that converts the Intel Hex output to an encrypted version for the bootloader. This tool is now slowing down the build. The build used to take 4 minutes and now it takes 17. The tool hasn't changed; it's taken from version control and it hasn't changed for years.

Another side-effect is that every application becomes very slow to start after the build has completed. For instance, it takes 27s before the Task Manager window appears after clicking on it in the taskbar, same for Acrobat Reader or any other application; they all take between 10 and 30s to start. CPU usage (less than 3%) and memory usage (around 35%) are 'normal' and they don't 'spike' when starting an application.

It is not fixed by running wsl --shutdown. I have to restart my system to get applications to start up immediately again.

Version of WSL2 I'm using:

PS C:\Users\geert> (get-item C:\windows\system32\wsl.exe).VersionInfo.FileVersion
10.0.19041.2311 (WinBuild.160101.0800)

PS C:\Users\geert> wsl --version
WSL version: 1.0.3.0
Kernel version: 5.15.79.1
WSLg version: 1.0.47
MSRDC version: 1.2.3575
Direct3D version: 1.606.4
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.2486


PS C:\Users\geert> wsl --status
Default Distribution: Legacy
Default Version: 2


PS C:\Users\geert> wsl --update
Checking for updates.
The most recent version of Windows Subsystem for Linux is already installed.

There is a WSL bug report regarding this issue but it was caused by Windows Subsystem for Linux Preview but I'm not using that. I'm using the latest official release version of WSL2.

Anyone any idea why this is happening and how to fix it?

Update: I tested this on another system with an older version of WSL2 and here everything works fine (the build takes 3m50s). This version of WSL2 is:

PS C:\Users\geert> (get-item C:\windows\system32\wsl.exe).VersionInfo.FileVersion
10.0.19041.2311 (WinBuild.160101.0800)

PS C:\Users\geert> wsl --version
Invalid command line option: --version
Copyright (c) Microsoft Corporation. All rights reserved.
...


PS C:\Users\geert> wsl --status
Default Distribution: Ubuntu
Default Version: 2
...
Kernel version: 5.10.16

Surprisingly, the wsl.exe.VersionInfo.FileVersion for both systems is identical.

My tentative conclusion is that the WSL2 update is broken.

The 'old' version of WSL2 on my 2nd system has a 'rollback' option:

PS C:\Users\geert> wsl --version
Invalid command line option: --version
Copyright (c) Microsoft Corporation. All rights reserved.

Usage: wsl.exe [Argument] [Options...] [CommandLine]


...


--update [Options]
    If no options are specified, the WSL 2 kernel will be updated
    to the latest version.

    Options:
        --rollback
            Revert to the previous version of the WSL 2 kernel.

But the WSL2 version on the system with the issue doesn't have the 'rollback' option anymore (but does have the '--version' option).

How should I fix the issue, now I can't roll back WSL2?

NZD
  • 2,818

1 Answers1

4

There is a WSL bug report regarding this issue but it was caused by Windows Subsystem for Linux Preview but I'm not using that. I'm using the latest official release version of WSL2.

Well ... You actually are using that. When that was posted, the WSL application package was in Preview. It's now been released, and as you can see, the bug report is still open on it. Apparently it has not been fixed.

How should I fix the issue, now I can't roll back WSL2?

It's important to understand that there are now two different "distribution methods" for WSL:

  1. Originally, WSL came as a Windows Feature that was enabled through Turn Windows features on or off in Settings.

    This is the "old" version that you refer to, which doesn't support the --version flag.

  2. Now, WSL is distributed as a UWP application. In the latest versions of Windows 10 and 11, it can be installed through wsl --install, the Microsoft Store, or even by downloading the application package and installing manually.

    This is the version that appears to have the ".exe slowness` issue, at least in some (perhaps all) releases.

You can still rollback to either version. In either case, start by uninstalling the existing WSL package (as I mentioned in this comment in that Github issue) by searching the Start menu for Windows Subsystem for Linux, right-clicking, and Uninstall. You can also do this through the standard Add or remove programs.

From your comment:

If I uninstall WSL, do I lose my Linux installations?

No. This will not uninstall any distributions. Those are separate packages, such as Ubuntu, Debian, Ubuntu-22.04, etc. Do not uninstall those, and you'll be fine. It never hurts to backup first, though. Either see this answer (or others) for wsl --export, or find and copy the ext4.vhdx file for your distribution.

Once the problem application version is uninstalled, a reboot is advised. After that, since you are on Windows 10, you should find that the WSL feature is still installed. (The feature is optional for Windows 11 users, and only needed if you want WSL1 support.)

wsl --version should no longer work, but wsl ~ should start the older "feature" version (also with the older kernel release). According to users in that Github issue, returning to the older, pre-application (feature) version of WSL resolved the issue. But at this point, that's a pretty big setback in terms of functionality. Under Windows 10, you'll lose:

  • WSLg (the ability to run Linux GUI application)
  • The ability to wsl --mount other devices into WSL
  • Systemd support
  • And much more

You also have the option at this point of installing an older "application" package. There aren't too many app releases at this point that aren't "Preview", but as I mentioned in that Github issue, you could go back to a pre-release version that pre-dates when the problem seemed to start occurring for folks. However, according to the final comment in that issue, the problem was even present as early as 0.66.2. So it may be a systemic issue in the application package.

If you'd like to try, however, you can install any older application package manually. See "Installing/updating without the Store" in my answer here - Just download an older release from the WSL Releases page.

NotTheDr01ds
  • 28,025