FSX Locks up / FSX Not Responding Freezes
I'm posting this here as reference for those who shall be interested and its worth reading again !!
for those who suffer from the dreadful FSX Freeze Lock up problem.
Full Article Link here : https://kostasfsworld.wordpress.com/fsx-oom-and-addon-vas-usage/
Tho that article may disappear one day, its reposted here as a future reference for everybody to refer back to just in case !!
Simply explained, VAS is a working space of a program (let’s just call it that). DO NOT think physical memory or page file have anything to do with this. VAS is a specific space for an application, which can, under 64bit operating system be up to 4GB for the 32bit application.
64bit OS + 32bit application (FSX) = up to 4GB VAS
(32bit OS + 32bit application = 2GB of VAS, or max 3GB with a tweak)
Remember this, as this is the 101 for OOMs.
Does it matter if you have 4GB, 8GB, 16GB, 32GB of RAM? No. Does it matter how big or disabled your page file is? No.
So what does it mean? FSX has 4GB of VAS to work with.
Everything you load into FSX, basically loads into VAS. Be that an aircraft textures, airport scenery, tree texture, whatever you install and run, is going to have its place in VAS.
Since we do have a limited space of 4000MB, we have to have concerns when this space is going to fill up.
"All those nice airport sceneries, HD aircraft textures, they take a very heavy impact on the VAS when loaded" !!!!!!!!
One of the biggest culprits when VAS is concerned is LOD_RADIUS in FSX.cfg. This setting alone offsets the VAS usage by couple of hundred MB when bumped from default 4.5 to 6.5 (I also suggest this in my guide, but with the caveat that it can pretty quickly cause an OOM).
When this space fills up, you are presented by windows with a very nice message that your memory is low and the application will now close. FSX is going to quit.
What we should be aware of, is how much our addons use. Some use more, some use less, but they always take some VAS space.
And most importantly, due to nature of FSX, this space is not freed as you fly along, nor has anyone yet come up with a plan how to free it up or fix this problem.
So for example: you start your flight with an addon aircraft and addon airport, and your VAS usage is 2800MB. When you fly along, this usage will slowly grow.
If you don’t overfly any other addon airports, it is bound to grow maybe couple of 100 MBs. let’s say for the sake of an example: up to 3200MB.
When you come into range of your destination, and let’s assume you have an addon airport, which loads about 300MB into VAS, you will successfully land, as you will end up with 3500MB VAS.
But, let’s assume another scenario, in which you overfly two airports on the way to your destination, or you have some photo scenery, or or or, and the VAS usage grows up to 3700MB until descend. Now you can pretty much sure your sim is 99% going to crash on landing with out of memory = OOM error.
So, what you can do is only counteract it through some sim-management!
1) Always know your VAS usage, keep a tool for measuring it at hand, so you can quickly check
2) Keep your other scenery deactivated – now, while I understand this might be a nuisance, there is a simple way of doing it – Scenery Config Editor – this tool gives you a possibility to quickly disable all non-essential scenery with a bit of sorting-imagination.
Download here: http://sourceforge.net/projects/fs-sceditor/files/
A word of caution on this tool: while very helpful, it can cost you your whole scenery.cfg if you are not careful.
My suggestion is to run it as FSX obviously, but uncheck the “Follow the New Scenery convention”. This will always change the scenery.cfg directly, which means, after you install a scenery, if the installer is following the New Scenery.cfg convention, you MUST start FSX first, before the scenery will appear in the scenery.cfg. Also always keep a manual backup of your scenery.cfg.
3) Keep away from really high quality textures, as much as you can – I know they are looking nice and beautiful. If you know what you’re doing, by all means, load them up, but flying NGX with McPhat HD textures over ORBX into UK2000 EGLL with 4096 clouds is not a possibility, so much I can tell you.
4) If you are in flight, and notice a high VAS usage (meaning very high, so that you probably won’t be able to land): save and reload the flight, possibly lower the LOD_RADIUS in between. Make sure however you are flying the aircraft that supports that (PMDG stuff does for example).
So how do we measure VAS:
There are more ways than one, but for me, the simplest one is a tool called “Process Explorer”, can be downloaded here:
http://technet.microsoft.com/en-us/sysi ... 96653.aspx
When you start it up, I suggest you press on the Process column, to sort the processes after their names, alphabetically.
As the next step, in the menu -> View -> Select Columns -> [Tab] Process Memory -> [check] Virtual Size -> OK.
Additionally you can deactivate any other columns that are displayed by default, if any. In the main window, press onto “Virtual Size” column, to sort after the virtual size. This will always put FSX as the first when running.
This will give you a neat view of FSX VAS so you can quickly monitor it.
NOTE: It is NOT possible to view VAS with a stock Windows Task Manager. Anyone coming to me with that idea, will be fully ignored.
Use above approach or any alternative (but then again, you should know what you’re doing if using alternatives).
So, I’d like to urge everyone, before you start yelling at developers that their scenery is causing OOMs, reflect upon your system and see how many OTHER stuff you have running and question yourself which one is the biggest culprit and where can you optimize.
Most importantly, if you have something to add to this page, which might benefit everyone, please make a comment, I’ll be glad to add it into the page.
Additionally, I will start here with couple of VAS usages for addons I own and use a lot, so you get a feeling what each addon uses, and I hope to expand the list as the time passes:
PMDG NGX: 741MB
PMDG 747: 711MB
UK2000 EGKK: 140MB
ORBX ENGLAND: 200MB
(Also please keep in mind these measurements are not 100% accurate, simply because they can’t be, they are more like guidelines)
ADDENDUM (Microsoft Fix, Heap Limit change):
https://kostasfsworld.wordpress.com/201 ... helperfix/