Chapstick

Test file for possible fix for CTD between Canada/Greenland

Recommended Posts

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. 

  • Like 1

Share this post


Link to post
Help AVSIM continue to serve you!
Please donate today!

Thanks. Happened to me a number of times in a particular area. Fly 6-7 hours then bang! CTD

Share this post


Link to post

I was able to fly CDG - MEM without crashing. My exit point on the track was URTAK. It'll take a few flights before I feel confident that it's fixed but it's promising...

Share this post


Link to post

Just happened to me nearing waypoint Janjo on Canadian shores. What a wasted 5-6 hours!

Share this post


Link to post

I've been using the beta bglmanx module for at least a half dozen N Atlantic / Canada overflights and can verify it avoids the CTD problem.

Share this post


Link to post
Just now, vc10man said:

Just happened to me nearing waypoint Janjo on Canadian shores. What a wasted 5-6 hours!

Using the beta module from the FSDT forum??  What was the exact nature of your event?

Share this post


Link to post

Thanks for the heads up, I didn’t know this had been posted.  Looks like people in that thread are having a good experience which is great, I’ll download it and give it a try once my current flight is done.

Good to see that we were on to something in that previous long thread about this issue.

Share this post


Link to post
1 hour ago, downscc said:

Using the beta module from the FSDT forum??  What was the exact nature of your event?

No, Dan, nothing of that sort, as I had not even heard of that 'beta  module' until I saw this topic while skimming the Atlantic. I was flying a straight PFPX-created Flight Plan and had not even chosen my STAR as I was still a fair bit away. Very quietly,unannounced, P3Dv4 just slipped away, and I do know I was approaching Janjo.That's one of the reasons, I rarely now fly East-West. In the QOTSII 747-8i Lufthansa pax version, Windows 10 pro 64-bit all up-to-date, except for the Nvidia drivers, the latest one that caused me so much grief, hence reverted.

Share this post


Link to post

I've been using it with great results for weeks as well on westbound transatlantic flights.  A word to the wise, keep a copy of the bglmanx64.dll handily backed-up.  If you happen to inadvertently run live update it will rewrite it with the previous version and the issues will return. Umberto intends to include it permanently in his next update but it may take a bit longer yet.     

Share this post


Link to post

This is weird. Re-set the entire flight from AS's EDDF to FT's CYYZ and been a cinch all the way through including the previous Janjo.

Descending right now into a clouded CYYZ, which leads me to think as I had so many windows open with AS,EFB2, etc,etc open, I may have inadvertently shut down P3Dv4. Only logical explanation I can give myself as EventVwr reported zilch.

Share this post


Link to post

From reading on the FSDT forums this fix or what every you want to call it has had positive feedback and has been added to the live updater. 

Share this post


Link to post

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

Share this post


Link to post

I’m thinking about dipping my toes into a trans-Atlantic flight.  Has anybody had any negative experiences with this mod?

Share this post


Link to post

I’ve safely flown westbound over Newfoundland, Labrador etc with no CTD’s since this fix was installed.

Share this post


Link to post
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!

Share this post


Link to post
Posted (edited)
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

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

“Doc, it hurts when I do this.”

”Well, don’t do that.”

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 

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.

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