- Messages
- 6
- Country
I've been getting this error after the latest "patch", among many others (the control sensitivity is a disaster now) but I want to focus on the topic now.
Foreword: since we are developers here, and I suppose that many have active developer background (not scenery/aircraft development, I mean software development) we know that releasing patches on friday is a very bad practice.
It is even more bad practice considering the covid situation. People are locked home and, for many, having a working game becomes a bit more important and, simmetrically, having a not working product is more frustrating than what it should be.
It seems that asobo does not get this and their processes (or lack of) are, to say the least, troubled.
Back on topic.
This morning I posted on the MSFS forum and, intentionally, did not want to reveal my findings because I want this thing to heat up a bit and, like Marko Ramius says at the end of the Hunt for The Red October, a revolution, now and then, is a healthy thing.
The topic went quickly closed because if used a "fock ffo" (intentional typo) and intentionally
circumvented their code of conduit. In my code of conduit releasing a bug on friday is worse and closing a topic for that reason is like making speeding tickets at a F1 race. But that's it.
The first symptom was that the application loading screen freeze:
The loading bar will not progress.
First move, empty the Community folder and, not to my surprise, the application loads perfectly.
Second move, restore sceneries one at a time and, again, application loads perfectly.
Third move, restore liveries. Freeze.
Now the investigation starts then.
First I reviewed, one by one, all liveries (fortunately I don't have many). Some were missing the MODEL folder, like explained here:
flightsim.to
I fix the six offending liveries (two were mine btw,
) and the game loads. So the first obstacle is cleared.
Next step, go to any airport (without scenery) and start a flight with one of the offending liveries. As soon as the loading process starts => CTD.
Event viewer check:
spot on, the same error I had with a payware scenery (Orbx KORS).
reload the sim, go to Profile and Aircraft Hangar. As soon as I select the same airplane with the livery I was using for the flight => CTD
Same error on the w10 events logged again.
Let's check that livery and I find a simple, tiny and trivial error:
Error code 0xc0000005 is indeed related to memory and who knows what happens. What surprises me is a piece software not robust enough to notify, circumvent and handle such a simple event.
Back to the offending file, I replace A320NEO.xml with the correct Bonanza XML and the plane loads in the hangar, I can fly and the sim appears to be happy.
Now the question is...this means that a simple, tiny and insignificant copy-paste error (what I call CopyPasteException) can lead the entire software stack to a non graceful crash. I'm really astonished.
Especially because the offending file was in the "community" folder which, let's be honest, will be riddled with stuff downloaded from the web.
I have a long history with MSFS (since 4.0) so, over the years, I learned to keep only what needed (and after checking it) but I'm very sure that most users are downloading whatever comes by.
I wonder if the same 0xc0000005 occurring in many parts of the world is related to simple and trivial errors like the one I found.
Foreword: since we are developers here, and I suppose that many have active developer background (not scenery/aircraft development, I mean software development) we know that releasing patches on friday is a very bad practice.
It is even more bad practice considering the covid situation. People are locked home and, for many, having a working game becomes a bit more important and, simmetrically, having a not working product is more frustrating than what it should be.
It seems that asobo does not get this and their processes (or lack of) are, to say the least, troubled.
Back on topic.
This morning I posted on the MSFS forum and, intentionally, did not want to reveal my findings because I want this thing to heat up a bit and, like Marko Ramius says at the end of the Hunt for The Red October, a revolution, now and then, is a healthy thing.
The topic went quickly closed because if used a "fock ffo" (intentional typo) and intentionally
circumvented their code of conduit. In my code of conduit releasing a bug on friday is worse and closing a topic for that reason is like making speeding tickets at a F1 race. But that's it.
The first symptom was that the application loading screen freeze:
The loading bar will not progress.
First move, empty the Community folder and, not to my surprise, the application loads perfectly.
Second move, restore sceneries one at a time and, again, application loads perfectly.
Third move, restore liveries. Freeze.
Now the investigation starts then.
First I reviewed, one by one, all liveries (fortunately I don't have many). Some were missing the MODEL folder, like explained here:

For Creators: Patch 1.10.7.0 breaks your Liveries – How to fix it - Flight Simulator 2020 News & Updates - by Flightsim.to
We’re following reports that Microsoft Flight Simulators recent patch – 1.10.7.0 – causes liveries to stop working properly. In most cases, users complain that they cannot select a...
I fix the six offending liveries (two were mine btw,

Next step, go to any airport (without scenery) and start a flight with one of the offending liveries. As soon as the loading process starts => CTD.
Event viewer check:
Faulting application name: FlightSimulator.exe, version: 0.0.0.0, time stamp: 0x5f985799
Faulting module name: FlightSimulator.exe, version: 0.0.0.0, time stamp: 0x5f985799
Exception code: 0xc0000005
Fault offset: 0x000000000058ef54
Faulting process ID: 0x984
Faulting application start time: 0x01d6af64a0575a53
Faulting application path: C:\Program Files\WindowsApps\Microsoft.FlightSimulator_1.10.7.0_x64__8wekyb3d8bbwe\FlightSimulator.exe
Faulting module path: C:\Program Files\WindowsApps\Microsoft.FlightSimulator_1.10.7.0_x64__8wekyb3d8bbwe\FlightSimulator.exe
Report ID: 6c0cd755-3cee-40ba-8d0a-2e86f44b5848
Faulting package full name: Microsoft.FlightSimulator_1.10.7.0_x64__8wekyb3d8bbwe
Faulting package-relative application ID: App
spot on, the same error I had with a payware scenery (Orbx KORS).
reload the sim, go to Profile and Aircraft Hangar. As soon as I select the same airplane with the livery I was using for the flight => CTD
Same error on the w10 events logged again.
Let's check that livery and I find a simple, tiny and trivial error:
This was in a Bonanza livery. So the sim, blindly and without any check (try - catch in Java for me) loads the A320 data in a Bonanza. There you have your exception.[models]
normal=../model/A320_NEO.xml
interior=../model/A320_NEO_INTERIOR.xml
Error code 0xc0000005 is indeed related to memory and who knows what happens. What surprises me is a piece software not robust enough to notify, circumvent and handle such a simple event.
Back to the offending file, I replace A320NEO.xml with the correct Bonanza XML and the plane loads in the hangar, I can fly and the sim appears to be happy.
Now the question is...this means that a simple, tiny and insignificant copy-paste error (what I call CopyPasteException) can lead the entire software stack to a non graceful crash. I'm really astonished.
Especially because the offending file was in the "community" folder which, let's be honest, will be riddled with stuff downloaded from the web.
I have a long history with MSFS (since 4.0) so, over the years, I learned to keep only what needed (and after checking it) but I'm very sure that most users are downloading whatever comes by.
I wonder if the same 0xc0000005 occurring in many parts of the world is related to simple and trivial errors like the one I found.
Last edited: