My firefox suddenly become sluggish and then froze. I opened Process Explorer to see what's going on and noticed the main thread of firefox.exe was stuck in the kernal function NtAllocateVirtualMemory. At that time, the process was only using 1.5GB of virtual memory space and I had more than 1GB of commit limit free and at least 1GB of RAM free. I thought the memory space of Firefox might have become too fragmented, so I killed it.
Then I got a surprise graph like below.
As you can see, there has always been RAM free during the entire period but I seemed to have hit commit limit anyhow. The page files are set to system managed and the system drive have more than 17GB free, so I have no idea how I could hit the limit…. Any thoughts on this?
System is Windows 10 build 10586. I have 8GB of RAM.
(It seems Firefox or some related thing has claimed a hidden 3-4 GB of virtual memory space. I think it could be the display driver, but why did the system not expand the page file?)
Best Answer
Physical memory and commit limit are distinct resources. You can run out of one even though you have plenty of the other left. You most likely need a larger page file to raise the commit limit.
Physical memory is very much like cash in the bank. Commit limit is very much like checks that you've already written. Even if you have lots of cash in the bank, if you've written a lot of checks, you may be unable to write more checks.
Say you have a system with 3GB of free RAM and no page file. And say an application asks for 2GB of memory. The system will say "yes" and raise the commit limit by 2GB. The system still has 3GB of free RAM, because the application hasn't used any yet. But if another application requests 2GB of memory, the OS will have to refuse. It has 3GB in the bank but has written a check for 2GB, so it can't write another check for 2GB.