Warning: long post ahead!
Access violation errors just indicate that the program tried to read some memory that it isn’t allowed to read. This doesn’t necessarily indicate a bug in the MSFS code, although it could. It could indicate an issue with add-ons that are called ‘in-process’, which is to say code in add-on libraries called directly by the MSFS code. This is why the first advice for troubleshooting is always ‘remove all add-ons and test again’.
The number of potential causes of this error are huge, which is why it’s the most common CTD error. MSFS is written in C++, a language which does not feature automatic memory management (for lots of reasons, mostly to do with performance, you couldn’t write it in a language like C# which does). It’s notoriously hard for a human being to write perfect code, and in C++ memory management issues are the root cause of many bugs. Someone with access to the MSFS source code could use the kind of information presented in the OP to diagnose the issue, but those of us without the source code can only speculate.
This stuff is really hard. I don’t imagine that the dev team is anything less than entirely competent, but even a very experienced developer will have difficulty finding and fixing some bugs. What I do suspect doesn’t help, and probably slows things down, is the process being used. My experience of running development teams in many different companies tells me that process is, 9 times out of 10, the thing that goes wrong. I don’t imagine that Asobo has invented the perfect process when every other company I’m aware of has not.
With almost every code update coming only in SUs, and SUs now being sometimes several months apart, the opportunity to quickly fix an issue, even if you have a fix ready, is lost. How many times has MSFS had genuine hotfixes? Unfortunately, unless you get to the point where you can continuously deliver small changes without stepping on work other teams are doing for the next big release, you can’t be as agile as you’d want to be. This is super-common in the industry and if I had an easy answer, I’d be a wealthy and happy man.
And the support process, like every other tech support process I’ve ever encountered, is designed to minimise the amount of stuff that goes to third line support AKA the dev team. Unless you have a separate third line support team made up of developers who know the product but don’t have to work on it, and thus are free to just tackle issues when they come up, rather than the regular devs who have deliverables and schedules and can’t just drop everything to fix a bug right now, you will always have to triage and prioritise bug fixes alongside new features and changes. You might argue about how those are prioritised and say you’d prefer them to be prioritised differently - and I would - but that’s Microsoft’s business. It’s their product.
I’ve worked with Microsoft for many years and there’s absolutely a tension there between being open with customers and carefully managing all comms. I remember when they declared they were going to be much more open when developing Windows Longhorn (what eventually became Vista) and that burned them quite badly. The level of access and direct communication we get from the team behind MSFS is well above that in most other parts of Microsoft outside the developer division (for things like .NET which are developed as open-source code). Compare that to Lockheed Martin, who operate in complete silence until a release is out.
I do get the frustration. I am often frustrated myself. Can things improve? I’m sure they can. Would ‘really ripping into these guys’ help? I don’t think it would.
