Unable to launch Windows applications from WSL

[skuzzer]

Please fill out the below information:

• Your Windows build number: Microsoft Windows [Version 10.0.18323.1000]

• What you're doing and what's happening: (Copy&paste the full set of specific command-line steps necessary to reproduce the behavior, and their output. Include screen shots if that helps demonstrate the problem.)

skuzzer@skuzlaptop:~$ notepad

• What's wrong / what should be happening instead: Notepad should launch, nothing happens instead.

• Strace of the failing command, if applicable: notepad.strace

[therealkenc]

I was able to reproduce here on 18323. I guess something went south that roll. Nothing to see in the strace. WSL thinks the execve succeeded.

1361  execve("/mnt/c/WINDOWS/system32/notepad.exe", ["notepad.exe"], 0x7ffff1922558 /* 21 vars */) = 0
1361  arch_prctl(ARCH_SET_FS, 0x294820) = 0
[... blah blah

On a lark I tried launching notepad.exe with CWD /mnt/c/Users/ken and it is okay. So there's your variable.

[Biswa96]

Something wrong in /init side. LxCore event log shows:

 ExecutablePath:init Function:LxpWritevHelper Line:20648 Message:[0xfffffff7] LxpFileReferenceByDescriptor
ExecutablePath:init Function:LxpSysDispatch Line:6133 Message:[0xfffffff7] Syscall 20 failed with unexpected error -9!

syscall 20 is writev.

If I launch in ~ folder, init translates into \\wsl$\Ubuntu\root.

[benhillis]

This is an issue with path translation that will be fixed shortly.

[gojimmypi]

fwiw - I am able to launch notepad.exe (not notepad without the .exe) from WSL, no problem:

Microsoft Windows [Version 10.0.17763.253] (older version than 18323 referenced above)

[Biswa96]

Is there any issue in new 20H1 builds? If I type cmd.exe in /bin folder it launches with this message:

'\\wsl$\Debian\bin'
CMD.EXE was started with the above path as the current directory.
UNC paths are not supported.  Defaulting to Windows directory.

[gojimmypi]

I will say that in at least one instance, I've seen different results in launching Windows EXE files, depending on the starting directory in WSL: whether it is a Windows file system from /mnt/c/... or the WSL linux file system, from ~/... (perhaps related to VoIFS?)

fwiw - cmd.exe does not seem to be affected on my machine:

gojimmypi@MYCOMPUTER: ~
0 $ pwd
/home/gojimmypi
gojimmypi@MYCOMPUTER: ~
0 $ cmd.exe
Microsoft Windows [Version 10.0.17134.648]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>exit
exit
gojimmypi@MYCOMPUTER: ~
0 $ cd /mnt/c
gojimmypi@MYCOMPUTER: /mnt/c
0 $ cmd.exe
Microsoft Windows [Version 10.0.17134.648]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\>exit
exit
gojimmypi@MYCOMPUTER: /mnt/c
0 $ cd /bin
gojimmypi@MYCOMPUTER: /bin
0 $ cmd.exe
Microsoft Windows [Version 10.0.17134.648]
(c) 2018 Microsoft Corporation. All rights reserved.

C:\WINDOWS\system32>exit
exit
gojimmypi@MYCOMPUTER: /bin
0 $ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 18.04.2 LTS
Release:        18.04
Codename:       bionic
gojimmypi@MYCOMPUTER: /bin
0 $

I will say that on more than one occasion, I've done a rip-n-replace of WSL Ubuntu, fully removing and installing fresh.

[benhillis]

@Biswa96 - This is an expected warning. cmd.exe does not support UNC paths.

[skuzzer]

Just checking, is this expected to still not be working fully in build 18890?
e.g. notepad works, but chrome doesn't

[techno-disaster]

@Biswa96 - This is an expected warning. cmd.exe does not support UNC paths.

@benhillis is there workaround to this?

[bessx]

@Biswa96 - This is an expected warning. cmd.exe does not support UNC paths.

how would one launch it without the warning?
I've been putting 2>/dev/null at the end of my cmd.exe commands, which I think could get me into trouble...

[therealkenc]

how would one launch it without the warning?

I work-around with pushd /mnt/c ... popd. In many (I'd say most) scenarios >/dev/null won't fly because you lose the actual stdout you want from the command.

The problem is worthy of a standalone new issue / feature request (categorization academic) for someone motivated. [The warning was not the OP submission, which was a failure to launch an interop app period, long addressed some eons back in Feb 2019.] Spewing a warning (however well meaning) is not Linux behavior (or *nix behavior). The warning message is notably incorrect when the command doesn't involve a UNC path to begin with. Whether addressing the problem would be entertained I can't say, but would get my thumbs-up on a well-formed OP from me, anyway. The fix is to have a L:\ drive to go with \\wsl$\ (same G:\ drive for an analogous filesystem product offering). Or in the absence of that, punt with a lame wsl.conf flag "yes we know UNC paths are not supported, don't spew text to the console."

In principle it could be worked-around harder for someone super-motivated enough to do their own binfmt_misc or bash trap, but that's a pretty heavy lift for a spurious warning.