Exception details for the pointer:
Stack dump of the offending thread:
There you have it. The Path::Create method called memcpy from the C runtime, which caused the exception trying to write data to a null pointer.
This accounts for most CTDs being reported where VCRUNTIME is involved.
They have devs roaming here.
They receive the crash dump analysis from telemetry.
They have the source code.
They have the same or better tools.
They are the only ones that can fix this.
As I said before, my guess is that it’s related to a threading synchronization issue as this seems more prevalent on fast computers. But this is just a guess. I don’t have access to the source code.
You should still submit your analysis to Zendesk. If I were a developer for Asobo I would expect data like that to come from official channels. I would not be browsing the forums to look for such info. You can choose to not share this information if you want but IMO you are impeding a solution to the problem. I don’t see any upside to not sharing it.
Talk about shooting the messenger !!
He reports it every time he has a CTD
We all report it every time we have a CTD
Its automatic … ?
So everyone posting their Windows Event reports in the forum, is really just a waste of time and space . they are pretty useless, apart from confirming that you did have a CTD.
This does "assume’ that Asobo does receive the crash dump analysis from telemetry.
They talked about “investigating” the possibilities of doing this in a past Q&A, but since then, the subject does not seem to have been raised again, at least, not in public.
Except if you turn the feature off, every application crash is sent to Microsoft via telemetry.
MSFS is not an exception.
Posting CTDs in the forum has not much technical value outside, as you describe, wasting space. But, it does have “consumer” value.
If Asobo / Microsoft care about their consumers, they just cannot ignore the thousands of posts related to CTDs. So, is it completely useless? I don’t think so.
It’s the same thing for AMD driver issues. I fill a report every single time I get a driver timeout crash. Even if MSFS is the only app triggering this, AMD cannot ignore the flood of reports coming in (presuming other players do the same) - if they do ignore them, they are idiots and don’t deserve our business.
Anyhow, we’ll see how it goes. I really think Asobo / Microsoft are looking into this.
Found this tip which might be worth a try - open Task Manager, go to Details, find FlighSimulator.exe, right click, and if Priority set as Normal, enhance it to High.
I didn’t say to post to the forums. I said to post to ZenDesk. I agree it would be wasteful to clutter the forums with that info.
And I’m not shooting the messenger. I’m disagreeing with your actions. It’s the internet; I have an opinion.
Please try not to be so sensitive to criticism. I’m not attacking you. I thought I worded it as evenly as possible.
This was a very reasonable and balanced post. Completely wrong for this forum. There is no such thing as User Error. Everything is Microsoft’s fault. Everyone here is an expert. Anything less than 240 frames per second in 5K is literally unflyable. And everyone is a special snowflake.
Thanks. I saw this before too. Didn’t change much in my case - haven’t done extensive testing though.
Also, interestingly, this is the kind of change that could have an influence on bugs related to threading synchronization issues.
These exceptions in RenoirCore go back a long time… “regularly”… september 2020… It could be AMD-CPU related in some way (?)
https://forums.flightsimulator.com/t/ctd-issues-discussion-megathread/150127/264
i also found a topic at Microsoft Support talking about this issue, they solved it reducing overclocking settings…
My memory is certified for 3200MHz with the board. However, the FS2020 only works properly if I reduce the memory clock to 2400 MHz according to the BIOS defaults. It’s not great, of course, because you want to use the full performance of the system with a game like this, but ok. As I said, the error is reproducible in this way: memory clock down - game runs perfectly, memory clock up again - error is back.
That would explain why my modest Acer Nitro 5 Laptop, seldom has a CTD, unless I start doing “silly” things, like trying to use a Thrustmaster “Top Gun” Force Feedback Joystick !!
Yeah we should all just buy slower hardware. It will instantly solve most of your CTDs ! 
and of course avoid these modern nifty joysticks generating zillions of events that keep your CPU buzy… play keyboard only, you’ll be safe.
It’s troubling to see that it has been plaguing the game for so long… and nothing has been done yet to fix it properly.
For the AMD only issue, I don’t think so as I saw alot of people powered by Intel with the same problem.
I think for me this has been the smoothest feeling update. Done a lot of testing of the turboprops, short and mid range flying without any CTDs cropping up. It may help the developers to list as many locations and specifics (what you were doing) when they occur.
My experience also.
Going back to Sept/Oct, I recall lot’s of discussion with the AMD/Intel finger pointing. No correlation as far as I can see. Recently I reviewed a bunch of posts both here and in a couple other forums. Made a ton of notes looking to see if we are making any inroads. The findings were telling. More than 60% of users reporting CTD events solved or reduced those events by reducing or eliminating O/C. Memory O/C has been the leading cause of VCRuntime errors as long as I have been following it.
The voting system in this forum is problematic in that a user finds a thread covering their problem. They vote first and read through the posts, or skim, or just post and ask questions already answered. 
They find the solution to their problem but don’t unvote the bug. Although there are a few from the beginning that have never found the solution, the data shows that more than 2/3 have.
Got a bit off track there…
Bottom line was that the data also showed that the ratio of hi end crashes to mid grade crashes looks to be about 4 - 1. I don’t know if the thread race hypothesis bares out on the faster systems or if the owners of the faster systems are more inclined to overclock.
Hmm?
I do think so, your DLL is AMD-only… it looks the same, but I bet these other people with Intel chips did not publish the same stacktrace you showed us, involving AMD-specific dll’s like RenoirCore.WindowsDesktop… so you got something pinpointed ! Nice catch, I would say, zendesk material…
This particular issue seems to be somehow related to very fast data transfer according to Microsoft.
I wonder what happens if you’d put a frame cap of say 30Fps and fly ? Do you see the same issues ? 
I had a lot of CTDs before. Then Feb-late May almost none. Now constant. Every day.
No overclocking
I7-10G
RTX 3080
Only mod is FBW A320
I’m getting a lot of CTD on short final now with the FBW320. Never had this problem before.
I don’t buy this OC memory theory for stable systems. Again here, faster hardware and faster execution time are excellent ingredients for thread synchro issues. Not saying it’s this but it does smell though.
Also, my system is rock stable, without any similar crashes for years ( it has been updated ).
I finished Half-Life:Alyx 3 times - in VR evidently - with high FPS. We’re talking more cumulated time (or close) than I did in MSFS. It never crashed. Not once.
MSFS is having a CTD at least once per session. When it’s not more.
I don’t buy the hardware issue thing. Not a second. Also, if it was the case, it would not crash 90% of the time at the exact same place, with the exact same stack trace. And for many different people.
This is an Asobo / Microsoft / CoherentUI software problem. That simple.
And only them can fix it.
I’m just very surprised they don’t.
DISCLAIMER
I’m only talking about the Renoir issue. CTDs can be caused by many things.