SU 3 Betas - until a few days ago things seemed to be improving and the VRAM/over stressed resources was slowly being resolved.  I suffered slow response, low FPS, over commitment of memory at times but very rarely suffered a CTD.

Suddenly with the installation of 1.5.15 and now 1.5.16 I could not complete a flight of any kind - even with an empty Community folder.  Sometimes the crash would be on the runway before starting, other times at 10 minutes into the flight. But, dozens of flights ended with a variety of error messages:

- hung device/bad driver/overheated GPU

- ROAR has stopped working

- the application suffered a error

- and others

I reinstalled two different GPU drivers, I changed DLSS levels, I updated audio drivers - none seemed to solve the problem.

Then I remembered an older post about memory issues that I had failed to heed because I have an almost new system with Corsair Dominator Platinum DDR5 memory running stock clocks.  Memory passes every test I am aware of and no other game has a problem.

So - I restarted and took a look at BIOS. I found that at some recent but forgotten time I had turned on the lowest level of MSI X870 Tomahawk motherboard  memory overclocking.  I reset the memory profile to default and rebooted.

Since that reboot I have flown two one-hour missions with over 40-addons using the Flysimware C414 and the Lear 35 addons.  The sim is running perfectly.  

It is hard to understand why all the 1.5.xx Betas up to 1.5.14 could tolerate the increased memory speed but 1.5.15 and .16 utterly died on the same memory.

 

 

Edited July 14, 2025Jul 14 by TacomaSailor

My question to you is why you are wanting to overclock your memory. Is running at normal speed achieving the same results?

If your memory is running unreliably, there isn't really anything to explain about why one beta crashes and another doesn't, because it all becomes a game of chance.

If memory is running unreliably, maybe due to overclocking, this means that when a program writes a value to it, then later tries to read it back, it might get a different value. This happens randomly -- it might work a billion times, then go wrong on the billionth-and-first time. It might go wrong only for certain memory access patterns. It might go wrong only for certain memory locations.

There isn't a practical way to write programs so that they'll run correctly in the face of unreliable memory. A program has to be able to assume that if it writes a value to memory, it will get the same value back. If it gets the wrong value back, the effects may sometimes be benign -- a single pixel may have the wrong color, or sound may be slightly distorted. But other times, the effect will be a crash.

If your memory is running unreliably and seeing crashes only from a particular program, maybe even just a particular version of that program, that doesn't mean it's that program's fault. That particular program just happens to trigger the conditions that cause your memory to sometimes return wrong values when overclocked. Someone else with unreliable memory might see crashes on different programs, or different versions of the same program. As noted above, it becomes a game of chance at that point.

Memory testers try to provoke as many different conditions as possible to get the memory to fail, but sometimes a memory tester will run fine while a particular program you want to run will crash.

So if you're seeing crashes due to overclocking, it's really not worth asking why those crashes are happening only with a given program. If dialing back the overclocking fixes the crashes, then keep your settings that way.

10 hours ago, TacomaSailor said:

So - I restarted and took a look at BIOS. I found that at some recent but forgotten time I had turned on the lowest level of MSI X870 Tomahawk motherboard  memory overclocking.  I reset the memory profile to default and rebooted.

Since that reboot I have flown two one-hour missions with over 40-addons using the Flysimware C414 and the Lear 35 addons.  The sim is running perfectly.  

It is hard to understand why all the 1.5.xx Betas up to 1.5.14 could tolerate the increased memory speed but 1.5.15 and .16 utterly died on the same memory.

As others have mentioned, MSFS is not really more sensitive to memory than other applications.  It's just that MSFS 2024 uses more memory, and if you have defective memory because of overclocking, MSFS 2024 is more likely to bring out issues with your memory because you overclocked it.  You can probably run a bunch of other applications in Windows, that eat up most of your memory, and you may start to encounter problems as well when your memory is being used up, because you simply have defective memory from the overclocking.

@martinboehme explains it the best.  Memory is just a bunch of 1s and 0s. Either a memory location is storing 1, or it's storing 0.  But an application that uses more memory, is more likely to bring out errors with the memory. 

I recommend you stop overclocking, if you want MSFS to be stable.

 

I've noticed that folks with so-called "high end systems" seem to have many more problems than folks with potato hardware.

I have almost the same setup as abrams_tank. Bought my PC years ago off of Amazon. I've never even opened the BIOS or concerned myself with any of my PC internals. The only thing I press is the start button. 

MSFS 2024 runs like a champ on my system, with settings medium/high, frame rates locked at 30. This on a 1440p ultra wide screen monitor. 

No crashes, lock ups or what nots. 

Once settled, I never touch the graphics setting in MSFS 2024. In fact, I'm so lazy, I've let Nvidia "optimize" my settings. 

Edited July 15, 2025Jul 15 by Ricardo41

Indeed the culprit could very well be your overclock.

On a regular base these kind of threads appear.

Start with a non OC system with all drivers updated. No addons.
That is the starting point.

From there first add addons and if it all works stable then you could try with OC.

But only if you know exactly what your doing.

