Change:
over the last week I have seen zombie processes running at full CPU load when trying to debug them (via SIGUSR1) they die analysed a crash dump and sees that this is because the EH is already in the process of shutting down the previous point matches the observation that no window reports its EH as having crashed <img width="1290" alt="Screenshot 2023-09-29 at 13 31 34" src=""
Can you take a process sample from the OS activity monitor, I hope the native stack can give a clue to what is happening.
Just happening. This is the command line of such an EH
This the process sample
Not sure about the part. Does this mean we run the EH under development or not?
It looks like we set that for all local EH process launches. Just having inspect-port doesn't put the process in debug mode. What you can do is use the "Debug: Attach to Process" command and select that process. This will fail, since the debugger won't then know what port it's listening on (if --inspect-port isn't given in the args, it always listens on 9229, and js-debug assumes that is what happens). But, then you can . AFter doing so you could grab a performance profile using the edge/chrome devtools on edge://inspect, or by attaching to that using an attach-type launch config VS Code and using the "take performance profile" command -- if the spin sample you recorded above isn't enough for Deepak to figure out what's going on.
Does that use SIGUSR1? Asking cos I have tried that first and sending the signal kills the process. From the crash dumps we do know that the process already was shutting down
Attaching the symbolicated sample Going from the top, indicates the EH process is already in the shutdown phase and has started to destroy the . At this point, connecting via a debugger is not possible since the agent host will stop receiving connections due to the following , so we cannot get perf profile from these processes. Moving further down most of the sample time is spent in which the environment gets deleted, this flushes the pending tasks in the libuv event loop but one thing to note is that entering JS via these tasks is not allowed due to the . But there are GC tasks being executed and which can enter JS. I think the error calls ` are from these callsites eventually leading to . At this point, I expect the process to abort and the main process should be able to reap the utility process but that is not happening. There is another data point looking back at the screenshot from , the zombie EH processes are titled and not in the process explorer. We resolve the pids to respective titles based on a map maintained in the main process, the process explorer gets it periodically via the following and the utility process related values are populated from . We default to when the pid map no longer has an entry for the process which can only happen when got invoked which inturn suggests that the main process did receive an exit or crash signal from these EH hosts. can you check the main process logs next time if it has any of the following entries for the corresponding zombie EH pid to validate this data
I attempted to setup a similar flow based on the stack with base Electron app but the utility process are cleaned up as expected. I can make a change in the destruction phase of the utility process to signal termination of isolate so that tasks which require to enter JS will not do so and I hope that resolves the long running draintask. I won't be able to make a new insiders build with this change until I am back from vacation but I can provide a custom electron build for local testing with OSS. would that help to validate incase you face similar issue with OSS as well ?
Ah, my bad, skimmed over that part. Disregard. (Yes, it sends SIGUSR1 on unix)
I am seeing this for which is currently spinning forever. Samples for this one
i think i have the same issue on my mac. It happens from time to time and my workaround is simply killing vscode and then reopen it. But sometimes i don't realize it until my Mac has run out of battery, which can be quite annoying. <img width="963" alt="CleanShot 2023-10-09 at 19 46 49 src=""!
Having the exact same issue. utility-process is running at 100% all the time on M1 Max, very annoying.
This bug might also exist in Linux build of vscode: ! (6% 16 cores = 96%) Command line of "utility-process" is: eu-stack of main thread of this process: Noticed that is also inside sampling.
Manually sampling with eu-stack running every second, for one minute. (And might related to and )
Sorry if I'm hijacking the thread but would uninstalling Node and installing Bun solve this problem? Doesn't sound like it's a VSCode bug, right?
Thanks for the logs , the stack does look related. I wouldn't be surprised if the issue is also present on Linux since the shutdown path is same for both.
Similar issue on my M1 Max, sometimes I observe even 3/4 zombie processes running in the background and have to kill them manually from process manager to stop them from draining battery. 2 more samples for such process:
Checked log and it looks weird. : However, PID still exists and is running at 100%.
Another hang process today with log: "Extension host with pid started" "Extension host with pid exiting with code 0" "Extension host with pid exited with code: 0, signal: unknown."
Is there any temp workaround? any script or bash command that we can run to identify and kill those pid? I am interested to do it manually, because i have a M2 and i am rebooting my macbook after some hours because get soooo slow
Restarting VS Code should already "fix" the problem because the extension host is a child process of the application. At least that does the job for me. Are you observing a different behavior? Note that "Reload Window" does not kill the zombie process (according to my observation).
Please help by posting the list of installed extensions. I am looking for similarities between our setups as this is possibly caused by an extension. This is my list To get this list run or . Please do the same and post your results here. Thanks
Thanks for looking into this! I am also facing this issue quite frequently. Here are my installed extensions:
Thanks everyone. Looks like the intersection is
code --list-extensions
Yep, I'm using those extensions too. Here's the full list:
is not a very good workaround: what if the process exits, but another innocent process just takes this PID?
It probably cannot do that as the pid is still taken? I agree it's not a great workaround, but until the root cause is clear it does solve the issue where a cpu is occupied.

Discussion:
extHost.dispose(); this._extHosts.delete(id); }); <ins> // See https://github.com/microsoft/vscode/issues/194477 // We have observed that sometimes the process sends an exit // event, but does not really exit and is stuck in an endless // loop. In these cases we kill the process forcefully after // a certain timeout. setTimeout(() => { try { process.kill(pid, 0); // will throw if the process doesn't exist anymore. this._logService.error(`Extension host with pid ${pid} still exists, forcefully killing it...`); process.kill(pid); } catch (er) { // ignore, as the process is already gone } }, 1000); </ins> }); return { id }; }