Investigating MSFS 2024 RAM pressure: major performance improvement from periodic RAMMap cleaning

I have been investigating several recurring MSFS 2024 performance problems, including gradual degradation during long flights, arrival stutters, resource warnings, and instability as system RAM becomes crowded.

After extensive settings changes, repeated flights, and testing several possible causes, system-memory pressure appears to be one of the primary causes of these problems on my system.

Periodically clearing retained physical memory has allowed MSFS to run reliably better for me. I am now working to determine which cleaning options provide the benefit and whether a small, reliable tray program can eventually make this workaround safe and practical for other users.

This remains an investigation—not an official fix—and I would like results from other systems.

Independence disclaimer

I am an independent MSFS user. I am not affiliated with Microsoft, Asobo Studio, or the MSFS development and testing teams in any meaningful capacity.

This is a personal investigation and possible community workaround. As far as I know, the developers would only receive these findings through ordinary community bug reports.

Important detail about my installation

Everything MSFS makes available for local download is downloaded and installed on my system.

My results currently apply only to this heavily installed configuration. I do not yet know whether users who rely primarily on streamed assets will experience the same memory accumulation or receive the same benefit from cleaning.

I also normally have additional programs and services running, including:

• SayIntentions
• GSX
• Aircraft-specific systems and applications
• Locally installed scenery and other content

This configuration may expose memory-management problems more aggressively than a smaller or mostly streamed installation.

System specifications

• CPU: Intel Core Ultra 7 265K
• Motherboard: ASUS ROG Strix Z890-E Gaming WiFi
• RAM: 32 GB Corsair Vengeance DDR5-6400 CL36
• GPU: EVGA GeForce RTX 3080
• Storage: Crucial P3 Plus 1 TB PCIe 4.0 NVMe SSD
• CPU cooler: Corsair iCUE Link H100i 240 mm AIO
• Resolution: 2560×1440

Relevant graphics settings

• Display mode: Full screen
• HDR10: Enabled
• Exposure compensation: -0.3
• Anti-aliasing: NVIDIA DLSS Super Resolution
• DLSS mode: Quality
• AMD FidelityFX Sharpening: 100
• Frame Generation: None
• V-Sync: Enabled
• V-Sync interval: Half refresh rate
• NVIDIA Reflex Low Latency: On
• Dynamic Settings: Enabled
• Terrain Level of Detail: 150
• Objects Level of Detail: 150
• Off-Screen Terrain Pre-Caching: High
• Buildings, trees, plants, rocks and grass: High
• Volumetric clouds: Ultra
• Texture resolution: Ultra
• Anisotropic filtering: 16×
• Water waves: Low
• Ray-traced shadows: Off
• Shadow maps: 2048
• Terrain shadows: 2048
• Contact shadows: Ultra
• Windshield effects: High
• Ambient occlusion: Ultra
• Cubemap reflections: 384
• Raymarched reflections: Ultra
• Light shafts: High
• Depth of field: Off
• Motion blur: Off
• Visual-effects particle quality: High
• Glass-cockpit refresh rate: High
• Character settings: High
• Road and sea traffic: Medium
• Fauna density: Low

With this configuration, I generally receive:

• 30–40+ FPS on the ground
• Around 80 FPS during flight
• Some expected brief stutters while new scenery and assets load

My problem was not consistently poor performance. It was degradation and instability that gradually developed as system RAM became crowded during longer flights.

What I have observed

As a flight continues, MSFS gradually consumes more active physical memory while the standby list also becomes increasingly full.

Memory usage climbs as new areas and airports are loaded, but it rarely drops by a meaningful amount afterward. MSFS eventually releases some memory, but it does so extremely slowly and frequently appears to retain data it no longer actively needs.

Even after returning to the main menu, large amounts of memory can remain committed or physically resident for some time.

My recurring problems appeared when:

• Physical system RAM became crowded
• Available RAM became low
• The standby list became nearly full
• Shared GPU memory began increasing
• I approached a complex area after a longer flight

MSFS sometimes identifies this condition as a VRAM limitation. However, my testing indicates that the more important threshold is system RAM pressure and the resulting use of shared GPU memory.

High dedicated VRAM usage by itself has not produced the same problems on my system.

The cleaning process also does not clear, reduce, or otherwise touch dedicated VRAM. Dedicated GPU-memory usage remains effectively unchanged. The significant change occurs in physical system RAM.

My experimental tray program

I created a small personal tray utility that periodically invokes selected functions from Microsoft Sysinternals RAMMap.

The current experimental sequence clears:

• Working Sets
• Modified Page List
• Standby List
• Priority 0 Standby List

The corresponding RAMMap commands are:

• RAMMap64.exe -Ew
• RAMMap64.exe -Em
• RAMMap64.exe -Et
• RAMMap64.exe -E0

The program is not ready for distribution yet.

I am still investigating which operations are actually necessary, which combinations provide the best results, and how to avoid performing a cleanup during a sensitive simulator operation.

My goal is to develop a reliable set of options that can work across different systems without introducing major problems. Until that testing is complete, I will not be distributing the program.

Effect on other running programs

