Aerosoft official retail partner for Microsoft Flight Simulator !! 
Click here for more information

Jump to content
truthknown

G3d.dll Errors With Aes And 3gb Patch

Recommended Posts

Sorry,

but all the test shows, that the allocation itself seams to work, but other conditions in the engine seams to generate the CTD.

So, we are still searching for the cause?

Share this post


Link to post
Share on other sites

Hi guys,

I would really encourage the developers to continue tracking down the issue. I use AES and UTE and my problem is, I get UTE-related OOM errors without the 3 gig patch and AES related g3d.dll errors with the patch. Therefore it seems like i can either use AES and UTE which is really pity as both addons are so great.

Cheers, Manu

Share this post


Link to post
Share on other sites

Hi,

my problem is, that I have installed UTE too and I never get any problem. So I have to try to find a situation, where I can get into this problem, otherwise it is not possible to reproduce the situation and so I can't find a solution for a problem I don't see.

With the tests I provide here (not anymore usable with 1.96) I have try to get a overview, in which level the CTD happens, but only one user as helped here. So I have a very small base of infos.

The result of the test was, that the CTD not happen in Memory allocation, not in activation of AES. It happens at a point, where the objects must be displayed. So it is possible, that a timeing are reload of Library objects into the fs Engine will generate this problem. So it is possible, that the FS itself is not handling the 3GB patch correct in all cases. It's deinfinitiv no coding issue of AES (in this case, it will also happen without the 3GB patch).

The only possible way I have is to find a workaround, so that the "internal handling" of the FS is not runing in his issue. But therefor I need to understand at which part of the process the FS gets into the problem. Without seeing the issue, a very complicated process.

I will provide some more Testcode next and I hope the more then one user will try it, so that the feedback is on a bigger base, maybe that helps to find the point faster.

Share this post


Link to post
Share on other sites

Hello,

I don´t know if somebody has mentioned it before (even don´t know if it´s helpful :rolleyes: ),

but I get the g3d.dll - Error (or g2d.dll) occasionally even when undocking a FS-window (2-d instrument panel for example)

from the main window and dragging it to a second monitor.

All windows get blank (black), HD is desperately rushing and some seconds later the error message

appears.

This is happening since I installed AES. It occurs on both - AES and Non-AES equipped airports,

with default and Addon-Aircraft, with and without Track-IR. I can´t find any regulars for it.

I´ve recently reinstalled my system. Before that I´ve had the 3GB-patch installed, but things were the same :(

My sys-specs are:

E6600, 2GB RAM, MB: nvidia 750i Chipset, GF 8800GT, GF8400GS

Track IR4

Win XP SP3 (32), FS 9.1, walk&follow, AES 1.96, No 3GB-Patch

Best regards,

Marcus Langemeyer

Share this post


Link to post
Share on other sites

Hi everybody,

Thanks to Oliver for coming back to this thread. I've got some more observations to tell. Since several weeks (could be since upgrading to the current AES version), I noticed that during a flight in AES-regions, the PC or the FS starts scanning the entire FS folders. During this "scann process", there are not enough ressources left for reloading the textures neither on the plane nor on the ground. Afterwards, once it has settled down again, the textures come back. Has anyone else made these experiences?

I have now deactivated AES two days ago and since then, those scanning problems have disappeared. And so far I have also not gotten any g3d.ll errors yet. Don't get me wrong, I don't want to blame AES, I like it so much and it's not fun to fly without it, but like I said, these are my latest observations.

Best regards, Manu

Share this post


Link to post
Share on other sites
Hi everybody,

Thanks to Oliver for coming back to this thread. I've got some more observations to tell. Since several weeks (could be since upgrading to the current AES version), I noticed that during a flight in AES-regions, the PC or the FS starts scanning the entire FS folders. During this "scann process", there are not enough ressources left for reloading the textures neither on the plane nor on the ground. Afterwards, once it has settled down again, the textures come back. Has anyone else made these experiences?

I have now deactivated AES two days ago and since then, those scanning problems have disappeared. And so far I have also not gotten any g3d.ll errors yet. Don't get me wrong, I don't want to blame AES, I like it so much and it's not fun to fly without it, but like I said, these are my latest observations.

Best regards, Manu

Hi,

how did you see that he is scaning the fs directory? Is there a window opend from the FS relaoding all? As AES is only a BGL which as a monitor box of 10000x10000 Meter around the airport and only up to 2000 Meter above, I don't think that the code of AES can generate any scans by flying above a airport in upper Flightlevels.

Did you use the 3GB Patch?

Share this post


Link to post
Share on other sites

Hi Oliver,

Yes I use the 3GB patch as it has cut down OOM errors. And from your desciption it indeed looks like AES doesn't have any influence as I am flying in upper airspace. So it may be just a coincidence that i have not gotten any g3d.dll error so far and not related to deactivating AES.

Regarding the scanning, there is no window in FS, but when I "heard" that my hard drive was starting to work like crazy, I opened up filemon and watched that something is accessing all files and folders within FS. Like I said, it suddenly starts, for example 30 min into the flight, then lasts ten minutes, and then stops again. The scanning has also happened on approach, which meant the textures of the airport were not there.

Strange that it hasn't happened during the last two days.

Best regards, Manu

Share this post


Link to post
Share on other sites

Yes,

the problem is, that all this can have to do with one buggy installed addon, which has missing or wrong textures, buggy bgls and so on.

I have installed now a Mesh, UTE, all WOAI, div. complex sceneries and aircrafts, but I have no chance to get the memory in a area >1,2 MB used by FS and I have a dll installed, which blocks 300MB on top.

But I also checks all my AI Aircraft textures to be DXT3, no empty TEXTURE Folder is present.

Based on this, I don't need the 3GB patch and never had OOMs

Share this post


Link to post
Share on other sites

Thanks for the tipps and for taking the time!

I envy your stable fs-installation! Can i have a copy? :)

