Wsl2 / Windows 11 Extremely slow agent communication times

[VibroAxe]

So I've been using this for a long time on windows 10 and have had absolutely no issues, well done for a really awesome piece of software.

However, since upgrading my laptop to windows 11 and reinstalling WSL2 (with WLSg if that makes a difference) the communication to the agent is EXTREMELY slow. From typing ssh at the command line to actually getting the gpg pincode prompt (/touch to auth flash on my yubikey) is taking over 20s, ssh-add -L is also taking a similar amount of time.

Performing the same operation from windows connecting to the gpg agent and I get the prompt instantly from both putty and winssh, implying this is an issue with the WSL2 connection somewhere.

Any ideas?

[BlackReloaded]

I have no win 11 on any device actual but @tobiaskohlbau. Can you confirm this behavior?

[tobiaskohlbau]

I did not experience this on my machine running the latest insider build.

By any chance this only happens on the first try? Thats most likely caused by the gpg-connect-agent not launched and needed to be relaunched.

[VibroAxe]

Nope, seems to happen everytime. I originally came here to complain it was taking over a minute, but that was actually my issue to do with running ssh-add too many times in a bash script. However the above 20s were based on runing ssh/ssh-agent directly.

Any debug I can run?

edit
gpg-agent is running at windows startup so should be available, and is available to the winssh/putty sessions without this lag/ issue

[tobiaskohlbau]

Can you try and run the attached utility program either by the provided binary or the attached sourcecode? It tries to find the pageant window and prints it's window handle.

pageant-check.zip

main.go

package main

import (
        "fmt"
        "syscall"

        "github.com/lxn/win"
)

func main() {
        hwnd := win.FindWindow(syscall.StringToUTF16Ptr("Pageant"), syscall.StringToUTF16Ptr("Pageant"))
        fmt.Println(hwnd)
}

go.mod

module pageant-check

go 1.16

require (
        github.com/lxn/win v0.0.0-20210218163916-a377121e959e // indirect
        golang.org/x/sys v0.0.0-20201018230417-eeed37f84f13 // indirect
)

[VibroAxe]

C:\Users\kinsman.PASCALL\Downloads>.\pageant-check.exe
66862

vibs@J-KINSMAN-2019:/mnt/c/Users/kinsman.PASCALL/downloads $ time ./pageant-check.exe
66862

real    0m1.502s

