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?

13
  • I would recommend upgrading to 5.15.83.1 which is the current stable WSL kernel release to eliminate the possibility that the bug that was discovered wasn’t fixed until 5.15.83.1, if was even fixed, 5.15.57.1 is an earlier build than what your using. I don’t see a Microsoft developer closing the bug report
    – Ramhound
    Jan 12, 2023 at 19:41
  • You say that restart fixes the problem? Restart of what - Windows or WSL?
    – harrymc
    Jan 12, 2023 at 21:27
  • @harrymc Restart fixes the side-effect that all applications start up slow. Until the next time I run my build...
    – NZD
    Jan 12, 2023 at 21:29
  • @Ramhound If I run wsl --update, it responds with: Checking for updates. The most recent version of Windows Subsystem for Linux is already installed.
    – NZD
    Jan 12, 2023 at 21:31
  • 1
    @harrymc I have to restart Windows, shutting down WSL2 (wsl --shutdown) is not enough. The build hasn't changed, it is exactly the same as before WSL2 was updated. If I move the tool (that has always worked fine when called from the WSL file system) to the C: drive (/mnt/c/...) then the build completes in 4 minutes and I don't have any issues with other Windows applications. If the tool is somewhere on the WSL file system (\\wsl$\Ubuntu-18.04\home\geert\projects\...) then I get the issues I mentioned in my question.
    – NZD
    Jan 12, 2023 at 21:49

1 Answer 1

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.

7
  • Software bugs are not hard to understand. You either have regression bugs that are reintroduced in later versions, or you have bugs in earlier builds that exist in later builds until it works. I would agree that the bug was not fixed yet.
    – Ramhound
    Jan 13, 2023 at 2:53
  • @Ramhound Sure, we just don't know when it was introduced. So it's unclear just how far back a user would need to rollback to handle it. I'm guessing that it is in all Preview/Store releases, and it just wasn't found until 0.67.6, since a lot of new users installed at that point due to the Systemd excitement. Jan 13, 2023 at 3:38
  • I mean the source code is available.
    – Ramhound
    Jan 13, 2023 at 3:39
  • @Ramhound I might be misunderstanding you, but it looks like your last comment might have been meant for a different post/reply? Jan 13, 2023 at 3:40
  • It's an incomplete message, I was multitasking, what I was going to say is that with enough WSL Linux kernel knowledge and programming experience one could probably find the difference between the working build and the build with the bug. Of course one could wait for Microsoft to fix it :-)
    – Ramhound
    Jan 13, 2023 at 4:05

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .