Those random camera problem with CTD have absolutely nothing to do with hardware, it’s a game problem atm since the last patch.
It seems that disabling Multiplayer / AI traffic can solve it.
Those random camera problem with CTD have absolutely nothing to do with hardware, it’s a game problem atm since the last patch.
Apple tends to put very small, insufficient thermal dissipation solutions in their machines to keep them nice and slim. And to prevent their machines from otherwise thermal throttling themselves into oblivion, they allow the CPU and GPU to operate right up to and sometimes beyond spec so their their performance doesn’t degrade to Pentium II levels during workloads.
Normally for work-type stuff, that’s not a huge deal, as the CPU and GPU aren’t being hammered with a 100% load for a long period. MSFS is rather poorly optimized atm and pushes hardware far too hard for what’s being done. I can run other demanding games at 4K in ultra and seeing high 60s / low 70s on GPU temp at most. My poor 2080’s fans are just screaming while the game sits at the main menu… There’s no other use I have of my computer that can push my GPU temps up to 80C.
So the only real way ASOBO is going to be able to debug a lot of these issues, is if the actual developer can reproduce them while running MSFS in a development environment.
Even if “testers” can sometimes reproduce the issues, and confirm that they are present, it’s only the developer who can actually see what might be causing them, if they themselves can reproduce it … and I suspect there are not that many in numbers, at ASOBO who can actually do that … so fixing these issues could take a very long time
Maybe, one way to speed up this would be for a select group to be issued a DEBUG version of MSFS, that while not being able to perform as well as the release version, would have the necessary debug feature and extra exception handing, to be able to better report when and why issues are occurring, maybe they are already doing this to their limited number of QA testers ? Who knows … certainly not me lol
I would love MSFS to succeed, and “be all it can be” – I have been waiting so long for the next version of the Sim (as a sim, and not a game) since FSX, but I am also a realist, and realize that there is very, little if anything I can do to make any difference, and that is just the way it is … short of trying to get a job at ASOBO , “Ce qui n’arrivera pas”
Now there are 3 thing I have no control over in my life " Death, Taxes and MSFS" so I will just accept that, and not let it stress me out.
I am just glad that really MSFS is just a “Game” (or Sim) , and is not going to make any significant changes to my life … and at the end of the day, like so many other things in my world - is not “My problem”.
Having said that, I REALLY hope that MSFS is a great success, and gives everyone what they are looking for, if not today, maybe at some time in the not too distant future.
Someone once said "I have a dream " … well, so do I – “True AI ATC” – It’s coming in the real World, ( like self driving cars, and the planes) so why not in a sim ??
I had a laugh at that!
I would try running the Repair function through the Apps section in windows…
A good developer can do a lot with a crash dump and even more if the crash dump includes a memory dump. Sending those to Asobo will help. While not every crash can be analyzed that way, many, if not most, can (at least if their developers are any good). Basically, what Asobo needs to do is ensure that crash dumps are being sent to Microsoft and bucketized. What that means is that crashes with the same call stack get lumped together so the crashes that are affecting many people are easy to see. Then common crashes get bubbled up in the reporting, get visibility, get investigated, and get fixed without customers needing to explicitly needing to do anything. I say send them to Microsoft because that infrastructure is already in place for Asobo to pull from.
More debugging tools built into developer mode would be great. Asobo isn’t going to give anyone debug bits or real symbols because they want to both protect their IP as well as prevent piracy. I haven’t looked at it that hard, but Flight Simulator seems to have code in it to defeat debuggers. I was getting constant single step exceptions when I tried attaching. It would be great to have symbols and debug bits for sure, but I don’t see it happening.
IMO, the biggest problem with reporting bugs in general to Asobo (and it is the same problem that dedicated internal testers would have) is that it is difficult to provide repro steps for many bugs because they happen in the middle of a flight. Isolating bugs in this environment in order to provide a useful bug report with sufficient steps to reproduce is simply going to be too time consuming for most of the small set of people that might otherwise have the skills to do it. Honestly, I’m not filing that many bugs because I can’t provide enough useful information at the time and I’m not really willing to spend my free time investigating to the point where I can isolate said bug. And I’m certainly not willing to do this for free, no matter how I much might love Microsoft Flight Simulator. I would be willing to take a preview build and give ship/no ship feedback–provided that Asobo made any such builds painless to download and easy as well as quick to roll back if need be. Basically, I’d want a dedicated high-bandwidth port so that if I needed to wipe my whole Flight Simulator install, it wouldn’t take me half a day to get it back.
It would probably be much easier on everybody if Asobo could design a “flight data recorder” that would keep track of plane state. Maybe it could only be in a rolling buffer, but if you could hit a button when you encountered an issue and the resulting file would allow the plane to be put back in a state around when the bug happened, then it would provide a means for we as a community to be far more helpful. I could certainly see encountering a bug, pushing a button and being able to enter a quick description of what was going on and then having the report along with the data being automatically sent off to Asobo.
Additionally, it would provide the basis for automatic resumption of a flight after crashing. I’ve only crashed once, but it was on approach after a two and a half hour flight and it was very frustrating. While I was able to use “travel to” to get back (and I was pleasantly surprised that it worked reasonably), it didn’t put me exactly back where I was and I wasted a few minutes getting back to the pre-crash point. If I were in cruise, the coarseness of the feature would have made this nearly impossible (assuming I crashed in the middle somewhere). At least that is my assumption. I’ve tried setting the dashed line to arbitrary spots on the flight diagram, but it hasn’t worked. And even if it were possible, there is no way of knowing exactly where the crash happened in the profile. Slew mode is an obvious possibility, but again, how do you know where you were when you crashed? And with flights not logging in developer mode, it is highly likely that I would forget to turn it back off after slewing and end up with my flight not being logged. As an aside, they need to prompt for flight logging at the World Screen if you are in developer mode when planning a flight and also if you turn on developer mode mid flight.
My other comment is that Asobo needs developers flying the simulator on a regular basis. Like “Dev Fly Fridays.” Maybe every Friday, developers fly the simulator. Aircraft (and maybe even parts of the world) are assigned out to individual developers on a rotating basis. IMO, that is the only way Asobo is going to get a handle on the state of the simulator. Developers need to be actually trying to do normal stuff and encountering the same issues that we as customers are (and experiencing the same level of frustration). I’d also encourage the use of second and third machines to be constantly in use for temporally long flights on autopilot. This would help flush out many of the autopilot issues we’ve been seeing, as well as random stuff like engine shut downs, etc.
Granted, I’m making an assumption that Asobo developers aren’t currently flying regularly in the simulator, but given the types of bugs we are hitting, it seems hard to believe that they are. Or maybe other forces are in play…In any case, they should either start doing this or possibly consider ways to make it more effective if they are already spending time inside the sim.
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 !!!
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.
#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.
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 ??