Jump to content
Sign in to follow this  
chapstick

Test file for possible fix for CTD between Canada/Greenland

Recommended Posts

4 hours ago, tooting said:

Wowsers... After all those years and that 25 page topic. 

Not to mention the profound statements on the impossibility of it being related to a certain .dll 🤫

Installed it about a week ago and have completed multiple westbound transatlantic flights from EU and UAE with no problems, finally!


Dan Dominik                                                                           

"I thought you said your dog does not bite....
                                                                That's not my dog."

Share this post


Link to post
8 hours ago, sddjd said:

Not to mention the profound statements on the impossibility of it being related to a certain .dll 🤫

Installed it about a week ago and have completed multiple westbound transatlantic flights from EU and UAE with no problems, finally!

I remember the abuse we all got in that thread daring to mention there was corrupted nav data from Lm in the bgls and there was a conflict with gsx.  I think Poppet banned me twice for it (when I said they should help each other out) , one was because they where so busy working on the release of 4.2 and how can I critise them.  Aerosoft style

Edited by tooting

 
 
 
 
14ppkc-6.png
  913456

Share this post


Link to post
9 hours ago, sddjd said:

Not to mention the profound statements on the impossibility of it being related to a certain .dll 🤫

Installed it about a week ago and have completed multiple westbound transatlantic flights from EU and UAE with no problems, finally!

Nothing has changed, and those statements are still 100% valid, which is proven by WHAT the "fixed" .DLL does to solve the problem (not really solve it, it only sidesteps it).

As explained so many times on our forum, and here too, the REAL cause of the problem must lie either in:

- A problem of the default navigation database in that area. Otherwise, why it would only happen *there* ? This is possibly related to having updated the navdata in some way, since to this day, I still cannot reproduce it on a clean install.

- A bug within one of the sim own's api calls in FACILITIES.DLL, which are unable to deal with the issue of wrong/corrupted/unusual data in that area, and it's that .DLL that is crashing the sim.

From our Addon Manager .DLL, we DO NOT try to access the simulator data directly. If we did, maybe we *could* have a way to fix this properly. Instead, we just call a simulator function to get us some data about the nearby airports, and apparently, when flying in that area, this causes the sim to crash by itself , because this function is not able to deal with the problematic data which is found in that area.

It's very likely you would have seen the same kind of crash if you used the default gps trying to look for nearby airports or navaids in that area but, since nobody probably does that (searching for airports while crossing the North Atlantic, and nobody uses the default gps anyway...), you only noticed this when installing GSX, which always looks for nearby airports, in case you need to pre-select a gate in flight which, of course, is a feature that has been added because it was asked by users for a long time.

So, the fix it's just being sure that no calls to the sim are ever made when flying over 10k feet or faster than 250 kts, since it's unlikely you would want to pre-select a gate for landing over 10k feet, so it's not really a solution of the problem, since the problem is there is something wrong with the data in that area and the inability of that sim OWN api to deal with the data corruption, so we are only sidestepping the problem now, but it's not really resolved.

  • Like 4
  • Upvote 2

Share this post


Link to post

You where never ever going to get LM admit there was a problem in one of their DLLS or corrupted data. 

Alas I'm 3 sectors in without the dreaded ctd.  Well done umberto 


 
 
 
 
14ppkc-6.png
  913456

Share this post


Link to post

I have done a lot of testing with a repeatable crash event I get in the area of the Hudson Bay and have come to the conclusion that it is a bug in the LM facilities.dll module.  If it were corrupt facilities data then the error would be precisely the same each time and yet I can change the entry location to the test scenario and the outcome changes.  I have decompiled most of the bgl files in the 0301 area and have not yet found corrupt data.  The one constant feature of this crash event is that it occurs in sparse geographic regions such as Hudson Bay, Labrador, Greenland and even have ran into it in W. China.  I can imagine a scenario within the facilities module where a buffer error occurs only when queried in such locales.


Dan Downs KCRP

Share this post


Link to post
On 2/23/2019 at 7:04 AM, Chapstick said:

So I was on the GSX forum and stumbled across this thread where Umberto posted a test version of bglmanx64.dll to fix the infamous NTDLL crash when approaching Canada from the east (and possibly other locales). I don't think I've seen a thread about it here, so I thought I'd share so we can get more test cases going. I'm eager to try it out on a transatlantic flight as soon as I have a moment today. 

Ive been using it since Umberto released the beta module and I have done 30+ wesbounds over the dreaded CTD region, without any problems. The new bgmlanx64.dll helps avoid the problem entirely. 

 

On 4/2/2019 at 2:44 AM, virtuali said:

Nothing has changed, and those statements are still 100% valid, which is proven by WHAT the "fixed" .DLL does to solve the problem (not really solve it, it only sidesteps it).

As explained so many times on our forum, and here too, the REAL cause of the problem must lie either in:

- A problem of the default navigation database in that area. Otherwise, why it would only happen *there* ? This is possibly related to having updated the navdata in some way, since to this day, I still cannot reproduce it on a clean install.

- A bug within one of the sim own's api calls in FACILITIES.DLL, which are unable to deal with the issue of wrong/corrupted/unusual data in that area, and it's that .DLL that is crashing the sim.

From our Addon Manager .DLL, we DO NOT try to access the simulator data directly. If we did, maybe we *could* have a way to fix this properly. Instead, we just call a simulator function to get us some data about the nearby airports, and apparently, when flying in that area, this causes the sim to crash by itself , because this function is not able to deal with the problematic data which is found in that area.

It's very likely you would have seen the same kind of crash if you used the default gps trying to look for nearby airports or navaids in that area but, since nobody probably does that (searching for airports while crossing the North Atlantic, and nobody uses the default gps anyway...), you only noticed this when installing GSX, which always looks for nearby airports, in case you need to pre-select a gate in flight which, of course, is a feature that has been added because it was asked by users for a long time.

So, the fix it's just being sure that no calls to the sim are ever made when flying over 10k feet or faster than 250 kts, since it's unlikely you would want to pre-select a gate for landing over 10k feet, so it's not really a solution of the problem, since the problem is there is something wrong with the data in that area and the inability of that sim OWN api to deal with the data corruption, so we are only sidestepping the problem now, but it's not really resolved.

Umberto,

I just want to say thank you for taking the time to look into this (although the CTD's were never caused by your own work), and for coming up with a fix/workaround! I personally know half a dozen simmers who have been extremely happy since you released the beta module. Our westbound flights making landfall over Labrador/Canada have been worry free since.

A big THANK YOU!

  • Upvote 1

Share this post


Link to post
14 hours ago, downscc said:

I have done a lot of testing with a repeatable crash event I get in the area of the Hudson Bay and have come to the conclusion that it is a bug in the LM facilities.dll module.  If it were corrupt facilities data then the error would be precisely the same each time and yet I can change the entry location to the test scenario and the outcome changes.  I have decompiled most of the bgl files in the 0301 area and have not yet found corrupt data.  

Yes, that's very likely. Also considering nobody ever heard of this problem with FSX (and I guess with 32 bit version of P3D), and that module changed quite a bit due to switch from ASCII to Unicode that happened with P3D4, which required to change all calls to the interface, in order to deal with Unicode string now used for all the names of the navdata objects.

The data might not be really corrupted, it might just be a result of the updated facilities.dll module not being able to deal with very sparse data, which would explain why it seems to happen mostly in remote areas, maybe some query somewhere goes into panic when no data is there, or maybe it's the result of some optimization.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  
  • Tom Allensworth,
    Founder of AVSIM Online


  • Flight Simulation's Premier Resource!

    AVSIM is a free service to the flight simulation community. AVSIM is staffed completely by volunteers and all funds donated to AVSIM go directly back to supporting the community. Your donation here helps to pay our bandwidth costs, emergency funding, and other general costs that crop up from time to time. Thank you for your support!

    Click here for more information and to see all donations year to date.
×
×
  • Create New...