13

I have a pretty new Windows 11 Pro installation, it has about a week. I noticed that my RAM usage is constantly going up. It was concerned because procexp readouts did not match the total used RAM value that's reported, with the difference factor of 4 or more.

I checked RAMMap and I found that processes never finish. None of the processes that have ever been created finish. They take up memory, which is mostly reported as unused active and page table memory.

For the following I created and exited 100000 cmd.exe processes. I used the following command:

FOR /L %i IN (1,1,100000) DO cmd /c echo %I

enter image description here

Notice the high page table and unused active memory readings.

All exited processes show up in RAMMap

enter image description here

At this point I was able to find more information on this issue, mainly https://randomascii.wordpress.com/2018/02/11/zombie-processes-are-eating-your-memory/

However, diagnosis using FindZombieHandles did not reveal what's holding up these processes.

c:\Programs\blogstuff\FindZombieHandles\prebuilt>FindZombieHandles.exe
110416 total zombie processes.
6 total zombie threads.
    222 zombies held by Taskmgr.exe(6640)
        137 zombies of cmd.exe - process handle count: 137 - thread handle count: 0
        25 zombies of firefox.exe - process handle count: 25 - thread handle count: 0
        11 zombies of dllhost.exe - process handle count: 11 - thread handle count: 0
        7 zombies of backgroundTaskHost.exe - process handle count: 7 - thread handle count: 0
        5 zombies of RuntimeBroker.exe - process handle count: 5 - thread handle count: 0
        5 zombies of EngHost.exe - process handle count: 5 - thread handle count: 0
        4 zombies of WmiPrvSE.exe - process handle count: 4 - thread handle count: 0
        4 zombies of ctfmon.exe - process handle count: 4 - thread handle count: 0
        4 zombies of consent.exe - process handle count: 4 - thread handle count: 0
        3 zombies of taskhostw.exe - process handle count: 3 - thread handle count: 0
        3 zombies of OpenConsole.exe - process handle count: 3 - thread handle count: 0
        2 zombies of mobsync.exe - process handle count: 2 - thread handle count: 0
        2 zombies of DbgX.Shell.exe - process handle count: 2 - thread handle count: 0
        1 zombie of WindowsTerminal.exe - process handle count: 1 - thread handle count: 0
        1 zombie of svchost.exe - process handle count: 1 - thread handle count: 0
        1 zombie of StartMenuExperienceHost.exe - process handle count: 1 - thread handle count: 0
        1 zombie of sppsvc.exe - process handle count: 1 - thread handle count: 0
        1 zombie of SearchHost.exe - process handle count: 1 - thread handle count: 0
        1 zombie of pwsh.exe - process handle count: 1 - thread handle count: 0
        1 zombie of msedgewebview2.exe - process handle count: 1 - thread handle count: 0
        1 zombie of explorer.exe - process handle count: 1 - thread handle count: 0
        1 zombie of conhost.exe - process handle count: 1 - thread handle count: 0
        1 zombie of audiodg.exe - process handle count: 1 - thread handle count: 0
    9 zombies held by svchost.exe(12660)
        9 zombies of EngHost.exe - process handle count: 9 - thread handle count: 0
    2 zombies held by nvcontainer.exe(4908)
        2 zombies of rundll32.exe - process handle count: 2 - thread handle count: 0
    2 zombies held by svchost.exe(4620)
        2 zombies of explorer.exe - process handle count: 2 - thread handle count: 2
    1 zombie held by atieclxx.exe(3504)
        1 zombie of atieah32.exe - process handle count: 1 - thread handle count: 1
    1 zombie held by NVDisplay.Container.exe(2896)
        1 zombie of dbInstaller.exe - process handle count: 1 - thread handle count: 1
    1 zombie held by svchost.exe(2268)
        1 zombie of userinit.exe - process handle count: 1 - thread handle count: 0

ObjExp.exe is also not helpful in this case. It shows the correct number of objects but can't identify the handles (notice how the number of handles is much smaller than the number of objects)

enter image description here

File, Token, and Event objects also follow the count, though I'm not sure how to interpret this, I assume they are just naturally created for every process (for example File handle being the image)

At this point I'm pretty sure the issue does not lie in any user-space process, and instead is caused by some system component/driver.

I attempted searching for these handles with WinDbg hooked up to the kernel with Driver Verifier set to Misc on all drivers. I tried executing !handle 0 3 0 Process but I can't find anything abnormal and the output is so slow (multiple seconds per line) that it's impossible to get a full reading. I also tried !process 0 0 but none of the listed processes show an abnormal amount of handles, though some show 0 handles which I assume may be a permission issue.

