Jump to content

Archived

This topic is now archived and is closed to further replies.

OPabst

Ooms, Ctds And Maybe More ...

Recommended Posts

Hi Oliver,

just tested your update v.1.98a and unfortunately still got the same CTD about 4 miles from the tarmac.

However, I think I might have good news for everyone suffering from this problem, as I may have found a way of making your workaround

("placing your aircraft to an AES-supplied airport before departing from a Non-AES airport") more stable. I´ve been testing my

modification of it about 20 times by now and I NEVER had a CTD with it. Tested my most problematic routes, I always got CTDs before & new

ones as well, all without a single CTD.

@ everyone:

This is what I did (Oliver, if you don´t wanna read all the following, please go to the end, where it says "@ Oliver"):

1.

Tried to find every Landclass-file on my system that causes a memory-leak (still need the /3GB-patch, though):

  • Searched for empty texture-folders.
  • Searched for files called "WC*.bgl" in the entire FS9-folder & -subfolders and moved all of them to "FS9\scenery\Base\scenery".
  • Got FlightSim-Manager & its latest patches and consecutively searched for Landclass-files in each and every scenery-folder with an attached texture-folder.

    In case a LC-file was found, I searched for .bmp files in the attached texture folder, named with a number of about 8-15 digits followed by two letters (something

    like *su.bmp, *fa.bmp, *wi.bmp, *hw.bmp, *lm.bmp, *sp.bmp), and for .agn-files.

    Two results were possible:

    1. No files like the ones described above could be found in the texture folder -> moved the LC-file to the "FS9\scenery\Base\scenery" folder (that doesn´t have

      an attached texture-folder!)

    2. Files like the ones described above could be found. This case was a little trickier:

      I followed the "memory-leak-discovery-pattern" described earlier in this thread and checked if this particular scenery had a leak.

      If it did have a leak, I used "filemon" to see which files were missing and causing the leak.

      In case I could find those missing files in any other texture-folder of FS (mostly they were located in "FS\texture"),

      I copied them into the texture folder of the scenery being investigated (the one where filemon said, FS couldn´t find them).

      In case I found all the missing files and the leak was gone, I left the scenery installed; otherwise, I uninstalled it.

2.

Made sure "AES-lite" supplied airports use the latest version of it that is updated to be compatible with the /3Gb-patch

(Frankfurt_2008 for instance has a compatible version, for other sceneries you´ll have to refer to Oliver).

3.

Some sceneries with moving ground traffic, e.g. "Overland´s Kansai" together with "URAKAWA - APT GROUND VEHICLES

for Kansai" can cause a very similar "g3d.dll"-induced CTD when arriving there from an AES-supported airport (even if Kansai

itself is not AES-supplied!!!). This kind of CTD doesn´t neccesarely only occur on final approach, but can also happen when just

flying over the aiport at high altitudes. Moving the airplane before departure from an AES-supplied airport to such an airport

should solve that.

BTW, I think that this could also be the reason for the CTDs, "Psolk" reported, when flying from an AES-supplied airport to a

Non-AES-supplied-UK2000 airport.

4.

Last thing I found was that when using Oliver´s "workaround", it was vitally important for the workaround to work properly, to move the

plane to a gate with MOVING JETWAYS at the AES-supplied airport before departure, wait there a couple of seconds until the jetway docks

at the airplane and then go to the Non-AES-airport for departure.

Attending to these 4 steps got AES back on my system :-) :-) and will hopefully help others too!

@ Oliver:

1.

I think the most problematic part of loading AES at the arrival airport with active /3GB-patch is the moment the Jetways are being loaded.

I remembered that you once gave me an AES-test-version without moving Jetways which worked fine. Therefore tested your workaround again

in two different ways:

1. Moving to an AES-airport with moving Jetways prior to departure from a Non-AES airport and

2. moving to an AES-airport without moving Jetways prior to departure from a Non-AES airport.

Test No.1 never caused the CTD when flying to an AES-supplied airport with moving Jetways

Test No.2 always caused the CTD.

So maybe this is, where the core of the problem could probably be found?!

2.

