Interesting! Looks like there may be a glitch in a scenery file in that area. FWIW, I run Pilots's FS Global Ultimate terrain mesh, ORBX Global Base 1.30 textures, and ORBX Vector 1.20.

 

When I had the crash, the Windows event viewer logged an error in both terrain.dll and G3D.dll. I believe both dlls were updated in the FSX-SE update just released. I'll have to re-visit that area and see if there is still an issue

 

I was running the newest update without any terrain mesh for the area. But I do have ORBX Global Base 1.30 and ORBX Vector 1.20 installed.

Umm...where was this thread before?

In the CTD Forum where I'm sending it back to.

 

Best regards,

This is an automatic message.

 

This topic has been moved from "MS FSX Forum" to "Crash To Desktop (CTD) Forum". This move has been done for a number of possible reasons.

• The most likely reason is that the post was off topic.
• The topic could also have contained images or a video that were not appropriate to the original forum it was posted in.
• The images might not have been "illustrative" or "explanatory" in nature.
• The topic could have been moved because we deemed it to be more appropriately placed elsewhere.

Please ensure that your posts are "on topic" and contain illustrative images or videos as appropriate. Do not post videos or images just for entertainment purposes anywhere but in the screen shot or video forums. See our image posting rules here.

 

Members who continue to post off topic posts can be denied entry to specific forums in order to reduce and remove the practice. Your cooperation is appreciated.

I was running the newest update without any terrain mesh for the area. But I do have ORBX Global Base 1.30 and ORBX Vector 1.20 installed.

 

ORBX seemed to have been the source of some of these crashes according to the Steam forums.

 

I run UTXv1 myself.

 

 

Can you try again with ORBX Global deactivated and/or Bojote's tweaks?

 

 

 

In the CTD Forum where I'm sending it back to.

 

Okay.

ORBX seemed to have been the source of some of these crashes according to the Steam forums.

 

I run UTXv1 myself.

 

 

Can you try again with ORBX Global deactivated and/or Bojote's tweaks?

 

 

 

 

Okay.

 

 

I just tried my westbound flight over the North Atlantic again with Bojote's tweaks and I haven't suffered a CTD going past Greenland for once!

 

Bojote added these tweaks to my fsx.cfg.

 

RejectThreshold=131072

 

AffinityMask=14

 

HIGHMEMFIX=1

 

TextureMaxLoad=3

 

SWAP_WAIT_TIMEOUT=2

 

MAX_ASYNC_BATCHING_JOBS=3

SmallPartRejectRadius=4.0

 

SOUND_LOD=1

 

These changes seemed to prevent that North Atlantic flight, however I've only tested these new changes once.

Oops, maybe I spoked too soon. g3d.dll crash over northern Canada. About six hours into this test flight. No terrain.dll crash. Hmm, maybe it its Orbx after all.

If you are using tweaks in your FSX-SE.cfg, expect crashes.  Go back to the default and start over again.  On or more of the tweaks is obviously not working properly and causing your crashes.

 

Best regards,

If you are using tweaks in your FSX-SE.cfg, expect crashes.  Go back to the default and start over again.  On or more of the tweaks is obviously not working properly and causing your crashes.

 

Best regards,

 

Hi Jim,

 

I was getting a consistent crash in my transatlantic flights near Greenland without the tweaks. I am simply just testing the claims that Bojote's tweaks may fix those crashes. No crash near Greenland now. I do now get a crash over northern Canada.

Hi Jim,

 

I was getting a consistent crash in my transatlantic flights near Greenland without the tweaks. I am simply just testing the claims that Bojote's tweaks may fix those crashes. No crash near Greenland now. I do now get a crash over northern Canada.

There is no tweak that will fix any crash.  Tweaks are bad for any system built after Sandy Bridge.  If you are getting a crash, you need to start investigating and you mentioned that maybe Orbx scenery was the cause.  I might agree as I understand there has to be a special installer to get addons installed into FSX-SE properly (read this in the long Turbine Duke Release topic in the FSX Forum by the developer of the Turbine Duke - Rob Young).  If you are getting crashes after installing an addon not specifically made for FSX-SE, then you are only asking for problems.  Why not wait until the developer provides a solution?  This is the same issue we have had with P3DV2 crashes in that people are installing addons not made for P3DV2 using an installer not approved by the individual developer of the addon.  The developers of these products made the product to work as is and not with a bunch of unapproved addons.

 

Transatlantic flights that crash are usually caused by OOM's.  Any photoscenery employed (enabled) worldwide will be loaded whether you want it loaded or not and take up massive VAS resources.

 

Best regards,

There is no tweak that will fix any crash.  Tweaks are bad for any system built after Sandy Bridge.  If you are getting a crash, you need to start investigating and you mentioned that maybe Orbx scenery was the cause.  I might agree as I understand there has to be a special installer to get addons installed into FSX-SE properly (read this in the long Turbine Duke Release topic in the FSX Forum by the developer of the Turbine Duke - Rob Young).  If you are getting crashes after installing an addon not specifically made for FSX-SE, then you are only asking for problems.  Why not wait until the developer provides a solution?  This is the same issue we have had with P3DV2 crashes in that people are installing addons not made for P3DV2 using an installer not approved by the individual developer of the addon.  The developers of these products made the product to work as is and not with a bunch of unapproved addons.

 

