Change:
VSCode Version: 1.38.1 OS Version: Win10 (10.0.) The following used to work in .NET Core 2.2 app with a debug profile for the in earlier versions of VSC (or OmniSharp if that's where the problem actually lies here), but it doesn't work with new 3.0 framework bits and the latest public VSC. Debug a .NET Core app in the using either the or project SDK that calls on the host builder so that the app should listen for to stop the app. The app doesn't stop. Steps to Reproduce: a .NET Core console app with ... The preceding code works if the app is run with in a command shell ... <img width="503" alt="Capture1" src="https://user-"a console debugger profile and run the same app in the ... The app will not respond to . In prior versions (.NET Core 2.2), would work when using the in this scenario. I asked ASP.NET Core engineering, and they thought it might be on the VSC-side of the equation given that works when the app is run in a command shell. See item response 4 at I put up a repro project at The sample app that I put up also has a keystroke-monitoring service that logs presses of the key. That code works. Running in the , the app reports that it hears the key clicks, while the app doesn't respond to . Sure, the app could listen for there and shut the app down, but that's not the point ... that would be a hack. should work the way that this app works in a normal command shell (I think :smile:). Does this issue occur when all extensions are disabled? That can't be checked because the configured debug type is , which isn't supported without either (or both) C# OmniSharp. In fact, I'm not sure if this bug report should be filed here or over on
Looks close to , can you check what your setting is set to?
~Sure ... how do I check that value?~ Found it :point_down:
Found it .... <img width="286" alt="Capture1" src="https://user-"... but that matches the "fix" described in the SO post at
if it's sysnative that indicates to be that you're running the 32-bit version of VS Code on a 64-bit OS, is that correct? Does the 64-bit version work?
64-bit OS, yes. <img width="361" alt="Capture1" src="https://user-"WRT VSC ... How can I tell? ...... I don't recall what I installed, but I imagine that I installed the 64-bit version of VSC.
should tell you, if you're on the 64-bit version you should definitely be using System32 not sysnative.
<img width="113" alt="Capture1" src="https://user-"
So .... I should get 64-bit and test. Stand-by ... I'll do that now and let you know what happens.
I suppose that I can install these SxS. ...... I'm working on our docs :smile: ... I hope I don't :boom: anything. Should I do this on my laptop, or will SxS be ok?
you can download the zip, close all your current windows and then open the zip executable. If you try running the 64-bit version while the other is running it will probably just open another 32-bit window.
kk .... ran the app with 64-bit VSC ... same behavior. After a few key presses that it heard, I hit ... nothing ... app still running. Only clicking the debugger stop button kills the app. <img width="515" alt="Capture1" src="https://user-"
Does the same thing happen when you launch the external terminal using ctrl+shift+c? Also can you open an integrated terminal and run and paste in the output?
Opening with Ctrl+Shft+C and running the app with it works ... <img width="336" alt="Capture1" src="https://user-"... <img width="424" alt="Capture2" src="https://user-"
btw - It does work in that terminal ... <img width="476" alt="Capture1" src="https://user-"
... and thus if I change the profile to ... it works. It's when I have it set to ... ... in the console window that's spawned ... that's where Ctrl+C doesn't work to shut the app down.
might be an issue with what the debugger is launching, I'm not sure if this is debug or an extension.
For the Python extension this breaks after version 1.46 (specifically ). It especially sucks because Pylance was introduced in 1.47 (or maybe 1.48) so I end up flip flopping when I need to ctrl+c out of debugging servers :(
The external terminal is typically launched by VS Code. And the terminal's executable for Windows is configured via the setting. The default is this: There where no code changes in that area around VS Code 1.46.
sorry this is on Ubuntu 20.04. I commented here because it was the only issue I found with pretty much the exact same issue where ctrl+c doesn't send a SIGINT into the program being debugged and pressing the stop button just closes the terminal and the program's SIGINT handler isn't hit. I'll post a repro soon.
I can repro this, but have no idea why it is happening. Simple program: Running the same command that VS Code is running from a instance manually, it works fine. But in an external terminal, no SIGINT is sent.

Discussion:
*--------------------------------------------------------------------------------------------*/ import * as cp from 'child_process'; <ins> import { memoize } from 'vs/base/common/decorators'; </ins> import { FileAccess } from 'vs/base/common/network'; import * as path from 'vs/base/common/path'; import * as env from 'vs/base/common/platform';

return new Promise<void>((c, e) => { const env = getSanitizedEnvironment(process); <del> const child = spawner.spawn(command, cmdArgs, { cwd, env }); </del> <ins> const child = spawner.spawn(command, cmdArgs, { cwd, env, detached: true }); </ins> child.on('error', e); child.on('exit', () => c()); }); } <del> public runInTerminal(title: string, dir: string, args: string[], envVars: ITerminalEnvironment, settings: IExternalTerminalSettings): Promise<number | undefined> { </del> <ins> public async runInTerminal(title: string, dir: string, args: string[], envVars: ITerminalEnvironment, settings: IExternalTerminalSettings): Promise<number | undefined> { </ins> const exec = 'windowsExec' in settings && settings.windowsExec ? settings.windowsExec : WindowsExternalTerminalService.getDefaultTerminalWindows(); <ins> const wt = await WindowsExternalTerminalService.getWtExePath(); </ins> return new Promise<number | undefined>((resolve, reject) => {

// inside it spawnExec = exec; cmdArgs = ['-d', '.', WindowsExternalTerminalService.CMD, '/c', command]; <ins> } else if (wt) { // prefer to use the window terminal to spawn if it's available instead // of start, since that allows ctrl+c handling (#81322) spawnExec = wt; cmdArgs = ['-d', dir, exec, '/c', command]; </ins> } else { spawnExec = WindowsExternalTerminalService.CMD; cmdArgs = ['/c', 'start', title, '/wait', exec, '/c', command];

} return WindowsExternalTerminalService._DEFAULT_TERMINAL_WINDOWS; } <ins> @memoize private static async getWtExePath() { try { const wtPath = await processes.win32.findExecutable('wt'); return await pfs.Promises.exists(wtPath) ? wtPath : undefined; } catch { return undefined; } } </ins> } export class MacExternalTerminalService extends ExternalTerminalService implements IExternalTerminalService {