Affects Version/s: 1.0
Fix Version/s: None
You landed on this page because we have detected a crash in "X4 - Foundations".
It's assumed that the crash occurs because the game ran out of system memory.
Note that in normal cases this should not happen with 64-bit applications and usually indicates an issue with the system setup.
Please follow these steps to verify your system is set up properly.
- Press the Windows Start button, enter "Control Panel" (without the quotes) and click on the entry to open the system control panel
- Click on System and Security -> System -> Advanced system settings -> Performance / Settings.... -> Advanced -> Virtual memory -> Change...
- Ensure that in this dialog either one drive is set to have the page file size managed by the system (i.e. no 2 and 3 in the screenshot below) or that Automatically manage paging file size for all drives (no 1) is ticked.
That way you ensure that the system doesn't artificially limit the available memory the game can use.
Please check your free disk space. If you specified only one drive to be used for the page file, verify that this drive has sufficient free memory available (in usual cases you can safely assume that ~20 GB of free disk space is more than enough for any practical situation). If you didn't limit the page file size, make sure that at least one single drive in your system has sufficient free disk space available (again: >= 20 GB should be considered sufficient).
This crash can also occur if the system runs out of memory because of some other application suffering a memory leak. If another application starts consuming too much memory, this can also trigger this out of memory crash.
If you regularly run into the out of memory crash, use the task manager and monitor the memory consumption by the programs running on your system. If you see a significant increase in another app (might be accumulating (slowly) over time, or produce high peaks), this is a hint towards some issue with that other application causing the crash in the game.
If you verified the steps above and still end up being redirected to this page upon a crash, feel free to contact us by mail for further support. Just sent a mail with the subject "X4-268 - out of memory" to firstname.lastname@example.org and add the following details to the mail:
- the dxdiag info taken directly after the crash occurred (this wiki entry describes how to get the information)
- a screenshot of the virtual memory dialog from the first step above showing your current page file settings
- the corresponding crash dump file (see this page with details on how to locate the dump file on your drive) - make sure to pick the correct .dmp-file by verifying the in the filename encoded timestamp roughly matches the date/time the crash occurred
We'll then get back to you trying to figure out the cause of the crash.
Games/Apps require memory to perform their work. Especially games can require a significant amount of memory. X4 Foundations is no exception here.
In general however the game hardly uses more than 4-6 GB of RAM. This can spike in certain situations (f.e. when creating a savegame) for which a continuous memory block is required. Still, even then the actual system memory the game requires should not exceed 6-8 GB in worst case situations.
You might therefore think that on a system with 8 GB of RAM you should never trigger situations of running out of memory. However, you have to account for two additional facts:
- other applications, drivers, and also the OS running at the same time as the game also require a certain amount of memory
- memory fragmentation
While you have more or less direct control over the first point (i.e. terminate any other memory hungry applications before starting the game), you don't have much to say when it comes to fragmentation in the memory.
Memory fragmentation is in principle the same thing as disk fragmentation. If the game currently requires 4 GB of RAM but is heavily fragmented, the memory it uses might be spread over (let's say) 8 GB of address space. If the game now requires a larger chunk of continuous memory (f.e. when it tries to create a savegame), it might end up exceeding what's available in your system.
Fortunately, that's where page files come in. If the current amount of required memory exceeds what's available in physical memory (i.e. RAM), currently unnecessary memory can be temporarily moved to the page file or memory can be directly referenced from the page file. Also as of Windows 10 memory can also get compressed while kept in memory ultimately increasing the amount processes can use beyond what is physically available without falling back to use a page file.
For cases like creating savegames this is still acceptable if this happens and will not be too noticeable by users performance wise.
The catch here is that if you also run out of available space for the page file, you are in trouble and there's no way for the system to provide the requested memory. Therefore, it's important to ensure that you do not unnecessarily restrict the page file size.
If you think back around 5-10 years ago, it was generally advised to set the page file size to a "reasonable" maximum size. Even better than that was to create a separate partition to be used solely by the page file. This "reasonable" size was advertised based on the fact that applications were limited to 2-3 GB of memory and on a system with x GB of memory, having a page file 1.5-2 times the available memory size was considered more than sufficient to cover all practical cases.
Nowadays things are different. 64-bit became the standard years ago, we have multi threading, and you keep a lot of apps running in the background while using the system without running into slowdowns which you would have run into on single core machines.
On the other hand, HDDs became so large that it doesn't really matter whether you have a page file of 1GB or 10GB, disk defragmentation became a background service which runs completely transparent to the user, and SSDs are a whole different type of drives where arguments given for limiting the page file size no longer apply (keyword: fragmentation handling).
So nowadays, there's really rarely a reason for keeping the page file setting to a fixed size.
Also be aware that your system has two distinct sets of memory (actually there are more, but only these two are relevant for this topic):
- RAM (aka: system memory)
- VRAM (aka: graphics card memory / video RAM)
While both of these are technically the same thing, VRAM is the RAM which is solely used by the graphics card and not available to the system memory. The out of memory crash described on this page happens however because of running out of system memory. So any increase of the VRAM won't make much a change to whether you are running into this crash and hence buying a better graphics card won't help in this particular case (obviously it might improve things in other situations).
We continuously work on improving the in-game memory handling to reduce the cases where someone runs into this situation.While this is an ongoing process where each new version has certain tweaks to improve the situation, we also identify and resolve bigger issues which led to this particular crash in older versions.
The following list provides a partial overview of the more relevant items and names the version the change got in. This might help you to get an idea that if you run into this issue in the past regularly, whether a later version might have resolved the issue for you.
- 2.50 Beta 4: Resolved a system memory leak which happened when the GPU ran out of VRAM.
- 2.60 Beta 1: Memory leak related to loading multiple savegames was resolved.
- 2.60 Beta 1: Multiple memory leaks were identified throughout the game and resolved (all combined, this should improve situations when running the game for longer sessions (talking here hours to days without restarting/reloading the game)).
- 3.00 Beta 3: Memory leaks related to signal leak gameplay were fixed. Especially if your play style is to regularly investigate signal leaks and ran into this crash, this fix might resolve the issue for you.
- 3.00 Beta 3: Unbound memory usage could occur with certain mods. This has been fixed and will no longer happen.
- 3.10 Beta 1: Fixed a case which incorrectly redirected players of a different type of crash to this troubleshooting page, instead. Players running into that kind of problem are now redirected to the correct troubleshooting page.
- 4.00 Beta 1: Reduces memory footprint, after having saved a game. Especially for saving successively within a game session, this might have previously resulted in significant memory consumption.
- 4.00 Beta 7: We replaced the memory manager used in the engine which should have an effect especially in reducing peak memory usage. This change also now reports most cases of out-of-memory condition with a specific Exitcode and corresponding popup message: Exitcode 1097
- 4.00 Beta 11 Hotfix 3: We tweaked the handling to better distinguish between cases of generic memory allocation issues and real out-of-memory scenarios. Therefore the exitcode changed to Exitcode 1113.
- 4.00 Hotfix 1 Beta 1: We tracked down a memory leak which could occur with modded games in specific cases. This mostly likely occurred whenever a savegame was loaded. Hence, loading multiple savegames within a single game session more likely triggered this case.
- 4.10 Beta 1: Fixed two resource leaks. One happened while standing on a platform in 1st-person (regression introduced in 4.00 Beta 5); the other (very minor) one could occur while controlling a ship and remaining stationary at the same position in space.