oh, and really, I don’t doubt anyone here. I just have a hard time to believe that all the installed versions of vcruntime would cause the CTD in MSFS. That’s all
I’ve not actually read a post of a breakdown of why it is supposed to be an issue. Anecdotally it may have been, and has been written up as one of the possible causes. Including the installation of the US English language pack for ATC, if I remember right.
- Computer boots and loads my.dll into memory from C:/System32.
- MSFS boots and loads my.dll into memory from D:/MSFS.
the MSFS version should simply overwrite the System32 version, right?
Or maybe, because they have the same name, Windows says, “done” and moves to the next file?
We know that we would never program code that just says, “Load this file”. We would say, “If this file exists, great, otherwise load this file, check to confirm it loaded, next”.
Now when we call a function from that .dll we expect that it is the latest incarnation when in fact it is the old one. Now that old function references a mem location that either has not been initialized, because the new version doesn’t use that location, or is being used for something else. “EXCEPTION ERROR” caused by “MSFS/MY.DLL”.
But it wasn’t his fault. Windows just thinks it is because that is who MSFS.EXE thought they were talking to.
Just spit-balling, but kinda makes sense…
Imagine trying to track down THAT bug…
haha tracking that one down would be bad. Your write-up makes perfectly sense. But if you pass the compiler the library to link, it shouldn’t matter, right ?
Oh well, I will probably stop thinking about it. P3D is doing very well for me. Let’s see when this gets fixed
It is getting serious lately I must admit. For the last week it is basically that it crashes 9 out of 10 times when starting flight at about 80% of loading bar it goes back to desktop just like that. And if it somehow starts simulator then after few minutes after departure it crashes anyway. I’ve tried to throw everything out of community folder (even that I have only stuf that I used to have there) and it doesn’t help at all.
Almost 850 votes. Was at around 800 in early March before the latest dreadful “update”. At this rate CTDs will be #2 or #1 issue before too long. Waiting to see what’s Asobo response in this, because currently I’ve paid tons of money for software I can’t even play (as it crashes on the welcome screen or the map 100% of the time even after clean installs while everything else works perfectly fine).
I don’t think installed VC++ versions are relevant. The game seems to be using its own version internally and would crash with an error about vcruntime140.dll v1.28.x, when the version I had installed was still 1.25.x. And in any case it’ll still crash with any VC++ version for that matter.
I’ve posted this in a couple of different topics but I was struggling with CTDs just loading into the world with the 126.96.36.199 update. I only had a 4GB page file set, I increased it to 32GB and my crashes stopped.
No success for me. Thanks anyway.
Dude how much system ram do you have? I have 32GB @3600mhz…No point me messing with this right ?
also with 32 GIG RAM you must not disable the virtual memory and MSFS consume a lot of it. We had users which thought that 32 GIG is sooooooo a lot and they disbled the virtual memory or limit it to 100 MB or also only 4GIG. This will not work !
Thus… it is still a valid hint to have the pagefile in mind. This hint is very old and I wonder that it is still necesseray that it must be mentioned or that users mentioned it as " a new idea".
Only if you own 64GIG RAM, you don’t need to think about.
about what you should think is to made checks with disabled XMP mode.
Also a well known hint… very well known…
I have 32GBs of Neo 3800 14-16-16 ram. I was certainly in the boat of 32 is plenty so I’m going to limit my page file to 4GB to force more physical to be used. I guess it wasn’t enough. I’m going to start reducing the page file tonight and see where the sweet spot is. Before 1.14.5 I had no issues with 32 physical and 4GB virtual.
I’m running XMP settings but clocking at 1800 IF, 1800 Ram. I normally clock at 1867 but wanted to make sure there were no issues with that.
oh one more thing to look at. If you are using an AMD chip and X570. Make sure you are up to date on the AMD Chipset drivers (from AMD) and your BIOS.
here a post with an image of possible commited memory ( and it is not the highest I had )
PS.: and yes… the memory consume is bit increased, but not at all places in the world
i have 32gb of physical memory… allocated another 128gb of swap space on every drive i have - three of them, all of them are ssd’s. the sim still crashes. what now?
it’s not about memory allocation what crashes the sim.
New Update 188.8.131.52 is available now (hotfix). But didn’t help me either.
- New patch 184.108.40.206. Would not download, quite possibly because of some problem with MS Store, so I had to resort to a Windows reinstall
- MSFS reinstall as well obviously, took half a day to download those 155GB
- Latest WHQL AMD drivers released a few days ago
- First launch resulted in “Display driver amdkmdag stopped responding and has successfully recovered.” and the entire PC froze, I had to physically reboot it. First time this happens
- Everything else works perfectly fine out of the box, all games included and in ultra settings.
It’s not PSU, it’s not BIOS, it’s not RAM, it’s not GPU, it’s definitely MSFS clashing with something else (AMD drivers or whatever).
Go figure. Bad programming, bad product, bad results. Blame me for being grumpy because I’ve paid literally thousands of euros for PC upgrade, peripherals and software and I still can’t play this thing since the latest update in early March.
Probably because it was not a patch addressing crashes. Whatever your root cause for that is still there on your system.
Yes, I understand the fact that yesterday’s patch was exclusively addressing the known performance issues and nothing else. CTDs will still be there for the foreseeable future and I sincerely hope Asobo do something to address them because there are many of us who have heavily invested in MSFS and it’s super frustrating to not be able to play. We’ve been even called “trolls” by certain lovely people here in these very helpful forums, but they can’t even begin to imagine what it would be like for them (who are able to play) to be in our place. I just pity them and I’ll stop there.
However I may have done a huge breakthrough for the first time in a week or so.
After a few more dozen workarounds which amounted to nothing, I finally got the sim to load 3 (THREE) times consecutively without crashing in the main menu. This is unheard of. I did a couple of very short flights and it didn’t crash when I returned to the lobby and it even let me download all 30GB of in-game marketplace updates and was stable for several hours in the main menu.
So the absolute last workaround I did was to disable Xbox Game Bar. 99.9% sure that did the trick to some extent. It can be done like this:
- Windows key + i to get into Windows Settings
- Select “Gaming”
- Disabled Xbox Game Bar overlay
Just before that I had also disabled AMD Adrenaline overlays but MSFS still crashed, so it’s probably Xbox Game Bar that did the trick. I’m not using any other workaround, no overclocks/underclocks, undervolts or disabled XMPs, nothing at all. Just a disabled Xbox Game Bar (running on its latest version anyway).
Unfortunately the 4th time around I got a VCRUNTIME140.dll CTD as soon as main menu appeared and the only different thing I did was to keep MSFS loading in the background while I was on the browser replying here in another topic. The 5th time I had the game load in the foreground and it’s still working fine half an hour later, I’ve left the aircraft flying circles while I’m switching between Windows, writing this post and so on, with no CTDs so far.
I pray to dear almighty God and all that’s holy and sacred and I pray to mankind’s welfare and to Asobo’s prosperity and to our childrens’ happiness, that disabling Xbox Game Bar was the trick that does it for me and I won’t have to use any other workaround.
… which is not to say the CTDs have stopped, as they are still happening all the time. The game will crash if it’s not loading in the foreground, it’ll crash if it returns to main menu after a flight and so on. It’s just that it usually works when a few hours ago it didn’t work at all (for a whole week).
edit: more never ending curiosities as even with Xbox Game Bar disabled the game will crash 100% of the time within 5 seconds being in the main menu if it’s in windowed mode. As soon as I switch it back to fullscreen (actually that’s borderless fullscreen, enabled via “C:\Users\asmod\AppData\Local\Packages\Microsoft.FlightSimulator_8wekyb3d8bbwe\LocalCache\UserCfg.opt”), then it becomes more or less stable again and I can now launch a landing challenge. Will this never end…
After the 220.127.116.11 update, I started to once again have the odd CTD. I got a hint though and so far running smoothly again. Reading back through this thread I noticed others have had similar behavior. I would get fps “stutters” during ATC audio events. And when I did CTD I would get some audio “stutters” right beforehand. I’ve got a Reverb G2 on the way so I’m not in the accepting mood. I noticed while watching Netflix, the odd time, I would get audio “stutters”. Well, I’ve been recording music professionally for some years. Those aren’t stutters. They are Buffer Underruns. I have been using my Mainboards soundcard which uses a Realtek driver. Ok I have the ability to test, So I did. I ran the game with my studio soundcard… what a difference. So far, no CTD. I’ll report back but its looking so far that the soundcard is the culprit. It has the latest driver too as one released after the recent windows update. MSFS seems a lot more responsive. It’s for sure a lot smoother visually, and ATC’s audio has no more effects on my FPS. My honeycomb controllers are also a lot snappier. As well I can reply to ATC the instant his/her audio stops, used to have to wait a seconds to reply
EDIT: Its not at all a cheap mainboard and the onboard DAC is “supposed” to be debcent