As I mainly fly online, I will check if all the MTL planes are in proper DXT3 format. Good idea.

I'm not sure if it's connected to a certain scenery as it has happened no matter were I fly in Europe. But that's pure speculation. But this thought has so far kept me from reinstalling the sim from scratch.

Which "dll" is it that you talk about? Does it a similar job as the 3GB patch?

Have a great weekend and best regards, Manu

Share this post


Link to post
Share on other sites

Hi,

the DLL is only internal and for testing. It only allocate memory, so I get faster near to the limits. Nothing you need.

But, I had just a OOM and CTD in FE.DLL. But, what I see, there was a AI Airplane (FSP A320) on the Airport with a large 32 Bit Texture.

I think, it not need to be a AI Airport, maybe all BMP not in DXT format will be potential critical regaring memory eating and CTD's.

Share this post


Link to post
Share on other sites

One important question:

Did anyone of you (how as OOM problems) use products of FranceVFR?

Share this post


Link to post
Share on other sites

Hi Oliver,

how are ya? Are you getting closer to solving this issue?

To answer your question as for me and my computer: nope, I do not use a single product of FranceVFR!

Regards,

Tetiaroa

Share this post


Link to post
Share on other sites

Hi,

I have FlightParis and FlightAlpes installed but not activated (I only activate them when flying VFR there). Are there known issues with FranceVFR sceneries?

I'm still trying to find an easy way to get potential 32bit textures converted to DTX3. I use DXTBmp, but it's rather time consuming scanning through all folders with this tool. Is there a quicker way to find and convert the texture formats?

I reactivated AES and crashed twice on the ILS at EDDM with a g3d.dll error. i will now try to uninstall UTE and delete the 3Gig patch to see if it helps. If not, I'm a candidate to reinstall FS from scratch as it really might be a faulty addon scenery causing the OOM errors.

Best regards, Manu

EDIT: Sorry, I missed your last post Oliver! I will read through it and try your suggestions. Thanks!!

Share this post


Link to post
Share on other sites

Hi,

UTE seams to be OK regarding the memory issue. It's more the addons. I am not so far yet to have checked the german scenery area, maybe tomorrow I know more.

Simwings (expect Ibiza) seams to be Ok so far also LPPT, LPMA and Malta (both Aerosoft and Daniels Version).

Share this post


Link to post
Share on other sites
Hi,

the DLL is only internal and for testing. It only allocate memory, so I get faster near to the limits. Nothing you need.

But, I had just a OOM and CTD in FE.DLL. But, what I see, there was a AI Airplane (FSP A320) on the Airport with a large 32 Bit Texture.

I think, it not need to be a AI Airport, maybe all BMP not in DXT format will be potential critical regaring memory eating and CTD's.

I have Martinique and Guadalope. Notice they have no LC folders.

Quick question Ollie. Would they be loaded (Mart&Guad) when flying near Boston?

Share this post


Link to post
Share on other sites

Shame there is nothing further that can be done here. The fact is, without AES and using the 3GB patch I haven't experienced any crashes whatsoever, with AES it crashes on approach to an enabled airport within a few miles. True enough that normally crashes don't occur in between two AES enabled airports, but mostly between one that is enabled and one that is not. That is unless the sim is paused for too long. Had another one occur on approach with a flight between two AES airports but had paused the sim for dinner in between.

I'm sure there is some merit to the landclass issue, but that doesn't seem to be what is happening here. I continue to add addons and they all work fine when AES is not enabled. Continued success as it is a great addon, but sadly it seems I have been guided by my last follow me truck.

Share this post


Link to post
Share on other sites
Shame there is nothing further that can be done here. The fact is, without AES and using the 3GB patch I haven't experienced any crashes whatsoever, with AES it crashes on approach to an enabled airport within a few miles. True enough that normally crashes don't occur in between two AES enabled airports, but mostly between one that is enabled and one that is not. That is unless the sim is paused for too long. Had another one occur on approach with a flight between two AES airports but had paused the sim for dinner in between.

I'm sure there is some merit to the landclass issue, but that doesn't seem to be what is happening here. I continue to add addons and they all work fine when AES is not enabled. Continued success as it is a great addon, but sadly it seems I have been guided by my last follow me truck.

I am now very shure, that it is not a AES generate problem, it's only AES which is the last addon coming active. The issue is present before, but in limits, so when AES is missing, nothing is to see. The memory leaks are often seen in landclasses, but not only there. Some Addon Aircraft have the same problem, sometimes based on Textures, sometime based on memory consuming Gauges.

It is definitive no coding bug in AES, but AES needs memory, when this is not available, I can't do anything.

I also have the feeling, that the basic AES code is not generating the crash, it's only happen, when AES will call visual object, which then are handle by the engine of the FS and there the problem is generated by serveral different modules, like g3d.dll, fe.dll, atc.dll and so on, which every gets in trouble because of the memory problem.

Share this post


Link to post
Share on other sites

And yet I continue adding other add-ons that don't seem to cause the same crashes that AES does. That's why it's hard to see the "straw that broke the camels back" theory because I can add other stuff without issue. AES from my perspective is definitely causing crashes that no other add-ons are causing alone, I just have no means to find a solution. And as the paying customer I'm much less inclined to even try at this point as I'd rather spend my limited time flying.

Share this post


Link to post
Share on other sites

Just wondering... Is this issue fixed in the later versions of AES?

/Johan

Share this post


Link to post
Share on other sites
Guest
This topic is now closed to further replies.

×
×
  • Create New...