The Resource Monitor tells you all of that.
How much memory is free, how much is allocated and how much is in active use.
Maybe “allocated” is not the correct term and “reserved” should be used instead.
If so, I apologize since I am not a native speaker and I don’t work in IT. The internet also destroyed what my Cambridge Certificate of Advanced English once taught me to be good English.
AFAIK, memory isn’t allocated to an app - it uses it as it needs it, provided there is some RAM available.
I don’t think that is how it works. Because something must tell the running processes how much memory is still available and where. Here is in a nutshell what the columns in Resource Monitor tell us:
- Commit – Amount of virtual memory reserved by the operating system for the process.
- Working Set – Amount of physical memory currently in use by the process.
- Shareable – Amount of physical memory in use by the process that can be shared with other processes.
- Private – Amount of physical memory in use by the process that cannot be used by other processes.
Note that all the talk about memory use by MSFS centers around the Commit column. This is the amount of virtual memory reserved for a process, in contrast to the physical memory in use by a process in all other columns.
This refers to something called the Commit charge, which is basically the total amount of virtual memory demand (physical memory AND pagefile) that Windows has to make fit somehow. Memory committed to one process is no longer available to other processes for the most part.
And here the simulator is causing problems. If the amount of committed memory to flightsimulator.exe and all other running processes exceeds the available total, the sim will crash because Windows basically pushes the red button on it so the entire system does not crash.
If any of the above is grossly wrong and incorrect, feel free to correct me and add to the discussion.