Crash to desktop known issue? What happens from now on?

Really interesting to hear this from an Actual Microsoft bug analyst !!
Your insight as to what “could be done” to make the process of bug elimination is very educational.

What I take form you post is “Why is ASOBO” not making use of the automatic bug reporting to MS … they are a MS sub contractor … should be so easy to get that information gather by Microsoft, back to their developers.
Maybe they are – that information is far above my pay grade.

Yes – really -0 don’t waste your time trying to look at the code yourself, or mess about trying any normal debug techniques… the protection is very advanced, all you will probably end up doing is “Pyssing it off” and it will lock you out from even running the app !!!

It “cops an attitude” even if you do simple acceptable things, like increase your ram, and then wants to do a lot of checking over the Internet before it will let the app keep running.

Good for them - far too much Piracy these days … and I don’t want to pay a higher price for the product, just to cover the loss to MS, from those Pirating MSFS and not paying their fair share for it.

Like most who have purchased it, I just want it to “work”, and not ME to have to work to get it to run !!!

OMG – I would PAY to see ASOBO developers flying MSFS on Live streams, and then explaining ( without a script) as to why things are happening that should not be happening.

I’d even place REAL MONEY bets on if a particular flight would complete or not !!!

1 Like

Former Microsoft Software Developer. I don’t work for them anymore, so I wouldn’t want any of my comments construed as speaking for Microsoft or as having any specific knowledge into what either Microsoft or Asobo are doing with respect to Microsoft Flight Simulator. :grinning:

Sorry, I did appreciate EX Microsoft… should have made that clearer when I posted.

#1 Please everyone pacify the Forum Bot … JOIN in !!!

I think this conversation should be of interest to ALL, so I am reluctant to take it private (as the forum Bot has just "suggested "to me)

So I have a question for @Geoffda, that he might be willing to answer with his expertise.


I have only even got ONE CTD in MSFS, despite several patch updates, and this one is 100% Repeatable, and very simply.

When I plug in a Thrustmaster FF joystick (or it is already plugged in when MSFS starts), the program will CTD.

I doubt if ASOBO have one of these joystick, to test with (but quite a few Simmers do, and all report this issues.)

The Joystick runs fine in W10, with FSX etc … it juts appears to be a MSFS issue.

To increase the Chances of ASOBO looking into this, I would like to submit a Bug Report with as much relevant info as I can.

You say Windows Event logs are next to useless, but there are other more usefull reports that may help ASOBO.

What do I need to do to generate these reports In some detail please.

(This should also help others with CTD issues submit a ore usefull Bug report to Zendesk ???)

Since it always reproduces, it should be pretty easy to figure out what is going on (at least for a developer with sources and symbols). Before trying to debug it though, I’d suggest checking the drivers for your USB host and your USB hub making sure they are up-to-date.

Start by enabling user-mode crash dumps in Windows Error Reporting. There is a link my original post and someone else responded by pasting the instructions. Then reproduce the crash and locate the crash dump.

[EDIT] Here is the link explaining how to generate crash dumps with Windows Error Reporting. If you don’t want to try to figure this out on your own, just generate the crash dump and include it with your bug report. That said, if you have the ability to dig into it a bit more, it would be worth trying to confirm where the crashing code lives so that you have some leverage to get somebody to look at it. It would be even more useful if you could do enough root cause analysis to determine who really owned the bug (i.e. it could be a Thrustmaster problem or a Windows issue). Unless this is a widespread issue, it might be hard to get anyone to look at it, so the more info you can provide, the better.[/EDIT]

If it were me, I’d open it in a debugger. Both Visual Studio and WinDbg (which is available for free with the Windows SDK) can open crash dumps. In either case, I’d set my symbol path to pull from the Microsoft symbol servers.

Looking at the crash dump in the debugger, I’d start by examining the stack to see if I got any symbols loaded and they gave me any hints. What I would hope for is symbols at the top of the stack, which might mean that I can conclusively identify the actual function where the exception occurs and whomever I send the bug report to won’t be able to blow me off (at least not initially–the root cause might still lie elsewhere, but at least I can force somebody to take a look). Actually, the symbols might not be right, so I would still check the address against the loaded module list to definitively identify source of the crash. Otherwise, I look lower–often retail bits are compiled with Frame-Pointer-Omitted and there are other optimizations that result in a less than complete stack. Anyway, my point is even if there is a symbol several frames down, it might still be in the module that is the culprit. In any case, I would look at the crash address and then dump the loaded modules in order to at least determine which module the crash is occurring. Again, that gives me incontrovertible proof of the culprit which means my bug report shouldn’t be dismissed.

