During the last Q&A the guys mentioned that they get reports of every CTD that happens, what might be beneficial to us users is if we can see these reports as well, so we can not only help diagnose them but actually find the exact reason they keep happening and take measures before having to wait for another Update.
So as per the thread title, could we also see these reports? thanks
At a minimum I’d just like to see a lookup table that translates the hexadecimal error code into something human-readable. It might be enough to tell you what major component or category to focus on.
X-Plane shows how to log events. And in 99% of the cases you can determine the cause of the crash. My best guess is that they are hiding the logs because otherwise we would be able to see how many internal problems MSFS has and that the “cleanup community folder”-reflex from support is not the best answer to tackle the problems.
As a first step, I am really curious as to WHAT reports they are actually receiving ?
You can generate your own detailed reports, when “YOU” CTD, by enabling Windows to create a Crash Dump, when MSFS does it’s CTD.
Once you have the crash dump (typically some 30 Mb) there are programs like WinDbg, you can run, that will analyze that crash dump file.
But making any sense of that analysis is not easy, especially as you do not have any MSFS source code, or a copy of MSFS that was compiled for Debug.
Your analysis is NOT going to tell you really what caused the CTD, in any way that would be meaningful to the average viewer (Non Developer)
The Numeric Code you see, is easily Googled, but again, that will not tell you what to change, but just tell you what the reason for the Crash was (Typically, Invalid Pointer)
For example, my most recent CTD occurred at
ntdll!NtWaitForMultipleObjects:
00007ffd`0238d8b0 4c8bd1 mov r10, rcx
00007ffd`0238d8b3 b85b000000 mov eax, 5Bh
00007ffd`0238d8b8 f604250803fe7f01 test byte ptr [SharedUserData+0x308 (00000000`7ffe0308)], 1
00007ffd`0238d8c0 7503 jne ntdll!NtWaitForMultipleObjects+0x15 (00007ffd`0238d8c5)
00007ffd`0238d8c2 0f05 syscall
**00007ffd`0238d8c4 c3 ret** <<<< CRASHED HERE
00007ffd`0238d8c5 cd2e int 2Eh
00007ffd`0238d8c7 c3 ret
00007ffd`0238d8c8 0f1f840000000000 nop dword ptr [rax+rax]
But does that really help me ? NOT REALLY !!!
It may help Asobo if they can identify what their code was doing at this point…
=============
I heard Asbo say in the Q&A they were getting “CRASH REPORTS”, from Players crashing Machines, but no details as to the details of these reports.
If MSFS is sending a 30 Meg Crash Dumo file to MS, every time my MSFS crashes, that’s a little concerning, as I do not recall ever authorizing MS to collect that data for MSFS. etc etc etc
They are not hiding the logs due to some conspiracy theory, they said in the Q&A to look into the possibility of making them available to the user’s too..
Really ? We need the reports too ?
I didn’t hear anyone asking Microsoft for CTD reports for Windows 11 testing being done by volunteer insiders. Oh gee whiz, I hope the developers can just get all the resources they need to continue fixing and enhancing this great Flight Sim… So far, pretty good job ! KUDO’s 2 U
The Logs themselves are meaningless to the community. But what might be significant, is the Asobo analysis of the reports, in terms of what is causing the CTDS.
I was thinking the same thing while watching that. Unless it’s embedded in some EULA we have implicitly agreed to.
Most MS App have a POP-UP when they crash, asking permission to send crash data to MS, along with the option to view the data to be sent , before accepting to send it.
MSFS just seems to Crash in silence, with no Pop-UP to give the user an option.
For numerous reasons, I do not think that currently MSFS is sending in any crash when it crashes, - at least, nothing I have specifically authorized it to share with MS or Asobo,
Maybe the reports referenced in the Q&A are really Zen Desk reports ?
I inferred it as them getting a report from every crash, not every crash reported. That may be wrong, but that’s what it sounded like to me.
I’d be interested to know what mechanism it uses. When the sim dies, the main executable terminates. But does it terminate before it gets a chance to report the crash, or is the crash being reported by some other method?
There is a program available called AppCrashView
from http://www.nirsoft.net
A typical screen from this program showing my recent MSFS CTDs
Most are 0xc00000005 Access Violations !!
99% of mine have been that type.
Pretty sure that’s one of the errors they were refering too as not theirs to fix. That seems to be an error on your system. 
I think that’s the errors that are occurring in Windows OS files, or Coherent, or Libraries that they are using in MSFS, as opposed to the code Asobo write & can change.
ie
Whats is interesting here is that most of these Coherent ones are at EXACTLY the same point (Exception offset), but have STOPPED recently ( after 7/8 ) so maybe that’s one they fixed in a more recent update ??
The software shown by N6722C works, but you’ll have to download.. and you’ll get a LOT of detail no one understands.
If you want crash time, the dll name and the exception code (e.g. this code 0005), go Windows Start and type “Reliability”, you’ll get the Reliability Monitor that is built into Windows.
THIS. I’m sure they DO believe these logs would be of no use to us, but I also believe that at least some of the CTDs could be caused by the app not receiving a response from the servers quickly enough due to a lack of servers overall or poor implementation.
Server problems could be a part of the reason for the higher number of CTDs reported on upgrade days vs non-upgrade days, the dreaded “update day syndrome”. More people that are consistently plagued with CTDs are probably getting in on update days, updating, then trying to fly after upgrading. They find that the changes didn’t solve their problems, and they report them on the forum, thus causing higher numbers of CTDs on update days.
Why does everything have to be a conspiracy or hidden agenda? What’s wrong with people today??
I am positive beyond doubt that Microsoft has at least though about or discussed releasing logs, reports, and about a half a million other things to the community. I know that this is hard for some here to swallow but the engineers who design this software are all well educated, experienced people. I am sure that they are busy enough trying to dig through the frey and find problems without the added help of millions of armchair software engineers. They would be working 24/7 for the next 12 years trying to go through the hundreds of thousands of inaccurate, presumptive, and angry, comments and suggestions. 99% of which are belief based and not fact based.
No one is hiding any big secrets that will effect your well being here. Just because you would like to see these things and they aren’t complying with your wishes, does not mean that you are being deceived, or that they’re planning world domination. It may just mean that they have enough to deal with without 100,000 to a million other hands in their business.
Sometimes…Most times…almost always, a rose is a rose. Nothing more.
Makes sense to me…
I don’t believe that MSAsobo management sits in a dark room conspiring to come up with ways to screw over their user base, but don’t think for a moment that they’ve given Asobo carte blanche to solve any problem they encounter.
If server resources really are to blame for at least some of the CTDs, what would keep them from dumbing down the code even more to require less server interaction instead of purchasing more servers to handle the load? I’m not claiming to be an engineer so I don’t know whether that’s even a possibility. While I wouldn’t go as far as to call it a conspiracy, it would show that their decisions and directions are at least not completely altruistic.
BTW if MS management reads this, please don’t send the black helicopters over my house in the middle of the night to take me to your corporate prison in Honduras (I heard they have one there).
Yes, that last part was a joke… maybe.
If you think that Server Issues are causing your Frequent CTD, you could always set MSFS to be OFFLINE, and do a few flights and see i f your CTD frequency decreases.
That´s absolutely the case, yes.
