VS Code holds onto parent console when launched via command line

[Tyriar]

Repro:

1. Open cmd.exe
2. Run code
3. Switch back to cmd.exe
4. exit

Repro's in stable and insiderrs and does not repro in Atom which is also on Electron 2.

Advice from Windows console team:

I believe VSCode is reconnecting to its parent hosting console for debugging purposes.

Starting with @joaomoreno who might know who to send this to, not sure who the real owner is though.

[DHowett-MSFT]

FWIW, The console is working as-designed. Since there is a connected client application, we won't exit because we don't want to sever its standard input/output/error handles (or the console handle it has allocated.)

[joaomoreno]

@Tyriar We have had some issues like this in the past. I do not know nearly enough about Electron, Windows or Windows console infrastructure to make an informed decision. If you have some ideas, solution, let me know.

[Tyriar]

@DHowett-MSFT we don't call AttachConsole anywhere AFAIK, is there any other way to attach to the console? Doing a search of the whole codebase+deps the only place AllocConsole, FreeConsole and AttachConsole are used is within node-pty/winpty.

[DHowett-MSFT]

We're definitely seeing Code (electron.exe, really) calling AttachConsole during startup:

0775f224 75c8a500 ntdll!NtCreateFile+0xc
0775f7fc 75d373db KERNELBASE!ConsoleCreateConnectionObject+0x158
0775fa44 75d3717b KERNELBASE!ConsoleAttachOrAllocate+0x91
0775fa70 0066755a KERNELBASE!AttachConsole+0x3b
WARNING: Stack unwind information not available. Following frames may be wrong.
0775fa7c 004e26f9 Code+0x21755a
0775fb04 02584bc8 Code+0x926f9

Unfortunately, I don't have symbols for Code/electron, so I can't point out the originating line.

