g3d.dll Crash with AES 1.93

[jpost 12]

I'm getting a g3d.dll crash on final approach, usually when just about to land (just above minumims). Seems to happen when flying from a non-AES-equipped airport to one which is AES-equipped. For example, flying EGLL-EDDF works fine; flying EGPH-EDDF - crash. Flying TJSJ-KCLT works fine; flying TNCA-KCLT crashes. Long flights between non-AES-equipped airports also work fine - such as KSDF-PANC. The first pair above were flown with the PMDG 737NG and the second pair with the PSS 757. This first appeared after loading AES v1.93 and applying the patch.

I'm running FS 9.1 with FSGenesis mesh; Active Sky weather; UT-USA (but not UT-Europe); and Ultimate Traffic set to 25 percent.

One other thing - it's asking me if I want de-icing at San Juan, Puerto Rico, when the temp is 27 degress Celsius!

Jerry Post

KORF

[OPabst 2091]

Hi,

please read the red note at the beginning here:

http://www.forum.aerosoft.com/viewtopic.php?t=14811

If you have the patch in the second note allready installed, try first to place you Airplane on a AES airport (then the memory is allocated) and then move to the start (non AES) airport. When you was one time at a AES airport after the start of the FS, the problem should not happen.

There is maybe a problem, when AES is loaded the first time in flight, when also the Airport is loaded. Maybe a problem is memory allocation of the FS.

[jpost 12]

Thanks for the quick reply, Oliver. I had missed the latest update and will give it a try.

There may be a memory allocation issue. I forgot to mention I use the "large address header" patch on the FS9 executable. There has been an issue with Cloud9 products and their bglman.dll caused by the header patch regarding memory allocation and usage. I will also try the new AES patch with a clean FS9 executable. Thanks!

Jerry Post

KORF

[tetiaroa 1]

Hi Oliver,

I´ve got exactly the same problem as Jerry posted above: when on final approach to "MegaAirport Frankfurt" about 1000-2000 ft AGL the sim crashes all over sudden, giving me either a g3d.dll- or ViMaIScn.dll-error message. Also the fact that flying from an AES-Airport to EDDF doesn´t create an error seems to be the same.

Besides that, sometimes I´m getting the CTDs (same error message) at startup in EDDF as well (using the PMDG 747-400).

There are still some more things to it that I found:

1. The error so far only occured with the "/3GB-patch" installed, which is necessary in my case, cause otherwise I´d be getting OOMs all the time(and those not only but including EDDF). And as you´ve mentioned something about "Problems In Memory Allocation Of FS" maybe this is, where the conflict kicks in?!

2. When configuring the parameter MaskClassMap in the "terrain.cfg" by exchanging every value of "3" and "1" to "0", the CTD not only occurs on final regularely but also at startup in EDDF (This value-exchange in the "terrain.cfg" is said to reduce CTDs when using 3rd-party landclass together with 3rd-party mesh)

3. Exchanging only every value of "3" or "1" to "0" in the "terrain.cfg" seems to even prevent the CTDs at startup a little.

4. Something that might be of interest besides:

I´ve converted my PMDG 747-400 from 32-bit textures to DXT3

Downloaded resized autogen from AVSIM and converted it to DXT1

This change increased fps a lot! Even though I don´t think this

has to do anything with the crashes at all, as they also do occur when

trying without thes changes, I mention it just in case.

5. I have two hardware conifgurations and installed the IoPageLockLimit-patch (after the crashes occured), don´t know if that´s of any importance.

What I´ve tried so far:

1. I installed the most recent version of AES (downloaded after 01.01.2008) and copied all DLLs from AerosoftAESDLL to their respective folders in FS9 -> no success!

5. Checked for missing textures, doubled AFCADs, misplaced landclass, reinstalled EDDF, AES, all AI-traffic, left out all .bgl´s from EDDF_LC except the land-polygons (LC_402-113.bgl) to reduce memory impact...nothing helped!

I'm also running FS 9.1 with FSGenesis mesh, FE, GE Pro2, Active Sky; UT-USA, UT-Europe, FS2Crew for the PMDG 747-400, PAI and WoAI-traffic + some minor addons (everything patched up-to-date including my video-card nVidia 8600 GTS).

The system is: Pentium Core Duo 2.13 GHz

2GB Ram

