Hi,

I am making a mission where I have AI and Civ spawn ranges set to 1500 for land based units and helicopters, for jets I have Civ range set to zero and AI set to 2k spawn radius so I can attack with the USAF AC 130, the mission is restricted to the left half of Altis and I am doing asymmetric warfare.

I am assuming I have my AI and Civ spawn settings too high but my question is this, after about 15 minutes of flying around on my mission one of two things happens, over time my fps drops to 5 and stays there till I quit mission, or, if I fly around a lot and then open the mission Task generator tablet to generate a task, the game freezes and generates the out of memory error below.

I have 8 gigs of ram and run on Windows 10 64 bit with two GTX 970s and an over clocked Sandy Bridge quad core. Is there something I can do to make my PC handle my intense mission settings(even a hardware upgrade would be fine) or is my only option to tune down my CIV and AI spawn settings?

20:13:10 DX11 error : CreateTexture failed : E_OUTOFMEMORY
20:13:10 DX11 error : CreateTexture failed : E_OUTOFMEMORY
20:13:10 DX11 error : CreateTexture failed : E_OUTOFMEMORY
20:13:10 DX11 error : CreateTexture failed : E_OUTOFMEMORY
20:13:10 DX11 error : CreateTexture failed : E_OUTOFMEMORY
20:13:10 DX11 error : CreateTexture failed : E_OUTOFMEMORY
20:13:10 DX11 error : CreateTexture failed : E_OUTOFMEMORY
20:13:10 DX11 error : CreateTexture failed : E_OUTOFMEMORY
20:13:10 DX11 error : CreateTexture failed : E_OUTOFMEMORY
20:13:10 DX11 error : CreateTexture failed : E_OUTOFMEMORY
20:13:10 CreateTexture failed : w = 3000, h = 1858, format = R8G8B8A8_UNORM, err = E_OUTOFMEMORY.
20:13:10 DX11 error : CreateTexture failed : E_OUTOFMEMORY
20:13:10 Virtual memory total 4095 MiB (4294836224 B)
20:13:10 Virtual memory free 154 MiB (162156544 B)
20:13:10 Physical memory free 2167 MiB (2272374784 B)
20:13:10 Page file free 1781 MiB (1868316672 B)
20:13:10 Process working set 2262 MiB (2372640768 B)
20:13:10 Process page file used 3463 MiB (3631677440 B)
20:13:10 Longest free VM region: 26804224 B
20:13:10 VM busy 4132745216 B (reserved 265072640 B, committed 3867672576 B, mapped 120565760 B), free 162091008 B
20:13:10 Small mapped regions: 25, size 106496 B
20:13:10 VID: dedicated: 3221225472, shared 1073676288, system: 0, max: 2906652672, used: 2430021632
ErrorMessage: DX11 error : CreateTexture failed : E_OUTOFMEMORY

You guys are awesome thank you!

I'm having the same problem.

@SpyderBlack723 - a 32-bit process cannot allocate more than 4GB of virtual memory on a 64-bit OS. So you can't just "increase the virtual memory" given to ARMA.

This is probably a leak, as I only see the OOM crash after going in and out of SP preview in the editor a few times. The new 64-bit client will probably partly fix this, although then we're gonna start running out physical RAM rather than virtual. At least it will take longer! :D

I don't see how changing the paging file would help in this case, as the virtual address space has been exhausted. Changing the swap/pagefile size doesn't change that situation. You can also see in his RPT that he has over 1.7GB free in the pagefile.

The reporter (and I) are coming up against fundamental memory limits of a 32bit process. That can either be caused by a leak or simply just trying to use too much memory at once. Either of these is possible.

@marceldev89 I'm not saying that the suggestion isn't valid in any case, I'm saying that @raditz5 's rpt file doesn't suggest it will help. Here's my rpt file from a similar crash .

Both rpts show the same thing - exhaustion of virtual memory, large pagefile, and plenty of page space free. I, for example, have an 8 GB pagefile set on my SSD.

I'm willing to guess as well that there's some kind of pagefile size limit, either imposed by ARMA or Windows. The numbers I've seen in my RPT file, @raditz5 's report file, and the numbers here on the BIS feedback app are all very similar. We all have about ~3.2-3.4 gb pagefiles with large amounts of page file space still free.

If I had to guess, here would be some things that would solve this crash (haven't tested yet):

• Turning down draw distance
• Turning down AI spawn distances in ALiVE
• Lower graphics settings (maybe not - I would think this affects video memory memory, which isn't an issue)

ARMA can only page out memory to the pagefile if it isn't currently required by the engine - so running out of virtual memory here suggests that we're just placing too high a load on the engine and need to dial it back, thus my suggestions above.

Update: I tried a combination of fixes I mentioned - reducing graphics levels, removing some unit mods like RHS, and reducing spawn distances in ALiVE, and that seems to have completely removed any crashes I'm experiencing. I don't think there's a leak in ALiVE or ARMA at this point, and whatever I was doing was simply too demanding on the engine.

There are lot of misconceptions about memory usage in ARMA in this thread, so let me clear some up:

• ARMA is currently a 32-bit process. This will change to 64-bit soon, but until then, ARMA cannot utilize more than 2GB of RAM on a 32bit OS, and about ~3.5GB of RAM on a 64bit OS. This can be seen in our RPT files - look at "Process Working Set". So upgrading RAM beyond ~6GB does almost nothing for ARMA (of course it helps in general, more room for the operating system, etc.) If you're not running any additional applications while running ARMA, 6GB of RAM would be more than enough.
• ARMA makes excellent use of the pagefile/filesystem memory, as noted in the link, but this system has limits. Not everything can be stored on the disk, because disk access is *orders of magnitude* slower than RAM. So ARMA is probably storing things like textures, units not onscreen, etc on the disk. Basically, think of the pagefile as "things ARMA doesnt need right this second, but needs quick-ish access to later". It seems like this pagefile can get rather large (~10GB) but, again, only certain things can be stored there, and definitely not things that the ARMA engine needs to render the current scene.
• All of our RPT files posted so far contain valuable information - none of us are exhausting the free space of our pagefiles, and we're all running out of virtual memory space. That clearly indicates that the current scene/whatever ARMA is trying to render is too complex.

So, to go back to OP - @raditz5 your spawn ranges and spawn limits are too aggressive. Turn 'em down. I haven't tried them in isolation, but mods and graphics settings may be an aggravating factor.

@tupolov it certainly does!

@SpyderBlack723 thats what I do.

@marceldev I'm not quite sure what "in-use" memory means in Task Manager, but as I said above, "in-use" memory does not necessarily mean "memory currently residing in RAM". Committed memory isn't even necessarily used - committed memory is just the OS saying "hey, this memory is available, so you can use it". So, not sure what you're getting at. Tools like RAMmap and Resource Monitor all show the working set size (actual live memory in RAM) of my ARMA processes to be less than 2GB.

@marceldev89 mate, you're not understanding this. Programming is my day job so I know how memory works. Committed memory != virtual memory in Windows. Virtual memory has addresses, that's the entire point of virtual memory - to create the address space. I have said over and over again how Arma's filemapping is great but has limited uses as how having 12GB in a pagefile is not the same as an application using 12GB of RAM.