Jump to content

G3d.dll Errors With Aes And 3gb Patch


Recommended Posts

  • Developer
Ok, will test and post results.

Just for the record. Slewing from airport to airport does not always bring on the CTD. So I think that the best way to test is to actually fly in real time.

I did (in the past while testing the DLL's with the 3GB patch enabled) try slewing and it was muich more at random. Flying in real time from NON AES to AES almost always gives the error (99% of the time).

Off to test....

Ok, then make Test 5 first, when it give the CTD, then go back to 4 and 3, so it is maybe faster to see. If 5 will not give the CTD, I will expect that 3+4 also will be ok.

Link to comment
Share on other sites

  • Replies 181
  • Created
  • Last Reply

Top Posters In This Topic

Ok, then make Test 5 first, when it give the CTD, then go back to 4 and 3, so it is maybe faster to see. If 5 will not give the CTD, I will expect that 3+4 also will be ok.

CYVR - KSEA

Ok started with test step 5 zip

green sign SUCESS!!!!

Ok no CTD so far.

How we doing Oliver?

Link to comment
Share on other sites

OK, tested the last 3 files:

Test_Step_3.zip

Test_Step_4.zip

Test_Step_5.zip

Test_Step_2.zip seemed to have been removed before I saw it - if there was any file for a 2nd test.

Got the green box "AES loaded success! AES deactivated" and no CTDs with any of these files.

Verified the result afterwards by again testing the original-file that always caused the CTDs and it confirmed the result - saying, the original-file causes a CTD the test-files 3+4+5 don´t!

Seems you´re getting closer to the core of it! Looking forward to tomorrow!

Link to comment
Share on other sites

More tomorrow...

Working excellent here Oliver.

Did another test flight EGGD - EGLL, that flight always caused a G3d.dll error for me.

Using test zip 5 I got the green sign and no errors again, #5 cured the CTD's so far. Have not tried (#3&#4).

Looking good!

Hope more people test.

Link to comment
Share on other sites

  • Developer

Ok, next steps:

  • Make a backup of the AES_LC*.BGL files you find in ..\Aerosoft\AES\SCENERY
  • Unzip the files of "Test Step 6.zip" to ..\Aerosoft\AES\Scenery

Then try to fly and see if you still get a CTD. This files are full function and if you don't get the CTD, all should work as normal. I have changes several loadparts, so it is possible that this will work, maybe not.

If you get the CTD, then unzip the files of "Test Step 7.zip" to ..\Aerosoft\AES\Scenery, keep the other files as in Test Step 6 (don't replace them with the backup!)

Then Fly again. Now you will get the green window, when AES is loaded. In this case, you see a number (starting 00 or 01) behind the text "AES is loaded to Step >". This number is important, so tell me, which number you have seen last, before the CTD comes up (if it comes).

The number will increment allways when you press F1 in that window. So go step to step by pressing F1. In some numbers, you need to press several times F1 until they increment (like in Step 17)

When you have reached step 38, the next step will be to start AES complete. After that, AES should work as normal.

It is possible, that the delay by pressing step by step will prevent the CTD, but that is also a result as then we can maybe try to delay the load.

Let us see what happens.

Link to comment
Share on other sites

Ok, next steps:

  • Make a backup of the AES_LC*.BGL files you find in ..\Aerosoft\AES\SCENERY
  • Unzip the files of "Test Step 6.zip" to ..\Aerosoft\AES\Scenery

Then try to fly and see if you still get a CTD. This files are full function and if you don't get the CTD, all should work as normal. I have changes several loadparts, so it is possible that this will work, maybe not.

If you get the CTD, then unzip the files of "Test Step 7.zip" to ..\Aerosoft\AES\Scenery, keep the other files as in Test Step 6 (don't replace them with the backup!)

Then Fly again. Now you will get the green window, when AES is loaded. In this case, you see a number (starting 00 or 01) behind the text "AES is loaded to Step >". This number is important, so tell me, which number you have seen last, before the CTD comes up (if it comes).

The number will increment allways when you press F1 in that window. So go step to step by pressing F1. In some numbers, you need to press several times F1 until they increment (like in Step 17)

When you have reached step 38, the next step will be to start AES complete. After that, AES should work as normal.

It is possible, that the delay by pressing step by step will prevent the CTD, but that is also a result as then we can maybe try to delay the load.

Let us see what happens.

Ok, going to try test zip 6 first. If all goes well we are cured.

If I get the CTD I will try test zip 7 and hit F1 until I see where the load problem is coming from.

I won't be able to test this until later this afternoon (that would be late eveing in Germany). I hope some others can post their results.

Link to comment
Share on other sites

Alright tested both:

Test_Step_6.zip

Test_Step_7.zip

Test_Step_6.zip: Even though "Test_Step_6.zip" seemed to improve things a little (not as frequently a CTD), the "g3d.dll"-related CTDs still occured in that situation that always caused them with active AES

Test_Step_7.zip: "g3d.dll"-CTDs before even hitting F1 once - happening without exeptions in that criticial situation described above.

Hope that helps a little!

Best regards

-Tetiaroa

Link to comment
Share on other sites

Alright tested both:

Test_Step_6.zip

Test_Step_7.zip

Test_Step_6.zip: Even though "Test_Step_6.zip" seemed to improve things a little (not as frequently a CTD), the "g3d.dll"-related CTDs still occured in that situation that always caused them with active AES

Test_Step_7.zip: "g3d.dll"-CTDs before even hitting F1 once - happening without exeptions in that criticial situation described above.

Hope that helps a little!

Best regards

-Tetiaroa

I would like to add that I tested zip 6 (EGGD - EGLL) and got a CTD on very short finals (four miles out) only a Vimaisnc.dll error as the cause this time.

I will test more later on.

Link to comment
Share on other sites

  • Developer
Alright tested both:

Test_Step_6.zip

Test_Step_7.zip

Test_Step_6.zip: Even though "Test_Step_6.zip" seemed to improve things a little (not as frequently a CTD), the "g3d.dll"-related CTDs still occured in that situation that always caused them with active AES

Test_Step_7.zip: "g3d.dll"-CTDs before even hitting F1 once - happening without exeptions in that criticial situation described above.

Hope that helps a little!

Best regards

-Tetiaroa

Hi,

does that mean, Step 7 will never work, Step 6 sometimes?

Which airport you are testing? When you unckeck that airport, the CTD is not coming?

Link to comment
Share on other sites

Um...my last post might have been a bit confusing. Let my try to shed some light on it:

I mostly test one special situation that usually (about 80%) causes the CTD:

1. A PMDG 747-400 with FS2Crew installed located at Frankfurt MegaAirport at a certain Gate and time (usually it most certainly happens at summer time during dusk) - btw also have UT-Europe installed (big memory-load as well).

Usually about 5sec after FS finished loading this startup scenario -> CTD

If that didn´t cause a CTD at this point, I consider things to be a little more stable - after repeating it a couple of times to be sure - and continue on with the next test:

2. Same scenario as above but additionally I use a modified terrain.cfg that works perfectly fine UNLESS AES is activated.

With this modification I could induce a CTD in the scenario above with active AES at 100%.

In case I´m not getting a CTD in that situation either (only happened with test 3+4+5 or deactivated AES), I can be pretty sure everything works as it should; but to be completely on the save side I then do my last testing:

3. Flying some test routes to see if it works, also including other AES-supported airports such as EIDW-EDDF, KLAX-KSFO, LEIB-EDDM or for long haul testing KLAX-EDDF (didn´t do this one for test-files 3+4+5 so far as my test with the modified terrain.cfg and Altstiffs testing already suggested that they work).

Now, to answer your questions, during my "testing-scenarios 1+2+3" (now referred to as T1, T2 and T3) both steps (6+7) acted similar:

T1: Step 6 AND step 7 worked sometimes, but sometimes also caused a CTD (esp. when pressing F1 fastly) -> they both work better than the original files as with them, the rate of CTDs was about 90% with step 6+7 only about 50%.

T2: 100% CTDs with both steps

T3: not tested as T2 didn´t work.

If I uncheck MegaAirport Frankfurt and test at EDDF -> all good.

If I test a flight to another AES-supported and activated airport (with EDDF unchecked) -> CTD at 100%.

Hope I could clarify things a little!

-Tetiaroa

Step 7 actually DOES work sometimes as well as step 6, but both of them also caused CTDs

Link to comment
Share on other sites

Forgot to mention 2 things:

1. The exact modification of my terrain.cfg: All lines beginning with "MaskClassMap=3" or "MaskClassMap=1" are renamed to "MaskClassMap=0"

2. The fact that it happens most certainly at EDDF during summer-time and dusk could also lead to the assumption, the CTDs there could also be related to a missing texture or an empty texture folder; but I already double-, tripple- and quadripple-checked that that´s not the case and apart from that...without AES it works.

Link to comment
Share on other sites

Hi,

have done a test flight with "Test Step 6.zip". This was a flight from GAP EDXW (without AES activated) to FSDreamTeam LSZH (with AES) using the Maddog 2006. Also I have activated all known memory eating sceneries, like UT and German Landmarks for this flight.

- 10 miles final the memory usage of FS9.exe was ~850MB, i have saved the flight.

- 6 miles final CTD with blank screen

- I have loaded the flight 10 miles final, memory consumption ~650MB. Flight could be ended without any problem with all AES stuff like taxi and docking.

I have found out that the memory usage of FS9.exe must not be higher then 600-650MB, then AES works fine. Possible that the usage of a lot of addon sceneries is fragmenting the FS9 heap so that there not enough space for AES functions?

Also I think the FS is crashing when a lot of scenery stuff is loading like the LSZH scenery. It seems to be that the trigger for loading the complex airport scenery is the same then the "AES crash".

Should I proceed with test no.7?

Stefan

Link to comment
Share on other sites

Hi,

have done a test flight with "Test Step 6.zip". This was a flight from GAP EDXW (without AES activated) to FSDreamTeam LSZH (with AES) using the Maddog 2006. Also I have activated all known memory eating sceneries, like UT and German Landmarks for this flight.

- 10 miles final the memory usage of FS9.exe was ~850MB, i have saved the flight.

- 6 miles final CTD with blank screen

- I have loaded the flight 10 miles final, memory consumption ~650MB. Flight could be ended without any problem with all AES stuff like taxi and docking.

I have found out that the memory usage of FS9.exe must not be higher then 600-650MB, then AES works fine. Possible that the usage of a lot of addon sceneries is fragmenting the FS9 heap so that there not enough space for AES functions?

Also I think the FS is crashing when a lot of scenery stuff is loading like the LSZH scenery. It seems to be that the trigger for loading the complex airport scenery is the same then the "AES crash".

Should I proceed with test no.7?

Stefan

This test if for those using the 3GB "patch" and getting g3d.dll errors.

I am going to test zip 7 Oliver. I get a ctd with the g3d.dll error at EGLL 99.9% of the time when flying from a non AES airport, if I remove AES I never get the error.....

Link to comment
Share on other sites

  • Developer
Should I proceed with test no.7?

Stefan

Yes please. Test 6 is only to know if it still happens, test 7 is more interesting for me.

Link to comment
Share on other sites

  • Developer
This test if for those using the 3GB "patch" and getting g3d.dll errors.

I am going to test zip 7 Oliver. I get a ctd with the g3d.dll error at EGLL 99.9% of the time when flying from a non AES airport, if I remove AES I never get the error.....

Yes, that what I understand. There seams to be different problems. You did not get the problem, when you load a flight direct at a AES airport,right? So, the problem of tetiaroa seam to be different.

Link to comment
Share on other sites

I have found out that the memory usage of FS9.exe must not be higher then 600-650MB, then AES works fine. Possible that the usage of a lot of addon sceneries is fragmenting the FS9 heap so that there not enough space for AES functions?

Also I think the FS is crashing when a lot of scenery stuff is loading like the LSZH scenery. It seems to be that the trigger for loading the complex airport scenery is the same then the "AES crash".

I don´t think it´s a lack of memory by being too fragmented - I mean, the lack of memory was the reason we installed the /3GB-patch in the first place, so there should be enough of it now (remember the patch allows FS9 to use more than 2GBs of memory!). ;)

I think it´s rather due to a problem with the modules ViMaIScn.dll and ViMaCore2004.dll used by AES that seem to have a virtual-memory allocation problem when using the patch and high memory loads require using addresses that normally couldn´t/wouldn´t be used with 2GBs only.

But that´s also just an assumption, Oliver might know way more and better about the core of the problem.

Tetiaroa

Link to comment
Share on other sites

Ok, tested #7

Results after two flights (EGGD - EGLL), I choose this because I get a CTD and error there 99.9% of the time....

I get the green screen, start pushing F1 repeatedly, and I can get to step 23 both times, then I get the CTD only it's the vimaiscn.dll giving me the error, not g3d.dll......

Also as a side note Oliver. I can load at and AES airport just fine. The only AES airport I couldn't load is KSEA. Keep in mind I have all of Richard Goldstiens Geo Renders that also utilize the same modules from Marizio. I diabled all the geo renders and I can load KSEA with AES activated.

Link to comment
Share on other sites

Oliver, I also only accidently came across that one situation, where I can induce it upon startup. Normally the circumstances are exactly the same as Altstiff´s.

I just figured that if I can find a startup situation where FS uses as much memory as possible, it could happen upon startup as well. Even though I then found it rather accidently, but the situation is quite memory intense anyways, so my assumption might have been right.

BTW, saving a flight upon landing, shutting down FS and restarting it with the previously saved flight, seems to diminish the memory-usage so much so that it´s actually not enough to cause a CTD in most cases anymore. Same thing when "slewing" instead of "flying".

Link to comment
Share on other sites

Oliver, I also only accidently came across that one situation, where I can induce it upon startup. Normally the circumstances are exactly the same as Altstiff´s.

I just figured that if I can find a startup situation where FS uses as much memory as possible, it could happen upon startup as well. Even though I then found it rather accidently, but the situation is quite memory intense anyways, so my assumption might have been right.

BTW, saving a flight upon landing, shutting down FS and restarting it with the previously saved flight, seems to diminish the memory-usage so much so that it´s actually not enough to cause a CTD in most cases anymore. Same thing when "slewing" instead of "flying".

Agreed, slewing as little effect on the CTD and it is much more at random when slewing.

For my testing I am starting at a non AES airport roughly 80nm away from an AES airport. Like I said, I can almost always reproduce the error on a flight from EGGD - EGLL.

Link to comment
Share on other sites

This test if for those using the 3GB "patch" and getting g3d.dll errors.

I am going to test zip 7 Oliver. I get a ctd with the g3d.dll error at EGLL 99.9% of the time when flying from a non AES airport, if I remove AES I never get the error.....

Hi,

I'm also use the 3GB patch, without I'm not able to do complete flight with the Suprunov Yak-40.

What exactly is the "g3d.dll" error? When my FS9 is crashing I get only a black screen without any error messages, like a freeze. After some seconds I get a dialog which would like to restart the FS9.

I have these crashes only on short final, at the point where AES seems to be triggered and initialized. Reloading a saved flight or slewing the aircraft does not force problems.

Stefan

[Edit] The module which is crashing is the vimaiscn.dll, have seen this in the additional dialog info

Link to comment
Share on other sites

  • Developer
I get the green screen, start pushing F1 repeatedly, and I can get to step 23 both times, then I get the CTD only it's the vimaiscn.dll giving me the error, not g3d.dll......

Thats a good info, so I will check this evening, what happens in this state.

Link to comment
Share on other sites

  • Developer

Ok for all Tester:

The problem wil have to do with the initial load of the AES related modules and/or the Memory need to be allocated at this moment. So the following question are important to know, before you post any statements:

Q1: Do you use the 3GB patch YES/NO

Q2:

-Wenn you start the FS (with a safed flight or by selecting the Airport in the Startupwindow) at a AES activated airport, which is not in a havy memory load area, like Default EDDN for example,

- using the Default Cessna

- and then you use the FS Goto Menü to switch to your departure Airport and

- then change the Aircraft to that one you want to fly.

What happens then in appoarch? CTD YES/NO

I will expact, that when you use 3GB Patch and you use the startup sequence of Q2, that all will work fine. Why: In this case, all the Memory allocation will happen in a Memory low usage time, so if the Boundary of 2GB will be the problem (what I think it is), the memory is availabe over all the time the FS is running.

The Offsets to the memory in the BGL code are limited to – 2,147,483,648 and 2,147,483,647 bytes, which will say, when the delta between the BGL "VarBase" Opcode and the Memory, where the Data should be stored is bigger then 2GB, the code will fail and point to a wrong segment.

As we don't know, where the code and where the Data are placed in Memory, when the available size is bigger then 2GB, it is allways possible, that the Delta is bigger then +-2GB.

So please answer the Q1 and Q2 with YES or NO

Link to comment
Share on other sites

Q1: Yes, 3GB is used

Q2 1):

- Cessna from AES active EDXW moved via airport selection to AES active EDDF-> ok

Q2 2):

