I hope this helps someone, because I just spent the better part of a day trying to get 1.5.9.0 running on my older system. It is an i7-10700 Gen 10 CPU with a MSI GTX-1660Ti GPU. I “had” 96GB of Ram in it using two 16GB Corsair sticks and two 32GB Crucial sticks. This new beta started crashing the second I upgraded to it from the last beta version 1.5.8.0. It would crash at 5% and sometimes at 20% loading. If I went back to SU2 there were no problems loading and running the program.
After a day and a half of a dog chasing its tail with uninstalling and reinstalling a plethora of stuff, reverting to earlier BIOSes, wearing my fingers raw in the BIOS setup, and plugging and re-plugging RAM, I’m now down to one stick of the 32GB Crucial Ram in there and now the program starts all the way every time.
So my bet is a lot of the CTDs and issues people see with this program are due to its silly hypersensitivity to hardware issues or timings that don’t affect other programs or Windows itself.
BTW, I ran a memory test program which booted from a USB stick to completion with the original setup and it completed without errors.
In my humble layperson’s opinion, the current RAM socket standard is a pile of garbage.
Both my current system, and the one before which was several hardware generations older, have/had this same stupid problem: there is considerable play - wiggle room - so that the RAM modules can be tilted in their sockets by a degree or so, perhaps it’s just half a degree.
But that’s still an infinite amount of possible tilt positions! And there is only a small band within the small wiggle room where the RAM module runs stable.
With two RAM modules that were just freshly inserted, there is a near-zero chance for me to immediately arrive at a stable system. There is always some wiggling and fumbling-around needed. The lucky case is the one where the system boots up with only half the installed RAM - in this situation, the BIOS should show the good socket, so you know you’ll have to wiggle the RAM module in the other one.
I would expect this kind of behaviour if the contacts were dirty and/or greasy, but my current build had this problem right from the start, on day zero of unboxing the components.
Good morning. Thanks all for the helpful responses. I’m a guy who has been in the IT business since the first Apple II, so I’m not a neophyte when it comes to hardware troubleshooting. Regardless, I do appreciate all your suggestions. The issue clearly is with this build of the application. My motherboard is an Asus ROG STRIX Z490E which supports up to 128GB of ram in four sockets. At this point, the only way I can get MSFS2024 to start consistently is to pull all RAM out of the system and put back in one 32GB stick in bank A1. It will start consistently, but will CTD now at random points into the flight. I NEVER had any CTD issues of note since the initial release of MSFS2020 up through the MSFS2024 build of beta 1.5.8.0. My only hope is that Asobo gets some useful telemetry from all my anguish. LOL
Correct. Your guess is as good as mine. Up until this 1.5.9.0 version I’ve been running fine with all banks filled and 96GB of RAM. All my other applications continue to run fine with all banks filled, just not MSFS2024 1.5.9.0 beta.
A good part of the CTDs are related to problems in the NVidia GPU drivers and another part to bugs in MSFS 2024 or in the add-ons.
Version 1.5.9 is particularly buggy so I advise you to wait a little and retest everything with the next releases.
That said, if the CTD is really related to the RAM, then the culprit is the motherboard, the bios or a defective stick. MsFs has no control over the RAM, it simply uses the memory available at a given moment, like any other program.
I hope you will solve your problem.
Kind regards
Interesting. With my electronics degree and software experience I doubt a software bug is causing the memory problems.
However 1.5.9.0 may well be using more memory (if you can roll back check with task manager).
Windows automatically allocates memory to buffer a large file; the FS use of file caching may have changed. Driver updates may use the memory differently. Windows itself and startup apps can use more memory.
All the above could be using more memory and stessing it in new ways.
Mixing ram modules is a known problem. Temperature can affect timing. Clocking memory flat out gives marginal benifit but is risky.
Take a step back and run exhaustive memory test. However, the absence of evidence is not evidence of absence.
Generaly it is not recommended to use diferent RAM sticks in your system. For multiple channel ram (and you dont want to be just in single channel) you need identical 2 or 4 sticks. Sometimes it is not enaught to have same timeings and capacity, even the same manufacturer, you want exactly the same model.
Also, if you end up with only 2 sticks, be carefull in what slots you put them. Generaly its the slot 2 and 4. Never One next to other. Look in your MB manual what slots to use for dual channel memory.
It is not just MSFS sensitivity. Its system sensitivity.
Normally I’d agree with you but it’s quite possible for software to use hardware in ways that seems subtle when written down, and are largely transparent to the user, but which can prove disastrous in certain circumstances.
Case in point: Win11 24H2 changed the way data is cached on NVME SSDs. Most users would never notice. Users of some models of WD_Black 2TB drives, however, were left ranting and moaning about the instability of MSFS 2024 for months, because we were using said drives to store our simulators.
There was no way for the average user to realize that the sim was crashing because Windows changed something under the hood. Some of us (me!) had been using our drives for more than 6 months before the 24H2 update caused such intermittent headaches.
Once the problem was discovered, I found SanDisk (the owner of the WD brand) had quietly issued a firmware update for the drive which corrected the problems completely. Once that firmware fix was deployed (by me, not through Windows Update, I will note), 2024 has been completely solid for me. Go figure.
So yeah, I have no problems believing software can use the hardware in ways that trigger edge cases along the margins of specifications. When a couple tolerances line up in exactly the wrong way, hilarity and frustration ensue. As an engineer in the aerospace field a long time ago, I took a 40 hour professional course in Dimensioning and Tolerancing and saw examples first hand what happens when a dozen (or a thousand) parts with sizes “+/-“ so many fractions of an inch, or so many millimeters or even microns, all line up “+” or “-“ in the wrong way and parts just don’t fit. I am 100% certain software works the same way when interacting with high-speed hardware all running at the edges of those industry specs.
if all other applications and windows run fine, then the issue is rather not HW related but poor coding of the specific application causing issues. looking at the overall quality of fs2024 and the inability of Asobo to fix things without introducing several new issues speaks for itself.
That’s definitely not true. Different applications can stress hardware in very different ways. Windows and other apps ran fine but FS would cause my power supply to shut down. I replaced the PS and all was fine.
That’s not a result of poor coding. FS is pretty hard on a machine.
yes, in your case I agree, then read my above comment like this: “if all other similar applications…” (games etc, currently I have zero issues with indiana jones which is more resource hungry and draw more power on my end for example, but experience various CTDs, with fs2024 su3 beta, su2 is more stable but is otherwise seriously lacking.. so currently a choice between plague or cholera)
Interestingly, the only other app that I could find that would shut it down was CineBench. FS is a beast to itself in some ways. Taxes the CPU/GPU, disk system, and network all at the same time.
Even some of the recent games like Doom are largely pre-rendered. I can run them at my monitor’s max refresh rate (60) and the machine barely breaks a sweat.
Does it matter which 32G stick is in or do they both work when in the system alone?
It’s still likely hardware. The memory testing applications use different patterns in the memory writes and reads to try to provoke things that cause errors - highs and lows on adjacent traces for crosstalk, etc. But they only test a few combinations that probably hit the majority of error-causing situations. They can’t test all possible combinations, though. And it might not be patterns on data lines. There can also be leaky cells and other issues where refresh just isn’t good enough to keep a bit solid where time between read and write can matter.
The application certainly writes and reads in its own way and that may still provoke errors, but it’s just the memory/mobo combination that allows the errors to manifest. It’s still a memory and/or mobo error in there somewhere.
The XMP profiles are just the settings likely to let the memory run at rated speed but it’s not a guarantee because the motherboard matters too. The high speed bus that connects the memory modules can become a factor especially when filling all the memory slots. The traces have capacitor and inductor characteristics at high speeds and with a full array of memory modules, some manual tweaking may be required if it even runs. That’s where the advice comes from to only run two modules for maximum speed and put them in slots 2 & 4. You want a dimm at the end of the line so the communication traces are all properly terminated with the right impedance. Put them in 1 & 3 and there can be reflections that cause errors. Fill all four and there can be loading issues.
Different applications hit memory and CPU differently. It’s good to test other applications and that can help see how generic a memory corruption issue is, but they aren’t really a good/bad indication of the software itself.