It’s probably a generic MSFS error that can occur under lots of different scenarios, because most of the CTDs I get since I upgraded to 6800XT are in the main menu and not while flying in any map. On the other hand there are plenty of users who have confirmed that they get these CTDs at specific map areas.
Every time I get a VCRuntime error my Radeon software is at fault. I have verified this in the Event Viewer, and by the fact that the GUI for the driver usually fails to load after a VCRuntime crash. Additional verification comes from the GPU reporting 99% load at idle.
That said, the error seems to occur roughly (or sometimes exactly - can be replicated) in the same place on the map.
Exactly the same symptoms here, but what troubles me is that this is happening with all AMD driver versions that have been released in the past 6+ months, even the ones that worked OK with R9 290X but throw the vcruntime140 error after I upgraded to a 6800XT in March. Also the same error occurs even without installing any AMD software (ie. Adrenalin) but only the driver itself. Obviously I’ve only seen it happening in MSFS as any other game is unaffected. So it’s most likely some conflict between the GPU and MSFS.
But it’s not isolated to AMD as even people with Nvidia get the driver timeout error, followed by generic vcruntime140 crash. And it’s not isolated to a particular place in the map (at least not for me), as I’m getting the exact same error in the main menu, when taxiing or flying with various aircrafts in various locations while some other aircrafts never crash at all anywhere in my map (e.g. C152/172, Just Flight Arrow etc). It doesn’t make sense.
Interesting about the JF Arrow. I have yet to experience a CTD event flying that model.
Conversely, I had three CTD events flying the Carenado Seneca V the past three days; two pre-update and one post-update. However, all three were “classic” failures not related to the VCRuntime140 error.
This software keeps “a lot of balls in air” when it is running (pun intended) so I’m not surprised that all the wrinkles have yet to be ironed out. It’s a work in process… and most days I have an absolute blast without encountering too much turbulence!
So it would seem Microsoft Support arent even replying now to support for VCRUNTIME140.dll CTD they told me my problem was Visual C++ Redistributable and I should reinstall it and then marked it as case closed, In the end, I reinstalled everything (Windows & MSFS) without any results Still CTD, I got back on to support and haven’t heard anything from them for 5 days, I give up at this stage
The vcruntime140 error we’re getting in MSFS seems to be catch-all thing caused by a memory violation or something similar. It’s so generic that updating anything that has to do with VC++ libraries will do very little to very few people.
I doubt MSFS is dependent on the version installed in Windows anyway, as it seems to be using its own internal VC++ libraries (there are people who have completely uninstalled these libraries from their systems and they still get vcruntime140 CTDs). The workaround suggested by Zendesk/MS/Asobo Support may help in some cases for some weird reason but I doubt it covers more than 1% of all vcruntime CTDs, probably less than that.
Same here for me.
CTD randomly with en error in my event log from the VCRUNTIME140.dll.
like @Zeppos, you own a RX 6800xt .
As we mentioned before, the VCRUNTIME140.dll is caused in most cases from : VCRUNTIME140.dll Error - #213 by MichaMMA
Thus, may be Zeppos can help you with hint for howto cooling your RX 6800xt in a correct way ( in another thread you mentioned issues with that already ) , which driver version works fine, other 6800xt monster issues
PS.: and don’t forget… this thread is not for VR users
Yesterday I had the longest flight (from LFLY to LOWS with solid overcast all the way) so far in MSFS before crashing with the vcruntime140.dll error.
What was significant is the fact that as long as I flew within solid clouds, and no other scenery was displayed besides those clouds, MSFS remained stable. However within five minutes of breaking out of the clouds for landing, MSFS crashed with the dreaded vcruntime140.dll error.
So here’s the latest from Microsoft Support
There’s no other way to fix the VCRUNTIME140.dll issue then installing or reinstalling the latest version of Microsoft Visual C++ Redistributable Package.
If the issue persists, please contact the Microsoft Support directly https://support.microsoft.com
Microsoft Flight Simulator Support Team
I uninstalled ALL Microsoft Visual C ++ redistributable packages without reinstalling them.
MSFS works just as well, but CTDs are still there.
Obviously I had already uninstalled ALL of these Microsoft Visual C ++ redistributable packages, and reinstalled the recommended version, BUT I still had CTDs.
I wonder why I take the head to answer, knowing that all these topics on the CTD, are only dead ends
I just don’t understand why people are looking at VCRUNTIME and poking around to fix this issue.
The error is happening there because the Renoir library used by Asobo is calling memcpy (memory copy) with a null pointer. That’s it. End of story.
Nothing to do with the Visual C Runtime.
Until either the Renoir library is updated or the code invoking it is protected, it will continue to cause more than 90% of the CTDs - in my case at least.
I too was experiencing several CTDs with the culprit being VCRUNTIME140.dll according to the Event Viewer.
I use MSI Afterburner mostly to display frame rates and GTX-1080 GPU/CPU temps. I have had some great success in getting MSFS to be much more stable by down clocking both the GPU’s Core Clock and Memory Clocks by -100.
Since using these settings I have hardly experienced any CTDs.
Hope this helps.
this is your opinion and for other user not “end of story.”
Some proofs against your theory can you find in formers posts: as example
which show that your finding is possible one error scenario, but not “the” main issue.
Well, I would not call my crash dump debugger an “opinion”. Rather a fact.
If the CTD is caused by the VCRUNTIME with a 0xc0000005 exception at an offset close to 0x00000000000014b4 (depends on some factors), then, whether you like it or not, it is the Renoir library. What triggers it is another story. But the culprit is clear.
There is no interpretation with a core dump and a stack trace. Especially when almost all crashes have the same exact cause.
Most of the experimental tinkering is not performed with factual data. Some may help reduce the occurrence. Meanwhile, the only thing it may indicate is that the cause MAY be related with a race condition or improper threading synchronization and the only thing it does is to partially close the weakness gap.
Anyhow, you can believe what you want. Otherwise, as a friendly advice, install a debugger and check the stack for yourself.
I have nothing to check… may be because my system is stable
And don’t understand me wrong: I not tell you that you are wrong. I want mention only that what you find out is valid for your CTD , but it is not necesserly the generally issue as we can see how these error was resolved in case of other users.
I’ve always been clear that this is for my setup.
Meanwhile, when I see the Application error posts of some other users, it is easy to see that it’s the same root cause in many cases.
Yes, there can be tons of other factors, MSFS having clearly shown it’s a “fragile” piece of complex and demanding software.
Some posts in this topic were removed due to being off-topic or discussing moderation. Keep posts on-topic to assist others with VCRUNTIME140.dll Error.
So I received New RAM today, And still CTD so I’ve changed CPU, GPU, Motherboard, & RAM still receiving VCRUNTIME140.dll error
I have found the reason of my CTDs and low general performance but i can’t even post a link to this very forum. see my latest topic in this forum.