Asobo/MSFS need to fix the code base…

[RobJC 2,069]

1 minute ago, Noel said:

Of note, I do have LOD set to 300, and really should change that to 400, and this affects VRAM in use for sure.

Yeah that would make a difference. I have tried 300 and 350 but didn't care for how the sim felt. Besides, when the serious aircraft show up I would probably have to set it back down to 200 anyway. 

[Noel 4,486]

6 hours ago, RobJC said:

Maybe RTSS and MSFS dev mode use different calcs, but not sure

About 1.2-1.5Gb lower on VRAM and SysRAM is reported thru the Dev Mode viewer compared to RTSS.  So when I just TO from KJFK VRAM was reported at 7.5Gb or so via Dev Mode reader, and right at 9Gb via RTSS.

Edited September 21, 2021 by Noel

[FrankPilot 123]

7 hours ago, fogboundturtle said:

your experience is anecdotal at best. My experience comes from helping thousands of users on the official MSFS Discord every day. 

 

That being said, it doesn't meant there isn't code issue with MSFS that causes CTDs. They are not as widespread at people seem to think.  This is my point. Easy to point the finger at Asobo compare to looking at your PC configuration. I had CTDs in KBOS once. I have no mods in KBOS whatsoever. I was pulling my hair out. Turns out a mods with really bad LOD in Catalina , CA was responsible for the CTD in Boston.  Liveries is also a big contribution to CTDs. It happens all the time. You get that OxC0000005 memory access violation error. It could also be a third party software like Capture One or AVAST messing things up.  I hope you are getting my point. This threads is starting accusing Asobo left and right where the proper troubleshooting wasn't performed.  I see this everyday in the MSFS discord.  They start claiming Asobo is the worst dev in the world turns out it had nothing to do with it. 

Sounds about right to me from someone who is at the frontline.  Cheers.

[Dominique_K 10,133]

12 hours ago, pmb said:

I agree to @fogboundturtle. I have rarely CTDs but could trace all of them, up to perhaps a couple of them since release, to mods, mostly freeware, which by itself or together with others are CTDing. I use the scenery linker and usually work to isolate the poisoned addon(s) which, however, costs me 1-2 hrs every time and isn't really fun.

That's probably not the only cause but an important one.

Kind regards, Michael 

I had two CTD in my sim, both provoked my me. One twiddling too much with the known flawed default avionics, one with an USB connection.  I have never had out of the blue CTD. So far...

At that stage, one year after release 

1/ every reasonable person would say that, except for the default avionics, CTD massively  come from addons, incompatibility with drivers including USB or hardware configuration.

2/ that being put out of the way, the Asobo code is faulty in translating these incompatibilities into CTD. Typical is a livery. Why the sim should go back to the desktop instead of ignoring it ? Same for a 3D models ? 

3/ and as the code is unable to catch the incompatibility before the crash, it cannot give any useable message.

The OP request to Asobo for fixing the base code doesn’t seem to me outrageous.

Now I see the members of The World Fraternity of Developers (Avsim Local Branch) coming after me 😄. No I am not a coder, just an old gamer and simmer who have seen and played many, many games and flight simulators ! 

[Moria15 950]

3 hours ago, Dominique_K said:

2/ that being put out of the way, the Asobo code is faulty in translating these incompatibilities into CTD. Typical is a livery. Why the sim should go back to the desktop instead of ignoring it ? Same for a 3D models ? 

3/ and as the code is unable to catch the incompatibility before the crash, it cannot give any useable message.

 

As a developer, (although not a member of the fraternity mentioned above 🙂  ) I can tell you that CTD's are generated by Windows 99.9% of the time.  ( Null pointers typically make up the rest)

Since it is windows terminating, there is pretty much no way that Asobo can intercept it to do anything with it gracefully.  Example.. on your liveries..  If Asobo tried the livery before putting it on your aircraft.. windows would still CTD.  You could spend a lot of time in the program finding a way to examine the livery and test it, but it would have to be done real time, each time  and have a default replacement livery and guess what..  then you would have stutters and people complaining about stutters and it not being the livery they selected.

This situation becomes worse when you have multiple threads running, because now a CTD can come from any thread.

If windows blows your program out, it's gone before the application can do anything about it.  The wiindows crash log will tell you (and it does) what program it was executing (and where it was in that program) when the CTD happens, but the program itself is being controlled by windows, not the other way around.  This is why every CTD should be Zendesked with the full windows error log so it can be located to see if there is anything Asobo could add to prevent it  (unlikely).

The only way you could exit gracefully (in most cases) is to take your program away from windows and run it in your own operating system, and thats a non-starter these days with the complexity of these things.

I will make a prophecy however...  when DX12 is introduced..  we are going to see a huge number of CTD's from people who don't have DX12 set-up properly on their machine, as this is another new high level wrapper which has even less protection in it than DX11  and that will also be a windows issue not an Asobo one.

Graham

Edited September 21, 2021 by Moria15

