search

microsoft / WSL

Issues found on WSL
https://docs.microsoft.com/windows/wsl
MIT License
17.29k stars 814 forks source link

"Invalid argument" when executing Windows commands on Ubuntu 20.04 #6170

Closed gAllegr closed 9 months ago

gAllegr commented 3 years ago

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-ubuntu

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

fcongit commented 1 year ago

I'm running into the same issue.

wsl -v 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

$ lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 22.04.1 LTS Release: 22.04 Codename: jammy

Steps to reproduce

$ pwd /home/fabrice $ cmd.exe /mnt/c/windows/system32/cmd.exe: Invalid argument

$ cmd.exe /mnt/c/windows/system32/cmd.exe: Invalid argument

$ cd /mnt/c $ cmd.exe Microsoft Windows [Version 10.0.19045.2486] (c) Microsoft Corporation. All rights reserved.

C:>exit $ cd - $ pwd /home/fabrice $ cmd.exe /mnt/c/windows/system32/cmd.exe: Invalid argument

jlv-adenza commented 1 year ago

I have the same kind of Schrödinger bug that comes and disappears randomly. 

wsl -v
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
jlv@ubuntu% lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 22.04.1 LTS
Release:    22.04
Codename:   jammy

Right now it's working, but few days ago here is what I got

jlv@ubuntu% cd /tmp
jlv@ubuntu% cmd.exe
/mnt/c/windows/system32/cmd.exe: Invalid argument
                                                 jlv@ubuntu%

and when moving on a Windows directory

jlv@ubuntu% cd /mnt/c
jlv@ubuntu% cmd.exe
Microsoft Windows [Version 10.0.19045.2364]
(c) Microsoft Corporation. All rights reserved.
C:\>
NickLiu635 commented 1 year ago

I have the same problem in WSL1, Win11 with USB disk.

WSL 版本： 1.1.3.0
内核版本： 5.15.90.1
WSLg 版本： 1.0.49
MSRDC 版本： 1.2.3770
Direct3D 版本： 1.608.2-61064218
DXCore 版本： 10.0.25131.1002-220531-1700.rs-onecore-base2-hyp
Windows版本： 10.0.22621.1413
user@pc:/mnt$ df
df: /mnt/e: Invalid argument
Filesystem     1K-blocks      Used Available Use% Mounted on
rootfs         499300008 316414232 182885776  64% /
none           499300008 316414232 182885776  64% /dev
none           499300008 316414232 182885776  64% /run
none           499300008 316414232 182885776  64% /run/lock
none           499300008 316414232 182885776  64% /run/shm
none           499300008 316414232 182885776  64% /run/user
tmpfs          499300008 316414232 182885776  64% /sys/fs/cgroup
C:\            499300008 316414232 182885776  64% /mnt/c
user@pc:/mnt$ cd e
user@pc:/mnt/e$ ls
ls: cannot open directory '.': Invalid argument

This USB disk works well in Windows Works well again in wsl after wsl --shutdown

ajmt-dev commented 1 year ago

This happens to me when running my WSL instance from an elevated Terminal shell/prompt - albeit it's Oracle.

Using Terminal not elevated, and the executables work as expected. This didn't happen in the past, not sure when it stopped working. image

wzis commented 1 year ago

The WSL2 on the most updated Windows 11 is still not stable:

[root@asus whc]# ./win11.bios.ps1 /var/tmp/.cmd.qOOVpp.ps1 : The term '/var/tmp/.cmd.qOOVpp.ps1' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again. At line:1 char:1

[root@asus whc]# ./win11.bios.ps1 Computer Name : ASUS BIOS : S5402ZA.305 Version : ASUS - 1072009 Manufacturer : American Megatrends International, LLC. SMBIOSBIOS Version : S5402ZA.305 Service Tag : N4N0CV093754164

[root@asus whc]# The win11.bios.ps1 is a powershell script encapsulated into a binary program with added anti-software hacking capabilities running on the Linux env. But as you can see, when first executed, it is not recognized as a command. But with doing anything, just run it 2nd time, it becomes ok.

wzis commented 1 year ago

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

Sublime1 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

@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 commented 1 year ago

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 commented 11 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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

eur2fe commented 9 months ago

@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 commented 9 months ago

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

OneBlue commented 9 months ago

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[bot] commented 9 months ago

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 commented 9 months ago

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[bot] commented 9 months ago

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 commented 9 months ago

Same issue with git commands.

benhillis commented 8 months ago

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

jstockwin commented 8 months ago

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 commented 5 months ago

+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 commented 4 months ago

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 commented 4 months ago

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 commented 4 months ago

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 commented 3 months ago

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.