Jump to content
Sign in to follow this  
Johnny19

P3D 4.1 CTD near Labrador

Recommended Posts

In terms of unusual CTD's I have the following which I find difficult to understand. Not trying to hijack this thread but rather illustrate the elusive nature of CTD's.

If I start P3Dv4 and select W16 Monroe FirstAir Field it gets to 100% loading terrain and textures and then does a CTD every time.

This happens with ORBX W16 installed or uninstalled. I even uninstalled ORBX W16, reinstalled the SCENERY MSI and tried it without installing ORBX W16 and it still CTD's after 100% loading.

However I can fly to W16 from another airport, land there and taxi around, and fly around the whole region surrounding W16 and never have a CTD. I've probably spent around 5 hours experimenting to try and find the cause of this but have given up now and just note never to directly choose this airport from the starting screen. BTW both ORBX W16 and S43 Harvey Airport (which are close together) are very nice airports from ORBX with beautiful enhancements to the surrounding region.

 

Share this post


Link to post
5 hours ago, Boeing or not going said:

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

Then you move on with your line of enquiry, continue with your process of elimination.


Steve Waite: Engineer at codelegend.com

Share this post


Link to post
On 5/17/2018 at 11:55 PM, 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.

Hi Umberto,

I just spent a hour reading through all of the posts in this topic, and i have some own theories about this. The problem is, i cannot exclude FSDT products from any of them, and this is why i quoted you. I may be wrong, of course. 

The problem i belive i have with FSDT products in general are C++ libraries. I purchased some of your products - GSX, CYVR, KJFK V2 and LSGG, but i'm not using them, becouse every time i install any of them, i get instability and crashes. Not sure if this is some specific product related, or couatl, or addon manager, i never tested p3d with one by one installed. But this has caught my attention - every FSDT product is installing C++ libraries, without checking if more recent are installed:

41368269444_f0ee36fa19_z.jpg

In the screenshot, you can see I updated all C++ on 29 april, anything that is installed on 13 May, is installed by FSDT(i checked it before and after running the FSDT installer). I had more recent versions for all of them. The 2015 version is now included in 2017, no separate installation is needed BTW. So, i had more recent version for this one too. This was causing problems with FSL A320 last Year, the FSL needed a more recent version and there was some conflict with 2 of them installed. There is a topic in FSL forums about this. So maybe some other addons needs more recent versions too, and there is a conflict with older version being installed. C++ are not well documented, but i belive if you have 2 versions installed(same year), it can cause conflicts. C++ libraries are not backward compatible - 2013 with 2012 for example. But the same Year versions(they are just updates)should be. Please let me know if i am wrong on this.

Important:

Any changes to my system and P3D(cfg files or other), should be referenced in a PDF or so, as a recommendations only, and not being done without my consent. This, in case you need some settings for displaying your sceneries correctly, or to perform better.

I do belive you can set your installers to check if update is needed, to not overwrite a more recent versions of C++ or anything else. You can also add an option for advanced users, there are a lot of us knowing what are we doing with our systems.

Don't get me wrong, i respect you and your work, i would just like to run your products without issues. The issues could also be on my side, so please let me know what you think about this. I belive this can be related to "CTD near Labrador", so this is why i posted it here and i didn't started a new topic or contacted you via support options.

For all others - for now, i belive this has something to do with overloading, maybe the System, P3D engine, simconnect etc. FSDT for example, can be just a contributing factor.

I'll test this routes now to check if i have any problems. I didn't tried this until now, since i didn't have any long haul planes, but i have PMDG 747 now.

I do have a lot of addons, all of the ORBX, PMDG(737 and 747), FSL, and most of the top scenery providers. I will let you know tomorow about results, since i'm doing all the flights in real time(no time acceleration). This can be another factor in CTD's, you are asking your systems to do a 2x, 4x, 8x more calculations. For now, my bet is on the overloading.

Everyone with this CTD, please post all of your addons and system specs. 

 

  • Upvote 1

Share this post