Can you tell me which "AES-lite" supplied airports use the new and updated version of it, which works with the /3GB-patch (such as the

one in Frankfurt_2008)?

3.

Do you have any news on "Cloud9-KLAX", if it will ever be updated to be supportable by AES? It´d be sooooo awesome to have an AES-KLAX!!!

Cheers,

-Tetiaroa

Share this post


Link to post

Hi,

thanks for your long feedback. I will take a look to the jetways, maybe I will find a reason, why they are important to prevent the CTD.

As the errors I found now, I think it is possible that I find more, when I port the code to FSX, because there, the engine is maybe not so stayable and shows up problems much faster.

Regarding AESlite: A new version for all GAP2 airports based on the new code is on the way, but not finished now.

Regarding KLAX look to the statement I made here: http://www.fsdreamteam.com/forum/index.php?topic=1001.0

Share this post


Link to post

Hi Oliver,

thanks for your update and your efforts on KLAX!

I did some more testing of the tweak, I described above, and still didn´t get any CTDs anymore! Isn´t that AWESOME?!

Still, I found one more problem, you might know how to deal with:

"Apt Ground Vehicles" by "Urakawa Dynamic Factory" seems to have the same problem with the /3Gb-patch & AES as the old version of "AES-lite" (at least at "Overland´s Kansai Intl."), which means that the sim crashes ("g3d.dll") when flying to Kansai with active "Apt Ground Vehicles" and AES or when arriving there from an airport with active AES. Moving the airplane to Kansai to a gate with jetways prior to flying there from another airport helps, but that isn´t a 100% save method - it still crashes sometimes.

Well, I don´t know, if you know about this addon for Overland airports at all, but I was just wondering, if you could maybe take a look into the code of "Apt Ground Vehicles" and see where the problem is located or - if that is impossible - maybe tell the developers of "Urakawa Dynamic Factory" how to change the code to avoid those CTDs with their addon and AES & the /3Gb-patch?

Anyways, everything else works fine now using the workaround, so if solving this issue as well meant too much trouble for you...never mind, you´ve done enough for me and for that I just wanted to say

THANK YOU VERY MUCH :rolleyes:

Best regards,

Tetiaroa

PS: 2 more helpful advices for other simmers:

  • Never raise the sim-rate above 4x when using the pushback feature of AES -> the pushback truck will disappear and the aircraft will stay stuck on ground after the pushback (without truck now) finishes. There´s nothing you can do to get the aircraft moving in that situation except restarting the sim.
  • In case you are using ASv6.5, do not download and use the hour "January 25th 2006, 2100z". This file is not working properly (at least in the area of EDDF) and causing problems with your airspeed indicator (at least the one of the "PMDG 747-400" ).

Share this post


Link to post

Any new information on this subject, I have been getting regular OOM flying longer flights into AES airports such as KJFK lately. Just curious if a tool or a "procedure" has been found to assist with some fix here?

Joe

Share this post


Link to post

I appreciate Tetiaroa's assistance in providing a work around, but frankly it's way more work than I'm prepared to put in to fix something that works flawlessly without AES. Oliver has stated that he believes this to be a kind of "straw that broke the camels back" scenario where AES is only the final piece in the puzzle causing crashes. I personally can not subscribe to that theory as I continue to add other add-ons, including beefing up AI usage, without any crashes whatsoever. I believe AES to have a fundamental flaw when combined with the /3GB switch and I fear those suffering from it will have to continue to do so. Despite being a wonderful add on that I used heavily prior to converting to the /3GB switch, it remains deactivated on my system today as it is too unstable.

Share this post


Link to post

Yes, I sure hope there is a cure for this. It is getting very irritating to put in a long flight and get an OOM on 2 mile final. Just happened with AES KORD . . .

Hope to hear an update or possible solution soon.

Joe

Share this post


Link to post

HI ...

a rather outdated thread, but nevertheless very interesting - thanks a lot for this, Oli :) !