Transatlantic flights that crash are usually caused by OOM's.  Any photoscenery employed (enabled) worldwide will be loaded whether you want it loaded or not and take up massive VAS resources.

 

Best regards,

 

Hi Jim,

 

I'm just using a process of elimination to rule out what does and doesn't cause a crash to help others. It's not OOM for sure. FSX:SE manages VAS much better, and at the time of these g3d.dll/terrain.dllcrashes I'm only using about 60% VAS. So far Bojote's tweaks haven't prevented a g3d.dll as some have claimed, and I don't plan on sticking with Bojote's tweaks if they don't do anything.

 

My guess it's probably OrbX. I will try my test flight again without it enabled and see what happens.

 

And you're right. I am asking for problems! I'm scientist at heart and that's what we tend to do.

Oops, maybe I spoked too soon. g3d.dll crash over northern Canada. About six hours into this test flight. No terrain.dll crash. Hmm, maybe it its Orbx after all.

 

This was with the current, patched version of FSXSE, right?

 

What aircraft did you use?

 

 

 

Next train of thought:

What's your page file setting in Windows? System managed or fixed size?

This was with the current, patched version of FSXSE, right?

 

What aircraft did you use?

 

 

 

Next train of thought:

What's your page file setting in Windows? System managed or fixed size?

 

Yep, patched. I was using my Captainsim 767.

 

Page file is fixed at 8192 MB on a separate drive.

 

I may disable all my addons, and do this Atlantic flight in the stock 747 with Orbx enabled and also with it disabled.

 

 

FSX:SE manages VAS much better, and at the time of these g3d.dll/terrain.dllcrashes I'm only using about 60% VAS.

 

Respectfully, that's totally incorrect.  If you read the AVSIM interview with the developer of FSX-SE, he states there was nothing changed in the FSX engine.  Nothing.  They just got it to work inside Steam.  That's it.  They have no authority to change the FSX code except to allow it to work in Steam.  So, if you are getting better management of VAS, that's possible as a virgin install of FSX without any addons or very few will give you a massive amount of VAS too.  It's when you start throwing on addons, like photoscenery, that cause the massive loss of VAS.  I think most of the FTX/Orbx scenery, like PNW, use some photoscenery and that can cause OOM's eventually. 

 

I recently completed several flights with my PMDG 777 from Chicago KORD to Washington's KIAD.  I used MSEV2 photoscenery for all of the States I would be flying over and maybe a couple of other States next door so that I would not see default scenery.  I had FSDT KORD and FlightBeam's KIAD installed.  I also used ASN and ProATC-X.  During most of the flights I had around 800MB's of VAS left at cruise level.  FPS were awesome and up in the 50's 60's most of the way.  All the way up to the approach into KIAD I had no less than 600 MB's of VAS left.  I turned into approach and suddenly the VAS level dropped to 400 MB's, and as I got closer to the airport, dropped to 200 MB's and froze with an OOM.  Now the flight from Chicago to Wash Dulles is about a two hour flight.  I do not have high FSX or display driver settings and have completely turned off Autogen as you don't need it for photoscenery.  I use no tweaks in my FSX but I did "tweak" LOD_Radius and raised that to 6.5 and the Texture_Max_Load raised from 1024 to 4096, the max.  I also use REX-4 Direct Textures and raising those settings high will destroy FPS and VAS if set too high.  I use the default settings.  The clouds still look great and the water at FL280 looks nice too.

 

I decided to try a flight with just the departure and arrival areas having photoscenery enabled and the States in between disabled, and instead use the default scenery.  Triple the VAS!  I had between 1.66 GB's of VAS remaining at takeoff and 1.5 GB's of VAS remaining as I turned into the approach.  Then it dropped to 941 MB's as I turned into the approach, down to 471 MB's at landing.  More than sufficient VAS needed to land and taxi.  I could have easily gone another two or three hours as VAS remained around 1.28 GB's during cruise level.  I have this all documented with the FSUIPC VAS utility.  It also stated I had an average of 29 fps throughout the flight.  What is eating up the VAS during the approach phase is definitely a mystery.  Maybe because of the lower altitude and more textures have to be rendered faster?

 

 

 

Page file is fixed at 8192 MB on a separate drive.
I may disable all my addons, and do this Atlantic flight in the stock 747 with Orbx enabled and also with it disabled.

 

Page file has nothing to do with VAS and will not save anyone from getting an OOM.

 

I think it is great that you are now going to do some test flights as you indicate.  That's the only way you are going to narrow down your problem.  That's how I solved my problems.

 

Best regards,

Respectfully, that's totally incorrect.  If you read the AVSIM interview with the developer of FSX-SE, he states there was nothing changed in the FSX engine.  Nothing.  They just got it to work inside Steam.  That's it.  They have no authority to change the FSX code except to allow it to work in Steam.  So, if you are getting better management of VAS, that's possible as a virgin install of FSX without any addons or very few will give you a massive amount of VAS too.  It's when you start throwing on addons, like photoscenery, that cause the massive loss of VAS.  I think most of the FTX/Orbx scenery, like PNW, use some photoscenery and that can cause OOM's eventually. 

 