Pretty much immediate in windows, reasonably quick from linux (i'd slay a fraction slower)
i'm using the gpg-agent with putty support if that makes a difference?

[tobiaskohlbau]

Sorry for the late response.

I'm still nowhere near an idea why this happens to you. That beeing a little bit slower on linux is most likely caused by the interop layer in WSL.

I'm using the gpg-agent with putty support as well on my Windows 11 machine. Is your machine an updated one or a clean install? Maybe it's only happening if it's a clean install.

[VibroAxe]

@tobiaskohlbau So i've just done another clean install on another laptop and have exactly the same issue, so this might be a clean install thing?

Windows PowerShell
Copyright (C) Microsoft Corporation. All rights reserved.

Install the latest PowerShell for new features and improvements! https://aka.ms/PSWindows

PS C:\Users\kinsman> wsl -l
Windows Subsystem for Linux Distributions:
Ubuntu-20.04 (Default)

PS C:\Users\kinsman> wsl --install -d Ubuntu
Downloading: Ubuntu
Installing: Ubuntu
Ubuntu has been installed.
Launching Ubuntu...

PS C:\Users\kinsman> wsl -l
Windows Subsystem for Linux Distributions:
Ubuntu-20.04 (Default)
Ubuntu

PS C:\Users\kinsman> wsl -d Ubuntu
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

vibs@J-KINSMAN-2021:/mnt/c/Users/kinsman$ sudo apt install socat
[sudo] password for vibs:
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following NEW packages will be installed:
  socat
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 323 kB of archives.
After this operation, 1394 kB of additional disk space will be used.
Get:1 http://archive.ubuntu.com/ubuntu focal/main amd64 socat amd64 1.7.3.3-2 [323 kB]
Fetched 323 kB in 0s (2723 kB/s)
Selecting previously unselected package socat.
(Reading database ... 31836 files and directories currently installed.)
Preparing to unpack .../socat_1.7.3.3-2_amd64.deb ...
Unpacking socat (1.7.3.3-2) ...
Setting up socat (1.7.3.3-2) ...
Processing triggers for man-db (2.9.1-1) ...


vibs@J-KINSMAN-2021:/mnt/c/Users/kinsman$ cd

vibs@J-KINSMAN-2021:~$ mkdir .ssh
vibs@J-KINSMAN-2021:~$ destination="$HOME/.ssh/wsl2-ssh-pageant.exe"
t -O "vibs@J-KINSMAN-2021:~$ wget -O "$destination" "https://github.com/BlackReloaded/wsl2-ssh-pageant/releases/latest/download/wsl2-ssh-pageant.exe"
 Set the executable bit.
chmod +x "$destination"--2021-09-27 13:51:31--  https://github.com/BlackReloaded/wsl2-ssh-pageant/releases/latest/download/wsl2-ssh-pageant.exe
Resolving github.com (github.com)... 140.82.121.3
Connecting to github.com (github.com)|140.82.121.3|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://github.com/BlackReloaded/wsl2-ssh-pageant/releases/download/v1.3.0/wsl2-ssh-pageant.exe [following]
--2021-09-27 13:51:31--  https://github.com/BlackReloaded/wsl2-ssh-pageant/releases/download/v1.3.0/wsl2-ssh-pageant.exe
Reusing existing connection to github.com:443.
HTTP request sent, awaiting response... 302 Found
Location: https://github-releases.githubusercontent.com/231393429/22f91200-cf6f-11eb-8d36-4f1f1c2c3996?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20210927%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20210927T125131Z&X-Amz-Expires=300&X-Amz-Signature=61538fb262fdd8b9822b4cf5b9974be9cee75951a5d70ef8f7fe1bee14396bb9&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=231393429&response-content-disposition=attachment%3B%20filename%3Dwsl2-ssh-pageant.exe&response-content-type=application%2Foctet-stream [following]
--2021-09-27 13:51:31--  https://github-releases.githubusercontent.com/231393429/22f91200-cf6f-11eb-8d36-4f1f1c2c3996?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20210927%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20210927T125131Z&X-Amz-Expires=300&X-Amz-Signature=61538fb262fdd8b9822b4cf5b9974be9cee75951a5d70ef8f7fe1bee14396bb9&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=231393429&response-content-disposition=attachment%3B%20filename%3Dwsl2-ssh-pageant.exe&response-content-type=application%2Foctet-stream
Resolving github-releases.githubusercontent.com (github-releases.githubusercontent.com)... 185.199.111.154, 185.199.108.154, 185.199.110.154, ...
Connecting to github-releases.githubusercontent.com (github-releases.githubusercontent.com)|185.199.111.154|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3727872 (3.6M) [application/octet-stream]
Saving to: ‘/home/vibs/.ssh/wsl2-ssh-pageant.exe’

/home/vibs/.ssh/wsl2-ssh-pageant.exe           100%[==================================================================================================>]   3.55M  9.26MB/s    in 0.4s

2021-09-27 13:51:32 (9.26 MB/s) - ‘/home/vibs/.ssh/wsl2-ssh-pageant.exe’ saved [3727872/3727872]

vibs@J-KINSMAN-2021:~$ # Set the executable bit.
vibs@J-KINSMAN-2021:~$ chmod +x "$destination"

vibs@J-KINSMAN-2021:~$ export SSH_AUTH_SOCK="$HOME/.ssh/agent.sock"
s -a | vibs@J-KINSMAN-2021:~$ if ! ss -a | grep -q "$SSH_AUTH_SOCK"; then
>   rm -f "$SSH_AUTH_SOCK"
>   wsl2_ssh_pageant_bin="$HOME/.ssh/wsl2-ssh-pageant.exe"
>   if test -x "$wsl2_ssh_pageant_bin"; then
>     (setsid nohup socat UNIX-LISTEN:"$SSH_AUTH_SOCK,fork" EXEC:"$wsl2_ssh_pageant_bin" >/dev/null 2>&1 &)
>   else
>     echo >&2 "WARNING: $wsl2_ssh_pageant_bin is not executable."
>   fi
 unset w>   unset wsl2_ssh_pageant_bin
> fi

vibs@J-KINSMAN-2021:~$ time ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAz5PwTwgjvwfvXg/GoaK9sbaP2El4U9/pxdSyv76XoT cardno:15 207 117

real    0m26.239s
user    0m0.002s
sys     0m0.000s

vibs@J-KINSMAN-2021:~$
vibs@J-KINSMAN-2021:~$

[VibroAxe]

Also of note, I tried opening pageant to see if that was any quicker, it;s definitely faster, but still taking 10s for an ssh-add -L, interestingly, the pageant-check is now taking ~20s to complete (for both)

Pageant

vibs@J-KINSMAN-2021:~$ time ssh-add -L
The agent has no identities.

real    0m9.067s
user    0m0.002s
sys     0m0.000s

vibs@J-KINSMAN-2021:~$ time ./pageant-check.exe
525766

real    0m22.944s
user    0m0.001s
sys     0m0.000s

GPG

vibs@J-KINSMAN-2021:~$ time ./pageant-check.exe
527614

real    0m26.119s
user    0m0.001s
sys     0m0.000s

vibs@J-KINSMAN-2021:~$ time ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAz5PwTwgjvwfvXg/GoaK9sbaP2El4U9/pxdSyv76XoT cardno:15 207 117

real    0m11.968s
user    0m0.001s
sys     0m0.000s

[dschaper]

Adding in another data point:

Edition	Windows 11 Pro
Version	21H2
Installed on	‎7/‎30/‎2021
OS build	22000.194
Experience	Windows Feature Experience Pack 1000.22000.194.0

dan@Viking-1:~/.ssh$ time ./pageant-check.exe
721522

real    0m14.925s
user    0m0.002s
sys     0m0.000s
dan@Viking-1:~/.ssh$ time ./pageant-check.exe
721522

real    0m18.263s
user    0m0.001s
sys     0m0.000s
dan@Viking-1:~/.ssh$ time ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGg3e898ea02z8yhDgo3n/8HJacyLpgY1aC4GDAqKWG6 cardno:

real    0m15.052s
user    0m0.002s
sys     0m0.000s

[alanaasmaa]

Can't test with pageant-check.exe my antivirus wont allow.
But i have same issue:

ssh-add -L 0.00s user 0.00s system 0% cpu 20.663 total
gpg --card-status 0.00s user 0.00s system 0% cpu 15.485 total

My windows is updated, not clean install.

[tobiaskohlbau]

Thanks for all the datapoints. With the upcoming release of Windows 11 I think it's worth digging into this. I'm still not experiencing this in my setup. Just out of curiosity do you all have:

/touch to auth flash on my yubikey

enabled, so that every request must be confirmed by a press on the yubikey? Maybe that is causing this issue, as I've not enabled that for now. Will test my theory on the next weekend.

[alanaasmaa]

Thanks for all the datapoints. With the upcoming release of Windows 11 I think it's worth digging into this. I'm still not experiencing this in my setup. Just out of curiosity do you all have:

/touch to auth flash on my yubikey

enabled, so that every request must be confirmed by a press on the yubikey? Maybe that is causing this issue, as I've not enabled that for now. Will test my theory on the next weekend.

No, I do not have to confirm the request.

[jliedy]

I am experiencing the same thing as to slowness.
Another symptom is after an indeterminate period of time the WSL2 process pegs the CPU until the socat job is killed.
All appropriate agents are running. I've got verbose logging enabled.

initialization script being used for this:

#!/usr/bin/bash

pageant_bin="${HOME}/.ssh/wsl2-ssh-pageant.exe"

export SSH_AUTH_SOCK="${HOME}/.ssh/agent.sock"
if ! ss -a | grep -q "${SSH_AUTH_SOCK}"; then
  rm -f "${SSH_AUTH_SOCK}"
  if test -x "${pageant_bin}"; then
    (setsid nohup socat UNIX-LISTEN:"${SSH_AUTH_SOCK},fork" EXEC:"${pageant_bin} --verbose=true --logfile=${HOME}/.ssh/pageant.log" >/dev/null 2>&1 &)
  else
    echo >&2 "WARNING: ${pageant_bin} is not executable."
  fi
fi

export GPG_AGENT_SOCK="${HOME}/.gnupg/S.gpg-agent"
if ! ss -a | grep -q "${GPG_AGENT_SOCK}"; then
  rm -rf "${GPG_AGENT_SOCK}"
  if test -x "${pageant_bin}"; then
    (setsid nohup socat UNIX-LISTEN:"${GPG_AGENT_SOCK},fork" EXEC:"${pageant_bin} --verbose=true --logfile=${HOME}/.gnupg/pageant.log --gpg=S.gpg-agent" >/dev/null 2>&1 &)
  else
    echo >&2 "WARNING: ${pageant_bin} is not executable."
  fi
fi

unset pageant_bin

Yubikey settings:

PS C:\Program Files\Yubico\YubiKey Manager> ./ykman.exe openpgp info
OpenPGP version: 3.4
Application version: 5.4.3

PIN tries remaining: 3
Reset code tries remaining: 0
Admin PIN tries remaining: 3

Touch policies
Signature key           Off
Encryption key          Off
Authentication key      Off
Attestation key         Off

pageant-check.exe:

~$ date;time .ssh/pageant-check.exe;date
Mon Oct  4 10:47:49 EDT 2021
462748

real    1m4.934s
user    0m0.002s
sys     0m0.000s
Mon Oct  4 10:48:54 EDT 2021

ssh-add -L while tailing agent logs:

:~$ date;ssh-add -L;date
Mon Oct  4 10:50:15 EDT 2021
2021/10/04 10:50:46 Starting exe
2021/10/04 10:50:46 Reading length: 1
2021/10/04 10:50:46 Querying pageant
ssh-rsa RSAPUBLICKEYBLAHBLAH cardno:blah
2021/10/04 10:50:46 io.ReadFull length error 'EOF'
Mon Oct  4 10:50:46 EDT 2021

gpg --card-status while tailing agent logs:

~$ date;gpg --card-status;date
Mon Oct  4 10:54:00 EDT 2021
2021/10/04 10:54:50 Starting exe
Reader ...........: Yubico YubiKey OTP FIDO CCID 0
Application ID ...: BLAH
Application type .: OpenPGP
Version ..........: 3.4
Manufacturer .....: Yubico
Serial number ....: BLAH
Name of cardholder: BLAH
Language prefs ...: [not set]
Salutation .......:
URL of public key : BLAH
Login data .......: [not set]
Signature PIN ....: not forced
Key attributes ...: rsa4096 rsa4096 rsa4096
Max. PIN lengths .: 127 127 127
PIN retry counter : 3 0 3
Signature counter : 10
KDF setting ......: off
Signature key ....: BLAH
      created ....: BLAH
Encryption key....: BLAH
      created ....: BLAH
Authentication key: BLAH
      created ....: BLAH
General key info..: [none]
Mon Oct  4 10:55:10 EDT 2021

On that one, please note the 20 second difference between the log showing "Starting exe" and output actually showing for the card-status command.

I'm going to see if I can revert to an earlier release of socat in case that is an issue.

[jliedy]

Running ubuntu 20.04 (Focal) and the release of socat is 1.7.3.3-2 which was released on 20 Feb 2020 and it doesn't look like there's any previous release to try in Focal.

Also: Pegged CPU may be due to trying to run ssh via git through WSL2 vscode integration. I'm gonna mess with it a bit to see if anything pops up in the log.

[VibroAxe]

Thanks for all the datapoints. With the upcoming release of Windows 11 I think it's worth digging into this. I'm still not experiencing this in my setup. Just out of curiosity do you all have:

/touch to auth flash on my yubikey

enabled, so that every request must be confirmed by a press on the yubikey? Maybe that is causing this issue, as I've not enabled that for now. Will test my theory on the next weekend.

I do have touch to flash enabled, however the ssh-add/list exchange still takes 8s on my current setup without a key even in the system

Also, thanks for looking into this!

[jliedy]

Enabling verbose logging on socat and tailing both socat and wsl2-ssh-pageant logs:

:~/.ssh$ date;ssh-add -l;date
Mon Oct  4 11:38:36 EDT 2021
> 2021/10/04 11:38:36.792907  length=5 from=0 to=4
....\v2021/10/04 11:39:38 Starting exe
2021/10/04 11:39:38 Reading length: 1
2021/10/04 11:39:38 Querying pageant
< 2021/10/04 11:39:37.903397  length=569 from=0 to=568
...5\f...........\assh-rsaBLAHBLAHBLAH.cardno:BLAH SHA256:BLAH cardno:BLAH (RSA)
2021/10/04 11:39:38 io.ReadFull length error 'EOF'
Mon Oct  4 11:39:37 EDT 2021

I'll see if I can find output for the GPG4WIN agent.

[jliedy]

I'm not finding the gpg4win log output (cursory glance as it was), but after messing for a bit, I think you're onto something with the win.FindWindow call.

[kaeltis]

To add some more info from a setup not affected by this issue (maybe it helps):

I couldn't get my YubiKey to work at all on Win 11 with the GnuPG 2.2.28 thats bundled with Gpg4win (gpg --card-status wouldn't detect it), so I'm currently using the official w32 build of GnuPG 2.3.2, which could talk to my YubiKey immediately (https://www.gnupg.org/ftp/gcrypt/binary/) - it's CLI only, but with this I'm having zero issues with both SSH and GPG (except for the need to change --gpgConfigBasepath as described in #26 (comment)).

