CTD (Resource Exhaustion Monitor)

And again, i get the CTD during flight -.- When i check my system logs, it says “Resource Exhaustion Monitor” and says that the Sim ate up 19GB of RAM.when crashing. I am on 16GB of RAM. Funny thing is that sometimes i can fly for about 4-5 hours and everything is fine and another time it crashes about 15 minutes into the flight.
I created a swap file with a size of 32GB because this was recommended somewhere. I checked my rolling cache file and saw that i set it to 25GB. I lowered it to 8GB now because i thought because that rolling cache file was too big.
I just do not get what causes the crash because as mentioned: Sometimes i can fly for hours and everything is fine.

Did you try to set up your pagefile?

so… still your old issue from january

might be you can give us some more logs from event viewer ?

Yes again it is the same problem than before. I haven’t had it since then and thought an update made it disappear. I created a new topic because my previous one was closed due to inactivity and i am so hoping for help:

Windows successfully diagnosed a low virtual memory condition. The following programs consumed the most virtual memory: FlightSimulator.exe (10064) consumed 17410703360 Bytes, OnAir Company.exe (13208) consumed 814518272 Bytes and MsMpEng.exe (4148) consumed 657223680 Bytes.

I do have 16GB RAM and my virtual memory is set to 32GB. The error occurs with a consumed size between 16-25GB for the MSFS.

I mean, what in the world is the fault here? I have a huge swap file with a size of 32GB but whenever MSFS uses about 16-25GB of (virtual?) memory, it crashes? My MSFS installation is located on drive G: and there is no swap file on G: but usually that should not be the problem. Or did i set the virtual mem size too big (32GB page file for 16GB of memory)?
I reduced the size of the rolling cache. When the sim crashed, the rolling cache had a size of 25GB, now i set it to 8GB.
I was able to finish my flight after 3 crashes with the reduced rolling cache on the 3rd successful flight but i do not think this proves something because sometimes i am able to fly for hours without any problems.

you allways have to check the commited memory, not only the working set. You can do this with help of the Resources-Manager.

The commited size of MSFS is much higher : example Finally.....Solved CTD issues... for those of us with < 32 GB ram - #109 by MichaMMA
( 25gig working set, 35Gig commited )

a note: because you own only 16Gig RAM, you should not run other applications in parallel.

Normaly MSFS consume max about 32GIG, but at some places, the memory consume is much higher. But hmm… I expected a virtual memory setting of 32GIG fixed should realy be enough.

I always have my Resource Manager open and know that i have to take care of the commited size. It crashes when it commits between 16-25 GB of memory. But when I set the page file to 32GB, why does it still crash when it comsumes less than this size?

More baffling to me is why, when I have 48GB RAM, I end up with a max use of around 18GB and also end up with 25GB in my virtual memory/paging file. MSFS is the only thing on a clean build PC!

I tried turning my paging file off at one point, went on a long flight. The max amount of physical memory at one time was 38GB.

okay… you not mention that you already spoke about the “commited” and not “working set” memory :wink:

The only idea is , as mentioned, other running applications and so your overall commited memory ist more than 16+32 ( see in Taskmanager ).

Otherwise don’t know why windows mean it has not enough virtual memory.

To be sure you can try the usualy "sfc /scannow … dism … " checks.

Someone correct me if I am wrong here but my understanding of how Windows manages the pagefile suggests that if you set the Min and Max the same then Windows will allocate blocks that may not be released if other programs require space.

By setting the Min to 16MB, Windows will release blocks as the become unused in an attempt to get back to the min freeing up the space for new requests.

Simply, do not set the min to a large amount as it may not be freed up for new requests.

That sounds good. Will set the min size alot smaller so that Windows can dynamically adjust the size and release blocks.

another idea to check whether it have somewhat to do with windows memory managment might be:

you can, before you start to play MSFS empty the Standby Memory.

You can do this with help of RamMap, a sysinternals tool:


Empty → StandBy List


You can also first empty the WORKING Sets ( you will see much memory goes into the Standby list too ) and then clean the Standby list.

Then you have clean/fresh memory ready for MSFS :slight_smile: