Global CLI tools creates a orphaned cmd.exe process when CTRL+C is pressed to exit

[natemcmaster]

Steps to reproduce

1. Download this sample build of dotnet-watch:
   dotnet-watch.2.1.0-preview1-t000.nupkg.zip
2. Create a nuget.config file (required until Add support for --source on dotnet install tool #8940 is fixed)

<configuration>
  <packageSources>
    <clear />
    <add key="local" value="./" />
  </packageSources>
</configuration>

1. Install

dotnet install tool dotnet-watch --version 2.1.0-preview1-t000 --configfile ./NuGet.config

1. Create an app and run dotnet-watch

dotnet new console -o app
cd app
dotnet watch run

1. Press CTRL+C

Expected behavior

This should force-quit the global CLI tool, including any parent processes.

Actual behavior

The cmd.exe process started to launch %USERPROFILE%/.dotnet/tools/dotnet-watch.cmd is orphaned.

Before CTRL+C:

After:

The "Terminate batch job (Y/N) question appears, but I cannot give it a response because the parent dotnet.exe process died.

Process 22736 was orphaned

Environment data

Shell: Happens using Command Prompt, Powershell 5, or ConEmu + cmd or powershell.

dotnet --info output:

.NET Command Line Tools (2.2.0-preview1-007796)

Product Information:
 Version:            2.2.0-preview1-007796
 Commit SHA-1 hash:  3ac579997c

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.17025
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Users\namc\.dotnet\x64\sdk\2.2.0-preview1-007796\

Microsoft .NET Core Shared Framework Host

  Version  : 2.1.0-preview1-26008-01
  Build    : 0327161c32d0d6175914521e47d91df3db38ebb4

cc @wli3 @anurse

[wli3]

I need to dig more on this

[analogrelay]

This is why bat/cmd files are so annoying as shims on Windows :(. I don't think this is avoidable when using them, but I don't know for sure.

[natemcmaster]

Did some quick research. Doesn't look like this avoidable when using cmd.exe. All the suggestions I've seen to get around this is to invoke something other than cmd.exe.

http://h4ck3r.net/2013/07/21/suppress-terminate-batch-job/
https://superuser.com/questions/35698/how-to-supress-terminate-batch-job-y-n-confirmation

[natemcmaster]

@livarcocc @wli3 I know time is winding down on preview1, so I'd like to re-emphasize this bug causes the console to become unresponsive, even after repeated CTRL+C presses.

I can't use dotnet-watch myself as a global tool because of this. Please take a look at dotnet/cli#8384. I don't know of any other solution than to just not use cmd.exe

cc @muratg

[muratg]

cc @danroth27

[danroth27]

cc @KathleenDollard

[KathleenDollard]

My apologies for missing this, thanks for the ping @danroth27.

I will discuss this with @livarcocc this afternoon.

[wli3]

https://github.com/dotnet/cli/blob/4343118151b7b72a4472f159c46d0a7ea99d0ab3/src/Microsoft.DotNet.Cli.Utils/CommandResolution/WindowsExePreferredCommandSpecFactory.cs#L72

this line is the real problem. It is not .cmd file alone. It is .cmd + how CLI create "Command" (start a new .cmd process)

If you directly call "dotnet-watch" it will not create the orphan process.

[shanselman]

Per PowerShell/PowerShell#11314 we are seeing this now with Scoop, Chocolatey, and most importantly PowerShell Core when installed as a Global Tool (which is the default recommended way per the docs) when used with the Windows Terminal.

Windows Terminal now adds .NET Global Tool-installed pwsh (which is becoming quite popular) and simply running it (via the global tool shim) and then pressing ctrl+c stops everything and orphans the process.

[shanselman]

@KathleenDollard can we reopen?

[wli3]

@shanselman this is not the same issue. Powershell non global tools distribution has a different exe with special handing in it.

[KathleenDollard]

Current understanding of the problem:

The reason this occurs is that normal Ctl-C handling by the AppHost used for all .NET Core runtime-dependent and self-contained applications can be adversely affected by the application itself. For example, a child-process it needs to not swallow the Ctl-C keypress.

Because this Ctl-C issue is due to the application behavior, it will occur regardless of how the runtime-dependent version of PowerShell is delivered. The non-runtime-dependent variants of PowerShell are, of course, not affected.

Suggestions for a fix has been passed on, so we expect PowerShell to be fixed in response to PowerShell/PowerShell#11314 so I am not reopening this issue.