Just been through a new  FSX install, and  started off with  basic visual settings in FSX slider graphics. .. You know the usual max or high cloud coverage with 80mile cloud draw distance, nothing too ambitious. 

 

 

After various iterations of tweaking app crashes and more turning down graphics in fsx, nivida inspector, and managing threads in process laso, etc.  I came to conclusion that,  the way FSX communicates system resource peaked out is a dll app crash.

 

I reached this conclusion cause i finaly built up the courage to turn ALLL fsx graphics sliders to ZERO!!! and guese  what, saved flights that crashed with 100% repeatabitlity on loading now loaded an ran smooth as a feather, but the graphics looked crap. Mind you i did not change from HD (1092 xxxxxx)resolution, but turned pretty much evrything else to ZERO!!!. 

 

 

From this point on i began the journey of gradually advancing the sliders to the right, with hopefully an artistic measure to stop just before hitting the app crash region. Currently testing promising settings flight. If ok then sliders can go up more when if i am bothered to test again.. But importantly i have a setting i know can make full flight wihtout crash.

 

 

If all sliders are ZERO!!! and still crash  you know what to do with your PC, .But if sliders arent ZERO and you looking for solution,then you know where to turn those sliders. 

 

What i find very suprising is, for the first time i making flight with medium cloud coverage and 90mile draw distance, and comparing with AS2012 cloud data, the representation looks spot on, but most  importantly thurnderstorms dont threaten to fry my mother board.

 

I thought i had settings just perfect till test flight ran into thurnderstorm, and i am using the fantastic AS2012 SP2 2048 32HD textures. Turned AS2012 cloud layers down to 4, but kept the HD. However setting medium cloud coverage in FSX and 90 mile draw distance looks just perfect, plus the extra smoothness and FPS.

 

 

Enough of the rant, turn sliders to zero to determin if the dreaded FSX dll appcrash solution is easily within your reach or not.

 

By the way, many thanks to makers of AppCrash Viewer Application and AVSIM where i got the link.

 

And finally UIAutomationCore.dll had no effect for me, turn sliders to zero before messing with windows,

 

ANd finaly yet again, if sliders are zero and you still have dll appcrash, I have just the solution for you.

http://www.alienware.co.uk/

 

 

Hope it hepls to reduce traffic on CTD forum.

Wonderful!  Everyone turn their sliders down to zero!

 

I will agree that any .dll CTD's I've experience come from over loaded slider options.  In my case, I go above and beyond the stock max values and do custom lod edits like LOD 6.5 and 5.5.  And then I put in tons of cloud layers.  What's happening is even though our hardware is getting better, we're pushing sliders higher on software with dated code.  Then we reach limits, like for instance, saturating the Virtual Address Space, and OOM strikes etc..

 

 

I reached this conclusion cause i finaly built up the courage to turn ALL fsx graphics sliders to ZERO!!! and guess what, saved flights that crashed with 100% repeatabitlity on loading now loaded an ran smooth as a feather

 

A good point.  An accurate point.  I usually recommend deleting the fsx.cfg, restarting FSX and letting the config rebuild.  That will bring your settings to the default and usually the graphics will not be very good but you have a smooth running machine.  I was getting OOM's with my LOD_Radius at 9.5 and even at 7.5 and Texture_Max_Load at 4096.  People told me I would get them but I didn't for a couple of weeks then I would see them sporadically.  I know what caused them and most people need to understand they can max out their sliders and do all kinds of tweaks to the FSX.cfg, and go where no one has ever gone before but they will soon see why everyone hasn't done that.  Right now I'm enjoying MSE V2 with LOD_Radius 6.5 and Texture_Max_Load at 2048.   Clear, non-blurry textures and no OOM's or crashes.

 

Thanks for making the point!

 

Best regards,

Jim

A few points to note since testing with settings on the lower side, but descent graphics.

 

1. Towards end of the flight, tried to check number of Ai around, and fsx crashed during the menu access. Otherwise the flight was very smooth locked at 30 FPS.

 

googled UIAutomationCore.dll helps with crash related to menu access, but you need to have xp or vista version of the dll. So i put the dll in fsx main folder. Will see over next few flights, 1 so far with no probs, but early days yet.

 

 

