Windows 10 committed memory increasing 80K/second, not showing in processes in task manager

Question

After upgrading to a new computer a couple months ago, I have to reboot every 1-2 weeks due to committed RAM steadily increasing.

I'm running Windows 10 Home with an Intel 13900K processor, PRO-Z790-P-WiFi motherboard, using the CPU's built-in video (latest display driver). 128GB RAM. 19GB page file.

Right now, for example, Task Manager for Committed shows: 91/147GB. Adding up the Commit size from the processes tab is about 47GB. So about 44GB of committed memory is unaccounted for. The committed memory is still used after closing all open windows.

Process Explorer confirms this. I can't find anything in RamMap to account for it (e.g. 128GB total memory, 49.5GB active, 64.9GB standby).

I wrote a program to calculate the "phantom" usage every 10 seconds (taking GlobalMemoryStatusEx's ullTotalPageFile and subtracting ullAvailPageFile to get committed memory in use, and subtracting NtQuerySystemInformation's PagefileUsage for each process). This matches Task Manager's results, and it while it fluctuates a bit, it steadily increases. Checking 4 1-hour periods overnight, the committed memory increased an average of 78.2K/second to 82.0K/second.

I was guessing the graphics driver, but being the latest Intel driver, I'm doubting that. Any guesses or thoughts for next steps? Thank you in advance for any help.

Answer 1

Finally figured it out. I'm posting here in case anyone else comes across this.

SOLUTION: Disable RunSwUsb service and set it to disabled. Alternatively, kill the RunSw.exe and SwUsb.exe processes (although they will come back). Or, see if they have updates to them. These are Realtek drivers (that I believe was installed with a WiFi dongle, but likely used by other Realtek devices as well).

HOW I FOUND IT: First, I shut down all running windows. Then, I went to the Processes tab in Task Manager. I tried stopping whatever processes I could willy-nilly in the "Background processes" section, checking the "Committed" value in Task Manager. When I got to "Switch USB2.0/USB3.0 for WinXP SP2+ ~ Win10 (32 bit)", showing a command line of C:\Windows\SwUSB.exe, ending the task caused the "Committed:" value in Task Manager to go down from 57GB to 17GB.

WHAT IT IS: RunSwUsb is a Realtek service, used at least for their wifi dongles. It sounds like RunSw.exe is the service itself, which starts SwUsb.exe which is the wifi driver. Some people have (guessed?) that the service is used to switch from USB3.0 to USB2.0 if overheating occurs, but who knows. I'm not 100% certain how the file got there: it was installed the day I received my WiFi dongle, but doesn't seem to appear in the driver package from the Realtek site. It is signed properly as Realtek. Hmmm.

THE WINDOWS PROBLEM: It is mind-boggling that Windows can allow a service to consume 40GB of committed memory while not showing it anywhere in Task Manager (or Process Explorer). Sure, some services will use 40GB (e.g. a RAM drive). But with the RAM drive, it at least shows up under "System". Right now, about 2 hours after a reboot, it has eaten up perhaps 250MB-500MB of committed memory (yes, "consume" is correct: it is RAM and/or paging file that other programs cannot use). Yet even with the advanced data in Process Explorer, nothing shows that (the highest is 80MB 'Virtual Size', but it was that high at startup, and doesn't go up).

Anyways, a thank you to Michael Taylor who helped me with some ideas. Even when you think you understand all the details about Windows memory management, there's always something else!

Answer 2

Adding up columns in TM rarely returns what you might expect for the result. This is unreliable. Furthermore committed memory means slightly different things depending upon the tool you use. It could be the actual commited/charged memory in use or it could include the memory that has been requested but not yet brought into physical memory as it hasn't been referenced yet. Other things that influence this include whether it includes user mode and/or kernel mode and whether it includes shared memory or not. There are lots of articles on the various memory properties and the various ways they could be interpreted.

What it boils down to is if you have a memory leak in the sense that over time your OS has more and more committed memory to the point where Windows can no longer allocate resources. This could easily be caused by kernel software. I recommend you download and run Process Explorer. It allows you to show all the various memory properties including committed memory. Ensure you run it as an admin so you can see all system processes and then order by the committed memory. If a particular process has a leak then it'll work its way to the top over time and you have found your culprit.

Answer 3

5GB is typical for Firefox -- I usually have 2-4 instances running, often with 10-15 tabs in each one.

I just rebooted, but before doing so shut down all windows, stopped what processes I felt I could safely stop, and stopped as many services as I felt I could safely stop. Still, the committed memory did not go down.

After the reboot (before running anything that doesn't start automatically, the committed memory was around 5GB, where I would expect. But, it appears to be climbing slowly like it has been, even with minimal programs running.

I'm planning to try starting in safe mode to see if it still happens.

Answer 4

Hello,

I had a similar issue and I was wondering if there is a better way of detecting the culprit.

How do we find where the difference between SUM(System.Diagnostics.Process.WorkingSet64) and GlobalMemoryStatusEx().ullTotalPhys (are these the right values to compare?)

What should we compare process explorer's 'system commit' with?

I believe this value is GlobalMemoryStatusEx(). ullTotalPhys - ullAvailPhys

Can we find this in System.Diagnostics.Process?

The VirtualMemorySize value (also shown in process explorer) is typically much too high

Any info on the memory info available via an API or how you can monitor the real memory usage of the processes is greatly appreciated.

FYI: We're suffering from windows killing random processes when it notices near memory depletion.