But one question remains for me: i don`t quite undestand the sentence:

"2.) FranceVFR Mediterranee Basepack

Two files generate memory usage: wc_fmbp_e.bgl and wc_fmbp_w.bgl

Moving this two files to a seperate LC Scenery directory entry will solve the problem for me.

how does that work exactly ? another folder named e.g. "LC_Med II", therein a "scenery" folder with the two files in it and this one declared in the scenery bibl. ? am I right in this ?

And my memory usage seems to be always very high ... ~ 600 MB with standard scenery, ~ 800 MB with addons and between roughly 1.1 and 1.5 GB with usage of phototerrain ... nevertheless I don`t suffer from memory leaks very often, although I own all mentioned sceneries. Only VFR Mediteranee has always been a problem on my system ...

Share this post


Link to post
how does that work exactly ? another folder named e.g. "LC_Med II", therein a "scenery" folder with the two files in it and this one declared in the scenery bibl. ? am I right in this ?

In this case, correct. Important is, that there is no TEXTURE directory beside, only a SCENERY Directory. In this case, the FS will go directly to his own TEXTURE folder and don't try to find the Landclass bitmaps in the subordinated TEXTURE folder, which generate the Memory leak, because he allocates memory for the BMP, but never give it back.

In some cases, the Landclass BGLs use local and default BMP the same time, then the move does not help, because in this case you miss the local Textures. Then you only can disable the BGL.

I just found another Scenery, which has this problem: Freeware Danzig ( http://library.avsim.net/esearch.php?CatID...amp;DLID=128249 ) here the file EPGD_okolica.BGL in EPGD_okolica.off renamed, the problem is gone, but also the groundtextures.

Share this post


Link to post

Okay, thanks a lot Oli ... really a very helpful hint ! but gives me a lot to do now ;) ...

Share this post


Link to post
Okay, thanks a lot Oli ... really a very helpful hint ! but gives me a lot to do now ;) ...

OK, my 2cents...

1. The g3d.dll issue is different than an OOM error. That is a 32 bit OS limitation when you bloat FS with a ton of add-ons and all of Oliver's Landclass advice would be good to follow.

2. The G3D.dll error has nothing to do with the /3gb entry in the boot.ini. It has to do with FS9 being largeaddressaware. I run XP 64 with 4 gigs of physical memory and still only enable the 2 sceneries I am flying between on any particular flight to keep FS a lean as possible. Running XP64 eliminates the /3gb entry but I still need the largeaddressaware flag in the fs9.exe to really use XP 64 and those 4 gigs of memory. I can fly the PMDG 744 for days now with no issues at all but I still get a G3D.dll error when approaching EGCC from AES enabled KEWR. I can recreate it everytime. I can also disable AES and complete the flight everytime. I have checked both KEWR and EGCC for LC issues and there are none. So the only other possible issue is AES conflicting with FS9 when it is largeaddressaware as there are no other sceneries active.

I am going to try disabling the dynamic traffic at EGCC to see if that helps as suggested above

BUT...

If the issue is really with AES and the largeaddressaware flag in the executable then what will happen with FSX that has the largeaddressaware flag set by default as vanilla FSX was crashing with OOM errors on 32 bit OS's without it so MS changed it with SP1 or 2. I am just throwing it out there because if this is the issue with FS9 will we have the same issue with AES and FSX and have to fly exclusively between AES enabled airports like we do in FS9? :huh:

Share this post


Link to post
2. The G3D.dll error has nothing to do with the /3gb entry in the boot.ini. It has to do with FS9 being largeaddressaware. I run XP 64 with 4 gigs of physical memory and still only enable the 2 sceneries I am flying between on any particular flight to keep FS a lean as possible. Running XP64 eliminates the /3gb entry but I still get a G3D.dll error when approaching EGCC from AES enabled KEWR. I can recreate it everytime. I can also disable AES and complete the flight everytime. I have checked both KEWR and EGCC for LC issues and there are none. So the only other possible issue is AES conflicting with FS9 when it is largeaddressaware.

I am going to try disabling the dynamic traffic at EGCC to see if that helps as suggested above

I don't want to say, that what you see is not true, but can you please explain me, how a programm code can generate CTD's on g3D.dll, when here is no code in memory? When you fly from a AES airport, AES and all his modules are in Memory, so far so good. All AES BGL's (the AESA_*.BGL you see in the SCENERY folder are limited by header, Refpoint range and so on to the region of the airport. The FS it self will remove all this code, latested 25NM away for the LAT/LON of the Airport. That mean, that no code is executed anymore, no Libobject call can be done and no AES related codeline is active when you reach the final airport (when it is no AES supported).

