Been getting a crash about once per day with an “out of memory” error.
Usually happens in New Dawn after doing the daily Talos.
Note: just restarted after the crash. Finished the current mission (which involved running about 10 steps and clicking on the quest giver) and SWL RAM usage is at 1961MB, which for a 32-bit executable seems a lot.
do you have a decent sized pagefile? if not do that
1960 MB sounds reasonable.
Been checking:
2 GB seems the max a 32-bit exe can eat on Windows, check 1st line in this table
TSW / SWL always had memory management issues afaik, and I doubt they’ll ever get fixed. It can come from the source code itself, or from the interpretation the compiler does with the code.
(FC devs, what’s the compiler you’re using ? Switch to llvm/clang ! 
)
Re-installed Windows a few months ago since I got new core systems including an NVMe drive. Still have the old SSD for comparison as a secondary drive. Old page file was 32GB, new one is 4GB. I have 32GB of RAM.
However, I have not run into OOM problems with any other program.
From the MS link you shared:
User-mode virtual address space for each 32-bit process on 64-bit systems: 4 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE using switch /PAE in boot.ini (boot.ini appears to have been secured from using the front door to edit it in win10, and everyone seems to recommend using a 3rd party program to access it in that environment.)
@rephaim Yes, but the exe also needs to be compiled with large address awareness. The only case I know about is for old Skyrim, Bethesda released a patch so the game could use up to 4GB system ram. I guess only FC devs know about SWL exe behaviour.
From a Skyrim mod comment (Note: it’s about the original 2011 Skyrim which is 32bit exe; the Skyrim Special Edition is a 64 bit exe):
«Skyrim TESV.exe is already large address aware (at least for the latest version). You can test this easily by uploading your original tesv.exe to www.virustotal.com, and then checking the details screen for whether it’s large address aware»
Obviously, I tried the virustotal tool by sending “SecretWorldLegendsDX11.exe”, and i can confirm that’s a 32 bit exe, and i didn’t see any large address awareness reference.
Both of the SWL clients have their LAA flags set.
@aeryl showed us SWL is compiled with large address aware flag, meaning on a 64bit Windows, SWL client should be able to use up to 4GB ram. Or maybe it just doesn’t need that much /shrug
Which is odd then because when I get the crash and report to Funcom dialog and I go to Task Manager it reports usage in the 2100MB plus range, not in the high 3000MB I would expect if it actually were running out of memory.
Although the crash is always in MemoryManager.cpp (640) IIRC. So it’s likely trying to allocate memory and crashing.
Also if I crash in New Dawn when I come back there seems to be some sort of fog - the sky is a much deeper blue than it normally is, no matter what time of day and things look foggier. It’s not the draw distance bug (I had that happen for a while off and on, so I know what that looks like). Really not sure what’s going on there - crash and restart should set things back to normal if everything is really cleared out.
The change in lighting after a crash in New Dawn has to do with how they simulate different times of day in the area. New Dawn is one of the few outdoor zones that has no regular day/night cycle, so they use visual trickery.
You’ll need to add the switch listed above to your windows boot file to authorize LAA programs access to that otherwise restricted memory.
“The Intel Itanium and x64 processor architectures can access more than 4 GB of physical memory natively and therefore do not provide the equivalent of PAE. PAE is used only by 32-bit versions of Windows running on x86-based systems.”
Adding the PAE option to boot is only required on 32bit Windows and I tend to believe almost all the Windows installed on home computers are now 64bits (especially tyrfing’s one since he got 32GB ram).
So despite game being large address aware, and being on a 64bit system, it seems SWL doesn’t want to use more than 2GB ram, or just doesn’t need it.
About the MemoryManager.cpp error, well, chances for that to get fixed are very very slim, since it’s been around since TSW time, and i think FC devs are actually busy on their Dune game. (And debugging mem errors is just hell for devs).
Refer to the previous link you shared, the 2nd column explains on 64 bit hardware the limit is still 2gb for 32 bit programs if flag is not set, 4gb if it is.
Update: Nevermind, you did say 32 bit windows is required and that is correct.
As far as I can tell, the crash happens when SWL has more than 2GB allocated, since that would be 2048MB. After the crash I can go to Task Manager and the program generally has somewhere between 2100 and 2600MB allocated. I have also used Task Manager a couple of times before the crash and it generally has more than 2048 allocated.
Something else is happening. Perhaps it’s asking for too large an incremental allocation or perhaps the code to shape the requested memory is failing somehow.
I am by no means an expert on this - my programming with C and C++ was >25 years ago and was undergraduate-level assignment stuff.
32-bit Windows can only address 4GB anyway (without some sort of windowing). I was under the impression that normal programs allocated the lower 2GB for the program and the upper 2GB for addressing Windows services, while the LAA switch changed that to 3GB and 1GB respectively.
Not sure how it works with 64-bit Windows (yes I have that). Presumably there’s still a “Windows service window” in the upper address area for 32-bit executables (shades of the DOS 640kb space - yes I did do some upper memory stuff to get certain DOS programs to run).
