As I understand it this program manages addons for fsx. I've had a few OOM's lately so have been using process explorer to track memory usage and couatl.exe is taking up 152,456K of VAS. This is very valuable VAS, so my question is can I disable it somehow, and what are the consequences?

As far as I know this file is for FSDT addons, if you disable it your FSDT airports (if you own any) will not work properly.

 

Regards,

First question: Go to the exe.xml file (C:\Username\Appdata\Roaming\Microsoft\FSX) and search for the entry of Couatl. Then simply replace the line <\Disabled>TRUE<Disabled> to <\Disabled>FALSE<Disabled>. This should disable it.

The consequence you'll face is the loss of some FSDT features, such as GSX.

 

Regards,

Flo

Not only FSDT product like airports and GSX, but also Flightbeam aiport (KSFO,KPHX) and Qualitywings 757.

It's not only for FSDT airports, i don't have their airports, only GSX. It works with all, default and payware, without problems. "Folow me car" can taxi on grass sometimes, everything else works like a charm

I think couatl would have its own memory VAS, not part of fsx, right? So I don't think your concern of VAS usage is an issue.

 

scott s.

.

I can't say I've experienced this problem with it. Works great on my system and setup.

 

Try lodging it in FSDT's forums, they are really good with supporting these types of issues.

 

They'll have you up and running in no time.

 

Jas

I think couatl would have its own memory VAS, not part of fsx, right? So I don't think your concern of VAS usage is an issue.

 

 

Exactly: each separate .exe process in the OS has its own private VAS, and each one can allocate up to 2 or 3GB for itself under 32 bit Windows, and 2 or 4GB under 64 bit Windows. It's 2 or 3 and 2 and 4 depending if the .exe was compiled with the IMAGE_FILE_LARGE_ADDRESS_AWARE flag enabled.

 

If Couatl.exe is taking 150MB of VAS, this is NOT taken away from FSX, but from the Couatl.exe private VAS.

 

Note that this space is not really "taken", because a large part of it is represented by Memory mapped files so, the number reported it's only an indication that Couatl.exe asked Windows to provide a "window" (MUCH smaller) over files that were read/written by Couatl for several reasons, but the actual memory allocated might be much less than that, because Windows will then arrange such requests with its own buffers.

 

And, Couatl.exe being a Python interpreter, it has its own internal memory manager with its own private heap, and there's really no way in Python to leak memory outside that heap, which makes Python a very safe language in regard with memory issues (exactly the opposite of C/C++), it's more similar to C# or Java in this regard.

 

Note that, Virtual Address Space doesn't really have anything to do with physical memory. The mapping between VAS and physical ram (or storage) is handled by Windows so, you can have 50 process running, each one with its own private 2GB VAS, on a system with just 4GB of RAM, because if they won't fit in the physical memory, the OS will start to swap memory pages to the hard disk.

 

That's why, it's technically impossible that Couatl.exe would cause an OoM in FSX, Couatl.exe can't even *see* the FSX memory, because they are entirely separate, if you had an OoM in FSX, it could only be caused by something internal to it, like a .DLL (not .EXE) module, either from FSX itself (like the g3d.dll) or from a 3rd party, and this includes also .GAU files for airplanes, which are just .DLL with a different name because the *combination* of all memory allocated by FSX and its .DLL/.GAU modules, exceeded the 3GB that FSX can allocate, since it's a 32 bit app with the IMAGE_FILE_LARGE_ADDRESS_AWARE flag.

 

Just to make it more clear: it's entirely useless trying to walk your running .exe processes in Task Manager, to fix an FSX OoM because, if you let Windows manage your swap file, the only way you could get a general system-wide OoM, is to end your hard drive space too, especially on a 64 bit Windows, were the *total* allocated memory could go up to 8TB!

 

You could kill ALL you other running processess, and still get an OoM, the only advantage of killing running process, would be getting better performances on a system with not so much RAM (let's say, less than 6GB), because with less running processes, there are less chances the system will need to start swapping.

 

So, your only option to fix an FSX OoM, is simply looking *IN* FSX: it's either a scenery, terrain, AI and/or settings, and all 3rd party .DLL and .GAU modules installed.

OOM errors are rare with 64 bit systems, very rare. Did you set your own virtual memory (page file) settings? Try System Managed Size. Seems to work best with FSX.

 

Best regards,

Jim