g3d.dll......help ..!

[Eziocin 46]

There's also a thing called trolling.

Guys,this thread is turning into an unpleasant and useless argument between people and this is not what ii was meant to be. I don't know about you, but me, personally, I spend most of my working time in the day arguing with people and the last thing I want to do is continue arguing when talking about one of my favourite hobbies...(nothing against you Word Not Allowed....I think your last post was quite appropriate....I quoted your post just because it was the last in a long series of posts over the same argument...)Having said that, here the problem is not that we have problems with "this" or "that" Addon, but that we have problems with "this" AND "that" Addon (at least in my experience): I have replicated it so many times in my sysyems that it cannot be a coincidence (it is a proven fact that on my rig, UTX and some Aerosoft Addon cannot live together, regardless what the FSX settings and tweaks are. I am also experiencing the fact (see my post some pages above) that when crashes occur I have no indication that the system resources (including VAS) may be particularly overstressed. In addition to that the experience may vary among users: for instance I have zero issues with ORBX sceneries (at least the Australian ones, as I don't have any ORBX US ones)....To me, despite the feedback of some us in this thread is giving a lot of added value, we will never get rid of this problem unless we get the Addons developers on board...which is a really hard task...so the right question is "how do we get them on board""...I tried to raise the same thread on UT and Aerosoft forums, but it was completely ignored in the UT forum and got very little interest in the other one.Do you think there is anything we can do in this direction ?Regards

[ZKOKQ 984]

Guys,this thread is turning into an unpleasant and useless argument between people and this is not what ii was meant to be. I don't know about you, but me, personally, I spend most of my working time in the day arguing with people and the last thing I want to do is continue arguing when talking about one of my favourite hobbies...(nothing against you Word Not Allowed....I think your last post was quite appropriate....I quoted your post just because it was the last in a long series of posts over the same argument...)Having said that, here the problem is not that we have problems with "this" or "that" Addon, but that we have problems with "this" AND "that" Addon (at least in my experience): I have replicated it so many times in my sysyems that it cannot be a coincidence (it is a proven fact that on my rig, UTX and some Aerosoft Addon cannot live together, regardless what the FSX settings and tweaks are. I am also experiencing the fact (see my post some pages above) that when crashes occur I have no indication that the system resources (including VAS) may be particularly overstressed. In addition to that the experience may vary among users: for instance I have zero issues with ORBX sceneries (at least the Australian ones, as I don't have any ORBX US ones)....To me, despite the feedback of some us in this thread is giving a lot of added value, we will never get rid of this problem unless we get the Addons developers on board...which is a really hard task...so the right question is "how do we get them on board""...I tried to raise the same thread on UT and Aerosoft forums, but it was completely ignored in the UT forum and got very little interest in the other one.Do you think there is anything we can do in this direction ?Regards

I posted on the AS forum some time ago, regarding EBBR and the INN VOR @ LOWI, and was told to remove everything to bare bones and try again. That was not going to happen. Head in the sand stuff really.Like Word Not Allowed, I have removed the two offenders, and will remain uninstalled till such time a cure is found. I have 42 addon airports installed, and onl;y 2 that are unusable with current config I have set up, so a small sacrafice. My scenery config looks like Clapham Junction.

[Tomaz Drnovsek 440]

Now in this case, PNW causes a problem and up to this point has not fixed it.

Why don't you respond to the fact that g3d.dll error is not happening only in PNW areas but also in Europe and other places? From yours and Michaels posts one can conclude that ORBX is responsible for those errors. Period. That's just not true, well, is it?

[Glynn 405]

HelloThere are only two things at play here:1: Badly designed scenery products that fall over when the sim is stressed2: Folks trying to run with their settings too high and stressing the simFrom the developers point of view though, if the product works with LOD 4.5 which is as far as the FSX slider will gothey have released a working product within the operating limits of the Sim, good luck with getting them to redo the product.With the settings just be happy that the hardware has finally caught up and gone past what the sim can offer.Two years ago we would have been happy just getting this thing running fluidly, now we want to crank up the LOD far further than Aces ever imagined.We as users are as much to blame as the developers of these products, we both insist on pushing the boundaries of the simUs with pushing the settings farther than the interface provides.The Developers from working outside of the SDK on many occasions.

