deplinenoise

That's fine, but virtual address space is the real concern nowadays, especially on a game system. Virtual address space has no relation to the amount of physical memory in the machine, so the options presented to game developers are: 1. Make a 64-bit program (unfeasible, as the installed base is still mostly 32-bit) 2. Apply workarounds that solve the problem for some users such as the fix I suggested (better, but still not foolproof, can be combined with 3 & 4) 3. Apply workarounds that limit the game's internal use of virtual address space to allow other things to claim the rest (hard to get right and requires user foresight, ArmA tries to do this with the maxmem parameter) 4. Allocate DX9 resources in the DEFAULT pool (reduces virtual memory but device recreation (e.g. alt+tag recovery, screensaver) will be serveral magnitudes slower as all resources will have to be recreated from source (hitting disk). I've found that even for 32-bit OSes it's a win to extend the virtual address space with the /3GB switch (Linux has a similar setting to alter the kernel/user split) and then let the kernel to the paging. The extra GB of virtual address space is worth it.

On 32-bit windows versions you're limited to 2 GB of virtual address space by default unless you boot with the /3GB switch. See http://msdn2.microsoft.com/en-us/library/ms791558.aspx On 64-bit windows versions, 32-bit processes always have a 4 GB vm space if they have the LARGEADDRESSAWARE PE flag set.

So, apparently BIS didn't set the large address aware flag on the executable, so the error is really that ArmA is running out of virtual memory space, not that the page pool is exhausted (i.e. out of memory). This happens frequently because when D3D9 resources are allocated in the SYSMEM or MANAGED pools, they are shadowed in main memory. This shadowing takes a significant slice of the virtual address space, which is already fragmented by DLLs and other things. I run Vista x64 with 4 gigs of RAM and a 768 MB 8800 GTX, and I was still getting the "Can't create surface.." crashes after upgrading to the 1.08 release. What I did was to manually enable the LARGEADDRESSAWARE PE flag of the ArmA executable. This allows D3D9 and other libraries to allocate larger, continuous ranges of virtual memory because the address space is twice as large. BIS should enabled the LARGEADDRESSAWARE linker flag for the next patch! I believe this will solve the memory errors for most high-end graphics cards, and it is virtually harmless on older machines. Until then you can enable it yourself. Disclaimer: for those of you who would like to try this, please note that it might flag your executable as different and thereby make it unsuitable for online play. No warranties, and all that. Take a backup of the executable. Download the Windows Platform SDK and install that. If you have a Visual C++ installation, that's fine too. Now run "editbin /largeaddressaware arma.exe" in the game directory, and you should be good to go. You can verify that the flag has been set by running "dumpbin /headers arma.exe".