2. HAd a lot of testing with current lowerside graphics, clouds set at meduim desnity, and cloud draw @80miles out. Ran into thunderstorm that caused heavy stutters, so reduced cloouds to ZERO!!! mid flight, and all was well. Verdict is clouds cause d the stutters,  so lowered to meduim and darw @ 70miles out. 

 

 

I am failrly new to UTX and GEX, plus now using AS2012 32bit HD clouds instead of REX.  AS2012 clouds look the best, but i suspect, more than anything else, the AS2012 clouds are also resource hungry.

 

Cloud coverage density in sim and on AS2012 representation at meduim density and 70 mile draw distance, looks a cross between ok and on the low side, regards comprison to AS2012 cloud weather window.

 

So the latest big deal i just noticed is AS2012 clouds look the best, but also very resource hungary, i suppose more so than REX 2048 clouds.

 

 

Looks like AS2012 2048 32bit HD clouds are same quality as REX 4096 HD clouds. I never used REX 4096 clouds cause of stutters.

 

But now using AS2012 HD clouds, i am finding you still get a dscent cloud representation even with clouds at meduim density, and 80 mile draw distance.

 

If you looking to gain more FPS, try playing with cloud density and draw distance and compare with weather forcast to see what  density suits you.

 

I used to use High cloud density and 80mile draw distance with REX 2048 clouds

 

with AS2012 HD clouds, currently testing meduim density and 70 mile draw distance. The representation at 80mile draw disyance was ok, but 70 less so.

 

 

On another note, finally decided to take the plunge on a science project. FSX PC heats up the room so much, i always wanted to pipe exhaust air from PC to a window, so as to let the hot air out of the room, but never bothered as expected little gain.

 

Well, the pipe from my portable airconditioner is now fitted to PC air exhaust.   luckily i use Lian LI case which is based on exhaust tunnel meaing there is only one exit for hot air, and its horizontally out the back. Form back of PC, pipe goes out window near PC. 

 

My case has 11 fans and 2 fan controllers, suprisingly those fans, most of which are 140inch create air enough pressure to move the the hot air down around 1.5 meter pipe.

 

It makes a huge difference in my case, with the FSx PC unable to raise room temprature as it normaly would, its cacthing a cold. This means i have been able to raise OC from 4.6Ghz to 4.71Ghz. AS2012 clouds are hungary, but they look good.

Yep, sadly this all would be fixed if only the graphics engine was truly DX10 or DX11. But clouds and any other large textures if you're running 4096 for example, brings the system to a halt.

My case has 11 fans and 2 fan controllers, suprisingly those fans, most of which are 140inch ...

I guess a bunch of 12 foot tall fans would generate a pretty good flow.... B)

He lives in a wind tunnel.

He lives in a wind tunnel.

 

 

I think that is the funniest thing you have ever written here Jim. I immediately had visual of that, haha

Wonderful! Everyone turn their sliders down to zero!

 

Summer1... Simmer2050...

 

Summer1... Simmer2050...

 

 

:Thinking:

 

 

 

 

My case has 11 fans and 2 fan controllers, suprisingly those fans, most of which are 140inch create air enough pressure to move the the hot air down around 1.5 meter pipe.

 

 

Take heart Simmer2050... NASA has made the same "error".

Yep, sadly this all would be fixed if only the graphics engine was truly DX10

 

DX10 is proving to be a very good alternative in 2013. The graphics engine is "truely DX10", you just have to apply some fixes

DX10 is proving to be a very good alternative in 2013. The graphics engine is "truely DX10", you just have to apply some fixes

No it isn't. Those so called fixes are tweaks of a DX10 preview mode, just to get that preview mode to work correctly.

I came to conclusion that, the way FSX communicates system resource peaked out is a dll app crash.

I wish I could point and laugh, and I'm sure a lot of people here will do just that, but I've seen too much evidence that this is exactly the case.

 

My system is extremely unstable. Most of the time I get a crash about every third flight. Recently the crashes stopped for a couple of months, but then started up again. Changing settings didn't seem to matter, and I've given up trying to track down individual fixes. Read any number of posts where someone says, "Thanks, that worked like a charm" followed a couple of days later by "The problem is back." It seems like 90% of the fixes are pure voodoo. But somehow, many people never have any crashes at all. Go figure.

 

