Enable Large Address Aware (for 64-bit systems with >3GBs of RAM)

A. What is this?
For those not in the know, Large Address Aware is an executable flag that tells Windows that a program can handle more than 2GBs of memory. Why this flag exists and is needed is something that would take a lot of time and effort to explain, so instead I will direct you to this link (but you don't need to know this stuff to use it).


B. Why would I want to use it?
This is actually very simple. If you don't enable this flag, the game can never address more than 2GBs of memory. TOTAL memory, as in video + system memory (which are two separate things, if you don't know). As you might imagine, you can hit this ceiling in very short order, which is good enough reason on its own to enable it. If you hit the ceiling, you will start seeing bugged out reflection textures and general weirdness. Without the flag enabled, the game will reliably crash when alt-tabbing in fullscreen mode.

Enabling the flag prevents all of these issues from occurring. Note, however, that this only works if your PC has at least 3GBs of RAM (preferably more, because there's plenty of stuff in the background that will hog RAM) and is on a 64-bit Windows (if you don't know whether or not yours is, go to Control Panel -> System and Security -> System, or just Control Panel -> System if you have icons enabled). 32-bit users can enable it and see some benefit, but must first use a command to change the user virtual address space, detailed here.


C. Isn't this against the Terms of Service?
Yes, but like the English patch, it is very unlikely that you will ever get banned for it (actually, even less likely because it's not the sort of thing that shows up in screenshots, and it doesn't actually touch any data - it's just a compiler flag). To be honest, this is something that SEGA should have enabled in the first place, as there's no good reason not to. It's 2012, after all.


D. Okay, so how do I enable it?

Step One: Download Explorer Suite and install it.

Step Two: Open CFF Explorer. On the start menu, it will be under "Explorer Suite".

Step Three: Click on File -> Open, and direct the program to your PSO2.exe, which will be in ..\Phantasy Star Online 2\pso2_bin\.

Step Four: Click on the "+" by "NT Headers" if it's not already expanded, then click on "File Header".

Step Five: Don't be intimidated by the table; click on the cell under "Meaning" and across from "Characteristics" that says "Click here".

Step Six: Ignore everything but the checkbox that says "App can handle >2gb address space". Click on it so that it is checked.

Step Seven: Click "OK". If you're paranoid, now would be a good time to backup your pso2.exe file. (This is not necessary, however, as the game will simply overwrite the file every time it updates).

Step Eight: Save, saying "yes" to the text box that pops up asking if you would like to overwrite the file.

Step Nine: ???

Step Ten: PROFIT!

Important: You MUST open the game using the .bat/shortcut method to bypass the official launcher, or else use PSO2 Tweaker to get around it. The game will overwrite the .exe file otherwise.

.bat method is as follows:

Quote:

---

Open Notepad and paste the following(no double spacing)

Code:

---

-cd "C:\Phantasy Star Online 2\pso2_bin"
SET -pso2=+0x01e3f1e9
start pso2.exe +0x33aca2b9 -pso2

---

Make sure that the first line matches your PSO directory exactly. So if its in all capital letters like mine is, make sure the line reflects that. Next, save the text file as a.bat file. Then run it with admin previledges.

---

You don't actually need that first line if you put the .bat file in the same directory as the executable, btw.

Shortcut method is simply to edit the "target" line of your PSO2 shortcut like so:

Quote:

---

"C:\Phantasy Star Online 2\pso2_bin\pso2.exe" +0x33aca2b9

---

Obviously, edit the file path to wherever your PSO2 installation is located.

Addendum: Note that you will have to repeat this process every time game goes through an update (just like the English patch, but unlike the English patch it will work every time without fail).


Let me know if this works for you. :-)

Thanks, i have Win7 i7 quad, 8gb ram so hope this helps

edit: after the change my antivirus thought pso2.exe was suspicious but it's not so just added to exclusions

whoa, i've noticed a huge difference. everything is smoother in cross bursts. nice find

Of course, the reason why this flag isn't set may simply because the game can't handle pointers where the most significant bit is set.
Also to let you know, this setting would have no effect on the video memory, it just means that the application can use more of it's address space on 32 bit systems with the boot settings (not playing with the registry) to decrease the kernel memory size, or on 64 bit where the kernel isn't part of the WoW64 process' 32 bit address space.

There are three things to note while doing this, important things.

If the executable is checksummed in any way shape or form, this will change it since you are modifying the executable's header.
Second, given the process' working set and commit sizes, the game itself doesn't use anywhere near enough to warrent this.
Third, and most important, this is doing unexpected things to the game. The game is written so that it will only expect 31 bits of the pointers to be relevent. By enabling this flag, then the Windows memory manager will start passing it pointers where 32 bits of the pointer is relevent. There has been pleanty of code in the past that has used the most significant bit of a pointer for some form of flag or packed pointers to save space dumping this bit or even weirder tricks. If the game does anything like this you will cause crashes. So this may cause the game to start crashing more.

So be very careful with this. It may not even help considering the game doesn't use up half of it's address space anyway.

Fortunately, the game doesn't use the most significant bit for anything important. I have been playing the game with the flag set for about a week now with no notable side-effects, and in fact have seen considerably fewer problems. (Really, it would be incredibly foolhardy of me to make a guide for this without some extensive testing beforehand, wouldn't it, now?)

Your information conflicts with my own, particularly with regards to how much space the game takes up, as before I set the flag I would see a considerable (and very annoying) number of errors that are quite asymptomatic of running out of address space. As mentioned, I saw textures with "ERROR" pasted all over them, outright missing textures and models, and the game would inevitably crash if I kept trying to play.