Going to your arrival-airport before you fly there helps - as mentioned above, but seems a little unrealistic to me....somehow :wink:

I´d really appreciate your help! Maybe you could released a patched version of AES that cures this bug!

Thank you,

Tetiaroa!

PS: Ich spreche auch deutsch

[OPabst 2091]

Going to your arrival-airport before you fly there helps - as mentioned above, but seems a little unrealistic to me....somehow :wink:

Thanks for your testing.

The last sentence is important, as it shows, that it is more or less a problem in a complex combination of memory allocation, which is not possible to fix for me at the moment. (btw, that part is in Intelliscen, so not my own part of AES). As I have understand the Memory allocation of Intelliscen, it used standard MS API's and Functions, so nothing special.

The design of the scenery engine in FS makes it not possible to have a "global" BGL file, active all over the world. So AES is only loaded, when you are in the area of an AES Airport. No way to load it everywhere.

In the most cases, this is not a problem, because when AES load in approach to the first AES Airport, it can allocate the memory correct, only in this hi mem intensive situation, the MS (maybe windows, maybe FS) generates problems.

So, for the moment, I have no other solution as to say, go short to one AES airport, when you have started the FS. Then you can do what you want. I know, not the best way, but for now, the only one.

[tetiaroa 1]

Hi Oliver,

thanks for your quick answer and explanation!

No worries, if you can´t fix it, you can´t! It´s actually not that much of a big deal, as now I know at least a way around those CTD and can finish my flights! I was just courious, if that was a known bug - or just concerning Jerry and me - and if it was known already, if you had a solution for it!

Thanks again,

-Tetiaroa.

[OPabst 2091]

Ok,

I will ask Maurizio (responsable for the ViMa Modules) if he can take a look to the 3GB Patch, maybe there is a handable solution for that, because at the moment, we only deal with the "normal" FS EXE.

brgds

Oliver

[tetiaroa 1]

That´d be fantastic...Thank you!!

-Tetiaroa

[OPabst 2091]

Hi,

I have spend two days for making the AES Code of 1.94 more stayable against loading problems, so please checkout the new Version, when it is available this week, to see, if the problems are gone. Please give me a feedback here.

[tetiaroa 1]

Hello Oliver,

first I´d like to thank you for your efforts in trying to help me out!! :oops:

Unfortunately I have bad news: Even though it seems your changes improved the stability of FS at start-up (especially when using those "MaskClassMap"-tweaks in the "terrain.cfg") , the CTDs with "g3d.dll"- or "ViMaIScn.DLL"-errors still do occur when approaching Frankfurt from a Non-AES airport. :cry:

I´ve tried the exact same flight (same time, date, route, aircraft...etc.) twice - to be sure - and got on both a CTD on final. To exclude other possibilities being the reason for the CTDs, I reconfirmed my results with another try (also the same flight), but this time using your workaround of placing the aircraft prior to departure (from the Non-AES airport) to an airport with active AES, and as expected, it didn´t come to a CTD.

Well, I hope that´ll help you a little, and thanks again for your efforts!

Please keep me updated on the issue in case you can solve it!

Best regards,

Tetiaroa!

[OPabst 2091]

Hi,

sorry, but now I have no more idea, what I can do, only to try to make all airports AES compatible, lol.

Maybe one test you can make: Disable the AESliteforGAP-EDDF entry in the scenery Library before your next fight. As this is also dealing with Intelliscene and Memory, maybe there is a confict. I don't think so, but lets try it.

[tetiaroa 1]

Hi Oliver,

please excuse my late reply, but I had to do a little bit of investigation first! After installing 9Dragons´Kai Tak-scenery I started to get the "g3d.dll error message" at EDDF again - even when using your workaround or just starting up FS at EDDF. Turned out to be a conflict between their modified "generic.bgl" and MegaAirport EDDF with active AES. Using the default "generic.bgl" solved the issue when using your workaround! By the way, this problem didn´t occur at any other AES-airport!

Well, while dealing with the problem above, I also got the chance to test your suggestion of deactivating AES-lite and as you already assumed, AES-lite doesn´t seem to be the problem. I tried two different settings when still using 9Dragons´ "generic.bgl":

1. I deactivated AES-lite and started FS at EDDF,

2. I deactivated AES and started FS at EDDF.

