Global CLI tools creates a orphaned cmd.exe process when CTRL+C is pressed to exit
See original GitHub issueSteps to reproduce
- Download this sample build of dotnet-watch: dotnet-watch.2.1.0-preview1-t000.nupkg.zip
- Create a nuget.config file (required until dotnet/sdk#8940 is fixed)
<configuration>
<packageSources>
<clear />
<add key="local" value="./" />
</packageSources>
</configuration>
- Install
dotnet install tool dotnet-watch --version 2.1.0-preview1-t000 --configfile ./NuGet.config
- Create an app and run dotnet-watch
dotnet new console -o app
cd app
dotnet watch run
- 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
Issue Analytics
- State:
- Created 6 years ago
- Comments:12 (6 by maintainers)
Top Results From Across the Web
Windows 10: CMD.exe cannot stop process with CTRL+C
1 Answer. One possible cause is if you start cmd.exe with the start /b command, since that disables Ctrl+C, as the help text...
Read more >How can I stop webpack dev server from windows console?
I run webpack devserver by issuing the "npm start" command. I've found that CTRL+C doesn't work for me and just creates an orphaned...
Read more >Ctrl+C doesn't work in cmd.exe
I can't cancel a process in cmd.exe by pressing Ctrl+C. This ... First you right click on the title bar Command prompt, select...
Read more >Clink v1.5.1
Name Default * Description
autosuggest.enable False *
clink.promptfilter True Enable prompt filtering by Lua scripts.
lua.break_on_error False Breaks into Lua debugger on Lua errors.
Read more >The subprocess Module: Wrapping Programs With Python
In this tutorial, you'll learn how to leverage other apps and programs that aren't Python, wrapping them or launching them from your Python...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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 https://github.com/PowerShell/PowerShell/issues/11314 so I am not reopening this issue.
@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