I'm aware that it's usually, if not always, a VAS shortage that causes FSX to crash when flying the likes of the NGX in heavy scenery, but NOT sure quite how that works....

 

Does FSX simply use up whatever is leftover (up to a certain limit i believe), after various addons, processes and services have used theirs?

 

I hear many views about whether it's helpful or not to close various services and processes etc, but not a definitive answer.  I have a bunch of stuff I usually close down BEFORE launching FSX.  Especially crap like iTunes etc. I also disable whatever photo scenery is not being used. I think it does make a difference, but not by much.  It's soooooooo frustrating, getting near the end of a flight, even a short one, to then have FSX stop with the dreaded 'Your PC has run out of memory' error!

 

I LOVE detailed scenery, but just can't use it as a destination for many quality aircraft:-(

 

Also, regarding the measurement of VAS...  I have 'Process Explorer', but from what I can see, it only shows what individual processes use, and not an 'at a glance' running total of either used or free VAS.

 

Do you close stuff down before starting FSX, and by what means?

 

Do you use anything other than PE for measuring VAS?

As I understand it, the VAS you should be concerned with would be that associated with fsx.exe.

 

I also have process explorer running all the time but don't check it much now that I have a

VAS display on one of my 'custom' XML gauges that I have installed on most of the aircraft

that I fly regularly. I also have a Lua script that will display a warning when my VAS drops

below a limit that I set.  The display lasts 3 seconds (settable) and repeats when the VAS

changes again, below the limit. ( I never hear the FSUIPC4 VAS warning sounds - the display

I always see )

 

As for shutting down various non-FSX related processes, that shou;dn't be necessary if you

have sufficient physical memory. FSX will use, at most, 4 GB. The rest is available for all the

other things that run.

 

I stopped shutting down other tasks when I went to 16 GB of physical memory.

 

Next time I fly I'll try to remember to check my VAS display to the process explorerer data

to see if they correlate.

 

 

 Paul

Hi Paul, hope you're well

Thanks for that.  My concern about the other services etc, is purely in relation to VAS, not RAM.  According to PE, some like iTunes and all its associated additional rubbish use vast amounts of VAS.  Are you saying that maybe that is not an issue - that I ONLY need be concerned about what FSX is up to?  Certainly makes life easier;-)

Total VAS useage limits are a function of the OS architecture and type. If you have a 32-bit OS the limit for FSX and everything else all added together is 4GB. If you have a 64-bit OS, FSX can use 4GB all to itself with everything else running using whatever you have over the 4GB limitation (up to the limit set by the type of OS. See http://msdn.microsoft.com/en-us/library/windows/desktop/aa366778(v=vs.85).aspx#physical_memory_limits_windows_7 for more info than anyone ever wanted to know).

 

Doug

 

Edited becuase I can't spel

Every 32-bit application running on 64 bit Windows can have upto 4G.

 

VAS totals are not cumulative. Two 32-bit applications can each have 4GB - that's 8GB in total etc, etc.

I just checked my FSX VAS display against the Process Explorer "Virtual Size" amount and they

do correlate. (Be sure you have PE set to display the 'Virtual Size' column)

 

My FSX VAS is reading about 2.17 GB remaining, while the "Virtual" amount allocated to FSX is 2.03 GB being used.. So at the moment my FSX is using about half the available VAS. As one of those numbers 'grows' the other will shrink.

 

So, as long as Process Explorer reports no more that 3.7 GB or so in the 'Virtual Size' column for FSX , you will be fine.

 

    Paul

Every 32-bit application running on 64 bit Windows can have upto 4G.

 

VAS totals are not cumulative. Two 32-bit applications can each have 4GB - that's 8GB in total etc, etc.

Indeed. My apologies if I indicated otherwise.

 

Doug

Every 32-bit application running on 64 bit Windows can have upto 4G.

 

VAS totals are not cumulative. Two 32-bit applications can each have 4GB - that's 8GB in total etc, etc.

Ah-Ha!!!

Finally the penny begins to drop for me;-)  Great answers for me here, ESPECIALLY this short and simple one!  I NEVER realised it wasn't cumulative, nor that EACH application had the 4Gb limit.

 

My system is 64 bit, but still I get MANY OOMs when trying to fly PMDG aircraft at detailed airports.

 

You guys rock! This forum really is the dogs wotsits;-)))

As I understand it, the VAS you should be concerned with would be that associated with fsx.exe.

 

...I have a VAS display on one of my 'custom' XML gauges that I have installed on most of the aircraft

that I fly regularly. I also have a Lua script that will display a warning when my VAS drops

below a limit that I set.  The display lasts 3 seconds (settable) and repeats when the VAS

changes again, below the limit. ( I never hear the FSUIPC4 VAS warning sounds - the display

I always see )

 

 Paul

Hey Paul that sounds interesting.  Where did you get that???  I'm guessing it's a bit of work to get it into each aircraft separately?

 

 

My system is 64 bit, but still I get MANY OOMs when trying to fly PMDG aircraft at detailed airports.

 

