Hi,
I had such great hopes for the arrival of the new crash report. I thought that this new tool would help me and fellow users who have to deal with CTDs to identify the cause of a crash of MSFS, similar to what the Log.txt file does in X-Plane.
What a disappointment!
This type of report may help the folks at Asobo, but not the end user, like myself! There is no way to decipher or interpret this collection of numbers for a layperson. How can I find out what caused the crash or which addon is faulty? If I need to send this in to Asobo/MS, how long would it take to get a response or a solution, if at all?
CrashReport.txt (29.6 KB)
1 Like
Itâs NOT designed for the end user to make any analysis from.
(End users do NOT have the source information or detailed knowledge of the internals of MSFS, , to make much use of the report.
It for submission to Asobo / Zendesk, (when Requested) to support a bug report.
3 Likes
I absolut agree! Its an absloute shame that the user cant see sth in there like in the log.txt of X-plane. It would make Troubleshooting alot easier for us
âItâs NOT designed for the end user to make any analysis from.â
How sad. 
1 Like
Then its toataly usless for the user! I know alot of people that have CTD´s and cant trouble shoot them Corectly. Its clearly a lack on Asobos side.
1 Like
This. 
This is typically true in most cases. There is nothing for me to glean from my PCâs crash report, or my phoneâs bug report or tombstone.
Youâll see a stack dump or memory info, or maybe a reference to a line of code, and all of those things are to help the developer.
If debugging crashes were as easy as reading a file that said âYour scenery pack from flightsim.to contains an errorâ then we probably wouldnât need crash reports 
6 Likes
The MSFS State Report was designed to help the test and dev teams reproduce CTDs that are sent in as bug reports on Zendesk/Forums, so understandably there are some parts of it that wonât make sense on an end-userâs side. I understand the want/need for debugging casually yourself though, and will send the feedback up.
8 Likes
This is going to be a rant, and if you donât want to read it, move on. With all due respect to MSAsobo, yes, the crash report was designed to help the test and dev teams. But why were the resourses at MS not put to task to create a log file for us at the same time? If you havenât seen a version of XPâs log file, google it and youâll see how well its laid out. After THREE years of MSFS users experiencing failures, youâre telling me that NO ONE at MSAsobo thought âhey, maybe we should create a log file system like XP has so our end-users can diagnose some of their own problems.â Just think of how the user community could have assisted others so many times by now.
I remember making the suggestion to create a log file way back within the first few months of MSFS being released, and I know many of you did as well. But instead of doing that, they came up with this. When do you think weâll see the results of these efforts? Maybe this year? Maybe next? Who knows, because we have no idea what this data represents.
Thank you.
7 Likes
I think thatâs what iâll put on my tombstone: Fatal Exception Error. Permanent system shutdown. Root Cause: [My death in professional medical speak]
1 Like
To fully analyze a Crash, you need many things that the developer (Asobo / MS), just are not t going to release, for a multitude of reason, one being that probably less that 0.01% of those that own MSFS would be able to make any sense of such information, or be able to use it. ie Symbol table, source code etc etc. - and those that tried to make sense it it would drown Asobo / Zendesk with a flood of technical question that would tie them up for years.
Its a lot more complex to debug these CTDs than it might appear to a casual user, and in any case, did we buy MSFS to FLY or spend all our time trying to debug something that we simple donât stand any chance of doing.
4 Likes
Hi,
Presently I am definitely spending more time trying to figure out my CTDs than flying in MSFS.
Thatâs why I had such high hopes to get something like an X-Plane Log.txt, which would point me towards an offending add-on, or possibly a hardware issue or something else that I would be able to take care of myself.
I too suggested this several times right here in this forum over the last few years.
Unfortunately the Crash Report may have turned out to be a tool for Asobo, but not for us users.
Fight the root causes not the symptoms. Itâs certainly frustrating for you but for Asobo itâs more helpful to avoid these problems alltogether than fight them locally.
The reason for the crash can be found in your Windows Application event log.
It will indicate the faulting module there, along with an error code.
That can give you some hints as to why it happened, though this is open to some interpretation.
Search on the forums for your code, and module, and youâll likely find multiple threads discussing it.
Hi @hobanagerik ,
If you mean something like this:
Faulting application name: FlightSimulator.exe, version: 1.32.7.0, time stamp: 0x00000000
Faulting module name: FlightSimulator.exe, version: 1.32.7.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x000000000258a349
Faulting process ID: 0x1924
Faulting application start time: 0x01d97ce36ea0c64f
Faulting application path: C:\Program Files\WindowsApps\Microsoft.FlightSimulator_1.32.7.0_x64__8wekyb3d8bbwe\FlightSimulator.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.FlightSimulator_1.32.7.0_x64__8wekyb3d8bbwe\FlightSimulator.exe
Report ID: 1236d7a9-95bc-4a20-b341-dc2441d55763
Faulting package full name: Microsoft.FlightSimulator_1.32.7.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App
âŚthan it is not much help for me. I have received dozens if not hundreds of these by now and I am still struggling to find the root cause(s) for my CTDs.
Perhaps the devs had decided that them being able to identify the cause of CTDs and prevent them from happening for all users, regardless of their inclination and ability to fix them themselves, would be the highest priority?
As @Jumminvana has stated, she will be feeding your feedback into the devs and you may still see your wishes met.
2 Likes
While more human-readable diagnostic logging might help to point you in the right direction to solve crashes, in general if something has caused an actual CTD then to understand the root cause you need to understand how the underlying software is written, which generally requires access to the source code. Which of course weâll never have.
It would be possible to instrument the code to log what itâs doing and to keep such a log file as the sim runs, as X-Plane does, but such logging can be expensive and slow down the code, so you want to do only as much as you need to. Perhaps Asobo does have logging in debug builds, but if so this is low-level logging that again wouldnât be much use to end-users.
Fundamentally, though, this crash report is not a log. Itâs a state dump at the time of a crash. Itâs diagnostically useful to the developers, but not end-users.
Maybe weâll get human-readable logs at some point. Basically, what @HawkMoth9135 just said while I was typing thisâŚ
2 Likes
This is a classic Windows - MSFS crash report.
And you can dive in and see the line of code that caused MSFS to stop, and windows generate this report.
Typically, its a Nul Pointer, where windows is trying to access a memory loction that it is not allowed to access, typically 0, 1 or -2.
Then the question is, where did MSFS get that bad address from, and the fun begins.
Tracing back to what happened is virtually impossible for the end user to do, without access to the source code, and even then, its very complex.
Here is a very crude example that may be easier to relate to.
Log File.
User drove his car to the Bar, and had several drinks, developed a headache, took some Aspirin, got into a fight with really big guy, had another drink and started to drive home. Crashed the car 4.3 miles from the bar, car caught fire, and everything was burnt up.
End of Log
So, what was the cause of the Crash ?
Answer: The user was born with an diagnosed or detected heart condition. When driving home, he had a heart attach, and crashed the car.
He may or may not have had that heart attach, if he has not driven to the bar, he may or may not have had the heart attack, if he had not driven, taken Aspirin, Got into a fight, but none of those was the real cause of the crash.
Maybe not an idea example, but by now you should be starting to get the point.
Also, closing down all bars, is NOT going to stop others having a similar accident, as the ROOT cause is totally unrelated to Bars,
Asobo problem is trying to determine the True cause of that accident, which in this case, was caused by the drivers mother smoking while she was pregnant, that cause the birth defect, that may or may not have âŚ
Its not an easy task to determine the cause of CTDs !!
2 Likes
Agreed. You have the worst possible combination, â0xc0000005â, and âFlightSimulator.exeâ.
I havenât seen a crash in ages now, but it wasnât always like this, and I used to get these crashes a lot. What I found helped was flying with the bare minimum of addons, and not allowing external apps to connect to the sim. As part of a diagnostic process I would fly barebones for weeks, even up to a month, till I had established beyond reasonable doubt that I had regained stability. Then I slowly re-introduced mods over a period of weeks.
Possible causes for me over the last few years:
JF Arrows, and having both the 530, and 750 addons enabled at the same time.
Interactions with in-game ATC. I suspect Azure TTS here.
Out of date rolling cache prior to sim/world update. I disabled that entirely about a year, and a half ago.
LNM flight tracking possibly breaking SimConnect. I just stopped doing that entirely.
My sim has never been so stable now. Some rules I still abide by, like avoiding multiple GPS addons.
I still use the WT 530, Azure TTS ATC, no rolling cache, and very rarely LNM, usually as part of a thread or helpdesk ticket to illustrate something, so only on for short periods of time.
As an example of how frustrating the process of diagnosing problems can be, I recently started getting unexplained CTDs in the middle of a flight. The sim would freeze, and a few seconds later, crash entirely. Not routinely, not every time, but often, and there was no common circumstance I could find. So I tried the usual things, removing add-ons etc, but it was rare enough and unpredictable enough that I couldnât really do a proper differential diagnosis. I had gotten the dreaded âgraphics device experienced an errorâ crash a few times and had rolled back to an earlier Nvidia driver, and had not seen it again; these new crashes were without any kind of error dialog, so I figured it wasnât a GPU problem.
Anyway⌠long story short, I realised that I had only started seeing these crashes since I put in two extra DIMMs to go up to 64GB RAM. So I ran MemTest86 and I got errors. This was surprising, since bad RAM usually ends up blue-screening the OS and that had never happened. But there were clear errors, so I removed one of the new DIMMs and the errors went away. Bad memory module, I thought. But I put it back to re-test and now there were no more errors.
In the end I understood: a slightly badly-seated DIMM was getting too hot and erroring out just often enough that eventually, MSFS used some of that RAM and crashed due to corrupted data. Having firmly re-seated the RAM and stress tested the system well beyond what it has to handle with the sim running at full-tilt, I havenât had the error again. So far.
No amount of log files would have helped me diagnose this.
1 Like
Congratulations on your Diagnosis and fix. 
I can confirm that the electrical connection between Dimms and their Sockets can often deteriorate over time, especially with the heat cycling of running a system that is running hot, and then cooling down when switched off.
If more players would occasionally run a memory checker/ stress test like MemTest86, there might be far less people blaming MSFS for their computer issues.
Just as some obsess over what heat sink compound they use when building a PC, everyone might consider the DIMM contact issues. There are products like
That both de-oxidize the connection, as well as protect it from future oxidation.
(also great for cleaning the contacts on your Credit Card chip gold contacts!! )
3 Likes