Link to post
15 hours ago, lodestar said:

Please let me know if i am wrong on this.

I don't have the knowledge to say you are wrong but last time I researched runtime libraries as a source of P3D crashing I gained some knowledge about how Windows uses a strategy called SxS or side by side to deal with multiple versions of the same library.  Have you included this in your hypothesis?


Dan Downs KCRP

Share this post


Link to post

Well, forgot to restart Coualt leaving EGLL for KSEA and guess what, got my first ntdll.dll CTD in forever (see below). Funny though it was around 60N105W. Somebody theorized that the speed in which it may be triggered may be dependent on the amount of physical RAM. I have 64GB of physical RAM so maybe thats why it took until then to CTD. Ah well, next flight on Wednesday I will redo the same route but restart Coualt.  Here is my route: 

 

CPT5J CPT UL9 KENET UN14 OKTAD Q60 LANON UL18 LIPGO SLG MOLAK NIBOG OSBOX AGORI 61N020W 65N030W 67N040W 68N050W 68N060W 68N070W 67N080W 65N091W 60N105W DUROT NCAC YMM J508 CALLY BOJAM J527 YNY J503 FOLDY GLASR GLASR1

 

Faulting application name: Prepar3D.exe, version: 4.2.21.24048, time stamp: 0x5a7c832c
Faulting module name: ntdll.dll, version: 10.0.16299.248, time stamp: 0xeffc9126
Exception code: 0xc0000374
Fault offset: 0x00000000000f87bb
Faulting process id: 0x38c
Faulting application start time: 0x01d3f0422b818e93
Faulting application path: C:\Prepar 3D\Prepar3D.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report Id: d9744043-80d4-4e7a-85cd-d9b1bbaf62a4
Faulting package full name: 
Faulting package-relative application ID: 


Eric 

 

 

Share this post


Link to post
Quote

The problem i believe i have with FSDT products in general are C++ libraries

This comment seems to be a bit generic. We are trying to understand the reason of a crash in NE Canada so, it would be best if you didn't added your general problems. If you have problems, please go to our forum and describe them properly: we'll surely help you.

 

Quote

every FSDT product is installing C++ libraries, without checking if more recent are installed:

I'm sorry but, this is just NOT the case. We are not installing blindly and, we are not even so reckless to "automatically" install something so important ourselves.

