terrain.dll CTD in P3D4.4

[samisahusky 13]

There is no confusion about the version. It has been 100% crystal clear since post #1:

These show the faulting module and the program that runs that module and their installed version numbers:

Faulting application name: Prepar3D.exe, version: 4.4.16.27077, time stamp: 0x5bfdbb35
Faulting module name: terrain.dll, version: 4.4.16.27077, time stamp: 0x5bfdbaa6

This shows a folder path that the above are installed into and have nothing to do with installed version number that is listed above. Folders can be named anything!!!!

Faulting application path: C:\Users\Steven\Desktop\P3Dv43\P3Dv43 MAIN INSTALL\Prepar3D.exe
Faulting module path: C:\Users\Steven\Desktop\P3Dv43\P3Dv43 MAIN INSTALL\terrain.dll

 

So again, no confusion anywhere except those who are not reading the entire issue, or those who don't understand how to read the error. No confusion. None. If you still think there is some confusion about what version was giving the errors and what's been done and proven working, then please go back to post #1 and try again.

[samisahusky 13]

4 minutes ago, SteveW said:

speaking as a professional developer.

 

.

I've never known a professional who wanted so badly to throw that out there whenever and wherever he/she/it/they/them could ... 🤨

[SteveW 1,792]

...you are correct that's not confusing, it's obvious that it is 4.4 from that as you say.

Something caused a confusion about versioning.. but anyway...Perhaps it's just as Jim said, that the settings might need reducing since 4.4 is harder on the system.

The way to go is start small with settings and watch task manager. If when the sim is settled there are any cores maxed, you've probably got a setting too high. Switch on VSync or limit the fps in some way to increase time between frames to accommodate the higher settings. Although as I said earlier, sometimes it's just a building removed or a texture maybe something like that with a lower setting selected.

Remember that because I handle many real life quires, my posts are aimed at all circumstances and all comers so may include something you are already aware of. Coming from the NT side of things into the FS arena it became clear that the use of a personal folder was being recommended to get around problems of addons writing to files they stored there. That was a mistake, however some inherited code they can't change. The professional way to get around the problems of apps not having write ability in those folders it so simple it hurts - to provide the permission. Adding the Modify Allow permission for the Users group on that folder is the way to do it. If you don't have permission you give the permission. Since when we log into windows we are members of the authenticated group 'Users', we can use that as it is safe to do so. After that there's no issues with that folder at any time.

Remember when installing into another folder even admins don't have access unless you give the Users group modify as well on those. So that if a problem happens in future with your account the sim will still run for another login. Installing onto personal folders can't be recommended in the long run since these apps (P3D) are designed for any login to gain successful use, and by so doing they can be installed with differences for different users if need be, as they would in commercial or educational places. Addons that don't comply are not seen in those places.

[Jim Young 2,356]

4 hours ago, samisahusky said:

There is no way an updated add-on failed because of folder placement because I didn't revert back any of the updates for those add-ons, I only reverted the main P3D sim from 4.4 back to 4.3 and all the add-ons still work prefect. All add-ons retained their updated status for 4.4 compliance, despite P3D being reverted back to 4.3 now. So your theory is not correct, and that should be pretty obvious to a "professional"

Pretty rude comments to someone who is trying to help.  Know you are frustrated but inappropriate, inciting, and rude comments are not allowed.

[SteveW 1,792]

What's more is I suggested the folder location naming might be a reason for confusion about the versioning of P3D, not a reason for the error. Juggling the semantics of posts to make out they are in some way wrong is not welcome.

[samisahusky 13]

This thread is not about confusion of P3D version. Please go back and read your replies. Another member also felt that there is no confusion about what version was installed, so I’m not alone in how the replies were written. 

Jim, you made a number of replies stating that the error was showing version 4.3 installed, which then confused everyone else who may have been able to help resolve the issue but then felt it was resolved because you stated the incorrect version was installed, when I had pointed out every time that the error showed 4.4 installed into a custom folder. Instead of pointing out where in ther error it stated version 4.3 as I requested, you dismissed my issue altogether as if I refused to acknowledge that you were right, despite having nothing showing version 4.3 in the error. 

 

