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,600
  • 16
  • 22
  • 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 '23 at 19:41
  • You say that restart fixes the problem? Restart of what - Windows or WSL? – harrymc Jan 12 '23 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 '23 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 '23 at 21:31
  • Restart of Windows or WSL? So you say that something in your build is causing the problem? Have you tried to run the build by stages to find the part where it happens? Also, did it happen in WSL1 (if you ever ran it)? – harrymc Jan 12 '23 at 21:32
  • @NZD - The WSL Kernel GitHub page has installation instructions. My suggestion would involve uninstall WSL then install the WSL from the MS Store. – Ramhound Jan 12 '23 at 21:42
  • 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 '23 at 21:49
  • @Ramhound If I uninstall WSL, do I lose my Linux installations? I've installed (cross-)compilers, lots of tools and of course the settings in my home directory. I can tar them of course, but will they work if I put them back? – NZD Jan 12 '23 at 21:58
  • @Ramhound - according to [WSL releases page](https://github.com/microsoft/WSL/releases) 5.15.79.1 **IS** the current stable kernel release – Jaromanda X Jan 12 '23 at 23:51
  • @JaromandaX - [The WSL Linux Kernel pages say something else.](https://github.com/microsoft/WSL2-Linux-Kernel/releases). Here is the thing, I suspect they introduce the bug in an earlier version and have not actually fixed it and was inverently introduced into the stable version. – Ramhound Jan 13 '23 at 00:45
  • @Ramhound - interesting, but that bug doesn't effect kernel 5.15.79.1, at least not in Windows 11 – Jaromanda X Jan 13 '23 at 00:57
  • I'd definitely recommend adding your symptoms to the Github issue. As I mention in my answer, you are almost certainly seeing the same bug mentioned there - It's just that what was in Preview when the issue was created is now the released code that you are running. – NotTheDr01ds Jan 13 '23 at 01:59
  • I see this problem too on `Linux w-B0ZXM03 5.10.102.1-microsoft-standard-WSL2 #1 SMP Wed Mar 2 00:30:59 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux` ``` d057039:~$ time /mnt/c/Windows/system32/whoami.exe global\d057039 real 0m0.089s user 0m0.003s sys 0m0.000s d057039:~$ cp /mnt/c/Windows/system32/whoami.exe . d057039:~$ time ./whoami.exe global\d057039 real 1m45.172s user 0m0.003s sys 0m0.000s ``` – Anton Golubev Mar 06 '23 at 18:13

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
  • 17,574
  • 4
  • 44
  • 81
  • 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 '23 at 02: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. – NotTheDr01ds Jan 13 '23 at 03:38
  • I mean the source code is available. – Ramhound Jan 13 '23 at 03:39
  • @Ramhound I might be misunderstanding you, but it looks like your last comment might have been meant for a different post/reply? – NotTheDr01ds Jan 13 '23 at 03: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 '23 at 04:05
  • @Ramhound Ahh, but that's assuming it's a kernel issue. It's probably *not*, since it's the (closed source) `/init` that handles the `binfmt_misc` running of `.exe`'s. That said, it *could* be a filesystem issue, in which case the kernel would be in play, but I'm suspecting some system configuration issue + the `binfmt_misc` support. – NotTheDr01ds Jan 13 '23 at 04:29
  • If it were a kernel issue, then it's entirely possible to rollback *just* the kernel using `.wslconfig`. I'll edit to suggest that as a possibility (but tomorrow). – NotTheDr01ds Jan 13 '23 at 04:31