An absolute must for CTDs - now - and it's not much work

This isn’t actually complicated. Why on earth this is not done, I do not know. But two things are mandatory I think, as someone who has been programming since the 6800 was a thing.

These should be done before anything including trying to fix CTDs. (Save for the caveats in the first neither are remotely difficult). The first alternative is probably literally a few lines of code.

  1. Some way of verifying the install (or speeding it up)

What we have is your classic “bug ridden cr*p” Microsoft style installer. If it doesn’t work and busts your system, tough. You get the same with Windows. “Oh but mine works”. Well bully for you. It frequently doesn’t because it’s designed and programmed by someone who assumes things work. You should assume installs will fail occasionally and write code that can at least attempt to handle this.

There are two ways of fixing this.

The ideal way is to be able to verify the installs. Each fspackage does stuff. This may be possible to verify. It may not because patches overlay each other, so it’s not trivial. I suspect it’s a tree of packages not a list. So we get a slightly better answer other than “it doesn’t work, reinstall”, which takes 36 hours where I am.

Frankly it is not good enough.

If they can’t do this, then plan B is actually dead easy. Cache the fspackage files that are downloaded, if there is sufficient space (say more than 10% free), with an associated checksum file. Then rather than download them from the internet, get them from the cache. If they fail the checksum when you use them from the cache, then redownload them.

It’d still take a while, it’s 127Gb after all and you’d have to unpack it , but it might take an hour rather than the best part of two days.

If people want the disk space they can just delete files from the cache.

Sorry, I don’t buy that this second one couldn’t be done by lunchtime today, though it might take a bit longer to test it. You download and construct the file.

I’m presuming it is verified somehow, if it isn’t your developers should be publicly executed. So just copy it to /fs2020/cache rather than /tmp or wherever it goes, and check if it’s there before downloading it, if it fails the verify then redownload it.

  1. Logging.

Half the ruddy problem is that you don’t know what’s going on. It’s like Apple vs Linux. Boot Linux and you get several screens of gobbledegook to most people. But for some people, it can tell them what is going wrong. With Apple and increasingly Microsoft it is “Your computer is not working properly. Please make it work by fixing the problem which is stopping it working properly. This way it might start working again”. Well thanks for nothing.

You don’t need to log everything just specific actions and phases, starting and ending of chunks of downloads from servers. In a text file, called log.txt or something.

For example, some people have problems with USB devices. If there was a log that said “Initialising driver for T16000 joystick” and a CTD occurred it wouldn’t guarantee that that was the problem. But it would give you a clue. If it crashed accessing a piece of scenery or on clicking a button, it would give the developers and people like me who try to help some clue as to where to start looking.

At the moment people are simply guessing. I don’t blame them for that, supporting this abomination must be a nightmare. It’s the standard Microsoft joke of fixing everything by turning the computer off and on again.

Look guys, that works with piddling little installs for little games where most of the game is sound and graphics anyway. It doesn’t work for this.

And program defensively. Especially installers and things that process external data. Do some basic error checking, don’t just expect it to work because it won’t.

And this

“a lot of CTD´s happen, cause there’s a problem with the connection between the MSFS2020 servers and your computer.”

it’s utterly unacceptable. Seriously, admitting this publicly is astonishing. You do know it’s possible to detect that you can’t talk to the servers ?

1 Like

I think this has some merit. The other day I had a CTD the instant I hit the button to announce my position on CTAF. Instead of hearing the pilot voice doing just that, the audio stuttered twice, then the sim crashed. It’s possible it was attempting to download the Azure TTS data for that announcement, it failed for some reason, and the code has no way of dealing with that situation so keels over.

That’s true. My problem is not that it causes the program to stop working. If it requires to load some files and can’t it might have to stop working.

My problem is that it is a crash to desktop. It should fail with “unable to connect to server” (or some other message that gives you a clue).

This is what the log is for. As you say, it’s possible it failed to load the TTS data. It could be something else. There’s no way of knowing. If there was a log message “Failed to load data from Azure”, then that’s fine.

In something relatively straightforward you can get away with that sort of thing, usually. MSFS is not a straightforward piece of software.

You can’t just write it, you have to engineer it.

Crashing can’t be avoided completely. Some programs allow hooks so that you can run code when some event happens, can’t recall if simconnect.dll does this. You can’t control what that “hooked code” does. Failing to load data should at least crash helpfully.

It is so infuriating because when it works it’s jaw droppingly awesome. These fixes , especially caching .fspackage files would make a huge difference for virtually no effort, because if you reinstall it might take 40 minutes rather than 40 hours. If I had just that MSFS would be my sim in (well hours, because I’d have to reinstall it again … but as fast as possible).

The log would save support hours and would help the developers to find bugs. And me. I’ve tried to help people understand event logs … but I can’t understand them. I mean, I know what they mean, what has happened in the most low level sense but they give me no information about why it happened.

That’s why I’m so infuriated by it.

I’ve tried to make it not-just-a-huge-complaint - I’ve suggested things which are actually doable and not hours and hours of work.


An interesting thread on the “0xc0000005” error, though not specifically referring to MSFS:

Even if you did there is nothing you can do about them. There is not much we can do to avoid these, unless you are lucky enough to realise a mod is doing it, then all you can do is remove the mod, or wait for it to be tweaked to stop the errors.

I think that’s why if anyone, including myself, files a Zendesk report of a CTD with that code, we just get the standard boiler plate response with a half dozen or so things that might help, but almost certainly won’t.

