FSX crashes

[Illegally Flying]

SPECS:
Processor: Intel(R) Core(TM) i3-N305 1.80 GHz
Installed RAM 8.00 GB (7.66 GB usable)
System type: 64-bit operating system, x64-based processor
Cores: 8
Logical Processors: 8


FIRST CRASH:

So I keep crashing and I dont know why. I did delete the UIAutomationCore.dll. Whats happening is, after I fly in FSX for over 20-30 minutes I get the windows mouse loading and then it just closes to desktop.

SECOND CRASH:

Theres this other one where if you finish flying and go to the menu and then go back to flying, you get this black screen


Any help guys. I wanna do a long haul flight in FSX without crashing and I cant do that until I fix the crashes.

[Rogen]

Running out of VAS (Virtual; Address Space) perhaps ? That is exceeding the amount of memory addresses FSX can access as a 32bit program which is essentially a 4 gb window of memory on a 64 bit OS or 2 gb on a 32 bit OS.

If you want a 64 bit version of FSX look no further than Prepar3D by Lockheed Martin, their 4.5 release is for all practicability, FSX as 64 bit which can handle huge amounts of VAS far far greater than FSX being a 32 bit program.

Plus it is DX11 based and resolve many of the existing FSX bugs and has a very high FSX compatibility rate.

Cheers

[JJ FSX]

Frankly a 1.8ghz CPU is pretty slow, however with 8 cores, it would be better than an old single core that FSX was designed for. Since we have more cores now, we have to have the correct AFFINITY Mask in fsx.cfg for FSX to use them. If it's only using one CPU it will crash a lot, especially at 1.8ghz. If the mask is missing it will only use the first core. The correct mask tells FSX not to use the first core0 but to use all of the others. Is your FSX using all cores? Check with Performance Monitor.

If your Affinity Mask is good and you still get random crashes, then try Setting your VM (paging file) to a fixed size, do not let Windows Manage it, With 8GB memory set it to a fixed size of 6144 (6GB). I've had 3 different systems where this stopped the random crashes. I currently have 32GB of memory and set my VM fixed at 10240 (10G). I don't get any random crashes and do very long flights.

More on this here:

https://steamcommunity.com/app/314160/discussions/1/4336483289194240631/?tscn=1721801395

[Rogen]

VAS is not a paging file...

That setting a manual paging file might assist in general operation and thus reduce the incidents of FSX crashing, it cannot increase VAS beyond the limit of what a 32 bit program can access, more likely it's just helping in not fragmenting memory blocks to excess.

Cheers

[JJ FSX]

Originally posted by Rogen:

VAS is not a paging file...

That setting a manual paging file might assist in general operation and thus reduce the incidents of FSX crashing, it cannot increase VAS beyond the limit of what a 32 bit program can access, more likely it's just helping in not fragmenting memory blocks to excess.

Cheers

Since VM stands for Virtual Memory (the paging file) and VAS stands for Virtual Address Space of the VM. IMO both refer to the same thing. The paging file is where the VAS is.

[Rogen]

Sorry JJ FSX... that's a common misunderstanding, VAS being "virtual address space" is where every single piece of memory is referenced via an address (VAS exists for all computers and OS),

The key here is "address" where the maximum addresses a 32 bit program can access will be in a range of 2 GB and 4 GB depending on if the OS is 32 or 64 bit and although 2~4 GB sounds like a lot, hungry programs like FSX always demand more.

And as programs began to exceed 32 bit limits, the 64 bit CPU and OS were born, where VAS is quite huge being 16 EB ( EB=exabytes or 2^64 bytes) of memory, though in reality a 64 bit CPU architecture, the motherboard itself and the Microsoft OS typically have limitations on the supportable address ranges and amount of memory.

Unfortunately memory swapped out to a disk paging file is not in anyway going to enable a 32 bit program to have access to more VAS greater than the existing 32 bit limitations of the machine.

The above said, managing the page file size manually will likely help get past any latencies of a dynamic swap file, for example as referred to in MS's troubleshooting advice link.
https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/slow-page-file-growth-memory-allocation-errors

As to VAS, here's a pretty good description in relation to FSX and how to work around the limits.
https://kostasfsworld.wordpress.com/fsx-oom-and-addon-vas-usage/

And here's another from PMDG.
https://support.precisionmanuals.com/kb/a108/vas-management-stopping-out-of-memory-oom-errors.aspx

There are other more technical discussions and papers e.g. Microsoft's Mark Russinovich has written a number of papers regarding 32 bit processes and memory handling, try searching for, Mark Russinovich's Pushing the Limits of Windows if you want to know more.

I can say with FSX I was constantly planning which scenery I would load for a planned flight and what aircraft I was intending to fly due to the possibility of running out of VAS, where as with P3Dx64 I can load everything and fly any aircraft without needing to worry about VAS at all, truly a relief.

Cheers

[JJ FSX]

Thank you for the detailed information Rogan.

I never said or meant FSX would have access to more than 4GB, I know thats the 32bit app limit, All I meant was the fixed size setting of VM prevents that latency, just as you said.

And with only 8GB physical memory on his machine windows is a lot more likely of calling the algorithm to decide if expand/swap is necessary or possible. With the size of the VM fixed the OS never calls that algorithm. That's all I was saying.

Cheers

[als_a_surfin]

Recently added aircraft, added plane through current aircraft. tried to add another didn't show up in current, went to load and got the plane in,. then I could added another through select. That seems to be to only way to add another plane.

[JJ FSX]

Rogan and everyone, a clarification;

There is an important thing that is out-dated in the article linked to here, I'm pointing it out so that people aren't misled into making huge pageing files (VM's), should they try my solution.

https://learn.microsoft.com/en-us/troubleshoot/windows-client/performance/slow-page-file-growth-memory-allocation-errors

It says: "We recommend that you set the initial size to 1.5 times the amount of RAM in the system."

That recommendation was valid, in the old days when computers had under 4G of physical memory. To have a 32 GB physical memory PC have a pageing file 1.5 times that (48 GB) is WAY TOO BIG, unnecessary and can hurt performance instead of help it.

Current day typical Physical Memory to Page file size recommendations are:

Physical Memory ........... Fixed Pageing file size.
8 GB...................................6 GB (6144 actual)
16 GB..............................10 GB (10240 actual)
32 GB..............................10 GB to 12 GB (12,288 actual), 16 to 20 GB if running Servers.

I have 32 GB physical and set my VM size to 10 GB and do very long fights (6+hours) with no crashes. And the OS runs super well. If you (I) ever get an OOM I would enlarge it in 2GB increments until you don't.

Hope this helps those that find it.
Cheers