Sign in to follow this  
XeroHertZ

Fatal error upon final approach :(

Recommended Posts

Hello pilots,

 

Don't know what to say but express my extreme madness...so after an almost perfect 6 hour flight from OMDB to LFPG. The game crashed with a g3d.dll Fatal Error upon final approach.

 

I have ORBX FTX Global, PMDG 777-300ER, and Aerosoft Night Environment France.

 

I guess i'm done with FSX..sigh

 

 

Share this post


Link to post
Share on other sites
Help AVSIM continue to serve you!
Please donate today!

First, done give up too easily as this is a fairly common CTD.

 

I'd recommend reading the PDF that AVSIM has compiled in their Crash to Desktop guide that has solutions to problems like this. The PDF can be found here http://www.avsim.com/files/file/65-avsim-crash-to-desktop-guide-for-fsx-p3d-fs9/

 

Also if you search thr forum here or Google g3d.dll FSX crash you'll find numerous topics that can help you out. Also if you have FSUIPC installed it can trap some g3d.dll errors to prevent the crash.

First, done give up too easily as this is a fairly common CTD.

Share this post


Link to post
Share on other sites

Thanks for the reply cmpbellsjc

 

Everything else is fine with the game..I barely have an CTD's. But this one frustrated me coz it was upon ending a 6 hour flight.

 

Guess I'll purchase FSUIPC and see if it fixes the issue...If it didn't i'll do more research.

Share this post


Link to post
Share on other sites

Guess I'll purchase FSUIPC and see if it fixes the issue...If it didn't i'll do more research.

The registered or unregistered version works.

 

Best regards,

Share this post


Link to post
Share on other sites

The registered or unregistered version works.

 

Best regards,

 

Thanks for the info Admin, and sorry for posting in the wrong section.

Share this post


Link to post
Share on other sites

Not a problem.  We do some housekeeping occasionally in case members post in the wrong forums and that happens all of the time.  If you are not sure of the proper forum, go ahead and post and we'll move it if it needs to be moved.

 

Best regards,

Share this post


Link to post
Share on other sites

I've had a CTD Fatal Error just before the approach phase on 2 consecutive flights.  Wondering if it has something to do with add-on airports loading.  Using Prepar3d 3.1 but it has also happened with 3.0.

Share this post


Link to post
Share on other sites

Hi Steve,

 

CTD's on the approach phase are extremely common and it all depends on the aircraft you are flying, whether using a commercial weather program and the weather is nice or stormy, the duration of the flight, and/or the airport you are landing is the default or a commercial airport with a lot of eye-candy.  Of course, your P3D configuration settings and the display driver settings will play a major role too. Prepar3D v3 and 3.1 are suppose to manage the use of the 4GB's of VAS space on your hard drive and I think it does a great job.  I use the FSUIPC utility (freeware or payware) to monitor my VAS usage and, when I complete the flight, I can look at the FSUIPC.log and review my VAS usage and fps usage during the flight.  Page 3 of the AVSIM CTD Guide (link in my signature) provides guidance on how to set up the fsuipc to monitor VAS.

 

I think you can ratchet up the settings to max if you are using the default aircraft and scenery for P3D.  When you start adding eye-candy like PMDG aircraft and airport scenery like those that come from FSDT or FlightBeam, and a commercial weather program like ASN, then things go downhill fast and you have to start compromising and reducing your settings depending on the power of your computer.  I personally do not think any computer system today can run FSX, FSX-SE, X-Plane, or P3D with max settings for very long without running into an issue like a CTD or freeze.

 

If you want, you can download and run AppCrashView (see page 1 of the AVSIM CTD Guide for the download link and instructions).  This app will show you the faulting module (in most cases) and that will give you a clue as to what caused your crash.  If it's the API.dll, then you ran out of VAS or got very low on VAS.

 

There are many other suggestions in the AVSIM CTD Guide for fixing crashes or investigating them.  For instance, have a lot of photoscenery?  If you enable photoscenery that you will not need during a flight, it will still load and the photoscenery could be on the other side of the planet yet it will still load taking up valuable resources.  I have used the process monitor utility in the background just to see what's running (see page 4 of the guide).  The guide provides instructions on how to set it up so only P3D and P3D addons are shown in the log and not all of the stuff running in Windows too.  I remember making a flight from Chicago to St Louis and the process monitor was show scenery being loaded in California and Wash State.  It turned out to be autogen in those states used by FTX/Orbx but there was no need for that scenery to be taking up resources for my current flight.  Just little things like that can help.

 

Hope this helps Steve.  Best wishes to you and your family during the Christmas holiday season.

 

Best regards,

Share this post


Link to post
Share on other sites

Thank you Jim,

 

I appreciate you taking the time to help.  I downloaded the CTD guide and will be doing some exploring when I have the time.

 

Thanks again!  Merry Christmas

 

Steve

Share this post


Link to post
Share on other sites

I personally do not think any computer system today can run FSX, FSX-SE, X-Plane, or P3D with max settings for very long without running into an issue like a CTD or freeze.

 

With utmost respect, I really must differ here.There seems to be this perception in the FS community that load or complexity will cause hardware to fail or the software to crash. I don't believe this is true, even for FSX.

 

On a pure hardware level, if the hardware is working correctly then you can run it at 100% all day long. Years ago I wrote a weather radar processing application that needed to split, zoom and re-encode radar data, plus create visualization of forecast models and synthetic observations. At the time, it required a pair of quad-core Xeons that would spend over half the time with all cores at 100%. Every five minutes, a new set of radar data would come in and it would peg the cores and chew through a few gigs of RAM. It ran perfectly stable for years before we moved it to AWS.

 

As another example, I regularly use Handbrake to re-encode TV shows and movies for my family's Apple devices. A Handbrake encode job of a movie or season of a TV show will peg all 8 of my cores at 100% for half an hour or more. The temperature will jump to the mid 80s Celsius. And again, it will all run perfectly stable until the encode job completes. The CPUs can and will throttle themselves if they get too hot. (I ran a Q9550 with a partially detached heat sink for months before I noticed.)

 

So there's nothing inherent to "load" that will make things crash. You can max out a processor, all cores, for years on end without issue. They get obsolete before they wear out. Same goes for RAM, video cards and SSDs. If the hardware's defective, that's another story - but there are no settings you can change in software to get around bad hardware.

 

The main cause of FS crashes is gauges/modules and scenery. The former are a huge security and stability problem because a compiled gauge is just a DLL that gets linked into the FS process and executed. It can do anything that FSX can, including (and especially) crash the process or leak memory. But it's going to do that no matter how loaded the computer is. If there aren't enough cycles, then processing slows down and frame rate drops. That's how it works. But there's no way that FSX can have external C modules running in process and protect against crashes - the only way to do that is have an interpreted language. (Which is what XML gauges are!)

 

Same with scenery - there's vast amounts of third party scenery built by who knows who, to vastly different standards. How optimized is it? Has it been developed and tested in isolation, or with 35 other scenery packages all installed and potentially loaded by FSX? How much of it (especially landclass and terrain) has been automatically ingested and processed? You get the odd error in gigabytes of source data.

 

The last bit is weather - if I recall correctly bad weather data can crash FSX quite easily. This is the root cause of a lot of crashes blamed on FSUIPC - it reads the weather via Simconnect and if the saved weather file is bad FSX goes poof. It goes away when FSUIPC is disabled even though that module is not the cause of the crash.

 

When you have all this random third-party stuff in your simulator, you've got an almost exponential level of complexity as add-ons get put into the mix. However, if you have a stable FSX installation (and by stable I mean with minimal changes) with good hardware and known good drivers (that also don't change) you can crank the settings up and be stable.

 

