P3D 4.1 CTD near Labrador

[nazethc 73]

And your conclusion will still be COUATL.  But thanks for dismissing everyone else's findings.  

[virtuali 4,421]

On 5/15/2018 at 7:24 PM, tooting said:

I honestly think we will ever get it fixed so long as both Umberto and LM can put their hands up and say 'not my problem', and both of them don't want to devote a large amount of time towards it.  Therefore you are left with the issue. Liability in action. Neither will admit to the issue

Sorry for not having noticed this thread but, of course, this issue has been discussed on our forum too and, I obviously asked some locations where this crash occurs (I initially asked for it months ago, but nobody was ever able to say anything more precise than "north east canada", which makes a bit difficult to test...), but finally last week an user was able to provide me with 4 precise lat/lon coordinates where his crash happened.

I flew to all 4 spots, but I couldn't find any issue. No crashes whatsoever.

As discussed on our forum, it's quite easily why one can be easily mislead "it's Couatl", because it doesn't happen when its disable but this, of course, it's not enough to indicate the problem is *caused* by it. It's only TRIGGERED by it, which is a big difference.

First of all, it's surely NOT Couatl because, Couatl cannot possibly cause a CTD, since it's an external exe, so it simply cannot access ANY of the simulator data directly. So, why the problem seems to disappear with Couatl disabled ? Because GSX, through Couatl, is asking the Addon Manager to ask the sim to provide data for nearby airports/navaids, in order to present users with a list of nearby airports, so you are able to pre-select a gate while flying. This request is not made by Simconnect, but uses the more direct and fps friendly Panels interface so, it goes like this:

GSX->Couatl->Addon Manager->Panels interface

GSX is just a Python script and Couatl is an .exe so, they cannot possibly access the Panels interface, so they must ask the Addon Manager to do that.

My theory is that is possible that somewhere in that area, there's some bad data, like an airport/navaid with a faulty name so, the one crashing is the SIM ITSELF, because we asked it to provide some data that has a problem. And in fact, all reports points to crashes in NTDLL.DLL, which is a general memory allocation service, and crashes in it are usually related to reading corrupted data.

That's what I meant with Couatl not being the cause, but it might be the *trigger*.
 

Even an airplane gauge, or an utility trying to read the same data using the same method might have caused the same issue.

That interface has changed quite a bit from FSX to P3D4: now it's entirely in Unicode (allowing for better support of international names) so MAYBE, it's possible there's some unknown issue in it, which cause issues in that area because of an unusual or possibly corrupted name there.

And, it's possible the bad data is not present in the default scenery, but it came with an addon  that added either airports or navaids in that area.

[Boeing or not going 578]

1 hour ago, virtuali said:

Sorry for not having noticed this thread but, of course, this issue has been discussed on our forum too and, I obviously asked some locations where this crash occurs (I initially asked for it months ago, but nobody was ever able to say anything more precise than "north east canada", which makes a bit difficult to test...), but finally last week an user was able to provide me with 4 precise lat/lon coordinates where his crash happened.

I flew to all 4 spots, but I couldn't find any issue. No crashes whatsoever.

As discussed on our forum, it's quite easily why one can be easily mislead "it's Couatl", because it doesn't happen when its disable but this, of course, it's not enough to indicate the problem is *caused* by it. It's only TRIGGERED by it, which is a big difference.

First of all, it's surely NOT Couatl because, Couatl cannot possibly cause a CTD, since it's an external exe, so it simply cannot access ANY of the simulator data directly. So, why the problem seems to disappear with Couatl disabled ? Because GSX, through Couatl, is asking the Addon Manager to ask the sim to provide data for nearby airports/navaids, in order to present users with a list of nearby airports, so you are able to pre-select a gate while flying. This request is not made by Simconnect, but uses the more direct and fps friendly Panels interface so, it goes like this:

GSX->Couatl->Addon Manager->Panels interface

GSX is just a Python script and Couatl is an .exe so, they cannot possibly access the Panels interface, so they must ask the Addon Manager to do that.

My theory is that is possible that somewhere in that area, there's some bad data, like an airport/navaid with a faulty name so, the one crashing is the SIM ITSELF, because we asked it to provide some data that has a problem. And in fact, all reports points to crashes in NTDLL.DLL, which is a general memory allocation service, and crashes in it are usually related to reading corrupted data.

That's what I meant with Couatl not being the cause, but it might be the *trigger*.
 

Even an airplane gauge, or an utility trying to read the same data using the same method might have caused the same issue.

That interface has changed quite a bit from FSX to P3D4: now it's entirely in Unicode (allowing for better support of international names) so MAYBE, it's possible there's some unknown issue in it, which cause issues in that area because of an unusual or possibly corrupted name there.

