(32-bit OS Users) Work Around for constant crashing after 5-30 minutes of play

You have to do it with administrator level.
You wont have access with a normal user account.

In the Start menu somewhere find the program "Command prompt". Right click it and select Run as administrator.
Then do A. If you dont have administrator access you have to boot the computer with the admin account.


Note:
Make sure you have at least 4gigs HARDWARE ram, that you have a 32 bit OS and its NOT Windows XP before doing this.
To check you just right click My Computer and select properties. A info screen should pop up telling you among other stuff how much memory ram you have and what bit OS you have.

I actually though they had fixed this issue with the game.
Then again I didnt bother swapping back because I like having my system this way now.

Dropping in to say, thank you for this fix. Altering the memory has made a complete difference. Now I can play longer than 10 minutes. I do however get the error when closing the application. But how that possibly matters is unknown to me. I could care less of that. I'm just happy to play as long as I like.

BTW: If anyone of the 32 bit Users got the Opportunity to upgrade cheap on a 64 bit OS i would go for it, 32 bit OS's are not as good as they were a few years ago.

OMG this really fix the crash,thx man.god bless you

Alright, im not a pro at computers trust me. Ive tried Typing the following into CMD while running it as administrator. "bcedit /set IncreaseUserVA 3072" And what it comes up with is "bcedit is not recognized as an internal or external command, operable program or batch file." Why is this coming up? Could anyone help i really want to enjoy PS2 and im not giving up!
Thanks for any feedback/help guys.
-Shotsye

Question for you

If that is the case - and under windows 7 x64bit PS2 is a 32-bit exe, has the following flag been used ??

"IMAGE_FILE_LARGE_ADDRESS_AWARE affect an x86 process running on a x64 OS (or a x86 OS with the /3GB directive). Your x64 application does not need to set the large address aware flag and it will be able to use all the available virtual memory on your system."

Bit of reading from technet http://blogs.technet.com/b/markrussinovich/archive/2009/07/08/3261309.aspx

Unless I mis-understood it - if the ps2 exe is missing the c+ (or c++?) code flag "IMAGE_FILE_LARGE_ADDRESS_AWARE" to make a 64bit OS aware that it can in fact use more user-mode virtual address space (if it needed to - with physical RAM and page file coudl use up to 12gig) - then this issue could also be affecting 64-bit OS's where the 32bit process is limited to the 2GB vitrual address space?

***********Warning - In coming Wall Of Technical Text*********************

32-bit Thread Limits

Even if the thread had no code or data and the entire address space could be used for stacks, a 32-bit process with the default 2GB address space could create at most 2,048 threads. Here’s the output of the Testlimit tool running on 32-bit Windows with the –t switch (create threads) confirming that limit:

Again, since part of the address space was already used by the code and initial heap, not all of the 2GB was available for thread stacks, thus the total threads created could not quite reach the theoretical limit of 2,048.
I linked the Testlimit executable with the large address space-aware option, meaning that if it’s presented with more than 2GB of address space (for example on 32-bit systems booted with the /3GB or /USERVA Boot.ini option or its equivalent BCD option on Vista and later increaseuserva), it will use it. 32-bit processes are given 4GB of address space when they run on 64-bit Windows, so how many threads can the 32-bit Testlimit create when run on 64-bit Windows? Based on what we’ve covered so far, the answer should be roughly 4096 (4GB divided by 1MB), but the number is actually significantly smaller. Here’s 32-bit Testlimit running on 64-bit Windows XP:

The reason for the discrepancy comes from the fact that when you run a 32-bit application on 64-bit Windows, it is actually a 64-bit process that executes 64-bit code on behalf of the 32-bit threads, and therefore there is a 64-bit thread stack and a 32-bit thread stack area reserved for each thread. The 64-bit stack has a reserve of 256K (except that on systems prior to Vista, the initial thread’s 64-bit stack is 1MB). Because every 32-bit thread begins its life in 64-bit mode and the stack space it uses when starting exceeds a page, you’ll typically see at least 16KB of the 64-bit stack committed. Here’s an example of a 32-bit thread’s 64-bit and 32-bit stacks (the one labeled “Wow64” is the 32-bit stack):

32-bit Testlimit was able to create 3,204 threads on 64-bit Windows, which given that each thread uses 1MB+256K of address space for stack (again, except the first on versions of Windows prior to Vista, which uses 1MB+1MB), is exactly what you’d expect. I got different results when I ran 32-bit Testlimit on 64-bit Windows 7, however:

The difference between the Windows XP result and the Windows 7 result is caused by the more random nature of address space layout introduced in Windows Vista, Address Space Load Randomization (ASLR), that leads to some fragmentation. Randomization of DLL loading, thread stack and heap placement, helps defend against malware code injection. As you can see from this VMMap output, there’s 357MB of address space still available, but the largest free block is only 128K in size, which is smaller than the 1MB required for a 32-bit stack.



Would that be correct?

Dev or anyone?

Advanced users could allow windows to give the process more memory

bump for thoughts?

Is there any known fix for these issues on Windows 7 64 bit?

My crashes are very random and happens in different situations. Sometimes during an assault on bases with all three factions
Involved, really massive battles to a small ghost capping scenario. The time between crashes vary a lot aswell it could be
Anything from 15 minutes to 180 minutes inbetween crashing.

I tend to crash more often when i got chrome webbrowser open with twitch on, and also frequently less when not running it.

This whole experience reminds me how HoN used to be. Crashing with ~55 minutes periods due to insufficient memory space.
That was on my old pc.

My new one carries an i5 running at 4.5ghz with 16gb ram together with a nvidia gtx 680.

And why do i have these crashes? I have no idea. I started playing just before Gu7 and the game ran flawless nothing to
Complain about at all. Then Gu7 and i started to experience fps drops and crashes, not to often nothing i couldent live with.
Now when Gu8 came something changed with how the game renders graphics and from snipers point of view. View distance got heavily affected.
Also with Gu8 fps drops increased madly and can Sometimes crash the game.

Please anyone help me out with this. I love the game id hate to stop playing it cause of game updates ?!
What might be causing this? I know you guys discusses 32bit here.. but the issue seems to be the same

Thanks in advance

Prove to do this:

This is the solution that fixed my issue. You have my infinite gratitude.