I'm afraid my knowledge isn't advanced enough to know how the game addresses video memory, but it's pretty clear to me that setting the flag has improved things in that regard tremendously. It may simply be because I run the game with Ambient Occlusion and 2xSGSSAA (which balloons the video memory usage massively), but regardless of the causes, the fact is that it has done me a lot of good setting the flag.

Edit: I have found a post explaining how video memory relates to address space. As it turns out, the reason I was having so many issues previously is because the game, as it uses DX9, was duplicating my video card's memory into system RAM... so when even 500 MBs of video memory was being used, I only had 1GB of system memory address space actually available, hence the glitches and other annoyances. Enabling the LAA flag mitigated this situation.

Quote:

---

Originally Posted by Zyrusticae

Fortunately, the game doesn't use the most significant bit for anything important. I have been playing the game with the flag set for about a week now with no notable side-effects, and in fact have seen considerably fewer problems. (Really, it would be incredibly foolhardy of me to make a guide for this without some extensive testing beforehand, wouldn't it, now?)

Your information conflicts with my own, particularly with regards to how much space the game takes up, as before I set the flag I would see a considerable (and very annoying) number of errors that are quite asymptomatic of running out of address space. As mentioned, I saw textures with "ERROR" pasted all over them, outright missing textures and models, and the game would inevitably crash if I kept trying to play.

I'm afraid my knowledge isn't advanced enough to know how the game addresses video memory, but it's pretty clear to me that setting the flag has improved things in that regard tremendously. It may simply be because I run the game with Ambient Occlusion and 2xSGSSAA (which balloons the video memory usage massively), but regardless of the causes, the fact is that it has done me a lot of good setting the flag.

---

Unless you really were getting errors literally saying Error, out of memory, then no, it is hard to draw that conclusion.

Unless you really went and mapped the address space of the application and checked to see if it was really running out of memory, there are all sorts of developer tools that allows you to do that after all.

As for video memory, that is addressed in the kernel portion of the process address space if it is memory mapped, and in 64 bit versions of Windows, that is outside of the WoW64 address space. (The kernel address space is in the upper half of the process address space, ie the msb of a pointer is set to 1,) which is why 32 bit processes are originally limited to the first 2GB (the kernel is in the other half). On 64 bit system, the 32 bit processes are actually 64 bit processes fitted out in a certain way. So the kernel is in the upper portion of the 64 bit address space (again the portion with the msb of the pointer set to 1, but there is the interesting cavet with this being limited in size.)

As for memory usage. Task manager always reports less than 1GB of working set. The amount in the page file doesn't get over this either. This is with everything set on and to the highest in the video settings and with my graphics drivers too. I'm in the process of attempting to map the process address space, but that is always fun.

And edit for the edit:

No, mirroring in system RAM != in the game's virtual address space. The two are quite distinct. That article also applies to 32 bit systems, since 64 bit drivers handle the linked situations without problems.

Oh, and just for fun edit 2:

It is actually possible for a process to use more than the amount of RAM in the system. Also, remember, that all 32 bit processes get a 4GB address space, all 64 bit processes get the very large address space with only 16TB usable total (8TB for user, 8TB for kernel).

I would be very interested to see the results of that.

As it is, the flag has fixed those aforementioned issues for me, and I'm not exactly going to argue against results, heh. Every time I run the game after a patch and forget to set the flag I notice it pretty quickly since the errors crop up again after short periods of play (it eventually got to the point where I couldn't play for more than an hour without textures starting to disappear outright).


Edit:

Quote:

---

Originally Posted by Ana-Chan

As for video memory, that is addressed in the kernel portion of the process address space if it is memory mapped, and in 64 bit versions of Windows, that is outside of the WoW64 address space. (The kernel address space is in the upper half of the process address space, ie the msb of a pointer is set to 1,) which is why 32 bit processes are originally limited to the first 2GB (the kernel is in the other half). On 64 bit system, the 32 bit processes are actually 64 bit processes fitted out in a certain way. So the kernel is in the upper portion of the 64 bit address space (again the portion with the msb of the pointer set to 1, but there is the interesting cavet with this being limited in size.)

---

This is a bit above my head, but how does this relate with regards to how much total memory the program can address? Does VRAM relate to that at all? That is to say, can a 32-bit program address, say, 1.5GBs of system memory and 1GB of VRAM on the side without the LAA flag? Because it seems to me that it doesn't really matter where the data resides, as the program still needs to address it somehow. I might be completely off on this, but it is consistent with my experiences in-game.

This whole thing is quite fascinating to me, so I'd appreciate further elaboration on this.

Oh, forgot to ask, what is your game resolution? I was going through what I knew of Direct3D9 and thought of a couple of things.
Also, have you tried reporting this to SEGA? If they either reduce their memory footprint or just enable that flag in the build of pso2.exe (which is really easy, one additional command line option to the linker) then that would solve your problem without you doing anything else, right?

My resolution is 1920x1080, though I run with Ambient Occlusion and 2xSGSSAA, as mentioned.

As for reporting it to SEGA, well... besides my Japanese simply not being that good, I'm also kind of afraid of being banned for playing from a foreign IP address. ^^;

what the fuck are you 2 on about.

nah just kidding, so in the end is it good or bad D: explain in simple terms. i havent noticed any problems so far...

So, I've been getting a couple of graphic errors, even on level 3 settings which supposedly my computer should handle perfectly (6GB of ram, GeForce 9800 GT). In fact the information SEGA released for the graphic test said that I should be playing this with graphic level 4, but when I do that the game crashes very often.

The errors involve "spikes" in textures, some textures showing glitches (like the screen showing "squares" blinking in and out the background), and even not slowing down ever, sometimes it crashes suddenly.

Would this help?