At this point I'm at a loss, while this issue is not debilitating it gets pretty annoying for my usual workloads that spawn a lot of processes. After 10 hours of normal computer use yesterday I amounted 20GBs of unused active memory and page table memory (held up by zombie processes), with over 20k processes.

driverquery /v output (and obvious potential offenders? The output is always the same regardless of how many cmd processes I spawn): https://pastebin.com/CcT7rzbJ

The issue does not manifest in safe mode.

Update 2: poolmon doesn't show anything abnormal. The only thing creating 10000 cmd.exe processes does is put the Proc tagged object into the top 10, which is expected as this handles the Process Objects. I don't think I'll be able to find this leak with poolmon as the handles take negligible amount of space and I'm not even sure if they would be reflected in the mem usage.

Update 3: I removed NVIDIA GPU drivers with DDU and reinstalled with NVCleanstall without telemetry. NvModuleTracker is not the issue. It was a possibility since it uses PsSetCreateProcessNotifyRoutineEx, but it turns out it's handling it properly. I don't know how to check which other drivers use this callback...

Update 4: I disabled BAM and DAM, the issue persists.

Update 5: I did a basic crosscheck between processes shown in task manager and rammap, which to my understanding identifies the first process that is being held and processes that are running since before the issue started manifesting. Not much useful information here though, basically saying it's a driver.

Update 6: I was able to resolve the issue by disabling the AMD iGPU in the BIOS and running AMD Cleanup Utility to remove the drivers. However, it's still unclear how to identify similar issues in the future, so the question remains open.

enter image description here

14
  • 2
    No, have avoided Win 11 like the plague -- takes far too long to configure to remove privacy issues. Commented Apr 10 at 17:01
  • 1
    "hundreds of physical pages being mapped to the same virtual address" doesn't sound unusual to me – the whole purpose of virtual addressing is that each process has its own mapping table, so different processes can see different things mapped to the same address, and RamMap apparently just merges all those lists into one. Commented Apr 11 at 9:41
  • 1
    @Sopel I have the same issue! I built a new computer and installed windows 11 3 weeks ago. However I have no solution and you seem more knowledgeable than me. But I made a list of the drivers we both share: pastebin.com/bzfuxNJN (156 in total) Is there anything else that could help?
    – leyou
    Commented Apr 16 at 14:11
  • 1
    @VomitIT-ChunkyMessStyle no, that does not have any effect. The issue in the linked thread is also completely different.
    – Sopel
    Commented Apr 18 at 1:00
  • 1
    @Sopel No need to uninstall Webview2, with these commands only Windows Widgets is removed. Howver, if you can disable the igpu, you should definitely see the difference. It's super weird, took me weeks to track down even the GPU part!
    – sebastiaan
    Commented May 2 at 6:29

2 Answers 2

5

This seems to be coming up a lot lately, so I'll leave a few relevant links in a community wiki in case more info turns up. Seems like a few people have managed to resolve it by downgrading or uninstalling AMD drivers.

0
4

I initially thought it was Docker, because of thousands of docker.exe and com.docker.cli process handles in RamMap, but the issue appears even with Docker desktop uninstalled and seems to be caused by AMD Radeon GPU driver (called: AMD Adrenaline. v24 is known to have the issue. The latest is currently v24.4.1).

If I'm not mistaking (certainly possible), it will turn out that everyone who has this issue also has AMD Adrenaline installed.

You can confirm whether that's the issue by uninstalling v24.* and installing v23.10.2 version of the driver, which is confirmed not to have the bug. You can download it here: https://www.amd.com/en/resources/support-articles/release-notes/RN-RAD-WIN-23-10-2.html

FYI disabling iGPU seems to solve the issue (I'm still testing that, but looks good so far). If not solve, at least it seems to considerably improve the number of zombie handles.

I have to mention that ZombieProcessHandles was instrumental in troubleshooting this, as well as Bob's assistance.

EDIT Just to report that it seems that the issue is gone since I disabled integrated graphics card 2 days ago.

3
  • 1
    Just to note I do not have AMD Adrenaline installed, but of course I did have that driver installed.
    – sebastiaan
    Commented May 11 at 15:06
  • And to note also: still have the driver installed now, and the GPU enabled. The solution was to stop anything from launching msedgewebview2. Not a single memory issue since I've done that. To be fair, this is not a viable solution for most people, it requires disabling the Windows start menu search (as it uses webview). I use Powertoys Run instead. I do really enjoy the start menu without ads though!
    – sebastiaan
    Commented May 11 at 15:13
  • 1
    > The solution was to stop anything from launching msedgewebview2 this does not solve the issue, it only results in fewer processes being created, making the issue harder to diagnose
    – Sopel
    Commented May 13 at 16:43

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .