Currently, there is no way to view a detailed log/traceback of what happened
when a CTD (crash to desktop) occurs. Especially in the context of
development, being able to see which gauge/function/call resulted in the CTD,
whether directly or indirectly, is extremely valuable and will save countless
man-hours of debugging, especially when it’s not even clear whether it could
be an issue caused by a module in development, or the sim itself.
Fully agree. To share another example. I’m currently investigating why I have
100% CTD when loading default World Update CDG LFPG. I found that at least two
freeware scenaries (KAVX and KEMT both by Foxtrot), when active in my
community folder, even with the duplicate modellib.bgl file fixed make direct
CTD when loading LFPG. Would love to know the last function call, the last
file loaded or searched…
Valid point 
But to be honest it should not CTD in the first place. I do not
want to dig in logs
Hello, We agree with tsgucci: chasing and fixing CTD is our priority (&
duty!), before exposing logs about them. So, this isn’t planned anytime soon.
@SonantAlpaca I believe the question is whether there is any tooling to chase
bugs induced when using our add-ons, especially in the context of supporting
our customers. In effect, when there is CTD, without a proper trace, it is
impossible to tell whether it is a bug in FS2020 due by FS2020 missing a check
somewhere, a bug only induced because of using a combination of add-ons, or
because a file is missing or malformed and in which case which file it is. So
as long as we as 3rd party devs are in the dark about what’s going on in the
customer computer, we can’t provide any support for our own products on FS2020
and although it would be easy to just say “It is FS2020 fault, no wonder but
we can’t help”, which is not good an answer for customer support nor enticing
to support FS2020 add-ons because we know we can’t help our customers with
FS2020, we rather help both our customers finding solutions and in doing so,
also giving you the information back to help you. Which leads to the point of
having at least a log file of what is happening, like with most games and apps
(and P3D and XP11 to cite 2 simulators where the log file is THE principal
support tool in practice). Now since you’re mentioning fixing CTDs, there is
something which is still unclear: in QA it is said Microsoft is receiving CTDs
dumps and they dispatch them to Asobo. The question I have: - No one I know
in Europe has ever been presented a GPDR acceptance for this. - No one I’ve
been tracing this with when using network or other tools has seen any such CTD
dump being sent to Microsoft from their computers. In practice, how does it
work then? PS: re-reading the initial question, it might be asking about being
able to open a dump file locally, which would be useful almost only if also
having the .pdb that goes with it. I believe we all understand you won’t
provide this but I don’t think this is what 3rd parties are really looking for
either.
Building off of this, although the current approach might be to try and fix
CTD’s firsthand, there are still quite a lot of them happening nearly two
years since the sim first launched. Maybe it’s time to re-evaluate that
approach and let third party developers and the community help out in finding
them by exposing logs…
Today for example and for some reason, as I was tracing Aprons in the scenery
I started working on a couple of days ago got many CTDs… Yesterday and other
times Dev Mode is stable and I could work on scenery projects for an hour or
more. Also the strange thing is that today I disabled all addons, yesterday
all addons were there…
it might be asking about being able to open a dump file locally, which would
be useful almost only if also having the .pdb that goes with it. I believe we
all understand you won’t provide Is it really such a big deal to provide a
.pdb file for MSFS. ? - or at least supply one to selected Beta testers or
trusted developers – who could make use of it, after maybe signing a NDA, (or
whaterver is needed )
I just occurred to me when reading another topic about a similar question that
in dev mode there is a console that you can read, and if I understand various
Asobo answers correctly, THIS is the logging tool to use for debugging. This
is helping but it seems to me we might be talking about different things which
seems related though. @SonantAlpaca most of the reasons I can see for a log
file can boils down to the actual shortcoming of the console in some cases: -
It is only in-game, while the game is running. Once it crashes, or the user
quits, there is no history a 3rd party vendor can inspect to assist their
customers. - The in-game log window lacks advanced search and other text
filtering you can more easily do with any text editor (think notepad++ for
example). - when the game crashes, although the dmp file is storing the stack
and a few other infos (if any is really sent because I’ve never seen any trace
of anything sent?!), it lacks the semantics of the log file which are
important sometimes (what is loaded, what is active, what did the user change,
what did the user do - like changing a setting or a preference etc…) As an
example of what could be a log file that probably most vendors are looking
for, there is an actual very good example which in practice is very effective
for support: the X-Plane log file. Just searching the following forums for
“log file” should give plenty of exemples and why it is useful for vendors:
https://forums.x-plane.org/index.php?/forums/
It would be nice to have a log file. And would save me a lot of time on my
aircraft development. Example just tell me which .xml file is crashing