Zombie Processes hangs unless Windows has been freshly restarted

[samaursa]

Brief description of your issue

When running the Zombie Processes scan on a Windows session that is long running, the Zombie Processes tab hangs presumably because of the sheer number of the processes.

For example, this is what I get after a Windows session (i.e. after restart) that is about 20 minutes long. There are over 10k terminated processes. It took System Informer about 1min to populate this window.

I tried the same with a Windows session where I hadn't restarted for almost a day and I gave the Zombie Processes window over 10 minutes to populate before killing the process. I am interested in Zombie Processes and not the terminated processes. Is it possible to improve the performance of the Scan by ignoring the terminated processes (at least allowing the user to have the option to not show terminated processes)?

Steps to reproduce (optional)

Run a scan of the Zombie Processes on a Windows session that is a few hours running without a restart.

Expected behavior (optional)

No response

Actual behavior (optional)

No response

Environment (optional)

System Informer 3.1.24298.0
Windows 11

[dmex]

Those terminated processes are also zombies. Something is keeping them alive and 10,000 after 24 hours indicates a severe issue.

[MagicAndre1981]

Are you using SI to scan for zombie processes because have a huge memory leak? I only see a few processes (EdgeWebView2, the mail app of Windows and svchost.exe) after running for several hours. Do you a 3rd party AV suite or any other hardening tool that may prevent closing handles to free memory?

[samaursa]

Wow okay. This is the first time I am looking at Zombie processes, so I have no baseline on what's normal.

Those terminated processes are also zombies

Zombies, as-in, they are still running? If not, and they are terminated, that's still a problem?

Are you using SI to scan for zombie processes because have a huge memory leak?

That's right. I have 128GB of RAM and it eventually gets filled up almost to the brim. However, if I (roughly) tally up the memory consumed by processes from the task manager, it is almost an order of magnitude lower.

git.exe and git-credentialhelper show up a lot. There were in the hundreds if not thousands on my last run (although I used RamMap for that because System Informer would just hang on the Zombie Processes window with that many zombie processes).

Thanks for the help on this, I appreciate it!

[dmex]

Zombies, as-in, they are still running? If not, and they are terminated, that's still a problem?

The kernel can't destroy the process while something has a reference and something is referencing all those process objects preventing the system from cleaning up/destroying those objects. Process termination is also asynchronous, the operating system queues a special termination APC and flags the process for termination but doesn't wait for termination to complete, so the process can continue waiting or executing in the kernel for some time before terminating.

[MagicAndre1981]

are you using the latest Git for Windows release? If you use the latest version, submit it their bugtracker.

[diversenok]

Git shows up a lot because it spawns many processes. It's clearly not the culprit.

@samaursa, if you right click on the process table header and enable the Handles column, is there a process that keeps a lot of handles open? If you find one, you can inspect which handles it has and if most of them are terminated process/thread handles, it's ought to be related to the source of the issue (by keeping all of them in a zombie state).

[samaursa]

@diversenok how do I go about inspecting the handles held by a particular process? All I see is the total number of handles of a process:

[samaursa]

@MagicAndre1981 yes, using the latest release. No one else on my team is having this issue. I can submit the bug if I can confirm it's not a problem on my end.

[diversenok]

how do I go about inspecting the handles held by a particular process

Double-click the process and switch to the Handles tab.

Although, looking at your screenshot, it might not be related to handles after all. You have process IDs above 2 million, which indicates that at some point there were 500 thousand processes/threads (that's really a lot!, I have 2000 times fewer). It doesn't fit into the current 200 thousand handles (which also reference other resources, not just processes). So either the handle leak happened earlier and stopped now, or it's not a handle leak but a driver-related issue. Drivers can keep references to processes/threads without using handles.

[samaursa]

Thanks!

I routinely have process IDs above 1 million that eventually go to 2 million until I restart my machine. I wonder if the compiler toolchain is part of the reason the count is so high.

Even now (after a restart yesterday), I have process IDs over 1.5 million.

[samaursa]

I think I found the reason why my process IDs are as big as they are. My git client (Lazygit) refreshes every 10 seconds. Here in the screenshot you can see them getting destroyed after being created just a few moments before.

The question is whether it's problematic to have the number of IDs be that high.

[samaursa]

Here's another interesting thing. Here I am sorting by Handles in a descending order. There is no way they all add up to 288,021 handles. Who's holding on to the other handles?

[MagicAndre1981]

What happens if you stop using Lazygit and use TortoiseGit (winget install --id=TortoiseGit.TortoiseGit -e) for some time? Do you still have the memory leak?

[samaursa]

@MagicAndre1981 good idea, I'll try that this weekend and see how it goes

I'm still mystified by the total number of handles vs. the processes that are holding on to the handles