[Dominique_K 10,133]

1 hour ago, Moria15 said:

 t CTD's are generated by Windows 99.9% of the time.  

Since it is windows terminating, there is pretty much no way that Asobo can intercept it to do anything with it gracefully.  Example.. on your liveries..  If Asobo tried the livery before putting it on your aircraft.. windows would still CTD.  You could spend a lot of time in the program finding a way to examine the livery and test it, but it would have to be done real time, each time  and have a default replacement livery and guess what..  

 

Thank you Graham, appreciated your post.  

Let me stay in my role of a naive gamer. In a way, don't you circle the issue back to the beginning. If I start from the premise that Windows is not treating MSFS in another way than another game, wouldn't be too fast a conclusion to say that the issue is indeed with a defective Asobo's code upstream of Windows ?

I took liveries as an example as we all suspect that liveries play a not insignificant role in CTD. Why in MSFS and not in P3D ? I have done liveries in the past, I have used liveries made by others. I don't remember any CTD. The worst is that the livery does not show up.

Another example, I can take my headset cable in and out the computer without crashing  games except MFS which or crashes or freezes for half a minute 

Third example. I play Empyrion parallel to MFS. Every so often, the game does a Return To Desktop without crashing. I have just to click back the icon in the taskbar to be back exactly where I was.

Edited September 21, 2021 by Dominique_K

[RobJC 2,069]

Let’s just say that on my PC only one piece of software generates CTDs. Only one crashes with my TrackIR. None of the games, sims or other software i run crashes with the exception of MSFS. My system is not heavily under load either.

The code needs serious attention. It’s not my Windows install or my drivers. It’s not my hardware. My CTDs started after Asobo updated MSFS with more threading. 

[fogboundturtle 2,708]

55 minutes ago, RobJC said:

Let’s just say that on my PC only one piece of software generates CTDs. Only one crashes with my TrackIR. None of the games, sims or other software i run crashes with the exception of MSFS. My system is not heavily under load either.

The code needs serious attention. It’s not my Windows install or my drivers. It’s not my hardware. My CTDs started after Asobo updated MSFS with more threading. 

that means your PC can't handle more threading. Fix that first. 

[RobJC 2,069]

30 minutes ago, fogboundturtle said:

that means your PC can't handle more threading. Fix that first. 

Yeah, right. 

[mrueedi 702]

2 hours ago, RobJC said:

The code needs serious attention.

What do you think a software company is doing all day long? That code has all their attention.

Here are a couple of things, you impossibly can't determine based on the experience on your machine:

- Overall condition of the codebase
- State of Asobo's quality assurance
- Whether there are "fundamental problems with how the code base is being managed"

Why?

1. Because only they know how often CTDs happen. Rest assured, they know very precisely the ratio between CTDs and uncrashed sim sessions, the ratio of affected users vs unaffected users and so on. That alone is the most important input parameter to priorize issues. I can understand, that you are annoyed being plagued with CTDs but whether you are experiencing a very rare cause or whether your issue is widespread, you and I dont know. Only they know.

2. Because these things are relative. While it would be embarrassing, if the Windows calculator would crash all the time, MSFS is so much more complex, depends on so much more complex hardware interactions, has so much more function points (the sum of capabilities) that a certain amount of even nasty issues like CTDs is actually expected. And whether the threshold that triggers repriorization on Aosbos end is overshot or not, you and I again dont know.

3. Because you can't judge the root cause of the bugs that happen on your machine. It could be an OS issue, it could be something which requires one line of code to be changed (this is very typical and does not give any clue that the codebase would not be sound) or a systematic weakness indeed. Any of these things could be the root cause. But you and I can't tell which one.

[RobJC 2,069]

42 minutes ago, mrueedi said:

What do you think a software company is doing all day long? That code has all their attention.

Here are a couple of things, you impossibly can't determine based on the experience on your machine:

- Overall condition of the codebase
- State of Asobo's quality assurance
- Whether there are "fundamental problems with how the code base is being managed"

Why?

1. Because only they know how often CTDs happen. Rest assured, they know very precisely the ratio between CTDs and uncrashed sim sessions, the ratio of affected users vs unaffected users and so on. That alone is the most important input parameter to priorize issues. I can understand, that you are annoyed being plagued with CTDs but whether you are experiencing a very rare cause or whether your issue is widespread, you and I dont know. Only they know.

2. Because these things are relative. While it would be embarrassing, if the Windows calculator would crash all the time, MSFS is so much more complex, depends on so much more complex hardware interactions, has so much more function points (the sum of capabilities) that a certain amount of even nasty issues like CTDs is actually expected. And whether the threshold that triggers repriorization on Aosbos end is overshot or not, you and I again dont know.

3. Because you can't judge the root cause of the bugs that happen on your machine. It could be an OS issue, it could be something which requires one line of code to be changed (this is very typical and does not give any clue that the codebase would not be sound) or a systematic weakness indeed. Any of these things could be the root cause. But you and I can't tell which one.

