Terminal: Terminal doesn't respond to SIGINT (CTRL+C KeyboardInterrupt) when running as administrator

[403-Fruit]

Environment

Windows build number: Windows NT 10.0.19041.0
Windows Terminal version: Version: 0.10.781.0

Steps to reproduce

• Start one terminal as administrator, and one normally
• Using PowerShell or cmd (didn't test other shells), start some continuous process, e.g ping -t localhost
• Try to interrupt process with ctrl+c on each terminal.
• Observe that it only works on the unelevated terminal.

Expected behavior

SIGINT causes console process to exit, regardless of elevation

Actual behavior

Process does not respond to SIGINT, and requires manual termination from taskmgr or another shell

[DHowett-MSFT]

Can't repro this, as admin.

[403-Fruit]

I think it's the way I'm launching it, as it's a bit improper. I have a shortcut on my taskbar with the target

C:\Windows\System32\cmd.exe /c start /b wt

that is set to run as administrator, just so that it defaults to admin. I just tried and it works as expected if I Right click -> Run as Administrator.

I can't remember why I used the above target, but setting it to wt.exe appears to produce the desired behavior, and CTRL+C works fine.

[DHowett-MSFT]

Ah, thanks for following up. That’s really quite strange. I’m not sure there’s anything we can do about that; perhaps there is something strange about app activation in this context... ☹️

For now, I’ll resolve this one as External. Please let me know if you have any other ideas or any other leads.

[eryksun]

I think it's the way I'm launching it, as it's a bit improper. I have a shortcut on my taskbar with the target

C:\Windows\System32\cmd.exe /c start /b wt

Why doesn't the shortcut simply run wt.exe?

The /b option of CMD's start command calls CreateProcessW with the creation flag CREATE_NEW_PROCESS_GROUP and without the flag CREATE_NEW_CONSOLE, so it sort of acts like running a background process in the current console session, especially if combined with redirecting the process standard input to NUL.

A process that's created in a new console process group initially has Ctrl+C disabled (i.e. the ConsoleFlags in the PEB process parameters has the first bit set). I guess it's because only 'foreground' processes should see Ctrl+C. This setting gets inherited by child processes.

Interestingly, this flag remains set in the process parameters and inheritable even if we run a non-console application such as Windows Terminal. I suggest that Windows Terminal should clear this flag to enable Ctrl+C on startup via SetConsoleCtrlHandler(NULL, False).

[DHowett-MSFT]

Good catch, @eryksun. Thanks!

[403-Fruit]

Why doesn't the shortcut simply run wt.exe?

@eryksun That's a mistake on my part. I don't quite remember why I ended up with that, and it seems completely unnecessary in hindsight. Thanks for the insight.

[403-Fruit]

By the way, you guys are doing an awesome job with the Terminal. It's a home run IMO, and I'm genuinely excited to see what comes next 👍

[msftbot[bot]]

:tada:This issue was addressed in #5472, which has now been successfully released as Windows Terminal Preview v0.11.1191.0.:tada:

Handy links:

• Release Notes
• Store Download