Hello Guys So I just downloaded and installed the client and went onto a match then as the game was loading it closed out completely and I was given an Application Error box stating : "The exception unknown software exception (0x40000015) occured in the application at location 0x601f327c" 2nd time around Was able to play the game for about 30+ mins then it froze. music shut down then the game just closed.
You have two problems. First it's outdated drivers: Code: ATI Radeon HD 5700 Series Driver Date/Size: 12/19/2012 16:09:52, 960512 bytes And most important problem, 32-bit operation system: Code: Operating System: Windows 7 Ultimate 32-bit (6.1, Build 7601) Service Pack 1 (7601.win7sp1_gdr.130708-1532) Memory: 4096MB RAM Available OS Memory: 3328MB RAM With 32-bit OS you only able to use 3.3GB of RAM and game is only able to use 2GB. You can check memory usage on crash, I mostly sure that your crash related to out of RAM. For your hardware you really need 64-bit OS.
Weird part is that the game works whenever I play 2v2 teams but crashes whenever I play anything else... How is it that the game crashes due to memory? I've not had any issues with other high end games in my life!
Other high-end game are designed for consoles with 256MB of RAM. This game is designed for current-gen PCs and 32-bit systems are not current gen. It's generates large planets and store everything in RAM. There is mostly no 32-bit only CPUs manufactured after 2007 year, no reason to use outdated architecture in 2013.
I understand but that being said that means the minimum spec requirements for this game would be 64bit only OS and 6gb+ of ram to even play the game? What about the 2GB of ram my video card has? What about windows virtual memory? There has to be a work around for us 32bit OS users because that would not be nice to all of us who purchased the game without knowing this bit of info.
On a 32bits Operating system (Windows or any other) no program can address (even virtually) more that 4gigs of memory. There's nothing you can do about it, it's just because of 2^32 inherent limitation. While many programs running together could virtually take advantage of more than 4gigs (2^32 + 2^32 ....) there's nothing you can do about the 32bits limitation for a single program/process. Knowing that Supreme commander was limited by the 32bits barrier, this would have made no sense to support 32bits OS. Now you still have one option which does not cost anything : switch to Linux 64bits which is free and absolutly supported by Uber provided you run the recommended distribution. So because Uber support a free 64bits OS means no one can blame Uber to not support Windows 32bits flavors.
That sounds like a more reasonable solution. I believe I can dual run linux from my current pc if I am not mistaken. Which linux distribution is the best one to use, ubuntu?
It's a bit more complicated than just "you can't allocate more than 4GB per OS / 2GB per process" in 32-bit Windows. First off, it's important to understand the memory architecture in x86-32 systems. There are two types of addressing - unpaged addressing and paged addressing. Unpaged addressing is as simple as having a pointer which maps directly into physical memory, i.e. a value of 00000000 is the first byte of RAM, and a value of 00000001 is the second byte of RAM. Paged addressing is much more complex, and involves a hierarchical structure of tables that point to blocks of memory. Paging allows for much more efficient use of RAM, and with supporting hardware can allow the OS to access much more physical memory from runtime code than unpaged addressing would allow for. In normal paged addressing, each address is split into three sections: a 10-bit page directory index, a 10-bit page table index, and a 12-bit page offset. This means we have 4KB pages (2^12 = 4096 bytes), and we can address (2^10) * (2^10) * (2^12) = 4GB of RAM. The CR3 register is used to point to the location of the page directory index, so that the CPU knows where to look when handling paged addressing. Now, if the processor supports Physical Address Extension (PAE), an additional level is added to the hierarchy, called the page-directory pointer table, and the 32-bit entries within each table are replaced with 64-bit entries. Now each 32-bit paged address is split into a 2-bit page-directory pointer table index, a 9-bit page directory index, a 9-bit page table index, and a 12-bit page offset. The 64-bit entries are actually split into 12 flag bits and 52 address bits, so the maximum addressable memory becomes 2^52 bytes, i.e. 4069TB, or 4PB. Currently, existing implementations of PAE allow 48 of these 52 address bits to be translated, such that a 32-bit operating system with full PAE support, on a 32-bit system with full PAE support, can address up to 256TB of RAM. That's nothing compared to the massive 16 exabytes (16,384 petabytes, or 16.7 million terabytes) of RAM that a proper 64-bit processor can access, but for practical purposes that's still a pretty huge address space. Now, here's where things get tricky. There is another abstraction on top of paged addressing, called virtual addressing. Virtual addressing is a way of providing memory segmentation to different components of the operating system, such as processes. Additionally, it provides a way to map different types of physical memory (e.g. RAM, NIC buffers, VRAM, disk buffers, etc.) into a process, whether it be user-mode or kernel-mode. Virtual memory is how an operating system passes data to hardware. In Windows, and indeed most operating systems, there's a concept of "mapping" memory. You map a physical memory source, paged or unpaged, into a process, and that gives the process access to that physical memory. There is a limit to how much memory can be mapped into a process at any one time, but that limit is not fixed. By default in 32-bit Windows, without PAE, the limit is 2GB. There is an additional boot option called /3GB, which allows user-mode processes to use up to 3GB at any point, though the cost is that the kernel can only use up to 1GB of RAM in non-PAE systems. It returns to 2GB when enough RAM is available and PAE is enabled. Now there are two tricks that can be employed here. The first is mapped section cycling, whereby memory allocations are made and then unmapped from the process, such that more memory than 2GB (or 3GB) is allocated but less than that is actually mapped into virtual address space at once. The second is Address Window Extensions (AWE), which allows unpaged memory to be allocated and mapped in sizes much exceeding the normal limit. So, in a situation where: * A 32-bit OS is used * More than 4GB of RAM is installed * PAE is supported by the system * PAE is supported by the operating system, and enabled * AWE is supported by the operating system * The process is AWE and PAE aware It is actually possible for the process to allocate a very large amount of RAM, comparable to a 64-bit process on a 64-bit machine.
Yes but this sort of **** only exists on windows and i daren't imagine the issues you can run into. Definitly this does not makes sense, switching to 64bits in the only viable option.
Yes you can dual boot. Current version have game breaking bug for Steam version of game, at least for non-advanced user. But sometimes later you might try Ubuntu 13.04 or Kubuntu 13.04 depend on interface you prefer.
This game currently in active development, it's mean sometimes later in future 32-bit version might be more usable. Probably this will happen in next update or you'll need to wait month to run it. Obviously developers will try to make everything possible to make game available for 32bit OS users, but right now it's just not priority at all. But I'm not developer, so I'm really think you need to upgrade to 64-bit if you want to play game right now. Or wait for updates, it's your choice. Video memory cannot be used as RAM. You probably need to learn what virtual memory is, it's not something you think. There is no workaround for 32bit OS users, on 32-bit Windows 7 process might only use 2GB of RAM. Not a byte more.
You make great post really, but... This game only have 32-bit version on Windows and there is no PAE support built in.
I found a PAE patch online for windows 7 and my computer is now reporting the full 4GB of ram within windows and is currently using more than the previous 3.25gb limit. I will keep everyone informed if this is working properly. Will be testing this out - video drivers are now up to date as well. Info on PAE windows 7 32bit kernel patch at http://www.furulevi.go.ro/enable_more_than_3GB_RAM_on_32-bit_windows_7_(PatchPae).htm
OK - this is strange I was able to play 3 solid 2v2 games today without any issues then its all random crashes, does not always crash , my guess it has to be depending on the # of planets (usually 2 is fine) and size etc, other than that here are my findings - Game crashes as soon as it gets to like 1.78gb of ram use on the system, i guess there is NO circumventing this issue. I will try to mess with the virtual ram to see if that makes any difference.
As you said, didn't do anything, oddly enough its a random problem b/c in some instances I can play the game... idk what to say.. i guess i am f'd for now.
PAE is literally a flag inside the executable's PE header. I can enable support for it with a hex editor, or a tool such as CFF Explorer. Once I've done that, the OS will allow the process to be loaded into high memory (i.e. virtual addresses over 0x80000000) which is useful when 4GB or more memory is available. PAE has little to do with extended per-process memory - as I said before, it's related to x86 paged memory management, which is not an operating system construct. PAE lets you address more physical memory at the kernel level, which can also be utilised to enable large non-contiguous allocations in user-mode. If you want to use more than 2GB of RAM in each process, you either need to have PAE + 4GT to get 3GB per process (pain in the ***, plus not that useful) or you need to have an AWE aware process, which will give each process (theoretically) no limit, but requires the developer to take certain steps. Yet another alternative is to use the NUMA memory management API to allocate larger chunks to nonpaged pools, but most systems don't support that. At the moment NUMA is mainly implemented on servers, but pretty much any latest-gen Xeon will handle it.
PAE is enabled by default since Windows XP SP3 and Vista on supporting systems, and pretty much every processor since the P4 has solid PAE support. AWE support is a little bit less common, but on any modern-ish system it shouldn't be a problem. PAE support at the process level is as simple as setting a compiler flag, or setting the Large Address Aware flag in the PE header of the executable manually. AWE support requires the developers to do some additional work, but that's the only real effort involved. Keep in mind that I wouldn't have suggested it unless I thought it was feasible. It requires a bit of thought, but it's relatively simple to make a process use AWE to allocate large heaps and manually manage them.
