Multiple instances or processes of visual studio code in task manager for single application window

Question

I'm using Visual Studio Code. I'm facing a performance issue on my machine. I went to task manager and saw that there are several instances of Code.exe in the process tab even though there is only one window of Visual Studio Code running/active on my PC.

I can see that in all there are eight instances of Code.exe. Although, I can see that all eight instances are taking RAM memory in the range of few KBs to a maximum of 55 MB. So one thing was sure that these few processes are not eating up too much memory together but still their count stumbled me for a second. I had an understanding that one Visual Studio Code window should map to a single Code.exe process.

I've one more observation. I opened another fresh window of Visual Studio Code and saw that the count of Code.exe processes increased by two instead of one this time. Total Code.exe process count now became 10 on its own when a total of 2 Visual Studio Code windows are currently active. I'm not sure what's going on in here. Can someone help me understand if this is the right behavior on how Visual Studio Code is implemented internally?

Solution 1

This behavior is by Design and is documented in the comments in the Github Issues #5856, #8006 and #20856

Summary from the comments mentioned in the Links

This behavior is a consequence of both how vscode was designed and the fact that it's build on Chromium/Electron. The number of processes should not really matter from an end user perspective, it's the amount of work each process does and the communication between them that are important.

By design, the UI framework we use is multi process by itself and then we have 1 process for extensions (per window), one process for file watching (per window) and 1 process for search. We also have 1 shared process for updates.

Using a Tool like Process Explorer, You can get more details about the Process. Only one of the Process code.exe would have the parent as explorer.exe which denotes the Main Process which spawned other Children Processes. Following is a screenshot of how the Main code.exe properties appears using the Tool Process Explorer.

Additionally, a quick glance at the command line arguments for each of the Children code.exe process would provide more useful information as to what each process is supposed to do. For e.g. one of the Child process code.exe seems to be an error Reporting Process for crashes.

"C:\Program Files (x86)\Microsoft VS Code\Code.exe" --reporter-url=https://ticinocrashreporter.azurewebsites.net/crash --application-name=VSCode "--crashes-directory=..\AppData\Local\Temp\VSCode Crashes" --v=1

Solution 2

Well I too just figured out that issue in my task manager. My case it is 6 instances. It was a lot more previously but once I cleared the recent project list in File > Open Recent, the number came down to 6.

Now the mystery of 6 was also resolved. The extra instances in task manager are used for the 'Extensions', 'Code editor' etc. windows / views inside VS Code.

You can verify this by killing one by one other instances in the task manager, as you do that the VS Code will start showing error and will complain about the instances that we are killing in task manager.

Hope it helps.

Comments

[RBT]

Interestingly when I looked at the properties of main code.exe process (parent of other code.exe processes) in process explorer, it shows its parent as <Non-existent Process>(5188). I checked the process explorer and task manager both but there is no explorer process running with PID 5188. Does windows play some trick to keep such explorer.exe process hidden from the user. I can see another explorer.exe process with a different PID 3056 though. Does window maintains multiple/several explorer.exe processes meant for different purposes?

[Abhinav Galodha]

Same exe can be run under different user accounts. Windows can have multiple explorer.exe running under different user accounts.

[Rich Lysakowski PhD]

What a terrible design! These should be threads, not full Windows processes.