This behavior is inherent in modern memory management. It will occur on pretty much every modern virtual memory OS if the amount of available backing store (pagefile or swap space) is not sufficient relative to the amount of physical memory.
If you look at modern applications on a Windows system, you can see that their working set (the physical memory they are using) will tend to be a bit less than their commit size (the virtual memory the operating system has promised them).
For example, on my desktop Windows machine, the browser I'm using to type this answer is using 207MB of RAM, but the operating system has already promised it 280MB of virtual memory. This means that at any second, the browser can consume 280MB of virtual memory without having to ask the operating system for permission, just by accessing mappings it already has. The operating system either needs to provide the process with this memory, or it has to forcefully terminate it, failing to honor commitments it has already made.
With no backing store at all, with just physical RAM, 73MB of additional RAM would have to be reserved for this application. Even though the browser is only using 207MB of RAM, it can balloon to 280MB just by using memory it has already allocated that the operating system has not actually allocated to it yet (just reserved).
If the operating system has sufficient backing store for all its commitments, then it can continue to make commitments. But it not, it's forced into an unpleasant choice. It can tell applications that it cannot make any more commitments, even though there's plenty of free RAM. Or it can grant application commitments, but then have to forcefully terminate applications when they go to use resources they've already allocated.
The solution is simple, configure ample backing store. This used to not be a problem. Everybody had giant disks with hundreds of gigabytes. So adding backing store equal to your physical memory wasn't a problem. However, recently machines with small SSDs are becoming common. So this is becoming an issue again.
Note that the page file need not even be touched for it to solve this problem. The operating system just needs to know it's available in the unlikely case that a significant number of commitments be called in at the same time. This almost never actually happens -- it's kind of like a run on the memory bank.