I have no idea, where I should search for a CTD generating code line, when the is no codeline active at this moment. Thats my problem to help you.

Btw: The Vistamare modules are also doing nothing, as long as no other code is calling function for this modules. Only the memory, which was allocated by AES on your depature airport is still allocated over the howl session. This is the only part maybe different to a flight with deactive AES. But the size of the AES memory is very small, releated to all the rest you need for the FS.

The only possible theory I have is, that under very special conditions, the Scenery engine gets in conflict to allocate memory to load the object of your destination scenery and so the G3D.dll module will crash. This can also be generated by a code bug of the scenery, which could normally handled or has no visual effect, but when the AES memory is in place, maybe it comes up.

So, when this problem does not happen, when you fly into another non-AES destination, maybe the scenery is involved in the problem. Is it EGCC from Gary (UK2000)? Maybe then I can have a look there.

Share this post


Link to post
I don't want to say, that what you see is not true, but can you please explain me, how a programm code can generate CTD's on g3D.dll, when here is no code in memory? When you fly from a AES airport, AES and all his modules are in Memory, so far so good. All AES BGL's (the AESA_*.BGL you see in the SCENERY folder are limited by header, Refpoint range and so on to the region of the airport. The FS it self will remove all this code, latested 25NM away for the LAT/LON of the Airport. That mean, that no code is executed anymore, no Libobject call can be done and no AES related codeline is active when you reach the final airport (when it is no AES supported).

I have no idea, where I should search for a CTD generating code line, when the is no codeline active at this moment. Thats my problem to help you.

Btw: The Vistamare modules are also doing nothing, as long as no other code is calling function for this modules. Only the memory, which was allocated by AES on your depature airport is still allocated over the howl session. This is the only part maybe different to a flight with deactive AES. But the size of the AES memory is very small, releated to all the rest you need for the FS.

The only possible theory I have is, that under very special conditions, the Scenery engine gets in conflict to allocate memory to load the object of your destination scenery and so the G3D.dll module will crash. This can also be generated by a code bug of the scenery, which could normally handled or has no visual effect, but when the AES memory is in place, maybe it comes up.

So, when this problem does not happen, when you fly into another non-AES destination, maybe the scenery is involved in the problem. Is it EGCC from Gary (UK2000)? Maybe then I can have a look there.

Hi Oliver,

Thanks for taking the time to reply Oliver, I know you are busy right now!!!

Obviously you have a lot more knowledge on this than I do, i am just reporting what I see and what I can recreate :). I think your comment "The only possible theory I have is, that under very special conditions, the Scenery engine gets in conflict to allocate memory to load the object of your destination scenery and so the G3D.dll module will crash." could be valid and that is why I am going to try removing the dynamic scenery as suggested earlier. That is my next test today. Perhaps it is a conflict. I really don't think this is a pure AES issue, the only aspect of real flying and FS flying that are similar is that it is never 1 thing that causes a crash, it is a series of problems and I think AES is just part of what is happening, not the root cause...

I did forget to mention that UTUSA and UTEurope are also both active but I think you already checked them and I went through Filemon with them as well. So literally the only two sceneries active are ImagineSim KEWR with AES and UK2000 EGCC with no AES.

Thank you again Oliver your efforts are GREATLY appreciated!

-Paul

Share this post


Link to post
Hi Oliver,

Thanks for taking the time to reply Oliver, I know you are busy right now!!!

Obviously you have a lot more knowledge on this than I do, i am just reporting what I see and what I can recreate :). I think your comment "The only possible theory I have is, that under very special conditions, the Scenery engine gets in conflict to allocate memory to load the object of your destination scenery and so the G3D.dll module will crash." could be valid and that is why I am going to try removing the dynamic scenery as suggested earlier. That is my next test today. Perhaps it is a conflict. I really don't think this is a pure AES issue, the only aspect of real flying and FS flying that are similar is that it is never 1 thing that causes a crash, it is a series of problems and I think AES is just part of what is happening, not the root cause...