Steve, when you brought up folder placement, it wasn’t as a suggestion, at least that’s not how it was written. I’m simply pointing out that it should be clear that if a revert solved the issue then the issue is with the update, and adding “from a professional” only makes it seem you are above the rest of us and therefore your solution must be the correct one. Professional or not, this post isn’t about folder placement either and making other feel inferior is not professional at all. I’ve found posts from over 2 years ago about you discussing folder placement and more than half of the users who replied stated they did not have P3D in the default Programs File folder due to read/write permissions and have had no issues. I’ve had that folder as full permissions since I got Windows 7 back in FSX days but I agree with the majority of users who have not had any issues with the sim, that it is easier to have it in a custom folder be it for shorter paths or for better organization. A good number of computers don’t come with a large built in hard drive, so that’s why we buy a larger SSD drive to install the sim into. If nothing was ever made to be installed into those drives they wouldn’t have the ability to. P3D and all of the addons I have for it take up a huge amount of space. Having everything in 1 custom folder makes it easier to back up and make it easier to find update managers and makes it easier to reinstall if needed. I will again say I’ve seen far more issues come out of having it installed into the default than I have seen with having it installed into a custom folder. 

 

I will again state for the final time, there is no and should be no confusion about what version is installed. Please read the entire error and OP clearly. 

[Jim Young 2,356]

You are spending more time trying to justify your responses than helping members try to learn and help.

14 hours ago, samisahusky said:

There is no confusion about the version. It has been 100% crystal clear since post #1:

These show the faulting module and the program that runs that module and their installed version numbers:

Faulting application name: Prepar3D.exe, version: 4.4.16.27077, time stamp: 0x5bfdbb35
Faulting module name: terrain.dll, version: 4.4.16.27077, time stamp: 0x5bfdbaa6

This shows a folder path that the above are installed into and have nothing to do with installed version number that is listed above. Folders can be named anything!!!!

Faulting application path: C:\Users\Steven\Desktop\P3Dv43\P3Dv43 MAIN INSTALL\Prepar3D.exe
Faulting module path: C:\Users\Steven\Desktop\P3Dv43\P3Dv43 MAIN INSTALL\terrain.dll

 

So again, no confusion anywhere except those who are not reading the entire issue, or those who don't understand how to read the error. No confusion. None. If you still think there is some confusion about what version was giving the errors and what's been done and proven working, then please go back to post #1 and try again.

You state there is no confusion about the version but I dare you to go into other crash reports where the Event Viewer was posted or an AppCrashView report was posted that showed another version that was in the faulting application path and faulting module path.  You explained that and I agree you can name a folder anything you want.  I just thought that was strange.  I have never seen a crash report showing a C:\Users path though.  The path is usually where P3Dv4.4 is installed like G:\Prepar3D V4.  I realize you have v4.4 installed and that was running when your application crashed I do not see why it was showing a User path.  Those are hidden folders.

It appears to me you have been trying to blame v4.4 for your many woes.  Prepar3dv4.4 just happened to be running when your crash occurred and it was most likely caused by an incompatible scenery or one that was being called but was not there.  Can I say exactly what scenery was incompatible or not installed properly?  No.  But I know for a fact it was not P3DV4.4 that caused your crashes.  Otherwise, I and thousands of others would be seeing the same crashes.  No, you did something wrong and only YOU can fix it by investigating.  No one else can tell you exactly what caused your crash.  They can give you suggestions like I did but they cannot say that ABC Scenery caused your crash or your scenery.cfg is corrupted or your dll.xml is corrupted or your p3d.cfg is corrupted.  You have your computer in front of you and know exactly what is installed.  I have seen where just the wrong version of the fsuipc.dll caused crashes like this.  I believe the fsuipc.dll was one of the programs updated when v4.4 was released.  So was ASP4.  There were a lot of bug fixes when P3Dv4.4 and I know that many of them fixed issues where a developer was suddenly seeing a lot of problems with their product.  For instance, Carenado had many issues in earlier versions of P3DV4 but a subsequent P3DV4 update fixed the problems. 

So, let's hope you can find a solution to your issue.  The fact you moved back to version 4.3 and it is running okay is a clue.  It does not mean P3DV4.4 is bad.  It means something you had installed in P3DV4.3 is no longer compatible with P3Dv4.4 or there was some type of installation problem.  I know you are frustrated as it has happened to me often but I always go to the AVSIM CTD Guide and follow it's guidance for investigating each crash.  This starts on page 10.  You rename the P3D.cfg, the Scenery.cfg, and both of your dll.xml's.  If you have scenery add-ons, you go to the C:\Documents\Prepar3d V2 Addons and move the contents of that folder to a temporary directory.  You restart P3D.  The P3D.cfg, scenery.cfg, and the dll.xml in your scenery.cfg folder will be rebuilt to the defaults.  You will have no add-on scenery installed.  No modules like the fsuipc.dll or Active Sky loading.  You will have pretty much a very virgin installation of P3D.  If no crash after restarting P3D, then it was one of these elements you renamed or one of the add-on xml's.  You will have to go through a lot of investigating.  It will not be easy but it is one solution that works.