And, it's possible the bad data is not present in the default scenery, but it came with an addon  that added either airports or navaids in that area.

The flights that CTD silently or "an error has occured" all come from European airports. Flying real routes to America or Canada. I'll look for flight plans once I am home. Around the area of the first airway off the NATs. north and south from near CYYT to more north close to CYYR.

[PWJT8D 446]

2 hours ago, virtuali said:

...My theory is that is possible that somewhere in that area, there's some bad data, like an airport/navaid with a faulty name so, the one crashing is the SIM ITSELF, because we asked it to provide some data that has a problem. And in fact, all reports points to crashes in NTDLL.DLL, which is a general memory allocation service, and crashes in it are usually related to reading corrupted data.

That's what I meant with Couatl not being the cause, but it might be the *trigger*.

Thank you very much for that insight. I think we can all understand a lot better of what is going on behind the scenes as to what could also be causing this. Myself personally, I've had crashes with couatl running, and not running. So for me, it ruled that out as being the culprit, others may think differently but for my own tests, it did nothing. It really seems to be a flip of the coin if I'm going to get a ntdll crash or not.

To talk about your theory about some bad data or navaid, this is something that has crossed my mind also. Crashes all seem to happen along the Gander Oceanic Line. And right at this line is where most of the NAT Tracks end and you enter airways into North America. Most of us all use real world routes. When I copy a route from SimBrief, it gets loaded into my Active Sky. And then from there, that route again gets loaded into my P3D flight plan. Could be possible that these up to date AIRAC routes are not playing nice with an older nav database that is within P3D? Maybe something along that coast is not correct or the sim can't find it and it crashes. Something to think about.

I also agree with maybe the sim just spent the last 5 hours loading no airports, nothing but water, and then all of a sudden a huge scenery load hits the sim along with hundreds of airports and then crash. I will post this again because the link was broken, but here was the locations of everyone's crashes, that I posted on page 14 of this thread.

https://photos.app.goo.gl/THAHXL58CKBxTgd82

[chapstick 2,757]

So it sounds like only LM can fix this issue if it’s some glitch in the scenery that has to be identified. Honestly, I doubt this will ever get fixed. They haven’t even patched the blatant and atrocious SimConnect window bug months after they broke it in the first place. 

[Boeing or not going 578]

16 hours ago, virtuali said:

Sorry for not having noticed this thread but, of course, this issue has been discussed on our forum too and, I obviously asked some locations where this crash occurs (I initially asked for it months ago, but nobody was ever able to say anything more precise than "north east canada", which makes a bit difficult to test...), but finally last week an user was able to provide me with 4 precise lat/lon coordinates where his crash happened.

I flew to all 4 spots, but I couldn't find any issue. No crashes whatsoever.

 

The route I took last, did not get to YWK

 

DENUT UL610 LAM UL10 BPK UN601 LESTA UP6
TUMTI/N0482F320 UP6 RODOL UM65 TENSO L603 REMSI DCT MIMKU/M083F320
DCT BILTO DCT 58N020W 60N030W 60N040W 59N050W DCT BOKTO/N0480F320
DCT YWK RJ DCT YMX DCT SYR

Edited May 18, 2018 by Boeing or not going

[Boeing or not going 578]

13 hours ago, PWJT8D said:

Thank you very much for that insight. I think we can all understand a lot better of what is going on behind the scenes as to what could also be causing this. Myself personally, I've had crashes with couatl running, and not running. So for me, it ruled that out as being the culprit, others may think differently but for my own tests, it did nothing. It really seems to be a flip of the coin if I'm going to get a ntdll crash or not.

To talk about your theory about some bad data or navaid, this is something that has crossed my mind also. Crashes all seem to happen along the Gander Oceanic Line. And right at this line is where most of the NAT Tracks end and you enter airways into North America. Most of us all use real world routes. When I copy a route from SimBrief, it gets loaded into my Active Sky. And then from there, that route again gets loaded into my P3D flight plan. Could be possible that these up to date AIRAC routes are not playing nice with an older nav database that is within P3D? Maybe something along that coast is not correct or the sim can't find it and it crashes. Something to think about.

I also agree with maybe the sim just spent the last 5 hours loading no airports, nothing but water, and then all of a sudden a huge scenery load hits the sim along with hundreds of airports and then crash. I will post this again because the link was broken, but here was the locations of everyone's crashes, that I posted on page 14 of this thread.

https://photos.app.goo.gl/THAHXL58CKBxTgd82

I run this addon that updates the navigation data. Activesky and pmdg have the same nav cycle https://www.aero.sors.fr/navaids3.html

Still I think mesh or timezone is going to be the cause

[SteveW 1,792]

2 hours ago, Chapstick said:

So it sounds like only LM can fix this issue if it’s some glitch in the scenery that has to be identified. Honestly, I doubt this will ever get fixed. They haven’t even patched the blatant and atrocious SimConnect window bug months after they broke it in the first place. 

With stock sim aircraft like the B58 these rely on the navdata in the scenery for the navigation systems.

With addon aircraft using FMS these rely on their own set of data that drives the FMS they are unaware of the navdata in the scenery. So if your addon FMS dll chokes on navdata and crashes the sim that's not from the sim that's from your plane.

To check this fly a stock aircraft to the area from the east AND from the west rather than fly away from the area eastbound or to it westbound.

If you get a CTD flying like that you can blame LM for sure.

But if you added in something, anything, to your sim - like mesh, navdata, any kind of scenery or any kind of dll then LM can't help that.

[B777ER 2,486]

Umberto explanation makes sense. However, if it is as he theorizes then wouldn't this bad data be read by the way he mentioned flying east as well? The OTS typically uses the same high altitude Airways over the northeast of Canada to get to the track system. Granted the eastbound ones are usually further south but at times they go further north and thus cross over this area. As well, many central and western US to Europe routes fly over this region as well. But nobody ever CTD going east. But yet the same data that GSX is requesting is still occurring. Very odd.... 

[nazethc 73]

And the one's with the errors have ORBX, Activesky...etc.  We're the tests run by Umberto with a vanilla P3D?  Or with a similar setup like most of us who have the error?  Wasn't really specified in the post.  And again, mesh, time zone why only westbound?  Surely, if it was the case it would happen eastbound also, since the same files are loaded.

[BrianW 124]

Are the majority of people that have experienced these crashes also using Active Sky? I did see at least one report of a CTD without it, but honestly there can be so many causes for CTDs there could be some statistical outliers in this thread.  Is there a potential that certain metars from a nearby station cause issues (like a parsing, or interpolation issue)? This could also explain why it doesn’t happen all the time. However it doesn’t really explain the westbound only issues.

 

I personally haven’t really noticed crashes in this area (and yes I use GSX), but my reasoning is that about a year ago I did experience a CTD flying from EDDF to KIAD on J573 near ENE. After the CTD I restarted the flight on the runway at KRKD flying DCT SEAER then proceeding with the originally planned flight. I saved the flight prior to departing KRKD in the event it crashed again, which it did. For the next flight I changed aircraft but had the same result. On the next try I turned off AI, but still had the crash. Next step was not running Active Sky but keeping the weather conditions as set in the saved flight, still had a CTD.  Finally I cleared all weather and sure enough no crash. I flew back and forth on J573 between SEAER and ENE a few times without issues. At this point a couple of hours had passed so I decided to try the saved flight using the current weather and again had no issues. So as a sanity check I loaded the saved flight once more without loading the new weather and once again had a CTD.

 

So with my issue it seemed like maybe a specific metar was causing Active Sky or ASCA to set some condition or load a texture that the sim didn’t like.

 

This issue may or may not be something similar, but even if it isn’t I really think we should start including the GMT time and date of both the weather as well as the (GMT) time in the sim, to see if there’s some sort of correlation with either a timezone, metar, or other issue.  There really needs to be a way to reliably recreate the crash before we can try to solve it.

[fluffyflops 1,858]

Nearly 20 years on the time zones are still knackered on it.  That's Calgary.  It's 2 hours out it's utc - 6.  Prepar think it's minus 8

When the sim is this fubar and they can't be arsed to fix it, it's no wonder my always ctds using real time. 

 

Edited May 18, 2018 by tooting

[PWJT8D 446]

I just don't fly westbound anymore. Not until this gets figured out. For me it's a flip of a coin whether I make it past the CTD area. Some days I do, some days I don't.

The only real way to test this is to start off with a clean install of P3D and run at least 5 flights with default everything. I know this may be painful with a default aircraft but you have to establish a control test.

Then introduce one add-on such as Active Sky, run 5 more flights. Remove Active Sky and introduce ORBX terrain and fly the flights again. Remove ORBX and then introduce GSX and fly them again. By testing this way I believe you could rule out any individual add-on as long as no crashes occure. At that point you could start introducing multiple add-ons into the sim one by one until a crash, you may find that two add-ons are not cooperating together.

I understand this test would be a huge undertaking and an immense amount of time, time that I do not have. Take it for what it's worth, just an idea.

[SteveW 1,792]

Start by "halving" the complexity and home in by halves. Perhaps turn off all addon airports but keep the plane for a few runs. I'm not saying it's the airports but at least it's a place to start eliminating.

[Boeing or not going 578]

16 hours ago, SteveW said:

Start by "halving" the complexity and home in by halves. Perhaps turn off all addon airports but keep the plane for a few runs. I'm not saying it's the airports but at least it's a place to start eliminating.

No add on airports I have installed are close to the ctd areas.