When testing the first scenario, FS crashed repeatedly and immediately after loading the scenery and, as expected, the second scenario stayed stable. I remember, when I was using AES v.1.93 and tried different "MaskClassMap"-settings, I also tested the scenarios above with the same results. So I really doubt AES-lite being the reason for these problems at EDDF (neither do I think EDDF_landclass has to do anything with it)!

What seems weird to me though is that these immediate "g3d.dll"-related crashes, when starting up FS with certain modifications ("MaskClassMap"/"generic.bgl") and active AES, always and exlusively happened at MegaAirport EDDF, they never happened at any other AES-aiport! Again, without modifications it works fine at EDDF even upon approach, but that only when using your workaround! What I didn´t get to test so far is, if the crashes upon approach, when not using your workaround, also happen at other AES-airports! Couldn´t there be a hidden conflict between AES and the scenery of MegaAirport EDDF? Also, I remember reports of a similar "g3d.dll"-related problem with MegaAirport Heathrow (don´t know, if with active-AES) at its time of release. The patch there had to do something with memory-load reduction, I think! Maybe there is a similar problem with EDDF and AES that only occurs under certain circumstances (/3GB-patch...etc.)?

I hope, you´re not giving up on me yet and that my assumption finally points into the right direcction of this annoying problem!

Best regards,

Tetiaroa!

[der_Julius 0]

Hello everybody,

I have the same problems like you guys. Correct me if I am wrong:

The FSCrash appears when AES is loaded for the first time? (In my FS it always happens when AES is "checking" my aircraft -> When I fly an airplane AES does not "know", i get the typicall yellow window. At the exact same position in the FS where the "checking" happens the FS crashes)

So could be a solution to create a BGL-File, a dummy-like which makes the FS "think" AES is active all the time, or is active when you start the FS?

best wishes

Julius

[OPabst 2091]

Hello everybody,

I have the same problems like you guys. Correct me if I am wrong:

The FSCrash appears when AES is loaded for the first time? (In my FS it always happens when AES is "checking" my aircraft -> When I fly an airplane AES does not "know", i get the typicall yellow window. At the exact same position in the FS where the "checking" happens the FS crashes)

So could be a solution to create a BGL-File, a dummy-like which makes the FS "think" AES is active all the time, or is active when you start the FS?

best wishes

Julius

Hi,

AES is only active in a region around the airports you have checked in AEShelp. It is not possible to keep it active all over the world, because the BGL Area is limited to a 30 Km Zone around the center of the BGL. Global areas are not possible (ok, are possible, but generate other problems).

So, aslong as you go to a AES supported airport on startup time, AES goes active once and allocate all memory it needs later. When you then go to a non AES airport, the memory is still allocated, so if you enter a AES area later, AES has his memory and don't get in trouble, when the memory is allready at the limit at this time.

[der_Julius 0]

Hi,

AES is only active in a region around the airports you have checked in AEShelp. It is not possible to keep it active all over the world, because the BGL Area is limited to a 30 Km Zone around the center of the BGL. Global areas are not possible (ok, are possible, but generate other problems).

So, aslong as you go to a AES supported airport on startup time, AES goes active once and allocate all memory it needs later. When you then go to a non AES airport, the memory is still allocated, so if you enter a AES area later, AES has his memory and don't get in trouble, when the memory is allready at the limit at this time.

Hey Oliver,

thank you for your fast answer.

Okay, I understand the problem about a global BGL-File.

So to avoid the trouble I load a flight on an AES Aiport and switch then to the airport I want to fly from..

Grüße

Julius

[altstiff 28]

I have been getting G3D.dll errors when flying from a non AES airport to an AES airport (for example KPVD to KBOS or CYVR to KSEA). If I go AES to AES )KPDX to KSEA) I do not get the error.

The error I get is G3D.dll error, nothing to do with memory errors. It seems to happen as I getting close to the AES aiport (maybe when AES starts to load?).

I do have the 3GB patch installed.

So what your saying Oliver, is to load a flight at an AES airport first?

Example>

CYVR to KPDX, I load at KPDX first, then swithc my plan to CYVR?

[OPabst 2091]

Correct, after start of FS go for a short time to a AES airport, so that AES can allocate the Memory. Then jump to you start airport and fly. When you then come close to the AES Airport, the memory for AES is allready in use, so you will get no problem.

[winsling 0]

Hello Oliver,

