Skip to content
READING [0%]
$ cat razer-zombie-processes.md

Restarting fixes Windows because your apps are broken

I couldn't reboot, so I found out what the reboot would have hidden: 12.7 GB leaked by NVIDIA, and 32,709 dead processes from Razer slowing down every frame on my screen

TLDR: after years of not knowing why my laptops would have worse performance than I thought they should, coding agents helped me finally figure out that Windows apps are broken (like the Razer apps or the NVIDIA overlay on your PC right now), but a few scripts and adjustments can fix them ad hoc! A feeling I never thought I would have.

Growing up, my friends and I couldn’t afford any gaming computers, and having a laptop and a desktop was out of the question, so we always had to milk the last ounce of performance from whatever we had. Countless videos watched and guides read to get the NVIDIA Control Panel settings as good as we knew how, learning what each setting in the game did to find the most “value for buck” setup, etc. As time passed, things like the GeForce app started automating these, and now that I can afford (well, maybe could, a few years ago before the RAM prices) a desktop, I only get to use it once a month, being so far away from everyone. But I still have a personal laptop, a Legion with a 3070 laptop GPU, which is good enough for my occasional “hop on Discord to play Peak or Subnautica 2 or anything” with friends.

Today was such a day. We found time, booted up the game, and… 2 FPS?

Normally I would have maybe gone for a restart, but since I started using this computer as a server, restarting is a huge hassle as I have to make sure all services are up etc, worse, my wife was already using an app hosted on this computer and I didn’t want to cut her flow off. But with Opus 5.5, I wanted to finally figure out what was going on. I was previously burned by memory leaks in audiodg.exe from Nahimic, so a memory leak in addition to just thermal throttling were the first few culprits in my mind, however I just never learned how to diagnose these issues properly.

So I opened a terminal, told Opus the game was running at 2 FPS, that I couldn’t restart, and to figure out why. And then I mostly watched (my main contribution to this investigation was approving permission prompts).

The usual suspects

It went through pretty much the same list I would have, just a lot faster and with actual numbers instead of vibes, and it found real problems on the way, just not the one that mattered:

suspects, in the order we checked them
  • ✗
    Another app on the same GPU

    real: one of the services I host on this machine was using the GPU way more than it should. Moved it off. 2 → 30 fps, but still stuttering

  • ✗
    Thermals

    CPU at 94 °C, but still boosting to 3.9 GHz. Not throttling

  • ✗
    NVIDIA Overlay leaking memory

    real: one overlay process from 20 days ago held 12.7 GB, with commit at 48.6 of 49.9 GB. Killed it. Stutter unchanged

  • ✗
    Frame pacing, G-Sync

    turned G-Sync on. Still stuttering, and now I noticed the terminal was too

  • !
    Something inside the Windows kernel

    the System process was burning 1.1–1.4 cores nonstop

So the memory leak instinct was right, the NVIDIA overlay had been sitting on 12.7 GB for 20 days, which is exactly the kind of thing a restart would have quietly wiped away without me ever knowing. Killing it didn’t fix anything though. What actually moved things forward was noticing, while watching Opus work, that the terminal was stuttering too, which meant the problem wasn’t the game at all, it was something underneath everything.

Into the kernel

Honestly, this is the point where I would have given up and restarted, I am not even sure I knew you could get a stack trace of the Windows kernel. Opus ran a 10 second kernel trace with call stacks (xperf, as admin) and came back with this:

dxgmms2.sys!VidMmWorkerThreadProc              75.81%
  dxgmms2.sys!VIDMM_GLOBAL::HandleTrimWnf      75.28%
    ntkrnlmp.exe!NtUpdateWnfStateData          74.68%
      ntkrnlmp.exe!ExpWnfFindScopeInstance     74.30%   (57.9% exclusive)
ntkrnlmp.exe!memcmp                            15.97%   (exclusive)

Which, if you are like me, means nothing at first glance, so here is what it is actually saying (or at least how it was explained to me):

how a dead program stalls your screen 1/6
  1. 1.

    Every window, your game and your terminal included, renders into GPU memory. The Desktop Window Manager (DWM) composites those surfaces into the frame you see.

    dwm.exe, dxgkrnl.sys

32,709 processes that don’t exist

When a program exits but something still holds a handle to it, Windows can’t clean it up, and it sticks around as a zombie. Opus compared how many process objects the kernel had against how many processes were actually running:

Live processes: 306   Process objects in kernel: 33,015   => zombies ~ 32,709

The top handle holders were Razer Game Manager (33,695 handles) and Razer Synapse Service (28,193). Game Manager watches every process you launch so it can tell when you start a game, and it looks like it opens a handle to each one and never closes it. It had been 20 days since my last restart, so that is about 1,600 new zombies a day, every one of them making that list a little longer (the software that makes my mouse glow was slowing down every frame on my screen, great).

Drag the slider back to zero to see what a restart does:

one lookup = walk the list until you find it
entries in list
33,006
dead ones
32,700
avg comparisons / lookup
16,503
vs. fresh boot
108× slower

lookups finished: 0 · this speed: 0.0/s. Slowed way down so you can watch it; the real one is fast, but it's the same shape, and every GPU memory trim pays for a walk.

A linear search is fine when the list is short, and right after a restart it is. By day 20 every lookup is about 100 times more expensive, and it happens every time a game pushes on GPU memory. That’s why it creeps up over weeks, that’s why a restart “fixes” it, and that’s probably why so many of my gaming sessions over the years started with a restart “just in case”.

Opus stopped both Razer services and within a minute the zombies went from 32,709 to 260, the System process went from about 1.25 cores to 0.2, and the stutter was gone. No restart, and my wife didn’t even notice anything happened.

To be fair about what’s actually proven: the stack and the before and after numbers are measured. That the zombies are what bloats this specific list is an inference, they dropped together at the same time and by about the same factor, but neither Opus nor I have seen the Windows source, so take that part with a grain of salt.

Check yours

If you are on Windows, open PowerShell and run:

(Get-Counter 'ObjectsProcesses').CounterSamples[0].CookedValue - (Get-Process).Count

A few hundred is normal. If you see thousands, something is leaking, and this will probably tell you what:

Get-Process | Sort HandleCount -Desc | Select -First 5 Name, HandleCount

If you run these, please let me know your number and your top offender, I am really curious what other people find.

A look behind the curtain

Restarting is a good idea, because it keeps problems like these from happening in the first place, but for the first time ever I do feel like I get a look behind the curtain. “Game has low FPS” has always been such an abstract problem that always made me feel uneasy, but now I can get to an actual answer. So next time something is going wrong with your computer, I recommend letting an agent loose to figure it out. What it finds might surprise you, and maybe even teach you a few tricks.

LAST_MODIFIED: Sep 27, 2026 TAGS:
#windows#debugging#gaming