A large number of .NET host instances were not destroyed.

[Personuo]

Describe the Issue

vscode version 1.102.1

There are many instances in .net host that cannot be destroyed after VSCode is closed
There is a very interesting phenomenon: if I keep the Task Manager open, these .Net Host processes are all in a process group named dotnet.exe (after some time, this process group is renamed to .NET Host) as child processes. When I close the Task Manager, all the .Net Host processes disperse into individual processes.

Steps To Reproduce

No response

Expected Behavior

No response

Environment Information

win11
vscode version 1.102.1

[nagilson]

Ok, so without spending many hours on trying to investigate, I think that its possible this is coming from the language server or roslyn / razor server client.

@allisonchou @dibarbet My suspicion is that these processes are launched as detached and since stdio is detached, they may not die when VS Code dies. I searched for unref and detached in all of the CDK logic. By default the processes should die when VS Code dies. Do you know off hand if these processes are all accounted for / closed?

[nagilson]

I dont know how to easily fix that though because I dont think we have a hook for 'onVSCodeClose' unless we asked for one, so we could store the PIDs in a singleton and kill them.

[dibarbet]

We shouldn't be launching so many separate processes, and generally on windows all the language server processes are named. This is most likely MSBuild or something similar. @Personuo can you share a screenshot with the command line column enabled? You can see it on task manager -> details -> right click the columns in the top and select columns -> command line

[Personuo]

Like this?

We shouldn't be launching so many separate processes, and generally on windows all the language server processes are named. This is most likely MSBuild or something similar. @Personuo can you share a screenshot with the command line column enabled? You can see it on task manager -> details -> right click the columns in the top and select columns -> command line我们不应该启动这么多单独的进程，而且通常在 Windows 上，所有的语言服务器进程都会被命名。这很可能是 MSBuild 或类似的东西。您可以分享一个启用了命令行列的截图吗？您可以在任务管理器 -> 详细信息 -> 右键单击顶部的列并选择列 -> 命令行中看到它。

[nagilson]

Yes, and that confirms what @dibarbet had suspected. Now I wonder if we need to try to do some coordination with MSBuild @rainersigwald to pkill all of these on close (note that I still dont think we have a way to take an action when VS Code closes..)

[rainersigwald]

Ideally you could ask for graceful shutdown via dotnet build-server shutdown --all or we have an API equivalent for MSBuild specifically ShutdownAllNodes(). But if it's not possible to detect that condition I'm not sure what we should do at the MSBuild layer--our model is the processes live for a timeout period (15 minutes) for possible reuse, and you definitely wouldn't want to disable that when you launch MSBuild in Code since it can dramatically speed up second-and-subsequent builds.

[JakeRadMSFT]

@lifengl - thoughts on this?

[dcog989]

Prior to this screenshot I had 3x .NET processes, each of about 800 MB. Restarting VS Code a few times resulted in the above.

Any workaround for this? It's a bit painful when you only have 16GB!