I have been having an issue where, if my system is up for a few days without being rebooted I will start getting warnings saying "Close programs to prevent information loss" and then a dialogue suggesting I close programs, which I can either cancel or hit "close programs" and Windows will force close some or all of the applications listed in the dialog.

I open task manager, and see that only around 30% of my memory is currently being used:

33% Utilization

When I open resource monitor to see how much committed memory is being used by specific applications, I still see relatively low memory usage:

Resource Monitor

I've had this problem for awhile and have struggled to find a solution. I've investigated causes like a driver leak by using poolmon, but never saw anything in poolmon that matched what others have described as red flags for a driver memory leak. What makes me particularly confused is why Win10 is telling me to close applications when I only have 33% of system memory being used.

up vote 14 down vote accepted

Wild guesses here.

You have disabled your swap file, following someone's random "optimizing" advice.

You have an OS driver of some kind that wants a large block of consecutive physical RAM. But it can't get it because all of the physical RAM has been fragmented over time. And because the swap file is disabled it cannot do a RAM defragment.

Enable your swap file.

As I said, wild guess.

  • Well, I have a set pagefile size of max 3gb. Is this what you mean by swapfile or is this a separately managed thing in Windows 10? It's not impossible I would've done something like this, I had extremely bad performance issues when I first built this machine in 10/2015 and tried several things like disabling core parking to fix it. It ended up there was a power management scheme that was reducing my power to like 10% and starving all the components and that was why I had systemic performance issues, but it's possible I may have done something like you said during that episode. – Brandon Apr 15 '16 at 17:28
  • 1
    Change your pagefile size to "System Managed" and your problems will likely go away. – Scott Chamberlain Apr 15 '16 at 17:38
  • I once had it system managed, and I still had the same problem, it would just take longer to manifest. When I set it to system managed the pagefile would max out at I believe 64gb, and then when the committed got up really high I'd still get the same low memory warnings. But I'd still see 70% or so physical memory available and no indication in Resource Monitor that over 60+gb of memory was currently committed to any listed process. – Brandon Apr 15 '16 at 20:48
  • I fully agree with Zan and Scott, it's your pagefile that's causing this problem (see windowsitpro.com/windows-10/… for another source that also says this). Set it to system managed, and the if problem shows up again, THEN start investigating. – Ƭᴇcʜιᴇ007 Apr 15 '16 at 21:39
  • So I think system managed pagefile was the core answer here. It seems that having it set to a static 3gb just isn't ideal in the Windows 10 environment. I implemented this solution a couple weeks ago and let it run in normal usage just to see what happened and while I still see a lot more committed memory than is accounted for in the Resource Monitor committed memory column, I'm not running into low memory warnings or issues now. – Brandon Apr 29 '16 at 1:48

Re your last Q - the short version: The error message is about "committed" virtual address space. If you look at the Commit Charge graph in your second screen snapshot you will see that it is indeed at or very near the limit.

The amount of RAM that is "free", "available", or "in use" does not matter. In particular a shortage of "available" RAM is absolutely not the reason for the "low on memory" or "out of memory" message.

The commit limit is equal to total RAM + pagefile size. When committed memory is allocated it is immediately charged to "commit charge" even though it has not actually been used yet... meaning that no RAM or PF space is used immediately. Physical space (whether in RAM or the pagefile) is only used when the memory is actually referenced. From then on it must have someplace to be, until the program frees it, or the entire process ends.

Example: Suppose you have no pagefile, hence your commit limit is 16 GB (your RAM size). Now, suppose that 8 processes each try to VirtualAlloc(MEM_COMMIT) 1 GB. Result: Commit charge is increased by 8 GB. There is no immediate impact on RAM, however! It's as if you bought a pad of paper at the stationery store, but you didn't actually get any paper. Every time you need a new sheet, though, one magically appears. Until you use up the whole pad (the size of the allocated region).

Now suppose each of those processes only actually accesses 100 MB out of its 1 GB. The RAM used would only be 800 MB.

But since each of them might reference all of its 1 GB, the OS has to ensure that 8 GB of RAM+pagefile space ... well, just RAM in the case of no pagefile... is kept available just in case that happens. Going back to the stationery store, they need to keep enough paper in stock to give everyone as many sheets as they previously bought.

Accordingly, the OS has to stop allowing VirtualAlloc(MEM_COMMIT) to succeed when the current amount committed hits the limit.

Why? Because the process is expected to check the result of VirtualAlloc to see if it succeeded. Once it has done so and found that the alloc succeeded, the process has every right to expect that its subsequent references to the entire committed region will succeed.

If Windows allowed the commit charge to exceed the amount of space available to realize that space, then that expectation could not always be met.

A quick workaround is to increase the default (=initial) size of your pagefile. From the above explanation you should be able to see why this will avoid the error message even though nothing might ever be written to that file. Again, the OS is ensuring that space for all of the commit charge is available in case it needs it. When processes allocate committed memory they're just saying "hey, OS, I might need this much." That doesn't mean they'll actually use it, and it certainly doesn't mean they've actually used it yet.

For more, see my answer here.

Now.... why you're using that much commit when your processes don't seem to add up to it is another question. To start looking at that, please show Task Manager's Performance tab, Memory section.

  • I have no words to describe such a perfect answer. Thank you. – Vinicius Tavares Oct 15 '16 at 1:45

Another possibility is that you're using Win10 32-bit, not 64 bit. While you have 16GB of RAM installed, there are 32-bit OS limitations that make practical use above 4 spotty. Further, the OS will impose hard limits /per process/ on what amount of RAM can be requested, regardless of physical RAM. If that's the case, not much you can do other than switching to 64-bit OS or running fewer applications simultaneously.

  • 2
    It would not be possible to be running Win10 32-bit and have Task Manager show a total of 16 GB, as it does in the OQ. And btw, the per-process limits the OS poses are on virtual memory, not RAM. There is no call you can make in Windows to allocate RAM per se. (Well, AWE, but that takes admin-level privilege and almost nothing uses that except some system programs.) You allocate virtual address space (say with VirtualAlloc) and then use it; as you use it, the OS allocates RAM to your process ("demand paging"). But of course not all of it has to be realized in RAM at one time. – Jamie Hanrahan Sep 20 '17 at 9:57

Your Answer

 

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.