Did a clean install with the first released insider beta ISO:

Microsoft Windows [Version 10.0.22000.194]
Original Install Date:     28.08.2021, 15:50:39

gpg --version
gpg (GnuPG) 2.3.2
libgcrypt 1.9.4

gpg-agent.conf:

enable-putty-support
enable-ssh-support
use-standard-socket
default-cache-ttl 600
max-cache-ttl 7200

tested on https://github.com/yuk7/ArchWSL:

uname -a
5.10.60.1-microsoft-standard-WSL2

ssh -V
OpenSSH_8.8p1, OpenSSL 1.1.1l  24 Aug 2021

gpg --version
gpg (GnuPG) 2.2.29
libgcrypt 1.9.4-unknown

socat -V
socat by Gerhard Rieger and contributors - see www.dest-unreach.org
socat version 1.7.4.1 on Mar 28 2021 15:38:51
running on Linux version #1 SMP Wed Aug 25 23:20:18 UTC 2021, release 5.10.60.1-microsoft-standard-WSL2, machine x86_64

time ./pageant-check.exe
529350
________________________________________________________
Executed in  105.60 millis    fish           external
   usr time    1.34 millis   95.00 micros    1.25 millis
   sys time    0.21 millis  207.00 micros    0.00 millis

time ssh-add -L
ssh-ed25519 XXX
________________________________________________________
Executed in  136.55 millis    fish           external
   usr time  115.67 millis   60.00 micros  115.61 millis
   sys time   46.00 millis  240.00 micros   45.76 millis

