Yes - it dropped my crashing from 100% of the time to 30% of the time.

Very easy to do .. back up your exe file so you can put it back for the next offical patch.

I have longhorn 64bit 2gig ram ... same thing .. it is worth doing this patch !

MadBoris rocks !

Thanks for this MadBoris. Works a treat on my Core 2 Duo 6400 Vista x64 home premium machine with 2 gees of RAM. Kept crashing before (don't even know why as I kept getting "unable to create the error report" (probably a permission thing)). Now I've just played for four hours on an 80x80 map with six players. It rocks!!!

This fix does NOT work. It simply "delays" the crash.
Tried it myself, vista, yes i did everything properly.
I had a savegame where it always crashed after about 10 minutes, with this trick it crashed after 30 min, then again, and again.

You are completely wrong. And it is not a fix, although a mod labeled my topic that way. It's a memory management alteration which does exactly what is necessary to solve the application space limit.

Since people are crashing for a hundred different reasons, maybe it is possible you are crashing due to some other reason. Besides 3220 has a new memory allocation bug, maybe that is your issue. This isn't some kind of anti-crash potion.

This absolutely and unequivocally works in doing what I stated in the initial topic. I haven't hit 2.9 GB, but if I ever did it would crash then too but I don't think anyone will hit that.

Thanks to MadBoris I can also play SupCom now. I think Baleur is too negative, I have this shitty computer and it really can run SupCom with 500 own units and about 350 enemy units on screen.

Just for the record, when I modded my exe, game crashed every time I tried to load a game that was saved before the modding (I mean my own saves during the battle), if your save don't load, just start the mission from the beginning.

Just to be clear although the timing of that issue took place after you added the "large address aware" header. It should have completely no bearing on game saves or compatibility of anykind online or offline. It's only a header change, nothing more, telling the application it is allowed to use more memory. Just wanted to clarify because some may get scared that this does something it doesn't. Glad it helped you.

I really hope GPG adds this officially soon because anyone that hits about 1.5 GB in SupCom will crash. Heck, they can even use my method before they package it in a patch, I mean it's hardly difficult and I know of not one single technical reason not to prevent alot of unneccessary crashing on large maps with AI.

According to
http://support.microsoft.com/kb/888732



needs to be added to your boot.ini if you are running windows XP x64 to access memory addresses above 2GB (increases to Maximum of 4GB for 32 bit applications)

EDIT:
According to
http://support.microsoft.com/kb/294418

it quite specificaly states you dont have to add this option

I'll handle this in two parts...

First off, you mention a "boot.ini" option, yet I see no mention of a "boot.ini" option, nor am I familiar with any boot.ini option like that. Please correct me if I am mistaken.

I'm very familiar with this quoted part of the graph:
X64 addressable space per process - "2 GB (4 GB if the /LARGEADDRESSAWARE option is used)"

The issue is still an x86 compiled executable (not x64), which does not have the Large_Address_Aware bit set in the executable itself. The /LARGEADDRESSAWARE option mentioned above is a linker flag used by visual studio developers. Anyway, this is what I have been saying all along, no boot.ini modification is needed for x64 just a /LARGEADDRESSAWARE option added to the exe which is what my batch does.



Part2:
A quote from the article that you link:


That is very very clear so I am not sure where your confusion is coming in, although I know not many people understand all this too well, which is why I try and keep things simple in the readme.txt and in supplying a batch file. This is what I have been saying all along. For x64 no boot.ini switches are necessary just an executable that has the Large_Address_Aware (/LARGEADDRESSAWARE linker flag bit in x64) header added in it, which is what my batch does.

My batch file allows the executable to utilize more than 2Gb of user-mode virtual address space in x86 and x64 (no other modification necessary in x64), x86 will require a boot.ini (or bcdedit for Vista) modification.

It's all very simple to do in the readme or initial topic info for Vista, the explanation and people getting it, seems to be the complicated part.

I can easily explain where my confusion came from, when i first read the first link i found this:


note this data was in a table so i reformeted it to be easyer to read on the forum.

seeing as I dont have either the NTLoader or all the win32 executable compilation options commited to memory and an option that should be amended to the bootloader's options states moments before the /LARGEADDRESSAWARE option is mentioned I presumed the 'option' was still refering to a boot time kernel option.

Not long later I read information in the second link I posted which cleared things up for me, and indeed does specificaly state you do not have to add this (or any) option:


You seem to beleive im am still confused at this point, although I thought my edit to my previous post pointed out that I was indeed aware.

Please take comfort however that looking into your patch has taught me about win32 OS and apps manages its addressable memory space.

I was most shocked to learn that the kernel is given 1GB of addressable memory - an entire quarter! does it really need this much, isnt this playing it more than safe - or is their code really that mad!

I posted this because (unless i missed it) I couldnt find anywhere that mentioned windows XP x64 specificaly, I beleive you mainly used the phrase 'windows XP and Vista (32 bit only)'

Anyway thanks for working this out, your knowledge in win32 executable compile flags and win32 memory allocation has doubled the possible duration of my games! Hurrah!

I guess your original intent wasn't clear to me, seemed to me you were another individual trying to debunk the need for the large_address_aware flag (others have come before ). I thought that is what you meant by the option isn't needed, option being, the header.

Anyway, I far from know it all, I know certain things pretty well, a lot not at all , but am always open to learning more.


In a strange twist, it's funny that right before I did read your post, I actually did add a x64 section to my main topic, I was prompted by some discussion from the hardocp forums, then seeing your post I thought you didn't like the x64 update. Anyway, misunderstanding no problem, I'm glad we are all learning, in the near future with Vista and more prominence on x64 and higher RAM in our boxes, we can pressure more devs to include these headers.

I have Vista 64-bit Ultimate edition and was crashing on the big maps (sometimes little ones) during skirmish and this modification completely fixed it. My problems before were crashing 10 or 15 minutes into a skirmish game which would dump me back to the desktop while Vista tried to figure what was going on.

Pretty lucky too, I was just about to return the game that day for a refund. I was able to finish off some saved games and finally see a skirmish game through.

Thanks MadBoris, maybe you should work with GPGames until they get their act together.

Very intresting. Damn sure this was my issue a weekend ago when playing with a friend. It was nearly guarrentied that we crashed 60-75min into a 2vs2 game unless we reallly annihilated the enemy.

Now in this case can we set the 2900 any higher? Curious for at least my case if I can ramp it up to say 3400 just for the heck of it. While im sure I can't use that much memory for 1 app at least 32-bit, still gives me the edge to do so just incase.

Unfortunately 3GB will be the hard limit for XP or Vista x86, so there is just under a couple hundred MB more available beyond 2900. Not really sure what happens if you actually set it above what it is allowed to use - 3072, but nothing good I'm sure.

Suprisingly to me, there have been quite a few reports of people being helped by this in relatively quick crashes (<10 minutes rather than just >45 minute mark or huge maps). I am not sure how or why, but there have been enough user reports to prove that somehow this helps other scenarios where I initially thought this would only help games with the largest maps and lots of AI. Maybe it has to do with the additional memory addresses available to some threads/processes, but glad it helped.

But for 64-bit Vista does this have an effect? Guess I'm not totally following what was being said.

Yes it helps since even if you're on Vista x86-64bits, the .exe file is a 32bits compiled exe, not a 64bits one. Mad Borris, correct me if i'm wrong

For 64 bit you just need to add the Large_Address_Aware header to the executable, no other boot modification necessary. So the /userva boot option is irrelevant for x64. I didn't notice you were on x64. Their is an x64 section on my initial post in this thread.

Ya I saw that but guess I didn't get it exactly since I didn't download the file. Makes sense now though.

Apparently after 5 weeks of this fix floating around here GPG has finally made an official comment on the Large_Address_Aware header:



It only took 5 weeks but I am suprised because it's not the answer I expected. But I felt like it was my responsiblity to post this information here since no one else has. So much for the forward thinking of no hard limits, no hard limits except 1.5GB memory.

All I can say is I have never had any issues with this and I am sure many of you that have been happy to stop crashing have never had issues either.

I'm only upset by this turn of events because it took 5 weeks of this fix floating around for an official response to show up in some fairly unrelated thread and how it ignored all the positive results. Although, their are many other threads beyond this one which proves this has worked for many without negative impact, as this was their only cause of crashing and now they are crash free.

To GPG:
I now would like to know what GPG's official stance is on their plans of fixing these memory limit crashes. And please don't tell me it is the forward thinking of removing 80k maps and making a unit count hard limit. How is it you ship a game knowing full well it will crash when hitting 1.5GB (actually the 2GB user mode app space) without any official comment or response to the problem which so many have suffered (many continue to suffer right now not even knowing it) only to say that the current work around shown here, that has worked flawlessly for others with many positive test cases beyond the confines of this thread, is not recommended. Hopefully it won't take 5 weeks to get an official response on how GPG plans to resolve this open sore.

Edit: Sorry for the intensity but it almost seems like certain people that should be in the know in GPG have not been aware of this obvious issue that has been 'clearly' exposed and delineated for many weeks and yet no positive response on plans to resolve it. I mean a solution of surpassing 1.5GB (for now and the future) instead of a minimalistic solution like coding the engine to not surpass 1.5GB usage.

I've now played quite a few games of varying settings (skirmish only, not ready for multiplayer) with Boris' fix and have not had any problems or unexpected behavior.

If GPG is recommending I should go back to before this fix, they are out of their minds.

The quote was taken a bit out of context. We have not tested the game with this flag set, and in our research we found there was the potential for subtle overflow conditions to occur, and we don't feel it's worth the risk.

The official stance is we're addressing memory consumption issues. The "big patch" we keep talking about contains a lot of these, and we've managed to reduce the memory footprint by about 25-50% (depending on the condition.) We're also looking at the reason behind the crash as well, as our code is designed to fail gracefully in out of memory conditions. It appears the memory management library we're using is not doing quite so well, and we're looking at how it can be fixed.

As to "releasing the game knowing it crashed" we didn't, in our testing the game appeared stable even when it hit memory limits. There was no conspiracy, these issues really didn't rear their heads until the game was out in the wild, and now we're doing our best to fix them. I think you'll see a lot of improvement in the next patch, and we'll continue to work on making SupCom more stable and fault tolerant.

Hi, and thanks for the response. I too am having a crashing issue in Skirmish with large 40x40 & 80x80 maps with A.I.. I've pretty much been relegated to playing smaller maps, without issue.

My question is, is there anyway I can send information about my PC configuration directly to GPG to help them with this problem?

The problem is a user-mode virtual application limit of 2GB! There is nothing to try and figure out, the "reason behind the crash" has been clearly delineated, explained, referenced with links and even pics provided. It has been successfully worked around with the Large_Address_Aware flag to circumvent the obvious cause and crash. A developer should know about that obvious issue, basic tools can be used to monitor the memory issue which I used in a matter of 15 minutes to verify the problem in my first large map, large AI saved game. I would have known that before it left the door. Even a month old thread dedicated to the issue apparently hasn't helped some to figure out the cause regardless how many times it is repeated, so good luck. I wouldn't be surprised if the memory allocation issue they mentioned on the 3220 patch notes is this same exact issue, as many others have speculated. There is even another crash this helps with, but they can figure that out.

The Large_Address_Aware header works fine for us that have had no other crashes. Of course their are potential issues, but the difference between definite crash and a subtil potential issue is worth it. When someone uses this and is 100% crash free, it is very hard to convince them not to use it. GPG just hasn't tested it, so how 'could' they know unless they actually read all the successful test cases in this thread and many others or actually devoted any time to testing it. That is understandable. They have so many crashes and performance issues to currently focus on that these large skirmish issues aren't in there priority, they don't have time to test this, lots of their recent focus is online issues and optimizing (including memory). Even I would do 'MEM_TOP_DOWN' (/NOLOWMEM) testing for them along with VirtualAlloc in the highest addresses to find their 2GB assumptions in their code but apparently they aren't looking into solving this crash that way. They will likely induce a limit some other way until they possibly deem this worth looking into for future products or x64 support. In the meanwhile the largest maps with largest unit counts will likely be taboo for the foreseeable future.

There memory management will go a long way to helping this issue but the 2GB virtual address ceiling, that they have limited the game to, will not go away. Now I can't help but wonder what was nerfed to get 25 - 50 percent lesser memory footprint, their is already excessive disk skating for assets when zooming, so time will soon tell. Unless the AI changes quite a bit in the future there won't be much lasting desire for 40k or 80k maps anyway, so a very potentially entertaining part of the game is kind of cut-off from lasting appeal or stable playibility for the foreseeable future. Unfortunately it's one of my most desired play styles.

A problem with providing a work around, like I did here, is people stop complaining about the problem because they are working fine. Devs then don't hear about the complaints via some 15-page outcry bumped to the front page all the time. So the problem isn't as pronounced to them since the complaints aren't constantly high, regardless of how repeatable it is. If people aren't complaining they must be happy. Furthermore, it doesn't effect the majority of the online community (outspoken public) so people just crash often in silence on their own single player skirmish games (with no GPG crash report possible).

I can understand the fear of introducing a new crash, it's been done many times in patches before so GPG is understandably gun shy. They should be with all the issues people currently have, we don't need new ones. I thought providing a public work around for a crash was a much better benefit for the end users, while at the same time documenting extensive proof of test cases for GPG. I thought that was the better route to take rather than engender public pressure to wave the banner of "fix this crash". If I had I to do it over, I might actually choose a different course if that is the one that actually works better. Although the proof does speak for itself pretty clearly in this thread.

Hi MadBoris,

I have tried using your method with version 3220 & 3223 of SupCom and it hasn't worked for me at all. SupCom's memory usage does break the 2GB barrier with your method, but I still have a gracefull crashing to desktop situation with the exact same frequency I did before.

My system has passed 24 hours of MemTest & Prime95, as well as a 3DMark06 marathon. I know that it's stable, because no other applications or games exhibit this behavior.

But, alas your method has not fixed my crashing problem.

Thoughts???

My specs...
Gigabyte GA-965P DS3 rev1, bios F9
Intel Core 2 Duo E6600 (stock)
4x1GB DDR2 667 (stock)
Nvidia 8800GTS 640MB (stock, 100.65 drivers)
Creative Labs X-Fi XtremeMusic (latest WHQL drivers)
WD 500GB SATA HDD, 2 x Maxtor 250GB SATA HDD
MS Windows Vista Ultimate x86 32-bit

If you have followed all the details and verified all your settings then your issue is something different. There are alot of possible reasons and varied crashes, I suggest starting your own thread to hopefully get some focused help on it.

BTW, SupCom's memory usage actually is about 1.5GB private bytes (what is visible in task manager) when this particular crash comes up that this thread focus's on. May be less depending on number of other running programs.