[cj-ibbotson 77]

I'll see if I have time to do a quick flight plan tonight along an area of PNW that always crashes if my settings are too high, I will use a default aircraft and also reset my fsx.cfg to default so others can test too, this way we can have common ground (well for those with ORBXs PNW). I did an hrs flight last night with no crashes but putting scenery complexity, autogen, water and traffic all at 100% generated the crash on cue 1.4nm south of OLM VOR flying on a bearing of 155 degrees. I have process explorer utility running to monitor VAS too though its often hard to get a reading from it on memory usage as FSX will freeze with the egg timer and I cant switch to view its memory usage, if I force FSX to quit out of its frozen state the inidcated memory obviously reduces immediately.This method of testing will show if FSX can or cannot cope with scenery addons as no other user tweak will be involved. I'll also use default weather and remove any nvidia inspectors adjustments

[zetato 8]

Hi all, really I got no time to read now all this topics, but I wanna reassume you my experience.My system is a Windows 7 64 bit on a i7860@3.53 GHz, ram 4 GB, ATI 5770.In the past I placed the 32 bit version of UIAutomationCore.dll in FSX folder as discussed in different forums.One week ago I installed a new 7" touch screen (Mimo 720S) to be used as an FMC's CDU. After some trobles I was able to use the new and third monitor (the primary is a 22" for FSX and the secondary is a 17" for charts and inflight apps), without problems, and I was very happy about that. After some flight hours, FSX had a CTD without evident errors, simply it closed at desktop. In the event viewer, i found the crash was related at G3D.dll.After that, almost any flight were ending with a CDT, for the most related at G3D.dll, and in some times at Terrain.dll. Inserting the string "MissingLibraryAlert=1" in the Scenery section of the fsx.cfg file, I had no more G3D.dll crash, but a lot of advisory. Anyway, crashes continued due to other dll's (Terrain, NT etc.). I noticed that the sim crashed especially using the mouse in the ingame content menu, simply clicking with the right button during a flight, and then moving up and down the selection in the menu I had a crash for sure after 20 - 30 seconds (especially with complex model such as IFly 737 NG).Those events reminded me the trouble I had in the past with UIAutomationCore.dll, and so decided to perform the procedure described here http://tinyurl.com/89xj6ly in the second post. I had a trouble to delete (rename) the files, it was required some addictional work with security options, but, finally I did it, and guys, yesterday I flew for 3 hours, continuously clicking the ingame menu, and had no more crash!!Just in case try this procedure, and see what happens. I don't know what happened to my system, maybe the DisplayLink software was recalling some function from the original UIAutomationCore.dll in system 32 or syswow64 (previously I had simply installed the 32 bit version in the FSX folder). Anyway, in case of DLL's crash in FSX I advice you to try this solution, and post your results.If someone already spoke about this in this discussion, simply disregard my message and sorry for my English.Mauro

[PIC007 82]

Why don't you respond to the fact that g3d.dll error is not happening only in PNW areas but also in Europe and other places? From yours and Michaels posts one can conclude that ORBX is responsible for those errors. Period. That's just not true, well, is it?

If you read my posts, I very clearly stated that I could NOT address the issues in Europe as I dont fly there, I was specifically referring to the PNW problem.

[ramsa329 0]