Here's some links for you. First, my FSX scenery settings. I run at 2560x1440 (higher than most single display users).

 

fsx_settings.jpg

 

There's a few tweaks in the FSX cfg but nothing too dramatic. As part of testing (and my own curiosity) I did a very long flight in FSX, from FSDT KLAX to default YSSY. Here's what task manager looked like at the end:

 

pmdg_taskmgr.png

 

That's 14+ hours. You can see a log here: https://www.deltava.org/pirep.do?id=0x116b0d that shows I'm averaging 43 fps for the flight. The frame rate was slow at KLAX but on landing it was in the 20s and 30s. (Download the Excel version on the link above to see it all.) The sim is doing what it should be doing - with complicated scenery, the frame rate goes down. It doesn't crash.

 

Look at the CPU time - it's over 33 hours for FSX. That means that over that 14 hour period, I had the equivalent of over two cores going at 100% - it's likely 1 pegged core and the others running a bit, but that's a lot of CPU use. Again, all perfectly stable. (It also gives a good idea of how little processing time other processes "take away" from FSX and why shutting them down is rarely of any value beyond the placebo effect.)

 

Finally, it's worth reminding that we all used to fly FSX using Pentium 4s.To give you an idea, a P4 has something like a twentieth of the power of a modern processor. Look here for some fun nostalgia: http://www.phoronix.com/scan.php?page=article&item=intel-478-retro&num=1

 

But FSX ran fine and stably on those machines. The scenery density had to be toned down a bit, but I was flying on a P4 using FSX with decent frame rates, like here: https://www.deltava.org/pirep.do?id=0x330a9 It worked, it ran.

 

Now that I have about 30x the processing power, I turned the settings up. And my video card needs to process 4m pixels instead of 750k. And I have more complex add-ons. It's all still perfectly stable.

 

And if it's not stable, it's not that there's not enough hardware. It's not the fault of FSX in most cases (UIAutomationcore being the biggest exception). It's because the add-on is buggy and/or poorly implemented. There's enough hardware to run FSX stably in all cases (maybe with varying frame rates).

 

I've had a CTD Fatal Error just before the approach phase on 2 consecutive flights.  Wondering if it has something to do with add-on airports loading.  Using Prepar3d 3.1 but it has also happened with 3.0.

 

Is it the same airport?

 

Cheers!

 

Luke

Share this post


Link to post
Share on other sites

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
Sign in to follow this