0

For the past few days I've had to restart my PC a couple times a day because I'm running out of memory. I have 32gb DDR3 1866mhz ram.

Here is a screenshot of the nonpaged driver memory usage snapshot with poolmon sorted by bytes.

Does anything look abnormal?

enter image description here

Jonathan Beaudoin
  • 369
  • 1
  • 4
  • 18
  • 2
    @magicandre1981 It is not obvious that the supposed "duplicate" is a duplicate. I see no evidence of a plague of processes and threads in that question or any of the answers. Did I miss it? – Jamie Hanrahan Feb 21 '17 at 19:46
  • 1
    Yes, there are many topics about memory usage, and a great many of them are not only the same problem (running out of commit) but also the same cause (insufficient or no pagefile). But that doesn't mean that every question about memory usage should be tagged as a duplicate, particularly when an answer has _already been given_ showing that it's not one of the typical ones. Do you mean to say that adding a bounty would erase the "duplicate" flag? – Jamie Hanrahan Feb 22 '17 at 17:11

1 Answers1

2

The "low on memory", "out of memory", etc., usually have nothing to do with free RAM, rather with the commit charge vs. commit limit.

It would be useful to see a screen snapshot of Task Manager's Performance tab, Memory section, as this will show the commit charge and limit.

However, two things do look abnormal here, and I suspect these are enough to determine the root of the problem: You have about 21,000 process objects ("Proc") and about 23,000 thread objects ("Thre").

For comparison: My system right here, also Windows 10, has been up for about 10 days and only has about 200 and 3200 of these objects, respectively.

This probably indicates that you have some program running that is madly creating processes and not allowing them to completely exit, perhaps by not closing the handles to them and/or to their threads. Although they are not impacting your RAM much right now (they occupy about 100 MB of nonpaged pool total), if processes and threads continue to be created and not deleted, they will eventually consume almost all of your RAM. RAM committed to the nonpaged pool does contribute to "commit charge", which is why these will eventually result in "low on memory" or "out of memory" errors.

A quick way to find the culprit may be look at Task Manager's Details tab. Add the "Handles" column, sort by that column, and see if anything looks abnormally high, and particularly if it's constantly increasing.

n.b.: The "threads" column will likely not be helpful. It would be helpful if you were looking for one process with a whole bunch of threads - which is not an impossible thing to happen - but the fact that there are about as many processes as threads here argues against that. With every process you get one thread (to start), so a plague of processes brings a plague of the same number of threads with it - but this won't show up in any one process's "threads" counter.

The "process tree" view of the sysinternals tool Process Explorer may, however, help. You're looking for a process with a whole lot of processes "under" it.

If that doesn't do it, try using the sysinternals ProcMon tool and look for process creation events.

If that doesn't do it, then it's probably being done in a kernel driver. Use the Windows Performance Toolkit to find process creation events.

For more on commit charge, see my answers to the questions I've linked below. Usually, running out of commit charge is fixed by either adding RAM or increasing your pagefile size (or running less stuff at one time), but those methods will not help with this problem. Nonpaged pool can't be paged out, so these Proc and Thre objects necessarily occupy RAM. And even if your pagefile is large enough to avoid running out of commit limit, the system will eventually show other problems due to shortage of usable RAM.

Windows says RAM ran out while there is still 4 GB of physical memory available

How does memory/commit charge work in Windows 10?

Jamie Hanrahan
  • 23,140
  • 6
  • 63
  • 92
  • Thanks Jamie! It seemed the culprit in this case was a program called "Synergy". https://dl.dropboxusercontent.com/u/91292881/ShareX/2017/02/Taskmgr_2017-02-22_00-28-00.png (almost 25k handles even though I haven't even used the software in months) – Jonathan Beaudoin Feb 22 '17 at 05:47
  • That's the "Synergy" that lets you use one mouse and keyboard across the monitors of several machines, even mixing OSs? Do you have a poolmon screenshot after killing the synergyd.exe process? – Jamie Hanrahan Feb 22 '17 at 06:09
  • To whomever: Thanks for the "best answer"! – Jamie Hanrahan Feb 24 '17 at 19:21
  • Holy s#@t, synergyd had 25k handles and after killing it ram usage dropped from 3.8gb to 2gb. I thought I was losing my mind because no process was listed as actually using this much ram. – Ozan Aug 13 '18 at 16:01
  • I guess with _this_ "Synergy", when you use it, you get _less_ than the sum of the parts! (snicker) – Jamie Hanrahan Aug 13 '18 at 18:51