We just launch the official Microsoft installer for such runtimes, just like anybody else (I don't think any software developer would be so fool trying to install the VC++ runtime by itself) and the Microsoft installer, of course, DOES version checking so, it will just skip away the installation, if it finds there's a newer version already installed.

Now, you are assuming this is not happening, so you are mislead thinking we "just install" (we obviously don't), because you haven't taken into account how the Windows SxS system works, and how updates are handled.

Those libraries installers don't "just" check the version, blindly assuming that a "new" version "must" be "better". Some versions are really better, but some might not be backward compatible so, depending which software you use, you might require BOTH versions of what LOOKS LIKE to be the SAME VC++ library, but it's not. The most obvious case of this, are the 2005 runtimes: Simconnect client apps made for the RTM or SP1 FSX used the "plain" 2005 version, while SP2/XPack clients REQUIRES the 2005 SP1 version and they ARE different and, in order to have both kind of apps running, you must have BOTH installed.

But it's even more complex than that. While there are versions of the same "year", which are straight updates, and versions why even if they are of the same "year" are in fact separate versions which might be both required by different apps, there are even BUILDS of the same sub-version and, there's a "policy" file which tells to the OS if an app that was built with a specific build, can safely run with an updated build of the same sub-version or not. It's not simple at all, that's why everybody uses the same MS installer, assuming it will do the right thing.

With SxS, it IS possible to have two versions of the same runtimes installed at the same time, even running together in the same process. This is the theory, when it works...

So, even if we are discussing P3D4, every 32 bit client that was compiled with the FSX Simconnect, requires either of these libraries, that's why they are still distributed with P3D4. Couatl, for example, is a FSX 32 bit client (no real need to move it to 64 bit, since it's external to the sim so, 4GB for itself are plenty), and it uses the VC++ 2015 version and can connect with all versions of the supported sim by means of the Simconnect client, which is ITSELF depending on the VC++ 2005 SP1 version.

Now, the key sentence of my whole post was when it works..The WinSxS mechanism is very complex, nobody really understand it entirely, and when it doesn't work, it's usually very difficult to fix it. Microsoft has moved away for it, and the VC++ 2013/2015 and later runtimes don't use WinSxS anymore (but their installers, which we launch, obviously do standard version checking) but, since the FSX SP2 version of the client, which is by far the most widely used by developers, even when connecting to P3D4, we are still somewhat stuck in being depending on working runtimes.

In fact, most of the issues with it, are caused by addons made for the FSX-RTM version of the Simconnect client, which sometimes seem to trigger a conflict with addons made with the FSX-SP2 version, and this is also depending on the module loading *order*. The WinSxS system, which is SUPPOSED to allow two runtimes together at the same time, sometimes doesn't work, and the first one loading get the sim "stuck" with the older version of the runtime. If at least all developers stopped using the ancient RTM version (nobody uses FSX RTM today), this would not happen.

So yes, we might be affected by other addons using the old version of the runtimes when there are problems in the SxS on a system but, you can be sure it has NOTHING to do with the way we install them, which is the only safe one: launching the official MS Installer, and let it decide if an update is really required.

Edited by virtuali

Share this post


Link to post
On 5/19/2018 at 8:23 PM, PaulFWatts said:

If I start P3Dv4 and select W16 Monroe FirstAir Field it gets to 100% loading terrain and textures and then does a CTD every time.

 

That seemed like an easy test to reproduce so, I just did that and...no problems whatsoever, starting with a default airplane on the W16 default airport.

GSX read the airport just fine but, of course, there wasn't much to do for it, but I tried warping to both ends of the runway, with no issue. Which indicates GSX has opened the .BGL and read it successfully.

Share this post


Link to post

Thanks @virtuali for checking it out.

My friend also has no problem loading this airport.

I won't lose any sleep over it as I can fly there and will just stay away from loading it directly.

Share this post


Link to post
On 5/21/2018 at 12:40 AM, virtuali said:

This comment seems to be a bit generic. We are trying to understand the reason of a crash in NE Canada so, it would be best if you didn't added your general problems. If you have problems, please go to our forum and describe them properly: we'll surely help you.

Umberto, please don't take my post personally. At the time i posted this, i must addmit, i was a bit angry. Becouse i have just discovered - the other developer was modifying my P3D cfg files - options, for his product to look better in P3D, and this was affecting other addons and performance. They even used some cmd commands with addmin rights on my system(during installation), to modify some OS settings... So, i apologize if i sounded like accusing you of something(i probably did). I mentioned i do respect you and your work, and i love your products.

But in my original post, i wrote "I belive this can be related to "CTD near Labrador", so this is why i posted it here and i didn't started a new topic or contacted you via support options."

I have some news about this. I managed to get all FSDT products working without problems on my system. I'm still On Windows 7, no reason for me to upgrade now, until i build the new PC with the latest hardware. The solution for me was to uninstall the latest Windows rollup updates - i don't have any updates after 10 November 2017 installed right now, and everything works great. Even some other applications and addons which stopped working after windows updates, for example "PSXseeconTraffic(the latest windows 7 version)". I'm really happy i can use GSX and your great airports again, without problems.

About C++ libraries...

On 5/21/2018 at 12:40 AM, virtuali said:

Microsoft installer, of course, DOES version checking

After reading a lot of C++ related, Microsoft's articles, i'm still not sure about this. After a lot of reading, my understanding is that C++ installer installs that anyway, or maybe - like in case of 2017 / 2015 versions, it just add the 2015 to the registry, i don't know if any files are replaced. But this alone(registry entries linked to the same file), it doesn't looks ok to me. I'm not sure about this, and i'm not a developer / programmer, but i do belive this can cause some problems. I do a clean reinstall of all C++ libraries after installing a new addon, and it works great for me. BTW, your products are working without issues with the latest(Major)versions only. Anyway, Microsoft advice for developers is to ensure compatibility with the latest available version, or to install libraries needed for your product, which you do, like all other developers. Nothing wrong with this.

I did a test, a long haul flight, EDDF - KIAD, with PMDG 747 and all other important addons, without issues. Please let me know if i i can be of any assistance with "CTD near Labrador". I can do some tests, if needed. In case of some other addons, it was about net framework for example.

It would be nice if we could know what is actually beeing updated with Microsoft rollup updates. I think i'm going to pass on all microsoft updates from now on, and i will keep my drivers and libraries up to date. I do not advise this with the windows 10, i'm using windows 7 and this is just my personal opinion.

Share this post


Link to post
3 hours ago, lodestar said:

Becouse i have just discovered - the other developer was modifying my P3D cfg files - options, for his product to look better in P3D, and this was affecting other addons and performance. They even used some cmd commands with addmin rights on my system(during installation), to modify some OS settings...

Not to derail this thread, but can you please identify the developer/product you're referring to here?

James

Share this post


Link to post
5 minutes ago, honanhal said:

Not to derail this thread, but can you please identify the developer/product you're referring to here?

James

Sorry, but no. That wouldn't be ok in my opinion. But i'm going to contact them about this

Share this post


Link to post

I am not superstitious, but knock on wood, am attempting a Europe-America flight in an hour. Uninstalled all FSDT products, changed some graphics settings, and have had successful long hauls but not the famous Europe-America guaranteed CTD routing!

  • Like 1

Share this post


Link to post
4 hours ago, Boeing or not going said:

I am not superstitious, but knock on wood, am attempting a Europe-America flight in an hour. Uninstalled all FSDT products, changed some graphics settings, and have had successful long hauls but not the famous Europe-America guaranteed CTD routing!

Good luck. So it's going well on long hauls, and you'll see if it manages the CTD flight. Keep us posted.


Steve Waite: Engineer at codelegend.com

Share this post


Link to post
2 hours ago, SteveW said:

Good luck. So it's going well on long hauls, and you'll see if it manages the CTD flight. Keep us posted.

Through Boston Center, no CTD. There were a lot of sim changes, reinstalled P3D, Orbx, PMDG. I did not add FSDreamTeam GSX or any of the FSDT airports yet. Stable for my first west-bound Atlantic flight since my last reinstall. Middle of June I can fly west bound again for a second test flight.

Share this post


Link to post

Just adding to this topic, I experienced the ntdll ctd in the location many have had it just now. 

Windows is all up to date, I have the latest nvidia drivers and all drivers for other hardware is up to date.

I hope this is fixed in 4.3 or what ever update LM are working on! 

If you're interested in trying the route I took yourself to see if you get the CTD the route is - 

INKU6F INKUR DCT CON DCT REVNU DCT DOGAL/M079F360 NATE 55N050W/N0462F360 NATE LOMSI/N0465F380 N516A TOPPS (CTD happened somewhere between 55N050W and LOMSI).

Faulting application name: Prepar3D.exe, version: 4.2.21.24048, time stamp: 0x5a7c832c
Faulting module name: ntdll.dll, version: 10.0.16299.461, time stamp: 0xd3988593
Exception code: 0xc0000374
Fault offset: 0x00000000000f879b
Faulting process ID: 0x294c
Faulting application start time: 0x01d3ff2cf375fc31
Faulting application path: C:\Program Files\Lockheed Martin\Prepar3D v4\Prepar3D.exe
Faulting module path: C:\WINDOWS\SYSTEM32\ntdll.dll
Report ID: 8ec14cda-5a31-403c-a7a9-0e346d9d3879
Faulting package full name:
Faulting package-relative application ID:

 

https://imgur.com/a/asEzIOE

Edited by shamrockflyer

Share this post


Link to post
Guest
This topic is now closed to further replies.
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...