Hello Umberto, i appreciate your answer.I think you did misunderstood my initial post or didn't properly read it as you are writing about a different topic. In my Event Log, i never have 2 crashes after each other.
Yes, that wasn't entirely clear. I edited your post because we prefer not posting inline images, as a curtsey to users with a metered/paid connection, not forcing them to download an image automatically. That's why have these suggestions in the Screenshot posting rules.
Its either GSX crashing without causing FS2020 to crash (not a real Problem but still not speaking for stability)
Of course. GSX cannot crash the sim.
No external app can do that, this is not really opened to discussion, unless you decide not to trust my insurance the Couatl engine IS a 100% user-level executable that doesn't have any privileged access to the simulator own memory, because it doesn't attach itself to the sim as a debugger, which would be the only possible way it could do that, and it could work only if you explicitly launched MSFS in DevMode with a specific command line switch to *disable* the check the simulator does to block these applications (this is part of the MSFS DRM as well)
About the overall stability, it depends what kind of GSX-specific crash you looking at, and in both cases stability won't be affected because:
- If it's a "crash" (not really a crash, more like an handled error ) that comes with a Couatl.ERR log or something displayed as an error in the Couatl.log which would cause GSX to Stop, this is 100% completely harmless, because there wasn't any crash to begin with. It was just a *bug* of the Python sandbox, which was correctly reported as such and logged, and nothing happening inside the Python sandbox can possibly affect the stability of the system.
- If it's a real crash that results in Couatl64_msfs.exe generate an Event, while this might sound more serious, it's *usually* harmless, because what is usually causing this, is an abrupt quit without being able to reclaim the memory allocated internally. However, the Windows OS will do that anyway so, the only possible problems I see is you are getting too many of these in the same session, and you are short on RAM, it *might* cause memory fragmentation over time.
or it's the Game crashing without generating an Event for Couatl (my main Problem) for a reason unknown to me even tho GSX was loaded and used. This 2nd Problem doesnt occur with GSX uninstalled. I posted 2 of these Event Logs in my initial Post as a Picture. Please take a look at it.
If you don't see any event for Couatl in the Windows even log, it's even more definite proof GSX couldn't possibly be the cause. What is more likely to be happening, it's a bug in one of the Simconnect API calls IN THE SIM, which are required by GSX to work. The most likely cause might be the Navdata API, because it's the newest addition, and there aren't many other add-ons ( if any ) using it.
And that's precisely why you are assuming GSX is the "cause", because it doesn't happen without GSX. The cause here is a possible bug in the Navdata API, which is only triggered by GSX, but that's just because it might be the only add-on using it. Of course, GSX cannot possibly work without it, unless you revert to the legacy Airport Cache method, which will prevent GSX from working on Marketplace airports, so we don't use it anymore after SU12.
If your crash happened while in Flight, when GSX is not doing much *except* calling the Navdata regularly, to present you a list of the nearby airports. if you don't need that feature, you might find easier to close the GSX Toolbar menu when in Flight, or even Quit the Couatl engine after take-off, and Restart it before landing.
If that fixes your problem, you can be fairly sure the crash happened because of a problem of the Navdata API (possibly even a problem with the data itself, like corrupted/illegal names for airports or navaids) so, again, it's NOT a problem "caused" by GSX, it's a problem the simulator has, and would happen with any other add-on that would make use of the Navdata API.
As i posted earlier, that's not the case for me.
Fair enough, so your crashes are likely issues with the Navdata API, not GSX.
You can try, as a test, to re-enabled the legacy "airport cache" method, by editing this file:
%APPDATA%\Virtuali\Couatl_MSFS.INI
and set this line:
useAirportCache=1 ( by default it's 0 )
This will use the old method of reading .BGL instead of the Navdata API. However, I'm not 100% sure if the Navdata won't ever touched again during flight.
Or, as I've said, you could just exit Couatl after takeoff and restart it before landing. It has been designed to be used like this, that's why there's a Try bar icon with options like "Restart" and "Quit" and an icon on the Desktop to start it manually.
I worked in the Field of QA for some Months, and in general if a Product is installed and a certain type of error occurs that doesn't occur with the Product not installed/disabled, it is highly likely that the Problem is caused by the Product itself and the Problem should be searched there and not somewhere else primarily.
It shows you worked for "some months". Any experienced IT would tell you this approach it's only useful as a general troubleshooting strategy to see what the problem is about, but it's just a starting point. It won't tell exactly what is the REAL cause.
I'll repeat it again, starting from the assumption an external .EXE CANNOT CRASH ANOTHER .EXE ( I'm being generic on purpose, because MSFS and its own add-ons are not an exception to this general rule ) UNLESS it attaches to it as a Debugger, and this is not something opened to discussion, if you take this into account, and add it to the other observation "it doesn't happen without GSX", then the only possible explanation left is, the simulator has issues with Simconnect that needs to be fixed, and you cannot possibly blame GSX for using what is 100% fully documented and, it's *required* by GSX to work properly.
And it's not as if I'm making this up: it has been fully documented and it's a very well known problem, even without GSX, that there are several cases of Simconnect completely breaking up (and Simconnect IS part of the sim, it CAN crash it), when the number of maximum objects (documented as 1000) has been reached. This usually starts with objects randomly disappearing, it degenerates into very low fps for a brief time, and it might even lead to a crash of the sim.
Again, it's probably *easier* to reach the limit if you are on big airport, with lots of AI and with GSX passengers, and you can be easily MISLED (again) assuming "it's GSX because it doesn't happen after I removed it", but in that case the fix would be removing ANY of the other add-ons as well, since each and every add-on contributes to the number of objects in the scene, so you just can't say one is more responsible than the other.
Therefore, saying "It works for the majority of Users, why shouldn't it work for you?" is leading to nowhere at this point.
That's not very different than your apparently "reasonable" assumption that, if you remove GSX it doesn't happen, so it must be a GSX problem, isn't it ?
If you need any further information like a GSX Log let me know, iam happy to find the cause of the Problem.
There's no need to provide anything, just try the two solution I listed because, since GSX cannot crash the sim, and if the sim crashes because we made a perfectly legal and documented Simconnect API call we NEED, there's just nothing we can do about it, it must be fixed by Asobo, the only things you might do to mitigate the problem would be those I listed before.