I did forget to mention that UTUSA and UTEurope are also both active but I think you already checked them and I went through Filemon with them as well. So literally the only two sceneries active are ImagineSim KEWR with AES and UK2000 EGCC with no AES.

Thank you again Oliver your efforts are GREATLY appreciated!

-Paul

So I tried disabling the dynamic scenery and loading KEWR at an AES gate, switching to EGCC and then back to KEWR before starting my pre-flight and that resulted in a successful flight. I am trying again without changing anything to see if I am successful again but this time no switching scenery before the flight. That would point to the dynamic scenery as suggested above.

I might have done some fuel predictions wrong though because right now it looks like I am going to come into EGCC on fumes. I wonder if the winds changed :o I might have bigger problems than AES ;)

I am hoping the issues is indeed with the dynamic scenery .bgl egcc is using...

Just an update,

-Paul

Share this post


Link to post
So I tried disabling the dynamic scenery and loading KEWR at an AES gate, switching to EGCC and then back to KEWR before starting my pre-flight and that resulted in a successful flight. I am trying again without changing anything to see if I am successful again but this time no switching scenery before the flight. That would point to the dynamic scenery as suggested above.

I might have done some fuel predictions wrong though because right now it looks like I am going to come into EGCC on fumes. I wonder if the winds changed :o I might have bigger problems than AES ;)

I am hoping the issues is indeed with the dynamic scenery .bgl egcc is using...

Just an update,

-Paul

Successful again last night with dynamic vehicles disabled. Trying again today and then probably going to go get Heathrow Extreme to use with 1.99 :)

If I can do another successful flight today that will be 3 since disabling Dynamic Vehicles...

So this could hopefully resolve my issue with flying from AES KEWR to non-AES EGCC but then I need to start worrying about what happens when I fly back from non-AES EGCC to AES enabled KEWR... ;)

-Paul

Share this post


Link to post
Successful again last night with dynamic vehicles disabled. Trying again today and then probably going to go get Heathrow Extreme to use with 1.99 :)

If I can do another successful flight today that will be 3 since disabling Dynamic Vehicles...

So this could hopefully resolve my issue with flying from AES KEWR to non-AES EGCC but then I need to start worrying about what happens when I fly back from non-AES EGCC to AES enabled KEWR... ;)

-Paul

You see, there are many way to problems, not only AES. When you fly back, first go short to an AES active airport, so that AES was active after start of the FS, then I would not expect problems when you come from a non AES airport into an AES driven one.

Share this post


Link to post
You see, there are many way to problems, not only AES. When you fly back, first go short to an AES active airport, so that AES was active after start of the FS, then I would not expect problems when you come from a non AES airport into an AES driven one.

Thanks Oliver!

I will continue to report back with status updates.

-Paul

Share this post


Link to post

Ok let me explain to you how my system works:

No 3gb patch, AES works fine. UT crashes my system with OOM errors.

Add the 3gb patch, AES causes g3d.dll crashes. and UT works flawlessly

It really is that simple.

Chris

Share this post


Link to post
KORD seams to be ok, no Landclass included.

The easiest Test to check, if a area is critical, you can do the test I have done:

1) download and unzip Filemon into a directory and make a link on the desktop for easy start.

2) Save a default flight in FS with Cessna, clear weather, AI traffic off

3) Start filemon, go to Volumes Menu and select the drive of your FS

4) Apply a filter like this:

include = FILE NOT FOUND

exclude = .fx;.CAB;.agn;uteur

(the uteur is to exclude UTE, so if you have other UT maybe change or add that)

Now, jump via Goto Menu to a Airport, where you want to check the area, then check if you see

FILE NOT FOUND events, where the Path is the Addon Texture directory and the Filenames are very long numbers like 012121103311011Su.bmp or in this schema: 058b2su2.bmp

Both indicate, that a Landclass file in the addondirectory looks for BMPs not available in that local Texture dir.

When you leave the fs at this position and only monitor the filemon, you will see that this events are happens every some minutes, even when you don't touch the FS.

