"Invalid argument" when executing Windows commands on Ubuntu 20.04

[gAllegr]

Environment

Windows build number: 10.0.19041.572
Your Distribution version: Ubuntu 20.044
Whether the issue is on WSL 2 and/or WSL 1: WSL 2

Steps to reproduce

WSL logs:

Expected behavior

When I run code . inside the root path or some subfolder of linux, VS Code on Windows should be opened, just like it happen when I run the command from the mount folder.

Same for the explorer.exe command (and all Windows commands). When I run them from root or a subfolder, the command should be executed.

Actual behavior

The system print me back an error saying Invalid argument

Note: I searched in previous issues for some help on how to solve this, but didn't found how to

[licanhua]

Are you with ARM device?

[gAllegr]

No, it's a x64

[gAllegr]

Hello, I see no answers.
If other info are required in order to identify the reason of this behavior, just name them and I'll provide as soon as possible.

[ropez]

@gAllegr I have the same problem. Did you figure out a solution?

[gAllegr]

@gAllegr I have the same problem. Did you figure out a solution?

Unfortunately no

[victoryc]

I am facing the same problem. Wondering why was this issue closed. The issue linked to above was also not resolved.

[tyronexj]

I am facing the same problem.
at startup, all good

$ /mnt/c/WINDOWS/system32/cmd.exe

Microsoft Windows [Version 10.0.19042.844]
(c) 2020 Microsoft Corporation. All rights reserved.

after run docker login

$ /mnt/c/WINDOWS/system32/cmd.exe

/mnt/c/WINDOWS/system32/cmd.exe: Invalid argument

[drzdbd1]

Facing the same issue. WSL used to work fine, not sure how long ago after a round of windows update, all windows commands executed in WSL started to throw "Invalid argument" error.

[sfailor]

I am encountering the identical problem

Windows version: 10.0.21337 Build 21337
WSL 2
Ubuntu 20.04.2 LTS

[sfailor]

This appears to be the same issue as #4260

[benyaminl]

I find a work arround for now using bash/ash shell, by mounting the folder as disk drive see #5718 (comment) to mount the network location as drive (on insider should be wsl.local)

You can create file on ~/.local/bin for cmd
for cmd command, for ash change first line to #!/bin/ash

#!/bin/bash
cwd=$(pwd)
if ! echo "$cwd" | grep -q "/mnt/"; then
    cd /mnt/c/
    param="cd /d Z:$cwd"
    if [ ! -z "$@" ]
    then
       param=$param" && $@"
    fi
    cmd.exe /K "$param"
else
    cmd.exe /K "$@"
fi

for powershell you could create psh file, change #!/bin/bash to #!/bin/ash if you using ash shell/alpine

#!/bin/bash
cwd=$(pwd)
if ! echo "$cwd" | grep -q "/mnt/"; then
    cd /mnt/c/
    param="cd Z:$cwd; powershell "
    if [ ! -z "$@" ]
    then
       param=$param" -c $@"
    fi
    powershell.exe -c "$param"
else
    powershell.exe -c "$@"
fi

for git on windows/for windows

#!/bin/ash
cwd=$(pwd)
if ! echo "$cwd" | grep -q "/mnt/"; then
    cd /mnt/c/
    param="cd /d Z:$cwd"
    param=$param" && git $@ & exit"
    cmd.exe /K "$param"
else
    cmd.exe /K "git $@ & exit"
fi

then make the executable