(This backtrace was generated by setting a breakpoint on conhost's connection request handler and then investigating the originating process to see where it was stuck.)

[DHowett-MSFT]

I am, however, convinced that this line is the cause. I can't find RouteStdioToConsole anywhere but Chromium's source, but it looks like that is what's calling AttachConsole.

[Tyriar]

@DHowett-MSFT I just spotted that as well, maybe the Electron build we're on isn't official. @bpasero our Electron builds may be being built without OFFICIAL_BUILD set:

https://cs.chromium.org/chromium/src/mash/runner/main.cc?type=cs&q=RouteStdioToConsole&sq=package:chromium&g=0&l=42

This likely has performance implications as well if this is the case.

[bpasero]

@Tyriar I got some homework for you:

• find out if this is true for our Microsoft build of Electron and/or the GH release to see if this is an issue with our internal build or a general issue with the GH build
• if this is an issue with GH build, report it to the Electron repo (https://github.com/atom/electron)
• if this is an issue with the MS build, I can forward this to the team that produces the build

[bpasero]

@Tyriar it looks like only starting with Electron 4.0.x we will benefit from this flag being set.

//cc @deepak1556

[deepak1556]

Electron does build with chromium OFFICIAL_BUILD flag since 3.x. The source of the issue is the code from electron https://github.com/electron/electron/blob/master/atom/app/atom_main.cc#L132 that attaches to the console mentioned by @DHowett-MSFT .

[Tyriar]

OK I'm a little confused now, doesn't code.cmd do the following:

1. Launch the CLI with set ELECTRON_RUN_AS_NODE=1 (we want the CLI to attach)
2. The CLI deletes ELECTRON_RUN_AS_NODE
3. The CLI launches the executable (not run as node should not attach)
4. The CLI exits which returns to the prompt (nothing should be attached)

Even adding this line to code.cmd set ELECTRON_NO_ATTACH_CONSOLE=1 will repro the same problem which should certainly not hit that Electron code path, so maybe it is an OFFICIAL_BUILD issue? I'll test the open source build which will pull official Electron releases, that should hopefully verify.

[Tyriar]

@deepak1556 does main.cc not get run in Electron as it's replaced by atom_main.cc?

[deepak1556]

atom_main.cc is the entry point to chromium's main which is invoked by content::ContentMain().

@Tyriar in your test case can you make sure the env variable ELECTRON_NO_ATTACH_CONSOLE is sent by CLI that launches the executable in step 3.

[Tyriar]

@deepak1556 I checked the renderer's process.env and it was there, so it seems to have been set all the way through. It's also set explicitly here in the CLI before launching the main process:

https://github.com/Microsoft/vscode/blob/ac1812d748463ca1cb1e6777e7029134f4b56f2f/src/vs/code/node/cli.ts#L117-L124

There's also some code here that deals ELECTRON_NO_ATTACH_CONSOLE inside the main process when it's setting up its env:

https://github.com/Microsoft/vscode/blob/ac1812d748463ca1cb1e6777e7029134f4b56f2f/src/vs/code/node/shellEnv.ts#L14

But it looks like it just carries it over:

https://github.com/Microsoft/vscode/blob/ac1812d748463ca1cb1e6777e7029134f4b56f2f/src/vs/code/node/shellEnv.ts#L52-L61

[bpasero]

Adding @joaomoreno who seems to have added ELECTRON_NO_ATTACH_CONSOLE via cd779ff

I am still not fully understanding the issue here and if the OFFICIAL_BUILD flag is missing or not.

[dweddig01]

Any updates on this. Reading through the comments is a little confusing if this is planned to be fixed, or not. What is weird, is it use to work where running "code ." from the command line did NOT seem to hijack the PowerShell 7 session. But now it does it again. I do have a newly installed computer so there may be a behavior related to some kind of setting?

[jeffreywstevens]

I now have this same problem. I execute "code ." and Visual Studio Code opens and immediately closes.
It only occurs in PowerShell Version 7.2.5. This is a Windows 11 pro workstation.
The developer command prompt, bash, old PowerShell all work fine.

[zeroxia]

On Windows 10:

1. Press Win+R, the "Run" dialog appears
2. Enter "code", and press <ENTER>
3. A black "cmd" console window appears, and the VS Code launches, and the black "cmd" console won't disappear

Or similarly:

1. Inside cmd.exe console window, type code and press <ENTER>
2. VS Code launches
3. In the same cmd.exe console window, type exit, and the console won't close.

The same thing in PowerShell, terminal won't quit after typing exit, but will quit after exiting the VS Code.

This is minor but quite annoying.

[kevincharp]

If I put in my environment variables the following path "C:Program FilesMicrosoft VS Code" and change the name of the .exe file from "code.exe" to "vscode.exe" would it have consequences for the correct functioning of VS Code?

At first glance it seems a possible solution that prevents a cmd window from opening when I run vscode that was previously run code

[AnrDaemon]

It will be even worse. In addition to holding the console, it will spam debug messages to it.

[kevincharp]

Two years with the same problem, no solution for an annoying cmd console popup? I also don't understand what the problem is with changing the environment variable and pointing to "C:/Program Files/Microsoft VS Code" instead of "C:/Program Files/Microsoft VS Code/bin".

When one points the variable to "C:Program Files/Microsoft VS Code" the pop up disappears.

So I was reading the only solution is not to start VS Code from the command "Run" and open it from the graphical interface?

[RazvanModex]

I solved my problem following @kevincharp solution described here. In my case, I had to change from C:\Users\<username>\AppData\Local\Programs\Microsoft VS Code to C:\Users\<username>\AppData\Local\Programs\Microsoft VS Code\bin. Essentially, you need to run code.cmd script instead of the actual Code.exe executable. I ended up with this problem because I lost my PATH variable.

[AnrDaemon]

Now, exit the shell in which you started the "code.cmd" script, while VS Code is still running. Console will stay open, unless

• VS Code was running before you started the script, or
• You closed VS code already.

[kevincharp]

Another solution I found was to install VS Code with Systems Installer, and verify that the environment variable is C:\Program Files\Microsoft VS Code\ by default it usually comes C:\Program Files\Microsoft VS Code\bin, When this variable is changed when executing the code command, look for the code.exe file in the Microsoft VS Code folder within Program Files.

[AnrDaemon]

Again, this is irrelevant to the type of installer. (I'm using system.)
Not using code.cmd makes situation worse. Not only it holds to console, it prints debug trace to it.

[kevincharp]

I don't understand what the problem would be with directly executing code.exe and not executing code.cmd? code.exe does not start a debug?
Isn't it supposed that when vsCode is started from the graphical interface what is executed is code.exe?

[RazvanModex]

I don't understand what the problem would be with directly executing code.exe and not executing code.cmd? code.exe does not start a debug? Isn't it supposed that when vsCode is started from the graphical interface what is executed is code.exe?

When you run code . from the terminal and then close the terminal, VS Code will also close.

[the-ress]

I don't understand what the problem would be with directly executing code.exe and not executing code.cmd? code.exe does not start a debug? Isn't it supposed that when vsCode is started from the graphical interface what is executed is code.exe?

The code command has some options that run in console without GUI (for example --list-extensions). They won't work with the plain code.exe.

[kevincharp]

In short, I understand that vscode is executed in different ways... if it is executed from the console, code.cmd is executed and code.exe is executed from the graphical interface. It does not seem like a correct way to execute a program that is normally used. run from the graphical interface, and it turns out that if you start from it, a debug process does not run. On the other hand, the terminal window that opens automatically and remains open while code is executed is annoying and requires having a more open window. Something that could be avoided.

[AnrDaemon]

When you run code . from the terminal and then close the terminal, VS Code will also close.

I totally forgot about this brilliant gem of insanity… I'm so used to NOT force closing the terminal, I didn't even try to test application behavior under such condition.

[zeroxia]

In either Windows terminal or cmd.exe, I can type calc to launch the calculator, and then back to the console, type exit, the console would exit, leaving the calculator still present.

For a thirdparty program like notepad3, it is the same.

So what's the difference for VSCode to not capable of doing this?

[AnrDaemon]

In either Windows terminal or cmd.exe, I can type calc to launch the calculator, and then back to the console, type exit, the console would exit, leaving the calculator still present.

For a thirdparty program like notepad3, it is the same.

So what's the difference for VSCode to not capable of doing this?

There's "a lil' bit o' difference" between starting a program from command prompt or running it by other means.
Try to run same "calc" or "notepad" from within a batch file. It will wait until you close the program and only then it would return to the prompt (or, more generally, continue the script execution).
But if you use incantation START "" notepad.exe, it would return to the prompt immediately. Same does happen for VS Code.
And if you exit the prompt instantly, it would happily close even if notepad is still running. Same DOES NOT happen for VS Code. The "cmd" app will exit, but the console window would remain as if you had started a daemon with START /B … and it is still running in background.

[Exathi]

Workaround for powershell is to launch vscode in a runspace instead. This seems to work without consequences.

$Powershell = [PowerShell]::Create()
$null = $Powershell.AddScript({code})
$Handle = $Powershell.BeginInvoke()
$Powershell.EndInvoke($Handle)