- YAK40 from AES active EDXW moved via airport selection to AES active EDDF-> ok

Q2 3):

- YAK40 from AES inactive ESCN moved via airport selection to AES active EDDF-> crashed (g3d.dll), reproducible

Stefan

Link to comment
Share on other sites

Ok for all Tester:

The problem wil have to do with the initial load of the AES related modules and/or the Memory need to be allocated at this moment. So the following question are important to know, before you post any statements:

Q1: Do you use the 3GB patch YES/NO

Q2:

-Wenn you start the FS (with a safed flight or by selecting the Airport in the Startupwindow) at a AES activated airport, which is not in a havy memory load area, like Default EDDN for example,

- using the Default Cessna

- and then you use the FS Goto Menü to switch to your departure Airport and

- then change the Aircraft to that one you want to fly.

What happens then in appoarch? CTD YES/NO

I will expact, that when you use 3GB Patch and you use the startup sequence of Q2, that all will work fine. Why: In this case, all the Memory allocation will happen in a Memory low usage time, so if the Boundary of 2GB will be the problem (what I think it is), the memory is availabe over all the time the FS is running.

The Offsets to the memory in the BGL code are limited to – 2,147,483,648 and 2,147,483,647 bytes, which will say, when the delta between the BGL "VarBase" Opcode and the Memory, where the Data should be stored is bigger then 2GB, the code will fail and point to a wrong segment.

As we don't know, where the code and where the Data are placed in Memory, when the available size is bigger then 2GB, it is allways possible, that the Delta is bigger then +-2GB.

So please answer the Q1 and Q2 with YES or NO

So, we need the DLL files that AES uses "patched" to look beyond 2GB?

to answer your questions.

1) Yes I use the 3GB patch

2) The problem is 99.9% of the time flying from a non AES airport to an airport that uses AES

As was stated above "slewing" or using a saved flight will not reprocude the error with any consistancy.

QUICK QUESTION OLIVER:

I know starting at an AES airport then selecting the airport you really want to fly from has been a soloution for some people, but does AES "UN LOAD" from memory during a flying session?

Say I start MSFS at KBOS (AES active and loaded), then use the "GOTO" menu to place me at KATL (non AES) and fly for seven hours to EGLL (AES ACTIVE). Is AES still loaded into memory from KBOS over 7 hours ago? Or does it unload over a period of time and need to load again as I come into EGLL?

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue. Privacy Policy & Terms of Use