The following post is not intended to advertise the fs-gs service but to try to clear up the differences expressed in this topic between those that use the service and those that don'tFs-Gs does not believe that the g3d problem exists only in ORBX scenery. I used that as an example in which the developer found a cure for a specific area by removing a file after what I am sure was exhaustive study.The post was by Holger Sandman and can be found in their forums. A 2nd post by the same author removed a whole airport which he felt was the culprit..I didn't comment on Aerosoft scenery because we are aware of g3d issues in addition to numerous other issues and do not recommend those sceneries to our clients. So the probability that they would be using any specific sceneries mentioned here as well as others are very low.Those fs-gs clients who have posted here are urged to stay away from products that I have either tested personally or through our network of clients, or through intensive study of product forums for all of the availabe add-ons in the market today have been found to be "un-acceptable" to our criteria.I never claimed to have a "fix" for g3d.dll errors nor do I tell that to potential clients. During the initial interview I make sure that a potential client understands the limitations of what we do and to set their expectations accordingly.If a client experiences a g3d.dll error or other errors I try to replicate the flight and see if it is a specific user error or machine/software error or if it can be repeated on my machines. We also ask the client to repeat the flight over and over to try to isolate potential causes.Fs-gs puts a very heavy emphasis on the structure of the scenery.cfg. I have found that by organizing the.cfg in a specific manner we can isolate the client from errors relating to it and I can unify my clients which makes testing a much simpler process when dealing with a large and diverse client base.I have been studying the issue of g3d errors very intensively for a long time mainly through multi-player flights because their is much heavier usage of all of the simulators aspects including multiple heavy usage planes such as those of PMDG and the Cessna mustang, Active Sky, in both stock and non-stock sceneries and with clients who are using a wide range of add-ons.My findings so far (and I urge caution here since these are specific to my service and may not be of any value to others)1. I urge my clients to always use the latest Nvidia drivers since we believe that there is a correlation between some older drivers and the g3d error unless a specific error in the drivers is found and substantiatted by Nvidia. I do not recommend that any client use ATI cards not because they are not "good" video cards but because of their specific interaction with FSX. We also recommend specific models of video cards to our clients which have been tested and shown to support the necessary "tweaks" which fs-gs uses. Fs-gs does not support tweaks initiated by a user or by 3rd parties which are unsubstaniated through our testing. Each tweak is set according to the users individual card and his/her fsx software environment. In this way we can control stability issues and produce much clearer test results.2 Our clients are taught to pre-flight their computers by using a set of specific settings which we refer to as our "bible". In this manner the client can control many aspects of their planned flight through adjustments in the ,cfg before launching the sim including autogen density etc for specific regions and applicable to their machine environment only.3. Through our continuing service plan I can check dll.xmls and exe.xmls for syntax errors which can often cause random crashes of failures to launch.4. I have found a correlation just recently between BIOS memory settings and overall stability issues which are also affecting instances of g3d errors (these studies are done on Asus MoBos and may or may not nbe applicable to others). Fs-gs wil either walk the client through the BIOS or allow more advanced users to adjust memory frquency according to information obtained from the MoBo manufacturer and other sources and set the correct frequency which may downclock memory in certain instances. This has shown to be effective in eliminating some repeatable g3d errors.5 g3d errors are not associated to UIAutomation core and there is no definitive proof that the errors that are associated with UiAutomation are best settled through the method of deleting them from syswow or through putting a copy of the correct UIAutomation directly into the sim.6. Fs-gs controls all aspects of overcloking a clients machine. An unstable machine done incorrectly will affect all aspects of the sim. We follow strict conditions regarding a clients machines environment in both the software and hardware aspects and will terminate our association with any client that cannot respect our policy.Although this may seem harsh it has saved our clients countless hours of downtime caused by instability errors.7. We never reduce sliders. Our clients are told what to expect in the initial interview of their current computers and are told what they can to do to achieve their goals within their budgets.8, Fs-gs sets and controls all aspects of the clients machine including FSX installation, which AV, anti-spyware , etc........... which may affect performance or cause compatibility issues thus reducing errors caused by incompatible sotware in the Microsoft windows environment. There is much much more of course and all of the above are work-arounds not cures !!!!!!. But for now this will do in explaining why my clients fly more and fix less as they have expressed here.Michael Greenblattwww.fs-gs.comwww.simaddx.com

[Kosta 122]

From the developers point of view though, if the product works with LOD 4.5 which is as far as the FSX slider will gothey have released a working product within the operating limits of the Sim, good luck with getting them to redo the product.

