There were some problems with early 2004. But the updates from Microsoft fixed the problems.
Naah, because I use 2004 version Windows 10. I was just wondering if that was the issue… 
I have been using Windows 2004 for the last 5 month. As a beta tester never had a problem with 2004 till the last update for the Flight Sim.
As I said they are pointing fingers but never look inside their house?
2 Likes
PC hardware configs let alone software as we all know can be fickle. With the vast array of OS systems and update versions, AMD, NVidia, Intel, etc. not surprising things don’t go as planned for everyone.
I’m running a 6 year old gaming rig I built in winter of 2014. I7-5930K, 1080ti and 16GB of DDR4 with W10 64 bit and a 42” 4K Samsung with settings to Ultra and get smooth play. Way and far above smoother than anything I was previously capable of doing in either FSX or X-Plane 11. I’ve had one CTD which went right to desktop, no blue screen of death. Knowing the VFR map 100% will cause a CTD I went ahead and deleted from the in-game screen menu as except for testing for the CTD, I never relied on it anyways. Far more accurate and current VFR sectionals availed at a click of the button online.
Granted, I’m flying GA aircraft but even apples to apples comparison to FSX (or X-Plane for that matter) while flying over places like NYC and LA which used to bring my rig to its knees with crappy mid-range graphics settings and 10-12FPS results, FS 2020 moves right along with 28-32FPS and far, far better graphics than FSX could ever hope to have, let alone out of the box “wow” weather (granted it sill needs more tweaking but better than it was, at least for me) that with FSX I had to have two payware packages to accomplish.
A starting point for you is to check the Application Log in Windows, and find the Red X event that caused the CTD.
It should give you a sense of what caused the crash. Of the people who did this and reported here on the boards, a majority of them found a DLL related to Visual C++, several libraries of this code support the FS program. Some fixed it by either Repairing the App or Re-Installing the App. Others found their video drivers were at fault, removed them, did a clean re-install.
Just some suggestions and ways forward that might help you further nail down where the root cause is specific to your situation.
I doubt it, (though I could be wrong). I’ve used Perfmon to watch private and virtual bytes and I haven’t seen anything that suggests a memory leak. Beyond which, a memory leak wouldn’t generally cause a crash. Instead, as physical memory got depleted, the processor would have to write more and more pages to the swapfile and the effect would be that the hard disk would start to thrash and the system would bog down. While it isn’t impossible that a bug in the Windows memory manager or one of the various heap managers could cause a crash in that situation, it wouldn’t be the first thing I would assume. Particularly since you were able to resume your flight before the symptoms started. If Flight Simulator had that kind of a memory leak, you would have come back to a totally unresponsive system. In any case, if you think you have a memory leak, you should run perfmon before hitting pause, note the private and virtual bytes, then take a look at what happens when you come back. If you are experiencing a memory leak, the numbers will have increased tremendously.
If a crash occurs in FlightSimulator.exe (which you mentioned you are seeing in the Windows Event Viewer log), all that means is that the something in that process space caused an unhandled exception. It doesn’t mean that it was necessarily Asobo’s code. It used to be that almost all Windows device drivers resided in kernel space, but that meant that badly written device drivers (of which there were many) could take down the entire operating system (which they did on a regular basis and Microsoft got tired of getting blamed). So Windows made a push to move drivers to user-space so that at least poorly written drivers would crash processes instead of the entire operating system. In Windows 10, many (if not most) drivers are going to have code running in user-space, and if there are bugs in those drivers, a program like Microsoft Flight Simulator is going to cause them to occur. I can tell you with certainty that Nvdia has drivers running in user-space, but there might be also drivers related to other peripherals that you could be running as well.
Unfortunately, crashes are very hard to diagnose without having visibility into the software. Without having a callstack with reliable symbols, there is no way of knowing where a given crash occurred. If a crash can be consistently reproduced then it can be found and fixed. But seemingly random crashes are extremely difficult to track down and even a good call stack is often insufficient to lead to a diagnosis. Having spent a great deal of time debugging crash dumps sent to Microsoft, I can tell you that in some cases, it is completely impossible to diagnose a crash post-hoc even with a good stack and memory dump.
All I can say is that most users are not experiencing crashes routinely in the game, which tends to suggest that the problem is not with Microsoft Flight Simulator itself. Otherwise, there would be far more reports than there are. I’ve only experienced a single crash while flying in probably 150 hours of playing. For most, the simulator is extremely stable.
And that isn’t helpful, I know, for anyone experiencing crashes. Unfortunately, there is literally not much anyone can do to directly tell you what is causing the crashes. There is undoubtedly something non-standard with your machine, but there is no easy way to figure out what the issue is. Ensuring Windows and all drivers are up-to-date is a good first step. So is emptying out the Common folder. I’m sure you have already done these things. After that, your choices are trying to use more advanced tools to try to get visibility into the problem. There are some useful tools at SysInternals. For example, you can view the running threads with procexp64.exe. You may see some drivers running their own threads which may at least give you some possible culprits to consider. Also, plain old device manager can give you insight about what drivers you are running. I would also suggest turning on Windows Error Reporting to create crash dumps for user space crashes (because I don’t think Asobo is generating them). Asobo hasn’t published retail symbols for Microsoft Flight Simulator, but at least you would have a crash dump to send to ZenDesk. If you know how to read a crash dump yourself, then you might be able to glean enough information to narrow down the culprit. Other than that, next steps involve starting over from a clean windows install–though there are no guarantees there. However, if doing that doesn’t work at least you will have the data point of knowing that something else that you might have installed didn’t somehow contribute to the system instability.
I’m sorry for anyone experiencing these kinds of issues and I believe me, I understand the frustration. But as someone who has worked with the Windows stack from bare hardware on up, believe me when I say that when people are experiencing widespread crashes in a retail application, the problem is usually something unrelated to the application itself.
[Edit] Another thought is that perhaps you have a different runtime version for one of the runtimes that Flight Simulator is depending on and you are encountering a runtime bug. I don’t know what runtimes and versions Flight Simulator depends on, but off the top of my head, I’d certainly look into msvcrt and .Net Framework versions. [/Edit]
1 Like
There should be an entry in your windows event log, if MSFS does a CTD.
Getting that, and submitting it with your report to Zendesk, should allow ASOBO to determine the cause.
Without that Event log, any reporting is as useless as just saying “MSFS does not work”
BTW: A Crash Dump is not what is needed. Thats for Windows BLUE Screen of death.
That is not what a MSFS CTD is … So a MSFS CTD will NOT produce a Crash Dump.
You can turn on “application” crash dumps (not related to BSOD).
Create the registry key LocalDumps if it is not present already. It is part of the WER (Windows Error Reporting). There’s 3 modes of dumps.
To enable and configure WER to capture and store application crash dumps, add the values to the following registry key:
Key: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\Windows Error Reporting\LocalDumps
Name: DumpFolder
Type: REG_EXPAND_SZ
Value: %LOCALAPPDATA%\CrashDumps
Name: DumpCount
Type: REG_DWORD
Value: 10 (decimal) This will collect 10 application crash dumps.
Name: DumpType
Type: REG_DWORD
Value: 0x2 (Value 2 is for Full dump)
Note: The preceding settings apply globally to all user-mode applications. Application crash dumps are saved to the DumpFolder location. Service crash dumps are written to service specific profile folders depending on the service account used. For example, the profile folder for Network and Local Services is %WINDIR%\ServiceProfiles. For System services, the folder is %WINDIR%\System32\Config\SystemProfile.
1 Like
They give you a laundry list of ■■■■ they are throwing up against the wall, other things like reinstall C++, clean reboots, update Direct X. I’m convinced they don’t have a clue as to what is happing with CTD’s. Amazing you can fly along for hours and then it just crashes.
1 Like
Interesting though - but how is a user meant to know what runtimes and version MSFS expects to see. – or more to the point, what is desired.
Some form of Analyser would be nice that went through the requirements for MSFS (as currently compiled by Asobo) and report the users current versions, and if they match the expected version.
At least then, everyone would be on the same page.
Its so so much have the latest … it more having the version that Asobo is developing & compiling for.
Maybe a stricter Manifest for MSFS ?
People can send Windows Event Logs to Asobo until they are blue in the face and nothing will get fixed because they don’t contain very much useful information. Crash dumps are the best thing people can provide and crash dumps with a memory dump are even better.
It is true that crash dumps are automatically produced for BSODs, but they can also be produced for user crashes. Many applications that I was involved with shipping automatically enabled capturing user space crash dumps and sending them to us at Microsoft. However, I don’t believe Asobo has this turned on.
Again, I used to debug crashes while working for Microsoft and I can tell you that a Windows Event View log is generally useless without an accompanying crash dump. While you get the address in which the crash occurred, that isn’t going to be helpful because of address space layout randomization. Even if ASLR was turned off, you would have to go get the linker to generate a MAP file and then find the address to figure out what function the crash occurred in, and then dump the binary to look at the assembly instruction where the crash actually happened. But without a call stack, you would have no idea what actually was going on at the time of the crash, so root cause analysis would be difficult to impossible. And most engineers today don’t know how to do all of that anyway, so they would most likely resolve the bug “No Repro” and move on.
3 Likes
@FrankRHansen - With your hardware, you’re running Windows on an iMac Pro it would seem.
I would try reducing resolution down from 5K to something more realistic if you aren’t already. People with the RTX3090 are struggling to run 4K all ultra. That Vega 56 is now 3 generations old and is not a card made for even 4K, let alone 5K. Perhaps in graphics workloads it’s fine at 5K, but definitely not for gaming. That’s a GPU made for 1080p / 1440p gaming at best.
Also, I’m wondering if your total crashes and blue screens may have to do with heat. Macs in general are notorious for poor heat dissipation and setting their hardware to run at and even past their designed temperature limits. MSFS in its current form basically turns even the best water-cooled beastly gaming rigs into ovens. Overheating could potentially be an issue that would crash the whole system to a BSOD.
1 Like
That is the hard part. Side by side runtimes was supposed to eliminate “dll hell” for the crt and for the most part it did, but it isn’t something that end users can easily dig into. .Net Runtime has a thing (I can’t remember what it is called) where essentially minor version updates are allowed, but major versions run SxS. So conceivably a point upgrade could possibly introduce a bug.
But like I said, crashes are extremely difficult for end users to deal with. They are hard enough on the developer side. To be truly effective at debugging them, you have to have a full stack understanding of the system from hardware to application source code as well as the tool sets being used to build the product (yep, compilers can introduce bugs as well).
Great point. Heat is a big deal at the hardware level and it can affect the behavior of the digital logic (leading to random crashes) before the CPU decides to throttle. Find a freeware temperature app and check out your cpu temperature for sure. Also, if you are overclocking try disabling that.
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.
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
@ALL
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.
1 Like