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.
