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
Notice the high page table and unused active memory readings.
All exited processes show up in RAMMap
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.exe110416 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: 0ObjExp.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)
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.
