UCRTBase.dll CTD with P3DV5.1 SODE 1.7.1 and AIGAIM

[mpo910 2,112]

Thanks for your Reply and explaination Jeffrey. It is good bad news;-). 

Regards Marcus

[Dick 47]

9 hours ago, AlanB77L said:

This tallies with what I experienced and reported in your forum: https://sode.12bpilot.ch/?topic=p3dv5-hf2-ctd

The jetway keeps docking at the A321's L2 door, needing me to reset it and send it to L1. This reset causes a CTD every time.

Hi Alan,

You bring some new items into the equation.  As far as I know everybody involved here was using 5.1. and reported the ucrtbase.dll error. I was under the impression that problem was introduced with 5.1. 

You are on 5.0 HF2 and report the SimObjectAnimationModule64.dll as the faulting module. 

I was also surprised to read that on your FSL321 the airbridge autodocks on L2. I never see this behavior. In my case there is always a popup asking a confirmation to connect to door L1. I replayed your scenario ( however you did not mention which gate you used ) but in my case  the airbridge connected straight to L1 and I did not have a CTD.

b rdgs/ Dick

[MachTwo 386]

3 hours ago, Dick said:

I was also surprised to read that on your FSL321 the airbridge autodocks on L2

The A321 IAE variant had L2 listed; which we removed in the latest update. So only L1 is supported now; the user can still add L2 if they wish.

Edited November 3, 2020 by MachTwo

[AlanB77L 0]

36 minutes ago, MachTwo said:

The A321 IAE variant had L2 listed; which we removed in the latest update. So only L1 is supported now; the user can still add L2 if they wish.

I have .115 installed now (still on v5.0 HF2), I've been using the A321 without SODE to avoid the CTD. Not having to undock from L2 and redock to L1 will likely mean I can avoid the CTD.

Interestingly, the above happens after loading into the sim giving me the SimObjectAnimationModule64.dll CTD, but I have the UCRTBase.dll CTD after landing at destination and shortly after jetway activity.

EDIT: I just tested at MK Studios EIDW stand 313 using the SODE auto-dock and it's still going to L2 (A321 CFM).

Edited November 3, 2020 by AlanB77L

[12bPilot 35]

13 hours ago, AlanB77L said:

This tallies with what I experienced and reported in your forum: https://sode.12bpilot.ch/?topic=p3dv5-hf2-ctd

The jetway keeps docking at the A321's L2 door, needing me to reset it and send it to L1. This reset causes a CTD every time.

Hi Alan,

I think this has to do with the "manual intervention" into an automatic docking process. I see you have "Aircraft state triggered auto-docking" activated. This setting - intended for home-cockpit users which do not want to use keyboard commands - is not designed to be used together with manual docking. This could potentially lead to "double-triggering" and this can cause crashes in the jetway animation (SimObjectAnimationModule.dll).

So if you want to have total control over the jetway-to-door assigment, don't rely on the auto-dock feature (disable it in the SODEPlatformManager -> Tools -> Settings) and assign the jetways manually using SODE's or GSX's menu.

[AlanB77L 0]

3 minutes ago, 12bPilot said:

Hi Alan,

I think this has to do with the "manual intervention" into an automatic docking process. I see you have "Aircraft state triggered auto-docking" activated. This setting - intended for home-cockpit users which do not want to use keyboard commands - is not designed to be used together with manual docking. This could potentially lead to "double-triggering" and this can cause crashes in the jetway animation (SimObjectAnimationModule.dll).

So if you want to have total control over the jetway-to-door assigment, don't rely on the auto-dock feature (disable it in the SODEPlatformManager -> Tools -> Settings) and assign the jetways manually using SODE's or GSX's menu.

Hi Jeffrey,

Thanks, I see I have it set to false now, I assumed it needed to be turned on for GSX/FSLabs integration. I suppose I'll now get the door selection when triggered and the auto-dock (from the SODE menu) still going to L2 is an FSLabs issue.

[MachTwo 386]

Just now, AlanB77L said:

Thanks, I see I have it set to false now, I assumed it needed to be turned on for GSX/FSLabs integration. I suppose I'll now get the door selection when triggered and the auto-dock (from the SODE menu) still going to L2 is an FSLabs issue.

