I’m sorry but if these have been vetted and approved for release on the marketplace why the hell should we have to do more testing for them? Why should people have to deprive themselves of a product they’ve paid for purely because of Asobo’s incompetence?
Per the guidelines of all subcategories in #bugs-and-issues we only want topics/posts related to the base MSFS. The developers can not control 3rd Party coding. If the base sim works without the additional add-ons, then contact that 3rd Party. If the base sim still causes issues, then this is what the developers need to know.
Yup. 'Cause they can conflict with another mod you may have installed. Or the sim was updated but the add-on developer hasn’t updated their software yet. Both can result in CTD that is not in any way the fault of the sim.
What makes you think the adds in the market are vetted? They worked on the developers machine and maybe on an Asobo machine, but there has never been a guarantee that it will run on your machine. That is why there is a separate forum category for adds.
This is the initial release for FlyingIron’s Spitfire IX and so for now it is available only from their website webstore. If you want to buy it today, this is the only way to get it. According to FlyingIron, the aircraft has been submitted to SimMarket.com and the MSFS Marketplace. The former will take about 2-4 weeks while the latter typically takes 4-7 weeks for approval
Are you telling me this is untrue and all addons are untested? If these are tested and validated by Asobo/MS before going on sale then they should be compatible surely?
Addons or not MSFS doesn’t work so doesn’t make any difference to me, I’m just trying to make others aware of the smokescreens being put in place trying to deflect blame from the developers, onto users, 3rd party developers or anybody else that might get in the way.
The purpose of the #bugs-and-issues categories is to discuss issues that affect the base simulator. Please do not discuss issues with third-party addons or modifications in this category. These should be filed via the developer’s preferred support method.
If you believe your issue may be caused by a third-party addon/mod, empty your community folder, restart the simulator and try to reproduce the error.
All issues caused by, or involving third-party addons/mods should be reported to the third-party developer. All issues related to the core simulator can be formally reported through Zendesk.
Hey everyone, I thought I would share some investigations I did with the sim in multiplayer and the stuttering bug. In summary if you have a different edition of MSFS than another player you will probably get a blinking nameplate AND stutters that are synced with their nameplate. Also the stutters also apply to any custom livery as well - so there’s two things going on with the stutters. Also since upgrading and adding the extra Asobo aircraft and scenery strangely enough my CTDs VCRUNTIME 140 errors have “appeared” to stop.
Anyway, see the link and maybe something in there may help you. It may or may not. Again, I’m not an employee of Asobo or a programmer just a guy who noticed something and wanted to investigate and share my findings with everyone plagued by these issues.
Hi all !!
No, nothing in the Community folder. With or without addons, the error persists. No systems overclock at all.
Getting the dreaded CTD when passing an exact location, every single time. No addons installed.
Takeoff from SBGO Rwy14 (Brazil) on MOSNA1A departure, with a “not very performing aircraft” (I’ve notice if you overfly the CTD location VERY high, you don’t get the error). Try with the 172. After passing GO014 waypoint, 38.4nm to NIMVA, boom, you CTD. It happens EVERYTIME.
The only noticeable difference is that a few times, let’s say 1 out of 5, the error description in event viewer is grammar.pggmod instead of VCRUNTIME140.dll
i7 4790K / RTX 3090
184.108.40.206 - MS Store Version
Thank you for your feedback. I remain convinced that the vast majority of CTDs are caused by bugs on the map.
Other than that, with your I7 4790, your RTX 3090 has a bottleneck.
thats interessting, because these error points often to a repeatable issue with the map at these position.
I can confirm the map bug:
tried two times
Route : GO014 → NIMVA
Name der fehlerhaften Anwendung: FlightSimulator.exe, Version: 220.127.116.11, Zeitstempel: 0x00000000
Name des fehlerhaften Moduls: grammar.pggmod, Version: 18.104.22.168, Zeitstempel: 0x6062f188
Time for a ZenDesk Ticket…
But as mentioned,
- the VCRUNTIME140.dll is normaly because of another reason.
Yes, the other reason being the calling method. Without the call stack, it’s hard to point to the offender but I can tell you that in more than 90% of the time, the offender is the RenoirCore::Path::Create method in MSFS. It’s calling memcpy (memory copy) with a null pointer. This is 100% the MSFS fault (in fact the library it’s using).
I investigate every single CTD I have with my debugger. The other most occurring issue an unhandled exception with a grammar in their Azure speech engine library.
I am assuming you have passed this info on to Asobo? Considering the ease of trapping nulls when you are calling a function. I am surprised this has not been fixed yet.
OK answered my own question.
@StopHalfling310, you do realize you could be the savior of all on this forum? If you have truly found the ‘golden fleece’, I might suggest you tell the developer. We could name the next
hotfix after you.
The very likely receive crash reports through their telemetry or simply via the Windows crash reports system. They are for sure aware of this.
And yes, there are very few excuses to let a process crash for this. Exception handling is not something new. Again, this is, I think, in a library from a 3rd party (originally Edge Case Games, now acquired by Wargaming).
about these we spoke allready here:
Might be a good idea that you explain how other users can check that your assumption is correct that 90% of the VCRUNTIME140.dll message coming from the “RenoirCore::Path::Create”…
This assertion is for my setup and I never stated this is happening for everyone else.
If someone wants to investigate their crashes, you have to instruct Windows to create a core dump upon an app crash. This is done through the registry.
Then, when you have a crash, you have to use a debugger to load the dump file (.DMP) and look at the call stack of the offending thread.
You can use any proper debugger for x86/x64 processes. Microsoft Visual Studio is very popular amongst developers (not free except for the Community edition). Microsoft WinDbg from the Store is also an interesting alternative (free).
Still having …140.dll issues in VR with G2.
21.4.1 drivers RX 6800 xt
R7 3600x 32GB
Win10 20H2 19042.964.
I note that in the SYSTEM logs just 2 seconds prior to the freeze and CTD that there is a WARNING event 4101 - display driver amdwddmg stopped responding and has successfully recovered.
Anyone else noticed these ? As my search on amdwddmg finds nothing. Anybody getting them on newer/older AMD driver ?
I also found a discussion about this error happening to somebody playing COD/warzone and Rainbox Six/seige
Pretty sure that 99.9% of all vcruntime140.dll crashes happen 3-5 seconds after a GPU driver timeout. I have never seen anything different. It doesn’t seem to be VR specific, as I’m getting the same crashes with the same GPU (6800XT) without having VR. I have tried all AMD drivers from November until now with no success and of course I’ve never had a single issue in any other game except MSFS.
For my part, I am 99.9% convinced that any vcruntime140.dll crashes that occur 3-5 seconds after a GPU driver expires are only a consequence.
The real cause is a bug on the map. And France, because I fly there often, is full of them. The worst part is that the Asobo studios are in France, in Bordeau more precisely
We can see a hanging balloon at this address 44.85026613522873, -0.5715156730831282
If I compare these bugs on the card, with our old CDs or DVDs, which could get scratched, as long as the read head did not reach the fault, everything worked perfectly.
Here, it’s the same thing, as long as you don’t fly over one of these bug areas, you may never have a CTD.
I experienced this with a person who did not have a CTD, I asked him to do a flight on a course on which I still had CTDs. He also had CTDs.
Now I could be completely wrong, and I would admit it, if they prove to me that I have too much, by giving me a miraculous solution.
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.