Interrogating CrashDump file

Evening all, today I downloaded DebugDiag, which reads the data from the CrashDump file generated when MSFS CTD, once its done its job it produces a readable HTML format file containing a lot of data and info, but as I am no expert on interpreting this I have forwarded the files to MS Support in the hope that it may show some light on my CTD’s, here is an example of the report:-

In FlightSimulator.exe.11772.dmp the assembly instruction at FlightSimulator!innative::utility::Stream::DecodeLEB128+1def100 in C:\Program Files (x86)\Steam\steamapps\common\MicrosoftFlightSimulator\FlightSimulator.exe from Asobo Studio has caused an access violation exception (0xC0000005) when trying to read from memory location 0x00000000 on thread [0]

So, FlightSimulator.exe from Asobo Studio has caused an access violation.

Does this mean that MSFS is the root problem??.

If anyone would like to see the complete report let me know.

1 Like

I played about with DebugDiag earlier this year, and yes, it was possible to drill down and see the actual instruction that had the null pointer, but then the difficulty is tracking back to see where it got that invalid address from, just looking at the disassembled code.

So at that point I stopped sending time on it,

Its not my job to diagnose or fix it… that’s what MS pays Asobo the “Big Bucks” to do.

Now I just run “App Crash View” to get some basic identification of what happened when I CTD, and move on…

At least those CTDs above are “Consistent” !!!

1 Like

This article may be of interest to you. And you can attach it to a ZenDesk ticket when requesting official Technical Support.

1 Like

Hiya, appreciate the response, from what I see it always appears to be an access violation when MS has to access a memory address, surely if this is correct then the problem lies within the main program and not any external application.

If the above assumption is correct then its down to MS and Asobo to address the issues, however I really can not see them holding their hands up high and admitting that all these CTD’s are down to their program.

Why do we, the end user have to do their job for them, would you pay a garage for doing a service on your car and do all the service yourself, no of course not.

Their MAIN Program, including any libraries they are using.
A call to one of these libraries, could result and error Code, maybe zero, or -1, instead of a valid address, then it is up to Asobo test that returned value, to make sure it is not an error code, and not just assume it is the data they were expecting.

In fact, this is exactly what I was seeing when I was messing about with DebugDiag.

Then, if it is really getting an error code, instead of data, and you successfully detect that, and do not use that error code as a address/pointer, then the problem MAY be to roll back what you might have been doing, to effect a graceful recovery.

1 Like

The vast majority of my CTDs over the years have been exactly the same access violation exception codes as yours - 0xC0000005. About the only other fails I ever get are with NVidia drivers, but after a driver reinstall and reboot, those seem to clear.

Just a couple of days ago I tried to start a flight from KORF to somewhere in the Caribbean, and began to select waypoints manually on the world map. For five staight flights, when I selected about the fifth waypoint, boom - CTD. Every one of them was 0xC0000005. I was running Spotify at the time, so I stopped it, and guess what? It worked after that. So I’m a genius now, right? Nope. The next time I thought what the heck and tried again with Spotify running, and had no problems. :crazy_face:

I’ve said it before, and I’ll say it again - if we had a detailed local log file like “that other” flight sim has, maybe we could all put our heads together and determine what causes the majority of the fails. But hey, maybe MSFS2024 will have one - we can only hope.

Hey guys appreciate your inputs on this, I bet if you (DestructZero) interrogate your CDT’s they are all going to be a memory access violation, the exception code we all get is a generic code and can refer to a number isues not just one.
Like N6722C I am convinced that MSFS main Program and its Libraries are the issue and Asobo needs to remove its head from its own rear and give this issue some serious investigation and stop asking US, the end user to do their work.

What it needs is for a group of simmers to attend the next Sim Convention and really rip into these guys and DEMAND some answwers.

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.

2 Likes

Exactly – and that is only Asobo ( and WT ?)

After 3 years, Asobo have not managed to eliminate CTDs – maybe its about time WT were tasked to try to do so, or some other 1st party dev…

or

Maybe its all a complete waste of time to try to fix a badly broken & unstable 2020, when 2024 is just around the corner.

Got to wonder how many at Asobo are even still working on 2020, when there is a deadline to release 2024 (formerly 2023!) , hopefully before it slips and becomes 2025.

Difficult decisions — maybe just be thankful that it is not YOU having to make them !!!

The only real decision a user has to make, is whether to re-start MSFS after a CTD, or call it a day, and do something else, and maybe to try again another day.

“ The definition of insanity is doing the same thing over and over again, but expecting different results” – Albert Einstein

They’re never going to eliminate all CTDs. New ones will be introduced, and there will be bugs that cause CTDs for people in 2024 too. We all know that.

They certainly can make the sim more stable than it is now, and a slower pace of change was supposed to help with that. It would seem that SU13 has been a regression, and all we can do is hope lessons are learned from that.

I remember when P3D went through a similar phase shortly after they moved to DX12 and we used to get crashes due to graphics code issues. Those got fixed but it took a couple of point versions to do it.

But like I say, I get the frustration. I opened one of the threads talking about the map zoom CTD bug which is now obviously affecting quite a lot of people. That’s half the battle - getting Asobo to acknowledge that it’s an actual bug and not a local config or add-on issue. And if I were getting constant CTDs and had been for months, like some people here are saying, I’d be super-frustrated to the point of, indeed, making a choice between simming and avoiding the hassle.