Then, if I can, I want to form a hypothesis on the actual cause. First thing is to look at the disassembly where the crash occurs (and consider the actual exception code and its implications). If I have a symbol, I might be able to infer what the surrounding code is doing by the name, but we have to be careful because retail symbols are usually inaccurate. So I will probably take it with a grain of salt, but for example, if I think I’m in strcpy and the crash is in a REPNE, well I might give the symbol a bit more credence.

In addition to the instruction at the time of the crash, I’ll look at all instructions leading up to the crash and examine register values. Although I can only do that for one instruction per register, it can often be very useful. For example, maybe RCX is some ridiculously high value and maybe from that I can deduce that we ran off the end of a string or a loop terminator failed or something like that. Then what I really want is a memory dump. If I have that, I can cruise the memory state at the time of the crash. I would definitely try treating the contents of any register (for which I was uncertain as to its use) as a possible pointer to a string to see if any possibly interesting strings turned up in memory. If there were any data structures that I thought those values would represent, I’d also try casting the addresses to pointers of those types. Sometimes you get lucky. Anyway, the more information you can discover, the more likely it is that you can form a hypothesis as to the root cause.

For a crash with a ThrustMaster, particularly 0xc00000005 (which is an access violation), I’d be expecting to find a MOV instruction either reading to or writing from/to whatever port is assigned to the Thrustmaster USB device. If I felt really masochistic, I’d probably try to reverse engineer the USB stack. That said, I wouldn’t be surprised to chase the problem all the way to the hardware. It quite possibly could be a bug in the USB host or even the joystick itself. If I knew that I had the latest driver, I might be tempted to pull the cover off the machine and try to find the USB host chip (I’d probably start by trying to find docs for the chip). If I could, I might try some hardware hacking tricks to try to get some visibility into the chip behavior as well as monitor incoming and outgoing bus signals.

Of course, the above depends on how motivated I was feeling, whether I had a workaround and whether I was getting good support from whomever owned the buggy code.

1 Like

When mine CTD it says it is sending info to Microsoft…

Yes, if you agreed to that, it will send some information. Likely, it is just the the Windows Event Viewer log for the crash. If it were sending a crash dump file, it would take several minutes between the generation and the upload. So even though you are sending information, it won’t be that helpful if the crash dump isn’t included. As a Microsoft developer, I had a way of asking for a crash dump, so it is possible that Asobo devs can do that as well. In any case, it is unlikely that progress will be made on a crashing bug report without a dump, unless it can be always (or at least regularly) reproduced from an included set of steps (which hopefully don’t take too much time to perform).

BTW, this thread might be potentially interesting to anyone using multiplayer: Vote [1.9.3] Long flights (>1hr) ending in Crash to Desktop (CTD) due to intense usage of SimConnect

I haven’t played with multi-player turned on, but it might be interesting to look for a memory leak in that scenario.


How – Thanks for such a detailed reply…

I will need it quite a few times for it to sink in.

However, I think I have come up with a better work around… that although might be a long shot, I think will stand more chance than sending in such a detailed report to Zendesk.

(1) Log into Amazon
(2) Buy a used Thrustmaster “Top Gun” FF Joystick. ($121)
(3) Send it to Sebastian Wloch @ ASOBO
(4) Ask him nicely to GIVE it to one of his Developers to “Play with”

Who could resist plugging that into their MSFS USB port !!!

hey I use one of those, its pretty ■■■■ good for the price, lots of buttons

Not in MSFS you don’t ??? (works fine in FSX)

or do you …??

If so, PLEASE – How ???

what do u mean? I am using one right now as we speak

The FORCE Feedback TOP GUN Thrustmaster ??

oh i dont have force feedback, same model hotas x but no FF

DON’T DO THAT !!! You got me so excited !!! Now such a let down :frowning:

1 Like

But that might be useful. Can you disable the force feedback in software?

Not that I am aware of.

A little more detail.

If the Joystick is plugged in when on the CONTROL screen

(1) The Joystick is identified by name.
(2) The screen comes up showing it only has a 'default" profile.
(3) A pause of about 2-3 seconds, where you are unable to start editing that profile.
(4) Then the CTD.

What to me is significant, is that it has not created a configuration file, or at least it has not been able to write it to drive, which i assume was the next thing it should have been creating, after identifying the Joystick correctly by name.

My guess is that something either in reading the Joysticks setup (Buttons, axis etc) failed, or something failed in writting that file to the HD.

Why ? Just a “GUT FEELING”

Hi Frank
I had the same issue with random crash to desktop with no message.
A fix had been posted early on after the update which worked with me.
First, make sure the language pack is installed. For most it is
Second, switch the text to speech audio setting to windows-off line.

Another thing that you can do is verify that the VFR window is turned on before taking off.
Good Luck

I just bought one of these and I can switch back on it from PC to PS3 :smile: