'cmd.exe /c <GUI app>' does not fork

[BatmanAoD]

Environment

Windows build number: 10.0.20197.1000
Your Distribution version: 18.04
Whether the issue is on WSL 2 and/or WSL 1: WSL 2

Build 20190 is also affected. Build 20170 and earlier are not affected. I am not sure about intermediate builds.

I have not tried with WSL 1.

Steps to reproduce

From a WSL terminal:

cmd.exe /c notepad

The specific GUI app does not appear to matter; I have tried this with gVim and VSCode as well.

Running explorer does not exhibit this behavior.

strace logs:

Gist: https://gist.github.com/BatmanAoD/a223863dd0c699c46f540b26d59ab4bc

WSL logs:

Feedback Hub link: https://aka.ms/AA9dpao

Expected behavior

As the GUI app opens, the WSL terminal command should return immediately, displaying a new prompt. The GUI process(es) and the shell should now be independent.

Actual behavior

The WSL shell appears to hang: it does not print new output or accept new input until the GUI process ends (e.g. by closing notepad). ctl-z and ctl-c do not suspend or kill the "hanging" shell process.

[therealkenc]

Can't repro here.

[BatmanAoD]

@therealkenc I'm sorry, I was trying to simplify my use-case and didn't realize that Notepad doesn't fork. The app that I know is broken is gVim, which should fork a new process so that the cmd invocation can return, causing a new prompt to appear.

[BatmanAoD]

gVim forks in gvim.bat by using start. So it appears that what's changed is the behavior of cmd.exe /c start <foo>.

In 20170, cmd.exe /c start notepad launches Notepad, and a new prompt appears just as it does for gvim. I don't want to re-update to 20197, so I haven't yet checked that this behavior is different, but I expect that adding start to your command will not change the behavior, which would confirm the bug.

[therealkenc]

what's changed is the behavior of cmd.exe /c start <foo>.

Cannot reproduce that either, where <foo> is notepad.exe. Will spare the screencap. For the sport also did a startnotepad.bat.

If you are doing your experiments on two machines (one on 20170 and one on 20197) that would be a better place to start looking for the variable. The probability that "the behavior of cmd.exe /c start" changed between 20170 and 20197 is nonzero but... let's call it... small.

I did notice one thing. Running the cmd.exe /c from /home (read not 9p, read not /mnt/c) is slow AF. You'll note the warning message when trying to use interop from outside a 9p current working directory. With the two-line batch file above, try doing:

$ cd /mnt/c/Users/you
$ cmd.exe /c 'C:\Users\you\startnotepad.bat'

If that works, start looking for what is making gVim special.

[BatmanAoD]

@therealkenc That does look like a successful reproduction to me, actually. As I said, after start, the cmd.exe invocation should return, and a new prompt should appear, letting you type a new command. The shell should not wait for Notepad to exit. Here's the behavior on build 20170; note that Notepad is still open:

As a side note, I always run cmd.exe from /mnt/c to avoid the warning and the slowness.

[therealkenc]

As I said, after start, the cmd.exe invocation should return, and a new prompt should appear, letting you type a new command

I see what you mean now; thanks. Yeah that batch file has exited alright, by the looks. Thanks for the report and persistence.

[DHowett]

Just dropping a note as the engineering owner for CMD (hi!): we haven’t changed start or batch processing since windows build 17763 😄

[therealkenc]

No doubt. Curious WSL interop does eat a batch file and exits back to prompt without launching start notepad.exe.

This .bat file returns back to the bash prompt:

@echo off
echo hello

This does not return until notepad.exe is closed, but does print 'hello' before notepad.exe is closed:

@echo off
start notepad
echo hello

From WSL, powershell.exe start notepad.exe does return. 😛

[BatmanAoD]

@therealkenc should I update the description & title, since the problem appears to be cmd /c start rather than just cmd /c?

Also, thanks for pointing out that powershell.exe start behaves correctly.

[BatmanAoD]

For now I'm using this as a workaround: https://github.com/BatmanAoD/public-config/blob/master/OS_specific/Windows/wsl_host_gvim

[dc46and2]

Seems like this affects more than just cmd.exe /c or cmd.exe /c start. In powershell or cmd terminal, if I run notepad.exe, the process is detached and I immediately get another prompt. Previously, it worked the same in WSL 1 and 2, but now if I run notepad.exe or a similar Windows executable it does not return until the .exe exits. As others mentioned, explorer.exe and powershell.exe start notepad do work correctly.

An easy workaround in bash is notepad.exe & disown. The process will linger in ps but not in jobs and closing the terminal does not affect the executable.

[microsoft-github-policy-service]

This issue has been automatically closed since it has not had any activity for the past year. If you're still experiencing this issue please re-file this as a new issue or feature request.

Thank you!