Yes because FSX is using (or close to using) all of it's available VAS memory, doesn't matter how much extra memory your PC has.  In fact, i can run FSX across my three eyefinity monitors and still play Prison Architect in my top monitor with no issues.  Neither program troubles the 32Gb i have available, in fact, i could comfortably run both in my Graphics card memory alone (yes i know it's not possible).

 

Interestingly, i have been browsing the Steam forums for X-Plane 64, people on there are complaining that they also get OOMs, even with 16Gb of memory.

 

 

 

Hey Paul that sounds interesting.  Where did you get that???  I'm guessing it's a bit of work to get it into each aircraft separately?

 

You can monitor the VAS usage with the full version of FSUIPC using the following process:

http://forum.avsim.net/topic/431663-vas-fsuipc-and-fsx/

 

Please note, it doesn't actually reduce your VAS use or solve the problem, it does give you time to save or end the flight before you crash out.

 

I also read somewhere (Aerosoft forum i think), that windowing and going full screen free's up some VAS, haven't tried it myself and given how delicate FSX generally is i would be rather reluctant too.

Hi Paul,

 

Like Dougal, I'm also interested in the gauge you use to monitor VAS.  Could you provide us with more info?

 

Thanks,

Gerry

My VAS monitor is just a few lines of XML code added to a couple of my existing XML gauges.

 

Those gauges are 'custom' creations for use while flying online with the 91st Bombardment Group and are not something that is easily transfered to another setup.

 

The Lua script, however, will be of use for users of FSUIPC4. It simply monitors the FSUIPC4 offset where the current FSX VAS is stored and generates a display when a low limit is reached.

function VAS(control, vas)

    vas_in = ipc.readUD(0x024C)
    ipc.writeLvar("L:VAS", vas_in)

	if
	   vas_in < 500000 then
	   ipc.display("VAS = "..vas_in,2)
	end

end

event.offset(0x024C,"UW","VAS")

If you save the script above as say, Disp_VAS.lua, and place that file in your Modules folder and add the lines to the FSUIPC4.ini file to cause the file to be loaded/run when FSX starts you should see the 'warning' when the threshold is reached. To test this, you can change that threshold from 500000 to something like 2500000 and you should get a warning display much earlier. Once verified that it is working, change the threshold value back to whatever you wish.

 

My other gauge code displays the current VAS all the time so one can see what comditions affect your particular situation.

 

Here is the XML code I added to my existing custom gauge to display the current VAS at the bottom of the gauge BMP, which is 112 by 166 in size and has several (5) rectangular display areas. The VAS display is at the bottom. Create a rectangular background BMP of 112 x 35 pixels and adjust the "Y" position in the xml code to position the text display correctly.

 

I set my 'warning threshold' to 500000 at which point the test color changes to Red.

<Gauge Name="VAS" Version="1.0">

   <Image Name="VAS_Background.bmp"/>
   
//========================== DISPLAY VAS ===================================
   <Element>
      <Visible>(L:VAS, number) 499999 > </Visible>
      <Position X="25" Y="138"/>
      <Text X="80" Y="12" Length="8" Fixed="Yes" Font="arial" Adjust="Left" VerticalAdjust="Top" Color="#EAEAEA"   Bright="Yes">
    <String>%((L:VAS, number))%!07d!</String>
      </Text>
   </Element>    
       

   <Element>
      <Visible>(L:VAS, number) 500000 <</Visible>
      <Position X="25" Y="5"/>
      <Text X="80" Y="12" Length="8" Fixed="Yes" Font="arial" Adjust="Left" VerticalAdjust="Top" Color="#FF0000"   Bright="Yes">
    <String>%((L:VAS, number))%!07d!</String>
      </Text>
   </Element> 
   
</Gauge>

Save the XML file as "VAS.xml", along with the background BMP file, in a folder called "VAS_Display"

 

Add the VAS_Displayfolder to your FSX Gauges folder and then declare it in the aircraft's panel.cfg file something like this:

 

//------ Add this line to the Window Titles section  xx=the last window number +1 ---------

Windowxx=VAS Display

//--- Add this section after your last window but ABOVE the first Vcockpit00 section ---

[Windowxx]
Background_color=0,0,0   
size_mm=136, 194    
window_pos= 0.87, 0.50   
visible=0
ident=1064
nomenu=0
type=special

gauge00=VAS_Display!VAS, 0, 0, 136, 194

 

 

I think that sould do it (I extracted the salient code from my existing gauge).

 

As always, back up any FSX files that you change (panel.cfg files)

 

  Paul

Paul, thanks for your info.  It will give me something to tinker with this weekend :smile:

 

Gerry

Do you use anything other than PE for measuring VAS?

Hi Paul, 

Like Dougal, I'm also interested in the gauge you use to monitor VAS.  Could you provide us with more info? 

Thanks,

Gerry

The following is taken from an upcoming revision to the AVSIM CTD Guide:

 

Monitor VAS – The freeware or registered versions of the FSUIPC utility will allow you to monitor the amount of VAS remaining during a flight session. This might be valuable in troubleshooting Out-of-Memory (OOM’s).

 

Startup program and then enter the Add-on Menu and select FSUIPC. Once FSUIPC is open, click on the Logging Tab and enter 024C under Offset and select S32 under Type. Select where you would like to have the usage displayed. The FS Window is for Full Screen sessions. The FS Title Bar is for Windowed Mode. AVSIM recommends you also check the Normal log file as this provides you information on how much VAS you had to start out with and then logs usage throughout your flight.

 

The VAS usage is displayed in Kilobytes (KB’s). The value represents the amount of VAS left so, the lower the value, the more VAS being depleted. The max amount of VAS allowed in computers with 64 bit Operating Systems is 4GB’s if running 32 bit applications like FSX. For 32 bit Operating Systems, the max amount of VAS allowed 2GB’s but this can be expanded to a max of 3GB’s with a switch like the /3GB switch. (NOTE: For more information regarding the /3GB switches for various Windows, please do a search with a search engine like Google or Bing as most members have upgraded to 64 bit Operating Systems).

 

To convert the KB’s to the amount of GB’s, you should use one of the Byte converters on the Internet like the following: Byte Converter. You will never see 4194304 KB’s displayed as this equals 4GB’s. You might see around 3GB’s (3145728) remaining when you first start up FSX/P3D but that too would be unusual. Do not be concerned with the amount of VAS remaining when you first start up. It fluctuates during a flight session.

 

Members might be interested in a utility in the AVSIM Library called Quantum Leap which allows you to speed up your trip across the US or any ocean but it requires the payware version of the FSUIPC utility. According to the developer, “this utility was written to allow an FSX aircraft established at cruise to "leap" to a point further along the flight plan track. It allows the user to select a nav fix or manually enter coordinates for the jump-ahead point, as well as setting a new time in the simulation to be set at the designated leap-ahead point. The primary objective was to leap forward on very long haul flights to eliminate long periods of droning or wrestling with accelerated flight. It was tested with the PMDG® 777 and 737NGX simulations, but will most likely work with most other add-ons.”

 

Out-of-Memory (OOM) – The following points apply in regards to VAS -

 

• FSX and P3D are currently 32-bit applications. A 64-bit operating systems is limited to 4GB of VAS no matter how much RAM (system memory) is installed. A 32-bit operating system is limited to 2GB of VAS with a “switch” to provide up to 3GB’s.

• OOM’s relate to VAS, not physical memory.

• VAS is not the same thing as the virtual memory (page swap file) that you can adjust in your system settings. A large page file or virtual memory swap file does not protect anyone from the 4GB VAS limit.

• VAS is effectively a pre-allocation of everything FSX/P3D can potentially access during a flight. It will fluctuate over the course of a flight and over different areas.

• Microsoft.net Framework packages reserve a chunk of the VAS and then commit memory from that chunk. For this reason, it is important you have the proper version of .net installed.

• See also API.dll.

 

Some common causes of OOM’s:

 

• Running out of Virtual Address Space (VAS). Happens mostly during flight sessions longer than one hour in commercial add-on aircraft and over commercial add-on scenery and airports with a lot of eye-candy.

• LOD_Radius 4.5 and/or Texture_Max_Load above 1024. AVSIM recommends a LOD_Radius no higher than 6.5 and a Texture_Max_Load setting above 2048. This includes add-on applications that increase texture resolutions above their default or texture compressions to 32 bit (i.e., from the default of DXT5 or DXT1).

• Disable BufferPools setting in program configurations. Comment the lines out in your FSX configuration as follows: //[bufferpools] (note two slashes in front of parameter). //UsePools=0. This tweak not recommend for P3DV2.

• Disable add-on Photoscenery not used for a flight session. Add-on’s such as FTX/ORBX may contain some photoscenery. Photoscenery will load if enabled even if you are not flying in that part of the world.

• High settings in weather programs. Going beyond the defaults set by the developers is dangerous in many cases.

 

Hope this helps.

 

Best regards,

• FSX and P3D are currently 32-bit applications. A 64-bit operating systems is limited to 4GB of VAS no matter how much RAM (system memory) is installed. A 32-bit operating system is limited to 2GB of VAS with a “switch” to provide up to 3GB’s.

 

 

Jim,

 

Did you mean to say "An 32-bit program running in a 64-bit operating system is limited to 4GB of VAS..."?  

 

Regards,

 

Dave

 

 

Hope this helps.

It certainly does Jim, thanks for doing the legwork and collecting this data on OOMs and VAS and posting here.  And thanks to all the others in the thread who also contributed!

 

...its amazing to think that, just like a real world pilot is also a meteorologist (Or better be lest he/she tempts fate when "guessing" what the weather will be), flightsim pilots who fly with all the goodies are also computer system experts (Or better be lest they are prepared to pull their hair out trying to figure out why their computer keeps crashing in flight). :Just Kidding:

 

In this new world (post computers), people have become (by necessity) multi-disciplined analysts.