after installing /3GB patch, FS gets the g3d.dll Error for me too. So I tried the hints I've read in the discussions (placing aircraft at a AES airport at first).

I have installed AES 1.95a, FSUIPC3.8, FS9.1. The followings scenario was reproducible: (all airports but EDLP listed in the following description are AES served)

1. started FS at EDDF at the Gate, loaded Wilco A320 at 10 a.m.

2. moved to EDLP, runway heading west bound

3. takeoff, climb to 3000ft and flight direct to EDLW

4. over EDLW heading EDDL (if I had started _not_ at EDDF but direct at EDLP, the Simulator would have died already 2nm far from EDLW)

5. flight direct to EDDL , over EDDL heading EDDK

6. 2nm far from EDDK -> g3d.dll error

I will try other combinations...

with regards,

Falko

[altstiff 28]

Ok I may have found a fix for this little problem. Not 100% certain but so far in testing it has been working on 4 test flights now. Two each of KPVD-KBOS and CYVR-KSEA. Before the fix I would get a black screen and a g3d.dll error as I got near an AES airport flying from a non AES airport, I assume when AES tried to load.

Try this at your own risk! It is not supported by Aerosoft or me in anyway. It's a mere tweak I tried because I insist on using the 3GB fix on my FS9.exe (I get OOM errors with out the fix applied)

If you don't know what CFF explorer is then do not try this. If you have applied the 3GB fix to your FS9.exe you have a good grasp of what you doing anyway and you will know what CFF explorer is.

A) BACKUP your ViMacore2004.dll and ViMaIScn.dll files, keep them safe, this may or may not work for you. This way you can always go back....they are both found in your FS9 modules folder.....

Using CFF explorer I added the "App can handle >2GB addressest" fix to both the ViMacore2004.dll and ViMaIScn.dll files. You do it the same way you did to apply the 3GB fix to your FS9.exe, all your doing is telling these two dll files to use more ram too if needed.

Result?

No more gd3.dll errors..... (fingers crossed )

Ok now lets see what some others come up with in testing.....

[OPabst 2091]

Thanks for you tip, but as you say, no "supported" tweak at the moment. But I point Maurizio to this post, maybe he can include that to the DLL's so that this could fix the problem.

[tetiaroa 1]

I tell you Altstiff, I´d be the happiest guy alive, if that also did it for me!

I already tried this tweak a couple of months ago, but unfortunately the error still occured. :?

Tetiaroa

[altstiff 28]

I feel your pain.

But I just did a couple more flights and even used the slew feature to try and reproduce the error between these airports (KPVD-KBOS & CYVR & KSEA). This tweak seems to have fixed it for me. I could never do these flights before without getting the g3d.dll error.

Your problem may be different as I have not had a problem loading an airport and getting that error in the process.

I did have that problem a long while back loading a freight dogs airport in the fall. I suspected a wayward fall texture was causing it becasue spring summer and winter and at night, I never got error. I never did find a soloution. AES was not even around back then.

[altstiff 28]

BOOOO!

Ok NOT fixed. I tried it from EGGD to EGLL and as soon as AES activates (appx 6miles from EGLL) I get the black screen and the g3d.dll error again. For some reason it does not do on the other flights in North America.

I also applied the 3GB fix to the g3d.dll and got the same error.

Quick question for Oliver. What AES modules/dll's load when AES becomes active?

[winsling 0]

Hello,

patching the DLLs did n't work for me either. There are two ways approaching airport without g3d.dll error, deactivating AES for this airport or deactivating the >2GB switch for FS9.exe. :-/

Falko

[altstiff 28]

Hello,

patching the DLLs did n't work for me either. There are two ways approaching airport without g3d.dll error, deactivating AES for this airport or deactivating the >2GB switch for FS9.exe. :-/

Falko

Yes it is certainly looking that way.

With so many complexe airports and aircraft the 3GB fix is a must have, your going to get OOM errors if you do not use it when flying PMDG or other complexe aircraft into places like KORD, EDDF or EGLL.

I would hate to lose AES over this issue.

I'm wondering if having AES activate at say 20 or 50 miles would help?

EDIT: While I was doing all this testing I did not use my normal Active Sky and AI Smooth programmes.

I just did a test flight again from EGGD to EGLL using Active Sky and AI Smooth and did NOT get the error! This is getting stranger......