Whoa whoa, wait a bit! There are people getting crashes at known positions even with default LOD 4.5 and 1024. How? You load lots of addons, have addon airports, and press to get VAS usage over 3GB. It's possible with NGX and some other addons. Especially if you keep flying over other addon airports.Still you won't OOM, but the error scenery is going crash because of high VAS usage. This is the error, not that we are trying high LODs. High LODs are only in place to cause a high usage on load, to be able to test the situation in place. I don't have to have LOD higher than 4.5GB to get usage higher than 3GB on some flights with NGX.And that said, I'm already waiting for the answer (from any developer) saying: in default FSX is working. Of course it does! Still badly programmed.

[aljones 15]

The following post is not intended to advertise the fs-gs service but to try to clear up the differences expressed in this topic between those that use the service and those that don'tFs-Gs does not believe that the g3d problem exists only in ORBX scenery. I used that as an example in which the developer found a cure for a specific area by removing a file after what I am sure was exhaustive study.The post was by Holger Sandman and can be found in their forums. A 2nd post by the same author removed a whole airport which he felt was the culprit..I didn't comment on Aerosoft scenery because we are aware of g3d issues in addition to numerous other issues and do not recommend those sceneries to our clients. So the probability that they would be using any specific sceneries mentioned here as well as others are very low.Those fs-gs clients who have posted here are urged to stay away from products that I have either tested personally or through our network of clients, or through intensive study of product forums for all of the availabe add-ons in the market today have been found to be "un-acceptable" to our criteria.

How can that post and those of your loyal customers here will help find a solution G3D.dll problem ? By NOT using some Aerosoft airports and ORBX PNW ? not going to happen in my case with several ORBX airports bought by me in the PNW region...Unless you have a foolproof SOLUTION, can yourself as a "service provider" respectfully stay the heck out of that discussion ? I have nothing against yourself or your service nor your customer's following but since nobody from your "side" is helping here.. ?For the moment I will continue to investigate a solution or at least, an acceptable compromise...Thank you....Alain from Montreal

[RedSpinnaker 35]

Would running SysInternals Procmon64, and having it logging everything on known CTD flights, then analyzing to see if a common denominator exists? I've been unable to discover any flights on my system (but then haven't spent THAT much time in PNW) which consistently cause a crash. Might fly around this weekend with some of the problem routes in this thread and see if I can force a crash. If so, will do it several times and see what the logs show.Just an idea.

[aljones 15]

Dan, just fly direct from KORS to KPDX @ 6000; this will bring you east of KSEA; if you monitor vas usage, you will find it starts to climb just before reaching KSEA airspace right up to a crash....Alain from Montreal

[Kosta 122]

Would running SysInternals Procmon64, and having it logging everything on known CTD flights, then analyzing to see if a common denominator exists? I've been unable to discover any flights on my system (but then haven't spent THAT much time in PNW) which consistently cause a crash. Might fly around this weekend with some of the problem routes in this thread and see if I can force a crash. If so, will do it several times and see what the logs show.Just an idea.

This is an idea, but did you ever took a look inside of it? Trying to decypher what it wants to tell you, especially in areas of FTX, where you have thousands and thousands of textures loading, good luck on finding anything...I've come to the conclusion which basically said "lots of textures = crash", in the end still, it remains a theory though. I don't think we're gonna be seening remakes of popular airports because of this statement, and certainly not PNW and other areas.

[GHD 21]

Dan, just fly direct from KORS to KPDX @ 6000; this will bring you east of KSEA; if you monitor vas usage, you will find it starts to climb just before reaching KSEA airspace right up to a crash....Alain from Montreal

I think you mean west of KSEA.There were no problems until way past KSEA, the VM peaked at 866MB. However, near Mayfield Lake, FSX stopped responding with the sound continuing.George

[mgh 89]

 

Would running SysInternals Procmon64, and having it logging everything on known CTD flights, then analyzing to see if a common denominator exists? I've been unable to discover any flights on my system (but then haven't spent THAT much time in PNW) which consistently cause a crash. Might fly around this weekend with some of the problem routes in this thread and see if I can force a crash. If so, will do it several times and see what the logs show.Just an idea.

Virtual Memory Map (VMMap), also from SysInternals, shows the virtual memory usage by any particular application in great detail.