Reading this again, I thought it would also be useful to address a premise that seems to be implied by the thread title.

There isn't some technique or setting that programmers can use to make a program less sensitive to unreliable memory. There aren't any "bad practices" for programmers to avoid lest they make a program overly sensitive to unreliable memory.

Memory needs to be reliable in the sense that it needs to return the values that were written to it, every single time, under all operating conditions. If that's not the case, there will be problems. There is no fix that can be made to programs that crash because of this; the fix is to back off the memory settings to a point where memory becomes reliable again.

If you're running with stock settings, you can expect your memory to run reliably, since you're running it in spec. (It's still possible to have a bad memory stick, of course. With name brands, this should be rare though.) If you're overclocking, you're running your memory outside its spec. It may run fine, but there are no guarantees. If you experience crashes, the first thing to suspect is the overclocking.

2 hours ago, Ricardo41 said:

I've noticed that folks with so-called "high end systems" seem to have many more problems than folks with potato hardware.

I have almost the same setup as abrams_tank. Bought my PC years ago off of Amazon. I've never even opened the BIOS or concerned myself with any of my PC internals. The only thing I press is the start button. 

MSFS 2024 runs like a champ on my system, with settings medium/high, frame rates locked at 30. This on a 1440p ultra wide screen monitor. 

No crashes, lock ups or what nots. 

Once settled, I never touch the graphics setting in MSFS 2024. In fact, I'm so lazy, I've let Nvidia "optimize" my settings. 

Yep, I'm running at 30FPS on an old Asus Laptop with a 3080, a dab of lossless scaling and I'm good to go.  Default airports or the odd hand picked one that doesn't hog FPS.  Literally never have a crash and the sim is looking great.  

12 hours ago, TacomaSailor said:

I reset the memory profile to default and rebooted.

Why are you not running XMP profiles? the default memory profile essentially runs your RAM at it's base performance.

Though like other's are mentioning there's very little benefit to manually overclocking your RAM especially with DDR5, just run the XMP profile and call it a day.

I've had my first CTD yesterday, flying the iFly 737 MAX from Barcelona do Lisboa, right after getting airborne.

I suspect the AI Traffic caused it. I am using default AI Traffic and ATC, and even set to Min it still injects lot's of aircraft around... I guess that caused the memmory starvation, or maybe the MAX itself, or a combination... or bugs in SU3... really don't know.

Most of the time I can run FS 2024 SU3 flawlessly though!

25 minutes ago, jcomm said:

I've had my first CTD yesterday, flying the iFly 737 MAX from Barcelona do Lisboa, right after getting airborne.

I suspect the AI Traffic caused it. I am using default AI Traffic and ATC, and even set to Min it still injects lot's of aircraft around... I guess that caused the memmory starvation, or maybe the MAX itself, or a combination... or bugs in SU3... really don't know.

Most of the time I can run FS 2024 SU3 flawlessly though!

The injection of AI traffic saturates VRAM not RAM, and starving your VRAM would just lead to low fps as MSFS is now pagefiling. That wouldn't lead to a crash necessarily.

There's a possibility that the iFLY 737 still being having experimental support for FS24 is a more likely culprit

These are unstable overclocks. Not every memory OC will be unstable. I'm running an OC with tightened RAM timings on my 64GB G.SKILL DDR5 kit and have had no issues in MSFS 2020 or 2024.

51 minutes ago, Lucky38i said:

The injection of AI traffic saturates VRAM not RAM, and starving your VRAM would just lead to low fps as MSFS is now pagefiling. That wouldn't lead to a crash necessarily.

Just to add that saturating RAM would also only cause low fps, not a crash. "Memory starvation" isn't really a thing in a 64-bit application - things will get unbearably slow (because you're paging to disk all the time) long before you get an out-of-memory error.

(In a 32-bit application, it's a different matter. Those who were around for FSX will remember the constant threat of out-of-memory errors - which weren't actually caused by running out of physical memory but rather by running out of address space.)

Agree with @Lucky38i that this is most likely simply a bug, either in the iFly 737, some other addon, or MSFS itself.

3 minutes ago, RNAVV19R said:

These are unstable overclocks. Not every memory OC will be unstable. I'm running an OC with tightened RAM timings on my 64GB G.SKILL DDR5 kit and have had no issues in MSFS 2020 or 2024.

100%

It sounds like the OP may not have lucked into a decent bin. Most likely the memory meets the advertised specs and not much above it. People who genuinely know what they are doing are able to work around this by identifying what timings are holding them back and going the full manual route or by incrementally adding voltage and retesting. Something the average user will skip and that's totally understandable. But this isn't the software's fault at all. Essentially a value was placed in a location in the ram and when the data was called the value was either missing or corrupt and you typically cant continue after that to put it simplistically. Not the software's fault.  

When i build my PC's i build them with the express intent to overclock cpu/memory and gpu to the point of being unstable .. then work my way back 10% to 20% below instability level. 

For the average Joe out there the safest bet is purchasing quality components ensuring that your components are on your motherboards Qualified Vendor List (QVL) and sticking to xmp/expo profiles as advertised.