Although these RAMMap operations affect system memory globally, I have not experienced problems with any other programs running on my computer during these tests.

Everything outside MSFS has continued operating normally. I have not observed crashes, corrupted work, major pauses, or lasting performance problems in other applications.

That does not guarantee identical behavior on every computer, but it is an important part of my results so far: MSFS’s SimBrief route import is the only operation I have found that reacts negatively.

Measured result during a demanding flight

One test occurred during descent into the Los Angeles/KLAX area while flying the PMDG 777F with:

• Fairly high graphics settings
• A custom livery containing 8K textures
• Detailed Los Angeles-area scenery
• All available downloadable MSFS content installed
• SayIntentions, GSX, and other supporting software running

Immediately before cleaning, Windows showed approximately:

• 23.9 GB of physical memory in use
• 7.6 GB available
• MSFS working set around 9.77 GiB

Immediately afterward:

• Physical memory in use dropped to approximately 16.2 GB
• Available memory increased to approximately 15.4 GB
• The MSFS working set dropped to approximately 2.55 GiB

Committed memory changed much less. This is expected because trimming working sets removes inactive pages from physical RAM without cancelling the application’s committed virtual-memory allocations.

Dedicated VRAM usage did not meaningfully change.

Most importantly, the cleanup caused no noticeable interruption. There was not a single visible hitch, and the flight continued running smoothly through descent and arrival.

Across my testing, periodic cleaning has allowed MSFS to run reliably better. The gradual degradation and problems associated with crowded system memory have largely disappeared while the cleaning process is active.

One warning: SimBrief’s Import Route function

So far, I have found only one specific negative interaction.

It occurs when clicking Import Route inside the SimBrief app within the MSFS 2024 EFB.

After cleaning memory:

• The EFB remains responsive
• Its map continues working normally
• I can view and move around the map
• I can manually create a route
• I can view and edit flight-plan information
• Other EFB functions remain operational
• The rest of MSFS continues operating normally

However, clicking Import Route inside the SimBrief app after cleaning caused MSFS to produce a device-hung error.

Using the same route without performing the cleanup allowed it to import normally.

The warning is specifically about SimBrief’s Import Route button. I have not observed a general problem with the EFB, its map, manual route creation, or other simulator functions.

My current safe procedure is:

1. Load the aircraft and flight.
2. Import the SimBrief route.
3. Allow the avionics and navigation displays to finish updating.
4. Begin periodic memory cleaning afterward.
5. Do not use SimBrief’s Import Route function immediately after cleaning.

This safeguard will be part of my continued utility testing. A future version may start with automatic cleaning disabled so the user can finish loading and importing the route before enabling it.

How other users can help test this manually

I am not asking anyone to install my program.

Anyone interested in testing the underlying behavior can download Microsoft Sysinternals RAMMap and use the options manually through its Empty menu:

https://learn.microsoft.com/en-us/sysinternals/downloads/rammap

Suggested procedure:

1. Start MSFS and load a normal flight.
2. Import the SimBrief route before clearing anything.
3. Allow the aircraft and avionics to finish loading.
4. Record system RAM, standby memory, shared GPU memory and performance.
5. Continue flying until the usual degradation or memory pressure appears.
6. Open RAMMap and manually clear the selected memory lists.
7. Return to MSFS and observe the result.
8. Report any improvement, lack of change, hitch, crash, or instability in this thread.

Please test this on a flight you are prepared to lose. These are system-wide memory-management operations, and different hardware or software configurations may respond differently.

For more controlled testing, users can also try the operations individually:

1. Empty Priority 0 Standby List
2. Empty Standby List
3. Empty Modified Page List
4. Empty Working Sets

This may help determine which operations provide the benefit and which operation or combination creates the SimBrief import sensitivity.

Information to include with test results

Please report:

• Installed system RAM
• CPU and GPU
• Aircraft
• Departure and destination
• Approximate flight duration
• Whether MSFS content is downloaded locally or primarily streamed
• Add-on scenery
• Running plug-ins and external services
• Physical RAM used and available before and after
• Standby memory before and after
• MSFS working set before and after
• Dedicated and shared GPU-memory usage
• Which RAMMap options were used
• Whether cleaning caused a visible hitch
• Whether performance or frame pacing improved
• Whether any other running programs were affected
• Any crash, instability, or device-hung error

Reports showing no improvement or increased instability are just as valuable as successful results.

Current conclusion

After extensive graphics-setting changes and testing multiple recurring bugs, system-memory pressure appears to be one of the primary causes of the degradation I experience in MSFS 2024.

Periodic cleaning has proven to make my system run MSFS reliably better. It restores physical-memory headroom, prevents the gradual degradation I was experiencing, and does so without reducing or touching dedicated VRAM.

I have also not experienced problems with other programs running alongside MSFS. The only negative interaction found so far is SimBrief’s Import Route function immediately after cleaning.

This remains an active investigation. I am continuing to identify the safest RAMMap options and develop a reliable program that could eventually provide this workaround without causing major issues.

In the meantime, manual RAMMap testing may provide a practical temporary fix for other users experiencing the same long-flight performance degradation while we wait for MSFS’s underlying memory-management behavior to be improved.