I recently completed several flights with my PMDG 777 from Chicago KORD to Washington's KIAD.  I used MSEV2 photoscenery for all of the States I would be flying over and maybe a couple of other States next door so that I would not see default scenery.  I had FSDT KORD and FlightBeam's KIAD installed.  I also used ASN and ProATC-X.  During most of the flights I had around 800MB's of VAS left at cruise level.  FPS were awesome and up in the 50's 60's most of the way.  All the way up to the approach into KIAD I had no less than 600 MB's of VAS left.  I turned into approach and suddenly the VAS level dropped to 400 MB's, and as I got closer to the airport, dropped to 200 MB's and froze with an OOM.  Now the flight from Chicago to Wash Dulles is about a two hour flight.  I do not have high FSX or display driver settings and have completely turned off Autogen as you don't need it for photoscenery.  I use no tweaks in my FSX but I did "tweak" LOD_Radius and raised that to 6.5 and the Texture_Max_Load raised from 1024 to 4096, the max.  I also use REX-4 Direct Textures and raising those settings high will destroy FPS and VAS if set too high.  I use the default settings.  The clouds still look great and the water at FL280 looks nice too.

 

I decided to try a flight with just the departure and arrival areas having photoscenery enabled and the States in between disabled, and instead use the default scenery.  Triple the VAS!  I had between 1.66 GB's of VAS remaining at takeoff and 1.5 GB's of VAS remaining as I turned into the approach.  Then it dropped to 941 MB's as I turned into the approach, down to 471 MB's at landing.  More than sufficient VAS needed to land and taxi.  I could have easily gone another two or three hours as VAS remained around 1.28 GB's during cruise level.  I have this all documented with the FSUIPC VAS utility.  It also stated I had an average of 29 fps throughout the flight.  What is eating up the VAS during the approach phase is definitely a mystery.  Maybe because of the lower altitude and more textures have to be rendered faster?

 

 

 

 

Page file has nothing to do with VAS and will not save anyone from getting an OOM.

 

I think it is great that you are now going to do some test flights as you indicate.  That's the only way you are going to narrow down your problem.  That's how I solved my problems.

 

Best regards,

 

 

That's interesting. I have more addons installed than I did six months ago due to Christmas sales, and all of western Europe in 30 M mesh.

 

Usually, in Process Explorer, I would tend to have 1000-1500 MB of VAS left, and then that drops to 800-900 MB during approach, and then the simulator gets really sluggish when I'm on final and I race to beat the OOM error. Nothing of the sort. I usually maintain 1000-1500 MB in FSX:SE and even more in cruise as the available VAS usually increases after I depart Heathrow which I don't remember if that happens in FSX Gold or not.

 

 

Usually, in Process Explorer, I would tend to have 1000-1500 MB of VAS left, and then that drops to 800-900 MB during approach, and then the simulator gets really sluggish when I'm on final and I race to beat the OOM error. Nothing of the sort. I usually maintain 1000-1500 MB in FSX:SE and even more in cruise as the available VAS usually increases after I depart Heathrow which I don't remember if that happens in FSX Gold or not.

 

Looks like we both are getting the same results in our tests.  To be fair though with your testing, you would need to have the exact same configuration in FSX and FSX-SE.  You may be getting more VAS in SE because of Steam?  All I can say is that the developer said there was no code changes and there never will be any code changes as he does not have that authority from Microsoft. 

 

When P3D was first released, we had a lot of OOM's from that software.  Whenever anyone cranked up their settings to the max, including Autogen, an OOM ensued without an hour, sometimes less.  Lockheed Martin developers did some testing and determined it only happened with Autogen maxed out.  They dramatically optimized the Autogen objects and the OOM's are still there but you can now take a 2-3 hour flight (with lower Autogen settings).

 

I have found high fsx.cfg and display driver settings, Autogen, and Photoscenery are the biggest culprits for using up VAS.  This has been found by PMDG too.  High settings for images in programs like REX-4 take up a massive resources too as you are calling up high definition images which require more power.  I suspect some tweaks, like the BufferPool and the AffinityMask tweaks take up resources too.  We have powerful computer systems and everyone wants to have the best graphics but, when you crank up the settings, those textures are being called faster and faster and using resources.  I do know my high LOD_Radius and Texture_Max_Load settings eat up a lot of resources too but I can control that by lowering the Texture_Max_Load from 4096 to 2048 (which is HD too).

 

We did not have these problems just a few years ago.  In fact, it was rare to see an OOM.  What has changed?  Not the old FSX code.  Not the textures.  It's the modern computer systems.  This is one major reason why we need to move to 64 bit programs and right now the only 64 bit program is X-Plane and there are rumors that P3D will someday be converted to 64 bit (which will require addon developers to change their products too).  But then, VAS will be almost unlimited.   Unfortunately, we'll never see it in FSX or FSX-SE unless Microsoft releases the code or develops a 64 bit product.

 

Best regards,