1st line support can’t help, because the devs. may not know yet why they are happening in the first place. Which logically makes sense as if they did they would have fixed them by now, but still. :wink:

That they appear to be happening on console as well, or at least CTD’s in general. is worrying though. It leaves me wondering whether we are looking at buggy Asobo code, or buggy FSX Aces Game Studio code they ported.

It makes me further wonder how many of the issues we have experienced over the last year have been down to this. Reverse engineering someone else’s code, and hoping that the documentation was good enough to explain what does what.

1 Like

Indeed. FSX doesn’t crash much IME now, certainly since they fixed the memory thing, but this code is pushing 20 years old now. I can understand why they used it as a scaffold, but it is a bit challenging at that distance and the way things are engineered has changed a lot.

Even so, if we had some idea what it was doing when that happened it would help track the bugs down. Something I would be happy to help with but at the moment you can’t even know whose bugs they are as you say. It could be either, or come from a misunderstanding of someone else’s code and how it interrelates.

At the moment there’s nothing other than “it doesn’t work”.

It’s what puzzles me. A log and a cached installer are not much work and would be way more useful to Asobo (the hard bit would be making the log accessible on Xbox !)

If I could reinstall in an hour (say, this is a guess !) rather than 30 odd I would be way more inclined to stick with MSFS and more tolerant of its crashing, because a reinstall just wouldn’t be a huge issue.

Steam does this with X-Plane, if I want to verify the 60Gb or so default X-Plane install, it takes about 10 minutes. I could understand if the intertwined nature of MSFS might cause issues, that engineering may be something Asobo couldn’t fix.

After hotfix#2 I couldn’t fly anything for about 5 minutes without it crashing out with C0000005 errors, and I wasn’t using the machine for anything else - most stuff I do on Arch Linux. I don’t randomly install stuff, don’t have any mods at all (I did change the tree size, but changing that back made no difference unsurprisingly). Before that I hadn’t had any crashes for ages (one I think ?) including the install of SU5 and Hotfix#1.

I think installs get corrupted. That’s probably what happened with Hotfix#2. This will happen, downloads will crash half way through and so on, but there’s no way to fix it short of a reinstall. Windows seems to occasionally random lock files from other processes that aren’t released by killing the process.

The sad thing is that most of the setup isn’t lost in the reinstall anyway. It sets the tree density back (in England trees are way sparser and smaller than MSFS !) and the joystick back to the default, but the changes I made to the buttons are still there, so that’s 10 seconds to fix, and the rolling cache is reset, which takes a few minutes but isn’t required.

1 Like

I’ve had three crashes since hotfix#2, so have been lucky in that regard. All three of them were in the same part of the world. Two were possibly explained by scenery cache, the third being the typically ghost in the machine stuff, possibly related to Azure TTS going wrong. but no real proof of any of that.

I think you can repair the install aka verify via the windows App settings.

All - I have been suggesting a “site” to go to so as to download the files/patches etc since inception. Europe was offered DVD’ s, rest of us were not. I would have opted for those just to have hard copy of base sim in case of reinstall. Yeah, think walmart sells them, walmart, why not MS Store. For those of us with poor internet, the 20+ hours download time has me considering not doing it ever again if it becomes necessary.

I think that verifies the bit it downloads at the start. I think the same thing happens on Steam, where it verifies the 1.5Gb stub that both download to start MSFS, but not the 160Gb ish that is the complete premium.

Odd thing is I think the security is mostly in the main program downloaded from the Store (except the encrypted planes… quite surprised they haven’t been decrypted yet.) It shouldn’t really matter what you do with the fspackages.

The DVDs would be useless anyway, because you’d have to keep updating them :frowning:

Yes, on DVD’s but, had to reload game after having to rebuild PC because of game. DVD’s would have gotten me to the base install quicker than the 20+ hours, but again, all the code has changed so lots of patches would have needed to be downloaded again. Hate this distribution model, think it’s like DCS and MechWarrior, you got to go online and download it then you hook up to server to play it. I want to play it on my machine, and have not care to interact with other pilots because I don’t want to show how poorly I am in this sim, now FSX that is a different story, medium graphics, but everything works great.

The log doesn’t necessarily need to be user accessible on Xbox. But some element that logs that fault and automatically flagged it back to the Dev’s (complete with now common “would you like to share this diagnostic data with…?” notification.

1 Like

I’ve been on the log file bandwagon since this thing came out. I remember after my first CTD, I went looking for the log file so maybe I could find a clue as to what happened. I mean come on, MSAsobo. I understand that sometimes people make suggestions and say “It would be really easy to code this” without knowing for sure, but a log file? Even a rudimentary file could help. If MSFS crashed, we could look at the last entry logged and work up from there. I know there are people on this forum that are really sharp and would learn how to decipher the entries rather quickly – imagine how much help they could give to everyone else.

I hate to think this, but perhaps MSAsobo knows that a significant percentage of problems are caused by their inadequate servers and they don’t want that fact to be logged for all to see in black and white.

1 Like

Indeed. I have tried to help people myself, but once you get past the usual, you’re just guessing.

I suspect it’s because the developers are less used to engineering things. The assumption that installs, server connection and the like will work and just flaking out if they don’t is very amateurish.

I did wonder if problems were made worse by the sudden influx of XBox fans into the sim, putting the servers under the stress. You’d kind of expect that at launch, and there’s an old saying about not building the church for Easter Sunday. But things haven’t improved noticeably.