[CLOSED] Keeps crashing at EDDM / No AI on Arrival

[Fragtality]

TC keeps crashing in EDDM, I'd have hoped it would be fixed with SU12/7.1.0. Somewhere during Arrival it crashed, I restarted it on the Ground but it crashed again somewhere during Turn-Around.
Restarted it again after departed from EDDM and on Arrival in EDDF it was still Running but it spawned no AI-Traffic at all.

[Kaiii3]

do you have any other AI traffic running?

[Fragtality]

Nope, same Settings as with SU11:
You cannot view this attachment.
You cannot view this attachment. 

[Kaiii3]

default airport?

[Fragtality]

Nope:
sim-wings EDDM
virtualFra EDDF

[Kaiii3]

test with default airports

[Fragtality]

It is the same with default Scenery, just sitting on the Ground is enough.
(See first Post for new Logbundle)

[heightsmite]

It is the same with default Scenery, just sitting on the Ground is enough.
(See first Post for new Logbundle)

Using tc 0.7.1.0, I'm getting a silent crash to desktop before the scenario finishes loading.  Event viewer shows faulting module as tc clr.dll

After several attempts using the same scenario, It manages to load p3d and launch the flight, but traffic controller quietly quits during the flight.  In this case, the airport was ksea and the a/c was pmdg 739

[Fragtality]

Interestingly it did not crash this Time when flying into EDDM. In fact TC was up whole Session (EDDF>EDDM>EDDF). But EDDF still was completely empty again on Arrival.
Change I did in the mean Time: Reducing the Density from 38 to 34.

[Fragtality]

Next Crash at EDDB or between EDDB and EKCH. With even further reduced Density.
Log and Events attached in the first Post, if anybody cares.

[Jorgen]

I don't know anything about AIG's TC except that it exists.

But I took a look at your Event Viewer screens, and the exception code there (C0000005) is what is called a Memory Access Violation, meaning that "something" attempted to write to an area of RAM where this "something" had no access rights.

There is nothing, however, that shows directly what this "something" is, but in all the cases I have seen on Lockheed-Martin's P3D forums, this has been an incompatible or badly programmed add-on - aircraft or scenery.

You might want to look into that.

Jorgen

[Kaiii3]

Based on the Logs it is looking like an issue with SimConnect ASOBO is already aware of... we donour best on our end to workaround this, but seems there are still some cases...

[Fragtality]

I understand that it can only be as good as the API allows and the current Implementation by Asobo is .. let's say there is much Room for improvement!
But it would still be cool if SimConnect-Quirks don't lead to App-Crashes. I mean .. many of the Addons I use are using SimConnect and even the Stuff I code myself use it - none of these crash at all or at least very very seldomly.
Don't know - maybe safeguarding more SimConnect-Code with Exception-Handling? Maybe a little "WatchDog" Application that automatically restarts TC?
I really love the AIG Stuff and personally think there is nothing like it. But it is not really fun to constantly hope it will still be running by the Time you arrive :/

[Kaiii3]

sadly we can no handle any AccessViolation thrown inside external code.. the "watch-dog"-App is something we have on our todo list, but time is limited and changes in MSFS with influence on AIGTC are taken up most of the time

[Fragtality]

Hmm .. what do you mean with internal Code? I meant Exception-Handling in the TC Code - it is clear that TC can't control or handle Exceptions within Asobos Code 
I'd contribute a WatchDog App if interested

Btw, is the Airport Vehicle Density to 1% in the MSFS Setting still a Thing? Judging from my Flights the Vehicles generated by MSFS due to this Setting increase the likelyhood of having Issues with the SimObject Limit (which in turn generates all Kinds of SimConnect Issues)