[SteveW 1,792]

On ‎2‎/‎24‎/‎2019 at 8:15 AM, samisahusky said:

 it's been suggested, but all major developers, to install into a folder on the desktop a

 

9 hours ago, samisahusky said:

and adding “from a professional” only makes it seem you are above the rest of us 

You inferred the professional approach - more juggling of posts to make yourself look cool and others look dumb.

If this is the case, *desktop installs recommended by pros*, then the industry is slewing into a state of amateurism that is unwelcome as well.

 

Edited February 25, 2019 by SteveW

[SteveW 1,792]

I like to consider myself one of us not above or below. Otherwise I'll not be giving away quality advise that is considered a commercial asset. Pros in this industry won't want to come to AVSIM to be told what pros think by those that have no idea, that's just - bad

[SteveW 1,792]

I'll attempt to address this ridiculous hullabaloo over the P3D folder.

 

We unzip the P3D 4 package and double-click the "Setup_Prepar3D.exe". We can look away at this stage and when it's over we can look again and find it's installed into:

C:\Program Files\Lockheed Martin\Prepar3D v4

 

Now I'm going to install my PMDGs. Since they want to write out to their panelsate files and the folder is read-only we need to provide write ability for that to work.

 

Remember that making a folder or drive partition we have ownership so as a User we can write there. But only as that user. If we run as admin, we are not an admin, we are us with admin privilege. So another login running as admin can't access the private folder - oops.

Also installing multi-user software packages in personal folders comes with many unseen problems that can arise in future. An error in the user account can render the install useless as well.

So I right-click on the folder, properties, security, edit, check Modify Allow for the Users group.

This is simple, a single checkbox: With files we check Read-write, for folders we check the Modify Allow on an authorised group assigned to that folder. Windows provides the Users group and the Authenticated Users group for this purpose.

So now I can install my PMDGs and they all work fine and save their files happily with no fuss. I continue to install addons and there's nothing to think about, they all get tested on this very configuration. Any other installs might become a problem.

So in short - We didn't have to make a folder or partition a drive, we don't worry about addons, and we don't worry about other logins gaining access since they are also members of the Users group.

Now that we can log in as ANY USER and run the PMDGs and they can write out their panel states.

If I want the bulk of addons on another drive I set the drive path and folder in the P3D config. SO that I can manage my 500Gb photo-scenery or big collection of AI planes. The main components of the sim are run from my main drive.

 

I had a distraught user contact me a few months ago after trying to partition their boot drive to make a drive for P3D and something went wrong, no idea what but they had to install Windows. They put their sim on the proper way as described above and since heard that all is good, excellent in fact.  A very definite 1-0 to me, do doubt about it.

 

This is not some big idea of mine, this is basic NT use.

However, making a folder or partition to avoid a read only folder is a 'big idea'. The so-called problem with program files folders is a fairy tale. 

Happy simming.

 

[samisahusky 13]

For anyone who may be interested, After 6 attempts I was finally able to make the KJFK-OREK flight without P3D CTD or App Hang. After updating to 4.4 is when the CTD issue would start. I reverted back to 4.3 and tested and everything seemed to be working, so I set up the flight plan again and tried the flight, but once again somewhere over Europe, P3D would then start doing an App Hang rather than a CTD. I did a full uninstall of P3D and all addons and then reinstalled going directly to 4.4 (I never reinstalled 4.3). I tested again and still I would get App Hang over Europe (the errors would only happen between 5-7 hours into the flight somewhere randomly over Europe after flying 3,000 miles without an issue). I was just about to give up when Avast Cleaner (AV disabled still from reinstall) popped up and it notified me of just over 20,000 issues with registry entries. I used Avast Cleaner (CCLeaner can do the same) to repair those bad links and I also followed the advice from a post here in the CTD forum about disabling the CMeteoXml.dll in the P3D install folder and also disabling BOTH dll.xml files (the one in C:\ProgramData\Lockheed Martin\Prepar3D v4 and the one located at C:\Users\yourname\AppData\Roaming\Lockheed Martin\Prepar3D v4). I restarted the computer after all 3 of those were done (all reg entries fixed, BOTH dll.xml files disabled and CMeteoXml.dll disabled). Loaded up the flight plan again, and gave it the 6th attempt and this time there was no CTD and no app hang.

 