A couple of weeks ago I got my first ever OOM. I didn't even know what one looked like before. Everyone knows absolutely how you get those, right? There's no other possible way to get the but that one. Well... I was flying stock scenery with options medium high landing at FNR in Alaska. Go check it out, but take a seaplane: it's a seaplane base with no runway, no buildings, nothing but water, trees and cliffs. The aircraft was a modified stock Grumman Goose, with all high res textures, which may have been a contributing factor, and there *may* have been a leisure boat somewhere nearby. I'm also running Accu-Feel but was getting crashes long before I installed that. Not exactly the standard recipe for an OOM.

 

Since then I noticed, flying a lot in the same area, that certain airports were more likely to cause crashes than others... and most of these were similar seaplane bases with no scenery at all. If I didn't get a crash, I'd often get a quick stutter (I don't have them otherwise) or a sound glitch (some crashes were XAudio2_6.dll) at the same point I'd expect a crash. Other times there was no problem at all.

 

Ok, we're looking at some kind of resource problem, right? Seems to be triggered by something in the terrain, especially near an airport, even if there's nothing actually there.

 

I tried two different things. The first was to reload the terrain by mapping a keystroke to the function. This took minimal time, but didn't seem to have any effect. The second, which I'm still using now, seems to help.

 

I will occasionally cycle through the S key views, especially when approaching an airport. These are the spot view, the nearest tower view, the right side wing view, then back to normal. I leave each view long enough to see some mesh/texture/autogen changes. After returning to the cockpit I toggle the sound off and back on again with the Q key. I still get crashes, but there are a lot fewer of them, and I still occasionally see the stutter or hear the sound pop if I've forgotten to do the view switch before approaching an airport.

 

This seems to do some kind of forced cleanup of cached terrain information, and may be getting rid of older allocated memory. This is as much voodoo as any other fix, but for the moment it seems to be helping me a lot.

 

A note on clouds: some clouds cause frame rate hits, others do not. I can't tell if it's the number or type of clouds that's the problem, but it seems to only happen when there's a lot of them. Reducing cloud layers seems like a good idea; overcast is seldom as total as many people think.

 

People told me I would get them but I didn't for a couple of weeks then I would see them sporadically.

This seems to be a common scenario with various problems. Everything is fine for a while, then the problem starts and doesn't go away.

 

Is there something that's being cached (shader cache maybe? anything else?) that builds up over time in an area and eventually causes problems? BTW, where can I find the shader cache to delete it. Just in case. I went looking but it's hidden very well. I know it exists, because I've deleted it before.

 

Hook

 

 

 

Summer1... Simmer2050...

 

Summer1... Simmer2050...

 

 

:Thinking:

 

 

 

 

 

 

Take heart Simmer2050... NASA has made the same "error".

 

 

 

Always happy to energize you with my breezy tonic B)

Is there something that's being cached (shader cache maybe? anything else?) that builds up over time in an area and eventually causes problems? BTW, where can I find the shader cache to delete it. Just in case. I went looking but it's hidden very well. I know it exists, because I've deleted it before.

Hook,

 

What you are referring to is way above my pay-grade...

 

But this is what I thought of: Post #178 http://forum.avsim.net/topic/280688-graphics-corruption-in-fsx-update-possible-solution-found/page-8

JSkorna, on 21 Apr 2013 - 7:26 PM, said:

No it isn't. Those so called fixes are tweaks of a DX10 preview mode, just to get that preview mode to work correctly.

So just because it is labeled with a "preview mode", than it's unusable ? If your DX10 is not working correctly, you most likely set up something incorrectly, or you are using FS9 legacy polygons, or textures. FS9 legacy polygons won't work in DX10, which is to be expected.

 

DX10 may be our only option in the future, with today's modern scenery and aircraft, which's memory footprints are only increasing. DX10 immediately saves about 300MB of RAM, which in term can save you from OOM errors.

 

If the scenery or airplane is 100% FSX code, it WILL work correctly. We just need developers to move off of the FS9 code bandwagon, and start developing addons 100% for FSX, so we can start using DX10.

 

Unless of coarse, P3D moves to 64-bit, but I don't see them doing this in the foreseeable future, and I'm afraid once we do get a 64-bit simulator, we will start stuffing so many addons in one area, the FPS will drop to un-flyable levels anyway.