I have lost count of the number of bugs that appeared after working initially, then got fixed, broken again and then fixed again. If you have ever done any serious programming in your life you already know this speaks to a problem related to how the code is being managed, or how the code is structured. 

Are you a programmer? Because i am. 

[MrBitstFlyer 3,820]

22 hours ago, fogboundturtle said:

your experience is anecdotal at best. My experience comes from helping thousands of users on the official MSFS Discord every day. 

 

That being said, it doesn't meant there isn't code issue with MSFS that causes CTDs. They are not as widespread at people seem to think.  This is my point. Easy to point the finger at Asobo compare to looking at your PC configuration. I had CTDs in KBOS once. I have no mods in KBOS whatsoever. I was pulling my hair out. Turns out a mods with really bad LOD in Catalina , CA was responsible for the CTD in Boston.  Liveries is also a big contribution to CTDs. It happens all the time. You get that OxC0000005 memory access violation error. It could also be a third party software like Capture One or AVAST messing things up.  I hope you are getting my point. This threads is starting accusing Asobo left and right where the proper troubleshooting wasn't performed.  I see this everyday in the MSFS discord.  They start claiming Asobo is the worst dev in the world turns out it had nothing to do with it. 

I can agree with your second paragraph almost entirely, but my experience is factual.  Every flight MSFS would crash at some point. MS released an update that Included CTD fixes. From that update my MSFS hasn't crashed once.  Obviously MS discovered something in the code that either caused the crashes or didn't trap errors.

When testing my community folder was emptied.  Prior to SU5 no crashes.  None of my other games or XP 11 crashed for the reasons you mentioned. I'm not sure how this is anecdotal evidence

MSFS is only a year old, so I fully expect periods of crashes and bug fixes.

[Spam3d 54]

23 hours ago, RobJC said:

I am running under-clocked for heat reasons.  

Oh that's interesting, definitely not OC then!

22 hours ago, 40track said:

Yup went to 4.7 from 5.3 achieved via disabling turbo boost but setting multiplier @47 Do this with good a good cooler. This stopped even P3D from throwing a CTD every 3 minutes. 11900k. Maybe CPU or MOBO not taking it. Not only that the joystick fixed itself after downclocking. Think Its a silicon lottery thing to achieve these awesome numbers. 

I have some decent cooling, my 3600x runs at 28c~ the RTX 3080 Gaming X trio on the other hand, its piping at 70+ haha, but its always the CPU clock that get it, just cant run it much above a minimal clock in Fs2020, or all sorts of funky things happen.

[40track 80]

2 hours ago, Spam3d said:

Oh that's interesting, definitely not OC then!

I have some decent cooling, my 3600x runs at 28c~ the RTX 3080 Gaming X trio on the other hand, its piping at 70+ haha, but its always the CPU clock that get it, just cant run it much above a minimal clock in Fs2020, or all sorts of funky things happen.

Yeah that's normal for a GPU. Impressive CPU temps tho. 11700k Noctua twin fan 67c ~ and getting close to thermal throttling. Better than my RTX 3060 12 gig any day. Yeah weve got a hot house here even in winter then all sorts of crazy CTDs happen beyond 3.6/4.7ghz. 5.3~ W11 dev OS just drops its stuff and says NOPE. Running P3D its stable but MS2020 is a work in progress on top of temps and background apps/ left over files on top of less than sturdy motherboards (Asrock) maybe. PCs so complex that now its getting to a ghost in the machine issue too.

Edited September 21, 2021 by 40track

[MattNischan 3,778]

6 hours ago, mrueedi said:

What do you think a software company is doing all day long? That code has all their attention.

Here are a couple of things, you impossibly can't determine based on the experience on your machine:

- Overall condition of the codebase
- State of Asobo's quality assurance
- Whether there are "fundamental problems with how the code base is being managed"

Why?

1. Because only they know how often CTDs happen. Rest assured, they know very precisely the ratio between CTDs and uncrashed sim sessions, the ratio of affected users vs unaffected users and so on. That alone is the most important input parameter to priorize issues. I can understand, that you are annoyed being plagued with CTDs but whether you are experiencing a very rare cause or whether your issue is widespread, you and I dont know. Only they know.

2. Because these things are relative. While it would be embarrassing, if the Windows calculator would crash all the time, MSFS is so much more complex, depends on so much more complex hardware interactions, has so much more function points (the sum of capabilities) that a certain amount of even nasty issues like CTDs is actually expected. And whether the threshold that triggers repriorization on Aosbos end is overshot or not, you and I again dont know.

3. Because you can't judge the root cause of the bugs that happen on your machine. It could be an OS issue, it could be something which requires one line of code to be changed (this is very typical and does not give any clue that the codebase would not be sound) or a systematic weakness indeed. Any of these things could be the root cause. But you and I can't tell which one.

This is one of the best replies to this topic that has ever existed on these types of topics.

-Matt