FSDreamTeam forum
Products Support => Los Angeles support FSX/P3D => Topic started by: balus on July 08, 2016, 01:19:38 pm
-
Flying from KIAD (Flightbeam) to KLAX (FSDT) and I get to about 26nm from 25R and I get a message that I am out of memory. I have tried adjusting paging files, reducing the LOD to medium but no change. Running ASN, flying an Aerosoft A320 on an i4790K, stock speed, with a GTX970, 16 GB ram in Windows 7
Any hints!
-
and I get to about 26nm from 25R and I get a message that I am out of memory.
That clears that FSDT KLAX doesn't have anything to do with it. The scenery loading range for KLAX is exactly 16.0 NM. Beyond that range, nothing of the scenery is loaded.
Since you were approaching from the west, the most likely cause for an OOM are too dense autogen settings (approaching LAX downtown), 3rd party sceneries for that area and too high scenery LOD range. A combination of everything, of course.
The only thing that wasn't loaded at that stage, was the airport.
-
Thanks Umberto,
Upon reflection perhaps the information I gave was incorrect, I was somewhat frustrated. I have tried this flight 3 times, the first 2 the error was just before landing, i.e. about 200 ft, the third time was earlier, maybe 26 mm was when the localizer became active and that's why it stuck in my mind.
On each occasion the culprit is reported as being couatl.exe, checking my event log
Faulting application name: couatl.exe, version: 3.1.0.3487
Faulting module name: ntdll.dll, version 6.1.7601.23455
Exception code: 0xc0000374
Fault offset: 0x000bf1cb
faulting application path is the path to couatl.exe and the faulting module path is c:\windows\syswow64\ntdll.dll
The previous errors are similar with the same exception code and offset
Edit: just checked my last Autosave and the location was N33 57.97 W118 7.43 which would put me somewhere just to the west of the DOWNE intersection - autosave is set 60 seconds.
-
On each occasion the culprit is reported as being couatl.exe, checking my event log
That doesn't mean Couatl.exe is the "culprit". It only shows it has crashed BECAUSE FSX exhausted its memory so, of course, an abrupt crash of the sim will likely Couatl to crash too.
Couatl.exe is a separate application, so it's not affected by a lack of memory in FSX, and it doesn't take away memory from FSX either, surely not when there's no scenery loaded. And you can be sure that nothing is loaded at that distance.
Since you said yourself the error report was the same on each occasion, it's clear that it cannot be the airport itself, otherwise it wouldn't have crashed at 26.0 NM out.
Couatl is the victim of your problem, here, not the cause.
-
Thanks Umberto,
if you re-read my second post you will see where I have stated that on 2 occasions that I was within 200 ft of landing.
I suppose my question would be why doesn't this happen at other airports, I have quite a few FSDT titles and have not had this problem. If I can fly a 12 hour flight in a PMDG 777 and land at KJFK with no problems, however I can't fly a 6 hour flight with a relatively light (VAS wise) Aerosoft A320 into KLAX, and I can consistently recreate the problem, then something is wrong.
Edit: I have uninstalled KLAX and re-flown the flight, this time successfully so it is FSDT KLAX that is pushing the sim over the edge. VAS after landing was around 600 MB free. I am also running MyTraffic and ASN, I wonder if they are contributing in some way - ASN is on another machine so I doubt it would be the issue.
I did monitor VAS quite closely after TOD and there is something happening at between 20 and 26 nm with FSDT KLAX - the amount of VAS available with it removed was 2 to 3 hundred MB higher.
-
if you re-read my second post you will see where I have stated that on 2 occasions that I was within 200 ft of landing.
If you re-read my post, you will see that I took account of this:
Since you said yourself the error report was the same on each occasion, it's clear that it cannot be the airport itself, otherwise it wouldn't have crashed at 26.0 NM out.
I'll try to explain it better: you said you have exactly the SAME kind of crash, both at 26.0 NM and just before landing. Since the crash it's the same (according to your report), and it happens at 26.0NM too, this clears up entirely the scenery being a problem.
If the crash happened ONLY before landing, the airport *might* have been the problem (it wasn't sure, but it was at leaqst possible), but if the SAME crash happens also when the airport is NOT loaded, than it CANNOT be the airport.
I suppose my question would be why doesn't this happen at other airports, I have quite a few FSDT titles and have not had this problem. If I can fly a 12 hour flight in a PMDG 777 and land at KJFK with no problems, however I can't fly a 6 hour flight with a relatively light (VAS wise) Aerosoft A320 into KLAX, and I can consistently recreate the problem, then something is wrong.
Not everything happening on any airport "must" be caused by the airport itself. The sim loads hundreds of files belonging to each and every addon you have installed at any given time, and each one takes a bit of VAS away from the sim. That's why you cannot say the OOM is "caused" by any one of them. It's caused by ALL of them, together.
Edit: I have uninstalled KLAX and re-flown the flight, this time successfully so it is FSDT KLAX that is pushing the sim over the edge.
It's not KLAX. It's everything. Of course, if you uninstalled something *else* or used a less memory-hungry airplane, you would obtained a VAS saving, preventing from OOM just the same.
For example, if you used a default airplane instead of the PMDG 777, you would have saved at least 600-700MB, compared to the 200-300MB you said you saved by uninstalling KLAX.
VAS after landing was around 600 MB free. I am also running MyTraffic and ASN, I wonder if they are contributing in some way - ASN is on another machine so I doubt it would be the issue.
600 MB VAS free without KLAX installed ? That's clearly proves you are already pushing far too much with too many installed addons and too memory-hungry addons and too high settings!
Here's the memory graph from ProcessExplorer at KLAX runway 7L, with the default 737:
http://www.virtualisoftware.com/binaries/images/klax_7l_737.jpg (http://www.virtualisoftware.com/binaries/images/klax_7l_737.jpg)
Here's the same, with the PMDG 777 loaded:
http://www.virtualisoftware.com/binaries/images/klax_7l_pmdg777.jpg (http://www.virtualisoftware.com/binaries/images/klax_7l_pmdg777.jpg)
As you can see, the PMDG takes 600 MB more of the default 737. I still have plenty of VAS free, even in the worse case ( 4.0 GB max - 1.8 GB = 2.2 GB VAS free ) so, you surely must have many other addons taking away VAS, if you only have 600 MB free at KLAX.
I am also running MyTraffic and ASN, I wonder if they are contributing in some way
Everything contributes! As you can see in the thread I've linked below, MyTraffic alone can take about 300MB, which is like the whole KLAX airport. Of course, this is not always the same, but it changes depending on traffic density and schedules.
ASN is on another machine so I doubt it would be the issue.
Of course ASN takes away VAS! First, even if the .EXE runs on another PC, the program is also use a .DLL, and that is loaded in the FSX VAS space, but the most memory are the *textures* taken by the clouds generated by the program, and the clouds models too. The more cloud layers you have, the more memory it takes.
Everything takes memory. The only thing that doesn't, is something that is not loaded. At KLAX is NOT loaded until exactly 16.0 NM.
I did monitor VAS quite closely after TOD and there is something happening at between 20 and 26 nm with FSDT KLAX - the amount of VAS available with it removed was 2 to 3 hundred MB higher.
Which further proves KLAX is NOT the problem. 200-300 MB for a detailed airport is nothing, and clearly indicates how well KLAX is optimized for VAS.
Some posts with tests made to prove which are the most memory-consuming things:
http://www.fsdreamteam.com/forum/index.php/topic,10512.msg81737.html#msg81737
-
Thanks for taking the time to explain Umberto, I do appreciate it. Time for some more investigation.