Are you using Developer Mode or made changes in it?
Brief description of the issue:
CTD when landing, got a popup saying press cancel to debug. I pressed debug and Visual Studio started. Navigated around there and took some screenshots from within VS, maybe they can help? If I had the symbol file I could tell exactly where it happened but I don’t. Strange name of the missing symbol file: KittyHawkx64 , what the heck is that? Found this: Wright Flyer - Wikipedia
Provide Screenshot(s)/video(s) of the issue encountered:
Detailed steps to reproduce the issue encountered:
Was on short final with the CRJ900 into EKBI, a few hundred feet above ground and aimed for the runway with the autopilot turned off.
Moved to Community Support: CTD-Help. Appears to be sim related based upon file names referenced in VS. Can this be reproduced using stock aircraft?
Since the aircraft involved is a Third-Party (CRJ), it’s also recommended to report this crash to the publisher or the CRJ.
This is most definitely not related to the CRJ. This is one of the most common memory errors the game has been producing since SU9. It’s often repeatable and there are no firm known ways to fix it.
What I did:
-run “scannow” command thru power shell on the system32
-clear cache / paging file
-change the size of virtual memory
-turn off my EFB in flight
I also logged into and out of the MS store and Xbox app and I’m not sure which of these steps may have fixed something but after getting this memory instruction error a few days ago I haven’t gotten it since. I now get the connection lost message quite frequently.
It’s interesting to note that one computer has gotten these memory instruction errors and one computer did not. WTH?
We are anxiously awaiting the patch.
Just seeing the multitude of errors and bugs SU9 introduced thus far, I don’t even want to waste the money on the PMDG 737! This stuff has to get more stable. I’d hate to be the guys who come on here and post about a memory error and CTD minutes before landing after a 7 hour flight.
Hi, I tried the same flight again EDDH-EKBI with the CRJ900 and the scenery for EKBI is bought at the market place. I got the same CDT again at the almost exact same position. The weather was different and it was another time at the day so it is not weather related. The CTD is repeatable!! Adding some screen shots again. It seems to be the main thread that fails, see the threads window.
Ok thanks, I was not aware of that. Ok, this SU9 seams to have created a lot of issues. Don’t they do any regression testing? It should be possible to have automatic tests which flies between a lot of airports.
I have debugged bad code all my life, both my own and others. If MS would provide symbols/source then we as a community would be able to solve several issues they are having.
as mentioned, the issue is here in the Third Party Addon
( or the api was changed in a way that the add-on now cause that )
A modable-game developer can not regression test all existing add-ons. The developer of a third party add-on is responsible here to stay up2date ( at least if she/he is intressted that users buy in future the products too ).
Of course MSFS might have a better error handling ( or should have ) to made it easier to find out “whats wrong”, but it is at the moment as it is…
For me intressting is:
may be reason for some users in the new/big thread about " memory could not be read" have similar cause…
I think they are related somehow as well. I agree that MS can’t possible test all the different add-ons that get released. But, they absolutely can and should build a game that does not CTD like it does when a mod needs to be updated.
The difficult with staying “up-to-date” is that so little detailed information is made available to 3rd Party Developers, when Asobo make SU version changes.
While this information is of little use or interest to the majority of users, there should be much more detailed information, made available to Developers, so they can remain compatible with these Asobo SU changes.
So why is this information not made available. Maybe because Asobo is not adequately keeping tracks changes internally, even be able to determine what they are changing themselves. ?
This could certainly help to explain why these SU updates appear, to those outside of Asobo, to be such causing so much disruption, and regression.
I think jthat the SDK update-process seems to need some optimizations. But I know some games, which are years old, which fight with exactly same challange
Also in these other games you need update to latest version, at least for multiplayer part. And then it is not ensured that all mods will works fine: exception are the official DLC - mods.
And also these games crash after all that years of development. Not so often, but it happens.
So… I think constructive critism is good… but we can not find a solution for “game update process and how mod developers are informed ( at least these in marketplace ) )”
It may be as simple, as just releasing to developers, read ability to the Internal Update Information that Asobo are making to MSFS,.
The level of detail in the currently release Update Information, is all but useless to Developers, and appears to be more something put together by Marketing, to promote that MSFS is being actively updated.
I would expect more like 20+ pages of detailed update info, for it to be of any meaningful use to 3rd party developers.
Mostly Sales Info – very little technical content about what is being changed, and for what is mentioned, little or no meaningful details.
yes… we all ( in special as developers ) know that theory, but we still live in real world with time pressure ( in special created from us, the gamers! ) , strange managed promises to the consumers ( again we ) which cause again pressure, etc. . It’s simple easy to say “should”, but bullet-proof software costs a lot of money and time ( and in special if you want to hire a Test-Team which is usually lot more people as the developer team ).
And in point of “money” we have some users which mean these 69€ for live-time-license is expensive
So yes… you are right… A application which support “plugins” should not crash because of a faulty plugin, but also a “plugin” should not be faulty …
I realy hope the mod developers get more information, eg. within the SDK docu…
Take a look at who Asobo are currently looking to Hire for MSFS (on the Asobo website), and look especially at what the requirements are (or lack of requirements) for anyone being hired for QA or testing. Very telling …
It is also about keeping backward compatibility. That seems to be very hard for MS in this case. Regarding testing, a lot can be done using automated testing. That could increase quality and decrease the need for manual testing if it is done right.
yep… but also here I can only refer to the other similar games on market… A long time backward compatibility is often not given. In best case one release, but very often you get the “red light” for not-compatible till the modder update its mod. Autotests are fine, but is like manuall test a lot of effort to implement that. And dont understand me wrong. I have same wish for stable software, tested, good QA team etc, but I just know what happens if the point “money” plays a role.