chmod +x /home/<your username>/.local/bin/*

Then after that on ~/.bashrc you could add path

PATH=$PATH":/home/<your username>/.local/bin"

If you want to test the change run source ~/.bashrc

if your're on ash/alpine write to ~/.profile

I hope this workarround help a while, I test it on Fedora WSL 34 and Alpine WSL.

Hope the wsl team could fix this problem. Hopefully, because this reproducable even on insider with new ISO which make me insane :'(

the result should be like this

BEN-TP-X220:~$ cd .ssh
BEN-TP-X220:.ssh$ pwd
/home/benli/.ssh
BEN-TP-X220:.ssh$ cmd

Z:\home\benli\.ssh>exit
BEN-TP-X220:.ssh$ cmd echo abc
ash: abc: unknown operand

Z:\home\benli\.ssh>exit
BEN-TP-X220:.ssh$ cmd 'echo abc'
abc

Z:\home\benli\.ssh>exit
BEN-TP-X220:.ssh$ psh "echo abc"
abc
BEN-TP-X220:.ssh$ psh
Copyright (C) Microsoft Corporation. All rights reserved.

Try the new cross-platform PowerShell https://aka.ms/pscore6

PS Z:\home\benli\.ssh> exit
BEN-TP-X220:.ssh$ git status
fatal: not a git repository (or any of the parent directories): .git
BEN-TP-X220:.ssh$ ls -al ~/.local/bin
total 20
drwxr-sr-x    2 benli    benli         4096 Jul 19 18:57 .
drwx--S---    4 benli    benli         4096 Jul 19 17:47 ..
-rwxr-xr-x    1 benli    benli          225 Jul 19 18:53 cmd
-rwxr-xr-x    1 benli    benli          247 Jul 19 19:04 git
-rwxr-xr-x    1 benli    benli          249 Jul 19 19:07 psh
BEN-TP-X220:.ssh$

I can did this because strangely it works on /mnt/c/ directory, at least the windows exe work on windows partition.

[kevinsullivan]

UPDATE: I updated Windows 10 Home to Windows 10 Education (which is Windows 10 Enterprise plus some educational cruft). I uninstalled and reinstalled WSL 2 and Ubuntu 20.04 LTS. THE PROBLEM PERSISTS.

ORIGINAL POST:

I wish I were equipped to help. All I can do is to further confirm the problem.

Edition: Windows 10 Home (I know, but it's supposed to work now; and essentially all university students using Windows are using Windows 10 Home on a personal laptop, so that's what we have to target here.)
Version: 21H1
OS Build: 19043.1151 (right up to date)

One bit of evidence I can offer: Replacing Ubuntu 20.04 LTS with 18.04 doesn't help.

Some kind of guidance / repair is urgently needed here (at least by me); I was planning on having this working by the time classes start at a University in just a few weeks. Again, deep apologies, but I'm not equipped to resolve the issue on the WSL / Ubuntu side. Any kind of update would be extremely helpful!

[RandomGHUser]

Same issue here running Debian WSL2 - I can invoke commands at first open, but after running a few commands, they end up stating "Invalid Argument". Also, WSL2 seems to forget where the current working directory is sporatically. I have a rust program calling env::current_dir() at different times in it's lifecyle, and the command eventually fails (not at it's first invocation, but when called in a later method). It will then completely fail on any subsequent execution, until I create a new terminal.

[byoung4]

I have the same issue, but I have verified that it only happens when my pwd is a network drive.

Example:

$ echo test | clip.exe  # this works OK
$ sudo mount -t drfvs '\\path\to\network\drive' /mnt/example
$ cd /mnt/example
$ echo test | clip
/mnt/c/WINDOWS/system32/clip.exe: Invalid argument

As a workaround, make a shell script called clip and place it somewhere in your path. This seems to work.

#!/usr/bin/bash
curdir=$PWD
cd /
cat | clip.exe
cd $curdir

Now you can just do

$ echo test | clip

[dresch86]

I am running Windows 11 Pro and encountered this same issue. It was working fine at first, but suddenly stopped. As a workaround, I found the following command from the docs to work from the Windows cmd prompt (https://code.visualstudio.com/docs/remote/wsl):

code --remote wsl+<distro name> <path in WSL>

I am wondering if a recent update changed the way paths are handled. I did not notice the remote server was reinstalled in WSL after issuing the above command.

[bartdorsey]

I have a new piece of information. Windows Terminal was recently changed to let you specify a linux path as the starting directory. When I open Ubuntu-20.04 with my Linux path in there, I get the Invalid Argument errors. If I leave it the default of %USERPROFILE% then it works fine. I think under the hood Windows terminal is using the new command line argument:

--cd <Directory>
        Sets the specified directory as the current working directory.
        If ~ is used the Linux user's home path will be used. If the path begins
        with a / character, it will be interpreted as an absolute Linux path.
        Otherwise, the value must be an absolute Windows path.

If I try this from Powershell, if I do "wsl --cd /home/username" then it can't run Windows executables.

But if I launch a wsl without the --cd, then it works.

[bartdorsey]

Interestingly WSL is in this state almost everytime I start my computer.

If I do a wsl --shutdown then the problem goes away wether or not I use --cd or not.

[jazad1089]

Add VSCode to the path this solved to me.

[razem-io]

UPDATE Better solution here: #6170 (comment)

---

I have this issue sometimes. Not yet sure why. It's because the wsl network drives aren't mapped correctly. So the path then won't work and this is why it is an Invalid argument. The path can simply not be resolved. A fast fix in cmd or ps shell:

wsl --shutdown
wsl

[sbkpilot1]

This has something to do with .git, whenever I do a code . from a directory under Git I get the Invalid Argument, however when I do it from any other folder it works just fine!

Edit - I believe the cause of this was CRLF line endings in the Git metadata files, What I did was deleted my GIT repo and cloned it again into my Linux filesystem using the native Linux client of Git so it creates the proper LF line endings, No more issues starting VS Code.

[vitamin7]

It's definitely have something to do with path. Here is an easy reproducible workaround:
Starting test (can be any directory, or even without specifying directory):

wt nt wsl --cd /

Inside WT:

user@host:/$ ping.exe
/mnt/c/WINDOWS/system32/ping.exe: Invalid argument
                                                  user@host:/$ cd .
user@host:/$ ping.exe

Usage: ping [-t] [-a] [-n count] [-l size] [-f] [-i TTL] [-v TOS]

Note: It's just necessary to issue a 'cd' command. But not necessary to actually change the directory. This is not environment related, as the only difference is "OLDPWD". Setting it explicitly doesn't work.

WT version 1.12.3472.0
O/S Ubuntu 18.04
WSL version 2

[muratcanakcay]

I'm faced with the same problem of getting Invalid Argument. It's unbelievable that the issue has not been resolved after almost 1.5 years.

And then there's also the issue with not being able to access the network drive under \\wsl$ from Windows File Explorer unless you map it to e.g. Z:\ drive. I don't know if they're related but there are many issues opened related to this, too.

[epigramx]

I got this bug after I installed 11 over 10. I noticed something interesting but very weird and hard to debug. If I'm in root's home or / the error happens but if I cd to /mnt/c it goes away (!).

[nathonius]

I see this pop up seemingly randomly. Doing a wsl --shutdown and restarting my terminal fixes it for the next hour or two.

[luismramirezr]

I created a simple script and added a symlink to replace the normal code:

#!/bin/bash

current_working_directory=$(pwd)
vs_code_directory="/mnt/c/Users/<YOUR_USER_NAME>/AppData/Local/Programs/Microsoft VS Code/bin"
param="$1"

cd "$vs_code_directory"
$(./code "$current_working_directory/$param")
cd "$current_working_directory"

It works for me for what I need (just open VSCode loading a folder or file)

[yutsuo]

Had this problem lately when trying to call vscode on WSL2.

Then one day I was looking at my Task Scheduler when I noticed this task:

I didn't create it. Maybe Docker Desktop did?

Anyway I disabled this task and one reboot later, voilá, problem solved.

[wzis]

I tried to copy the chrome.exe from the Windows "Program Files" directory to /var/tmp/, then run it , got the same issue, why:
root@DESKTOP-R0EA0CF:/home/gwz/sec# cp /mnt/c/Program\ Files/Google/Chrome/Application/chrome.exe /var/tmp
root@DESKTOP-R0EA0CF:/home/gwz/sec#
root@DESKTOP-R0EA0CF:/home/gwz/sec#
root@DESKTOP-R0EA0CF:/home/gwz/sec# /var/tmp/chrome.exe
/var/tmp/chrome.exe: Invalid argument
root@DESKTOP-R0EA0CF:/home/gwz/sec#
But if I run the /mnt/c/Program\ Files/Google/Chrome/Application/chrome.exe, it's ok.

[wzis]

a typo, should be without doing anything, just run it 2nd time..

[Sublime1]

This might helps someone else here. I just got this issue this morning. Not sure what changed, everything was working fine yesterday. Last night I hibernated. This morning I noticed that WSL started up faster than usual, which surprised me as it usually takes a minute. Then I do my usual

cd project
code .

And I get that Invalid argument error.
Code is working fine from Windows.

Then, I closed WSL session and from Powershell, I did
wsl --shutdown

Restarted WSL and now Code is working again!

[ono7]

I use wezterm had to set default_prog = { "cmd.exe" } to start, than I do wsl --shutdown followed by wsl and it works.
I also get to \\wsl.localhost\Ubuntu after I do this. Other wise I get access denied, so it must be something with the way that volume is mapped some how. I hope this helps to figure out a proper solution.

[M-Giri-856]

@OneBlue or @craigloewen-msft Hello, any news/updates on this issue? Several users have reported this issue going back almost 3 years now, but there have been no fixes, or acknowledgements even.

[tonyjthomas]

The wsl --shutdown workaround does fix it temporarily, but it's a major inconvenience. Both Docker Desktop and VS Code misbehave when wsl is yanked out from under them, so I end up needing to close all my Code windows and shut down Docker before doing it.

I've not tracked down what causes the "Invalid argument" to start happening - I used to think it was sleeping/hibernating that was the issue, but I've observed it happening even without sleep.

It happens at least once a day. This issue and #4698 are both major barriers preventing me from recommending WSL2 to anyone as a daily driver for work.

[aarontjohnson]

So at least for me, I have found the Invalid argument behavior was caused by the WSL_DISTRO_NAME environment variable in Linux not matching my distro name from "wsl --list", note this behavior is easily reproducible:

(~)[513]> set |grep WSL
WSL_DISTRO_NAME=Ubuntu-22.04

(~)[514]> net.exe
The syntax of this command is:

NET
[ ACCOUNTS | COMPUTER | CONFIG | CONTINUE | FILE | GROUP | HELP |
HELPMSG | LOCALGROUP | PAUSE | SESSION | SHARE | START |
STATISTICS | STOP | TIME | USE | USER | VIEW ]

(~)[515]> export WSL_DISTRO_NAME=not_the_right_name

(~)[516]> net.exe
/mnt/c/Windows/System32/net.exe: Invalid argument

(~)[517]> export WSL_DISTRO_NAME=Ubuntu-22.04

(~)[518]> net.exe
The syntax of this command is:

NET
[ ACCOUNTS | COMPUTER | CONFIG | CONTINUE | FILE | GROUP | HELP |
HELPMSG | LOCALGROUP | PAUSE | SESSION | SHARE | START |
STATISTICS | STOP | TIME | USE | USER | VIEW ]

[ajkessel]

Same problem here, but WSL_DISTRO_NAME matched the wsl --list distro name. Only workaround I've found is to terminate and relaunch wsl.

[fangpenlin]

I encountered similar issue while I was trying to run .exe file from systemd. It turned out my bash has an env var the systemd service doesn't have:

export WSL_INTEROP=/run/WSL/342519_interop

If this env var is missing, you'll see an Invalid Argument error. I am not sure what's WSL_INTEROP value here, will look into it see what I find.

[Jackbennett]

This is the exact same output you get if applocker blocked the binary exe, just a heads up.

[eur2fe]

@OneBlue We are using WSL to run a Linux GitHub runner under Windows, while using the Windows executable of the Git credential manager to obtain the Git token from WSL.

In the GitHub workflow running in Ubuntu/WSL, a Git clone randomly fails with

Cloning into 'repo'...
/mnt/c/Program Files/Git/mingw64/bin/git-credential-manager.exe: Invalid argument

When I trace the Microsoft.Windows.Subsystem.Lxss ETW provider, there is an LxssException that contains some additional info:

PartA_PrivTags: 16777216
wslVersion: 2.0.9.0
File: D:\a\1\s\src\windows\common\SubProcess.cpp
FunctionName: 
Line number: 206
Type: 0
HRESULT: 0x8007010B
Message: ApplicationName: C:\Program Files\Git\mingw64\bin\git-credential-manager.exe, CommandLine: git-credential-manager.exe get
Code: 

As 0x8007010B translates to The directory name is invalid, it seems like the code that launches the Windows executable fails to provide the proper directory, or perhaps uses the current directory of the process or the WSL path that cannot be translated to a DOS path? That may be the reason why the issue occurs at random.

[eur2fe]

As a sidenote, if the Windows error is indeed The directory name is invalid, the errno mapping could be improved.

[OneBlue]

As 0x8007010B translates to The directory name is invalid, it seems like the code that launches the Windows executable fails to provide the proper directory, or perhaps uses the current directory of the process or the WSL path that cannot be translated to a DOS path? That may be the reason why the issue occurs at random.

Thank you @eur2fe. Can you post the full logs ? /logs

[microsoft-github-policy-service]

Hello! Could you please provide more logs to help us better diagnose your issue?

To collect WSL logs, download and execute collect-wsl-logs.ps1 in an administrative powershell prompt:

Invoke-WebRequest -UseBasicParsing "https://raw.githubusercontent.com/microsoft/WSL/master/diagnostics/collect-wsl-logs.ps1" -OutFile collect-wsl-logs.ps1
Set-ExecutionPolicy Bypass -Scope Process -Force
.\collect-wsl-logs.ps1

The scipt will output the path of the log file once done.

Once completed please upload the output files to this Github issue.

Click here for more info on logging

Thank you!

[eur2fe]

I had to implement a workaround to keep our GitHub runners working, so I cannot reproduce this specific problem. However, I created a small repro that may help. Essentially it triggers a race that causes the process creation to fail due to an invalid current directory. Not sure if the root cause is the same (here the current directory being non-existent), but the outcome is the same. I have also seen the problem that the original post is referring to, where I am in the users home directory and the Windows process creation fails consistently (which sounds more like a communication problem with the VM).

I am sending you the logs via e-mail.

#include <stdio.h>
#include <errno.h>
#include <unistd.h>
#include <sys/stat.h>

int main(int argc, char **argv)
{
        int result;
        const char* home = "/home/user";
        const char* path = "/home/user/test";
        result = mkdir(path, 0755);
        printf("mkdir: %d\n", result);
        result = chdir(path);
        printf("chdir: %d\n", result);
        FILE* file = popen("/mnt/c/Windows/system32/cmd.exe /c echo Hello", "w");
        usleep(10000);
        result = chdir(home);
        printf("chdir: %d\n", result);
        result = rmdir(path);
        printf("rmdir: %d\n", result);
        result = pclose(file);
        printf("pclose: %d\n", result);
        return 0;
}

user@host:~$ cc test.c && ./a.out
mkdir: 0
chdir: 0
chdir: 0
rmdir: 0
/mnt/c/Windows/system32/cmd.exe: Invalid argument
pclose: 256

If I make the usleep delay sufficiently large, it works:

user@host:~$ cc test.c && ./a.out
mkdir: 0
chdir: 0
'\\wsl.localhost\Ubuntu-22.04\home\user\test'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.
Hello
chdir: 0
rmdir: 0
pclose: 0

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any author activity for the past 7 days. If you're still experiencing this issue please re-open it.

Thank you!

[tuyen-at-work]

Same issue with git commands.

[benhillis]

Fixed with https://github.com/microsoft/WSL/releases/tag/2.1.0

[jstockwin]

The above release doesn't appear to have fixed the issue for me.

I'm on WSL Release 2.1.0 (in a windows terminal):

>wsl --version
WSL version: 2.1.0.0

but from inside Ubuntu on WSL from my home directory:

$ ping.exe
/mnt/c/Windows/system32/ping.exe: Invalid argument

For me, WSL may work for a few hours without this problem, but at some point it appears. Once it starts, every .exe program will show this error. The only "fix" is to wsl --shutdown which is obviously very inconvenient.

[shashanksingh28]

+1, I believe this issue is not resolved.

$ wsl --version
WSL version: 2.1.5.0
[from Ubuntu-22.04 wsl instance]
$ code . &
/mnt/c/Program Files/Microsoft VS Code/Code.exe: Invalid argument

FWIW, a wsl --uninstall and re-install solved it for the same version. Its possible that the container was created with an older version and hence the problem randomly manifested

[daviewales]

I get this if I'm inside a directory mounted with rclone.

cd ~
echo 'hi' | clip.exe # works

rclone mount sharepoint: ~/sharepoint --vfs-cache-mode full --max-read-ahead 1024Ki --daemon
cd ~/sharepoint
echo 'hi' | clip.exe # error: /mnt/c/Windows/System32/clip.exe: Invalid argument

[dgreenwald-ccs]

I get this if I'm inside a directory mounted with rclone.

Same for Samba mounted folder.

(was trying to use it as a workaround for drvfs problems)

[pwalessi-dell]

I encountered this today on:
WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.19045.4291

wsl --shutdown fixed it for me, we'll see if it comes back.

[kipz]

Same here. Happens randomly during my working day.

WSL version: 2.1.5.0
Kernel version: 5.15.146.1-2
WSLg version: 1.0.60
MSRDC version: 1.2.5105
Direct3D version: 1.611.1-81528511
DXCore version: 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows version: 10.0.22631.3593

wsl --shutdown is the only thing I've found that works.