[ophers]

F***g unbelievable! Pardon my French!!
@kaeltis comment got me experimenting and uncovered the simplest of solutions:
Copy wsl2-ssh-pageant.exe to your Windows user home directory and run it from there.
Now the response time is blazing fast again - under 200ms.

So in the script given in README.md https://github.com/BlackReloaded/wsl2-ssh-pageant#bashzsh, change the fourth line from:

wsl2_ssh_pageant_bin="$HOME/.ssh/wsl2-ssh-pageant.exe"

to

wsl2_ssh_pageant_bin="/mnt/c/Users/johndoe/.ssh/wsl2-ssh-pageant.exe"

[jliedy]

I hate that you found this. I can confirm that I'm getting consistent 5 second times running pageant-check in the prescribed fashion. This is strictly an issue with the library that the author is using, and not any issues with the application itself. This is a frustrating bug. I may submit this as a bug on the underlying library, but the author hasn't touched the source on it since March so I doubt that it's going to be worked on and fixed for Win 11.

qwer@asdf:~$ time .ssh/pageant-check.exe
458816

real    0m25.310s
user    0m0.002s
sys     0m0.000s
qwer@asdf:~$ time /mnt/c/Users/qwer/.ssh/pageant-check.exe
458816

real    0m5.190s
user    0m0.003s
sys     0m0.000s
qwer@asdf:~$ time .ssh/pageant-check.exe
458816