When you open the Taskman and check the virtual memory in the processpage for the FS9.EXE, you will see that the memory grows every loadcycle.

I have now a tool, that can identify Lanclass BGLs in addon directories, where a Texture subdir exists, but I can't say, if the needed BMP's are all present, because therefor I must decrypt the BGL format to get the needed BMP names, which are not stored there. Very complex process. I hope, that after my holidays I can go forward here.

But: Keep in mind, that if you remove Landclass files or move them to a seperate entry, you may change the visual effect of your addon. Allways make a backup and document, where you make the change, so you can go back to default.

Hi Oliver,

can you describe how we can do this same procedure using Sysinternals' Process monitor ?

Thanks

Share this post


Link to post

Hi!

Is anyone having problems with EGBB Birmingham Xtreme v1.1 and AES (1.99a)?

I'm asking because I tried many flights from LOWW(AES) to EGBB(AES) and got allways a CTD (g3d.dll and/or g2d.dll). It happens just before VORLOC intercept for rwy 15. Sometimes I could reach ILS full stablished, but never got to the runway.

I tried to load AES at EGBB before going to the departure airport but with no results.

Then I disabled the 3GB switch and... the same CTD. :(

Finally I disabled AES from the scenery library and I could make the flight.

So... anyone? :blink:

Tanks in advance and best regards, ;)

Share this post


Link to post
Hi!

Is anyone having problems with EGBB Birmingham Xtreme v1.1 and AES (1.99a)?

I'm asking because I tried many flights from LOWW(AES) to EGBB(AES) and got allways a CTD (g3d.dll and/or g2d.dll). It happens just before VORLOC intercept for rwy 15. Sometimes I could reach ILS full stablished, but never got to the runway.

I tried to load AES at EGBB before going to the departure airport but with no results.

Then I disabled the 3GB switch and... the same CTD. :(

Finally I disabled AES from the scenery library and I could make the flight.

So... anyone? :blink:

Tanks in advance and best regards, ;)

Disabling ground animations at EGBB solves the issue

Share this post


Link to post
Hi, Found this (4Gb patch), Does anyone know this will help? Before I download it I would like to know :rolleyes:

http://www.suprunovdesign.ru/forums/viewtopic.php?t=406

http://ntcore.com/4gb_patch.php

//Frank

Yes, it helps great deal. Here's what I posted at the Coolsky forum, note that you might require new registrations for a few Addon products that have a hardware-registration:

The OOM issue (not only with the Super 80) is pretty much solved:

I have tortured both FS9 and the S80 over the past nights and finally believe to have found something that *does* work.

1) make a backup copy of your fs9.exe

2) download this little tool: http://ntcore.com/4gb_patch.php

3) use it to patch your fs9.exe (the tool is self explanatory)

4) add following parameters to your boot.ini file: /3GB /userva=2560

The sollutions I came across so far all lacked the parameter /userva=2560 - so don't mix this up with something that didn't work for you in the past.

Also one of the reasons NOT to try this was solved with DirectX 9c (missing textures on some machines and other oddities).

Now on to the boot.ini file:

Example:

Before:

multi(0)disk(1)rdisk(0)partition(1)\WINDOWS="Windows XP Professional" /fastdetect

After:

multi(0)disk(1)rdisk(0)partition(1)\WINDOWS="Windows XP Professional" /fastdetect /3GB /userva=2560

5) Reboot

No more OOM errors.

IMPORTANT:

Do this at your own risk. This modification should not harm you computer in any way, you can always easily revert the original settings by removing the added parameters from the boot.ini file

Share this post


Link to post

YES.... it seems to work, now I can fly from Vienna to London with NO OOM's ;)

But I still have to do some more testing this weekend....

Share this post


Link to post

I have been reproducing a OoM while flying from non-AES to AES several times now.

I use the /3GB switch as well as the patched fs9.exe to allow for it (see post above).

Also I noticed the fs9.exe consumed no more than 1.4GB of my 3GB while giving the OoM-error.

I will try without ActiveSky as well as reverting the 3GB patch.

Share this post


Link to post
Guest
This topic is now closed to further replies.

×
×
  • Create New...