It should be false when using our titles - as documented in our manual (there's a page on recommended GSX settings). 

The L2 issue was resolved in our latest release (116b) - that should resolve the issue for you.

[AlanB77L 0]

4 minutes ago, MachTwo said:

It should be false when using our titles - as documented in our manual (there's a page on recommended GSX settings). 

The L2 issue was resolved in our latest release (116b) - that should resolve the issue for you.

Thanks Andrew, I didn't find any SODE settings in the manual.

I will update to 116b, I was holding off on that because I didn't realise there had been any changes apart from 5.1 compatibility and I have no plans to update to 5.1 until ActiveSky is available.

[pmemery 4]

Hi Jeffrey,

If that can help, in my case I am flying P3D V5.1 with SODE enabled. No GSX , no autodocking system, nothing else that some sceneries from Aerosoft.

I reproduced the problem while at LFMN (where I added moving jetways using SODE placement tool).

I was just watching a departing flight, the jetway started to move away from the aircraft and completely retracted to the point where SODE replaces it with the static jetway and then CTD ... 

[pmemery 4]

and here below are the last lines from the SODE log file (the log file is in debug mode) :

[11:07:51.150] INFO SODE.FSLOOP : [JETWAY CONTROL SYSTEM:AI] Jetway undocked but AI pushed back or vanished during movement! Trying to swap to static model...
[11:07:51.150] INFO SODE.FSLOOP :  - SimObject 'PhM_LFMN:Jetway 1 GATE_A 40' [Taxi2Gate_LFPG_Jetway_S3]. ID: 350
[11:07:51.181] INFO SODE.FSLOOP :  + SimObject 'PhM_LFMN:Jetway 1 GATE_A 40' [Taxi2Gate_LFPG_Jetway_S3_Static_0]. ID: 489
[11:08:00.773] FATAL SODE.WATCHDOG : Sim Process running test failed!
[11:08:00.787] DEBUG SODE.FSPROCESS : Cleaning up Memory...
[11:08:00.794] DEBUG SODE.FSPROCESS : Removing Top-Menu structure...
[11:08:00.794] DEBUG SODE.FSPROCESS : Closing Connection to FS.
[11:08:00.896] INFO  : Terminate SODE.

[12bPilot 35]

1 hour ago, pmemery said:

Hi Jeffrey,

If that can help, in my case I am flying P3D V5.1 with SODE enabled. No GSX , no autodocking system, nothing else that some sceneries from Aerosoft.

I reproduced the problem while at LFMN (where I added moving jetways using SODE placement tool).

I was just watching a departing flight, the jetway started to move away from the aircraft and completely retracted to the point where SODE replaces it with the static jetway and then CTD ... 

Thanks.

Yesterday, I was able to narrow down the cause for the CTD, it has to do how SimConnect within Prepar3D v5.1 handles a removal of a specific type of object, for example when SODE removes/replaces a jetway.

Reported this to LM, waiting for their results.

Edited November 4, 2020 by 12bPilot

[BerndB 349]

30 minutes ago, 12bPilot said:

it has to do how SimConnect within Prepar3D v5.1 handles a removal of a specific type of object, for example when SODE removes/replaces a jetway.

Reported this to LM, waiting for their results.

I´ am wondering why they think that a CTD is allways the only best way to handle any exception handling....😜

Being serious, i have had already the suspicion that these increasing number of possible CTD, because of UCRT..., VBruntime....kernelbase..dll something violation could be also related to the ongoing development of the OS Windows 10. Because MS has restricted their coreaplication more and more for safetyreasons, it´s quite possible that those kind of abonded "backdoor-access-tools" like SimConnect are causing trouble, while using codes which would denied for the way they try to access corerouitines of Windows. Not generally but under specific correlations they now produce and exception handling which was not in the past. Especially that seemingly Windows OS core libraries like the kernel.dll is involved this is very likely more and more a Windows compatibiltiy issue. May the devs have to take this into account and i would be very corious how people like Pete Dawson would think about it. Maybe he had already some flaws which forced him to handle some codes of FSUIPC in a different way to be "in line" with windows security rules.

Edited November 4, 2020 by BerndB

[LarsA 90]

Thanks for the update, Jeffrey! Hope, you can solve it! 

[12bPilot 35]

Got news for you:

V5.1 added a new feature called „Adaptive Simulation Group“, mainly intended to reduce visual jittering when flying in close formation with other traffic (multiplayer or AI).

Due to the way SODE works internally (it basically injects AI objects...), Prepar3D picked them up into that new simulation group and when SODE tried to remove the injected object, the sim crashed. This is going to be fixed within Prepar3D.

Until then, there is a workaround (hoping you don‘t do much close formation flying), courtesy of P3Ds dev team: You can disable this new adaptive simulation group system in the Prepar3D.cfg

Quote

[SIM]

AdaptiveSimGroupEnable=False

Let me know if this fixes those CTDs.

Edited November 4, 2020 by 12bPilot

[Dick 47]

Yes !  I tried the EKCH/gate 14 boarding/pushback scenario that earlier would give me 100% CTD but  with the added lines to the CFG it went without CTD. 

Will do some more flying tomorrow but the first test from my side went ok

Thank you all !

b rdgs / Dick