real    0m25.214s
user    0m0.000s
sys     0m0.001s
qwer@asdf:~$ time /mnt/c/Users/qwer/.ssh/pageant-check.exe
458816

real    0m5.186s
user    0m0.003s
sys     0m0.000s

Further testing proved your fix to work. I'm doing this over remote desktop with a Yubikey 5 NFC and as soon as I copied the executable to the prescribed destination and made the change to the script, my attempt to ssh was successful without having to wait half a minute.
I'll take a crack at this again while at the office later.

Good job figuring this out. You just made WSL2 usable for me.

[tobiaskohlbau]

I hate that you found this. I can confirm that I'm getting consistent 5 second times running pageant-check in the prescribed fashion. This is strictly an issue with the library that the author is using, and not any issues with the application itself. This is a frustrating bug. I may submit this as a bug on the underlying library, but the author hasn't touched the source on it since March so I doubt that it's going to be worked on and fixed for Win 11.

I have my doubts that it's the underlying library. As it's executed on Windows in both cases. The only thing which changes is the initialization done by WSL or Microsoft to name it. It think it's time to report this issue to the upstream WSL. There was a very similar found with the new Store WSL version which wasn't able to execute from within the Linux filesystem at all. See #27 and microsoft/WSL#7521. Maybe it's related and the people at Microsoft have an idea what's happening. I'm still curious why others and me are not experiencing this. Maybe there is still something common in your setups. If you open an issue on wsl please reference this issue and microsoft/WSL#7521 so that they get as most information as possible.

