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!

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 April 2, 20197 yr by tooting

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.

“Doc, it hurts when I do this.”

”Well, don’t do that.”

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 

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.

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!

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.

are the forums down ?