I cannot confirm which of those 3 things seems to have fixed the issue, but I do recall AS4 Live Weather giving a few spots of red while over the Atlantic on almost all of the attempts. The CMeteoXml.dll file does something with weather for Carenado but it is not required to fly so disabling it would have no negative impact on the setup. Per previous posts in the CTD forum, that file has been known to cause CTD when exiting bad weather if you are also using Active Sky, so that could have been it. It could have been that the 2 dll.xml files were both calling for the CMeteoXml.dll file to be used when it didn't need to be used thereby causing a conflict between Active Sky and CMeteoXml.dll Carenado weather, or it could have been a different bad address in one or both of the dll.xml files. Or, it could have been one or more of those 20,000 reg entries that were incorrectly mapped was causing the conflict and it only came up when trying to update P3D from 4.3 to 4.4. Who knows. But my advice for anyone who is getting weird or random CTD or App Hang, do these things in this order: 1) disable CMeteoXml.dll by changing it to CMeteoXml.dll.off 2) disable BOTH dll.xml files at the addresses above to dll.xml.off (P3D will rebuild them when you restart P3D), 3) use some type of trusted cleaning software and check your registry entires and allow the cleaner to fix any errors it finds, and then rerun the reg check on the cleaner and fix errors until you get 0 errors and finally 4) restart your computer.

 

After running those steps, I was able to do a 13 hour flight with no issues from P3D, but I did notice that UTLive isn't working properly now. Most likely because of a bad install or missing files. I'll uninstall UTLive then check registry errors, restart comp, reinstall, restart comp again and see if that fixes it.

[SteveW 1,792]

Well done. What is concerning is how those registry errors came about. Let's hope you find the cause before more problems start if that's what it was. It's always the same thing though there's something affecting the sim and only by stripping right back can some problems be resolved..

[samisahusky 13]

It may have had to do with the previous version of 4.3 not having been uninstalled as it should have been from my system. I did follow the instructions from Poppy for updating, but still anything could have gone wrong. A huge majority of the registry errors were Microsoft looking for documents I don’t have on the C drive anymore and only about 5 or 6 were anything related to P3D or its addons. 

 

Given that I did have a test flight work properly while using AS4 and UTLive but not my VA ACARS, and then failing when I was using ACARS, I would think the culprit was a bad update install of the ACARS system 

 

utlive is working properly on version 1.1 after an uninstall, reg check, computer restart and reinstall of UTLive. Im skeptical to try to install 1.2 because 1) it doesn’t really update anything but the schedules and I’m pretty happy with the current schedules as far as traffic density goes and 2) as I said before, if it ain’t broke, don’t fix it ... and 1.1 isn’t broken.

 

What concerns me tho is that I was able to complete the 14 hour flight with UTLive running but it hadn’t injected traffic. It is properly injecting now, but does anyone know if P3D4.4 did any changes that would have made an AI Aircraft not compatible anymore? They all worked without issues with 4.3 and I’ve been extremely diligent about only getting the correct AI model types for P3D. I can’t tule out that 1 model type was causing the issues either because I didn’t have any traffic on the flight. 

Edited March 3, 2019 by samisahusky

[SteveW 1,792]

12 hours ago, samisahusky said:

I did follow the instructions from Poppy

Poppet!

I expect most registry errors showing were just items left behind from installs. Basically most apps will leave some things in the registry after uninstalling, like registration details perhaps, or form sizes and locations maybe, so they are picked up if the app is installed again. But Registry size although supposed to be a drag on the system is not really too much of an issue, since billions of branches can be searched in the time it takes to read a text ini file.

[SteveW 1,792]

..There's a lot of hullabaloo about the registry too. There are no bad registry entries in particular: A 'bad' registry entry could simply be a value that when read in by its application causes that app to work incorrectly in some way that could hang the app or maybe crash the system. That's not a registry error that's an application error from an app that fails to see an input incorrectness and acts on it when it should take avoidance. Registry cleaning is not necessary other than for storage space since even if a billion entries were cleared there would be little difference to the time taken to read it for an item. However since apps can start working again after cleaning the registry this is basic evidence that an app is operating that has not taken due care somewhere reading the registry.

Edited March 3, 2019 by SteveW