Edit:

Great find @ophers many thanks!

[jliedy]

I mean that it's not your app, but the FindWindow function from the lxn/win library that is having the difficulty. Whether it's something that has changed in functionality or a bug within WSLg, it's nothing you're able to really do anything about.
Also don't think we can really expect the dev for lxn/win to assist with looking into things as it seems like they've not submitted anything since March.

[tobiaskohlbau]

I mean that it's not your app, but the FindWindow function from the lxn/win library that is having the difficulty. Whether it's something that has changed in functionality or a bug within WSLg, it's nothing you're able to really do anything about. Also don't think we can really expect the dev for lxn/win to assist with looking into things as it seems like they've not submitted anything since March.

Just to clarify, I didn't want to say it's not wsl2-ssh-pageant nor lxn/win. But I doubt that it's related to lxn/win as this is only a wrapper around the windows functions (syscalls). The library doesn't know anything about WSL or other linux related things. And it's never executed in Linux context neither, it's just called from the interop functionality of the WSL (which MS is responsible for).

All lxn/win is doing is calling the following on the windows provided system libraries:

func FindWindow(lpClassName, lpWindowName *uint16) HWND {
	ret, _, _ := syscall.Syscall(findWindow.Addr(), 2,
		uintptr(unsafe.Pointer(lpClassName)),
		uintptr(unsafe.Pointer(lpWindowName)),
		0)

	return HWND(ret)
}

https://github.com/lxn/win/blob/a377121e959e22055dd01ed4bb2383e5bd02c238/user32.go#L2440-L2447

I will go ahead and report the issue to microsoft/wsl.

[tobiaskohlbau]

Everyone who is subscribed to this issue and experiencing it please go to the following issue microsoft/WSL#7591 and try to describe your WSL setup, windows version and as much as possible to help Microsoft developers recreate the situation.

I cannot reproduce this either, if your users can help narrow this down that would help make it more actionable.

[jliedy]

Done.

[VibroAxe]

@tobiaskohlbau moving the exe back to windows fixes, well done all! Interestingly a symlink from the linux FS to the windows file system also works to keep configs more comparable

[ophers]

I'm still curious why others and me are not experiencing this. Maybe there is still something common in your setups. If you open an issue on wsl please reference this issue and microsoft/WSL#7521 so that they get as most information as possible.

Done that. I also have Docker Desktop 3.6 installed. Maybe this is a differentiating factor?

[ophers]

It might have nothing to do with FindWindow().
I tried npiperelay with the exact same effect:
Running npiperelay.exe from Linux home-directory is 10x times slower than running it from Windows home-directory.