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

[Zyrusticae]

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 (http://en.wikipedia.org/wiki/Memory_address) (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 (http://msdn.microsoft.com/en-us/library/windows/desktop/bb613473(v=vs.85).aspx).


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. (http://www.ntcore.com/exsuite.php)

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:


Open Notepad and paste the following(no double spacing)

-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:

"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. :-)

[Silver Crow]

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

[Ana-Chan]

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.

[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.

Edit: I have found a post (http://www.techpowerup.com/forums/showpost.php?p=1323113&postcount=1) 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.

[Ana-Chan]

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).

[Zyrusticae]

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:


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.

[Ana-Chan]

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?

[Zyrusticae]

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. ^^;

[Silver Crow]

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...

[Darki]

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?

[Ana-Chan]

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. ^^;

Don't worry about that. I've reported a couple of things as well as a few cheaters and I'm still playing.

But yes, since it uses the D3DX9 library, and with that kind of resolution, I really can understand memory issues. I was guilty of the "works for me" mindset there briefly without thinking of the people who use really high resolutions. *sigh* I should be ashamed of myself for that.

[Darki]

On the resolution issue, btw, I play with 1680x1050. Currently I play with a bit less to use window mode, though.

[Ana-Chan]

Well, given your physical RAM, I'm assuming you are using x64 versions of Windows. Could you check the PSO2 working set in Task Manager?

You may actually be running into similar issues.

[Darki]

Hum, the problem is that I'm one of those whose GameGuard doesn't like the Task manager in any form or flavor, I can't bring it up in any way and if I open it before the game, it crashes.

But this change is pretty simple, so I'm going to do it and go extreme and run the game at graphic setting 4 and 5, and see if I feel any improvement at least at level 4.

[Blackheart521]

Tried it and didn't really notice any differences as of yet, but haven't done any taxing things yet such as code destructions or PSE bursts, might just be because I only have 4GB of ram so it wouldn't add that much being able to go over 2. ^^;

[Ana-Chan]

As I should have already mentioned, physical RAM is not the same as process address space. What the Large Address Aware flag does is to allow processes to use more of their address space, up to a maximum of 3GB on 32 bit systems with the right boot options for Windows set (normaly this does nothing on 32 bit systems, you must explicitly enable it and run the risk of problems because of kernel mode using less) and around 3.5GB on 64 bit systems (it is impossible for 64 bit systems to get all of the 4GB address space for a few reasons).

The only way you would see any difference with this set is if the game is running out of memory. Enabling this flag isn't a performance panacea or anything like that since the memory manager still allocates memory at the same speed if 2GB is available or 4. The memory manager also normally favours locations lower in the address range too. As I also said, even with 4GB of RAM, you are able to run and allocate lots more in a 64 bit process, much more than the amount of physical RAM you have. The defaults for Windows x64 is that the user portion of a 64 bit process has 8TB of address space (yes 8 Terra Bytes). The only thing that restricts the amount you can allocate in that is your page file (which defaults by using a multiple of RAM size, but can be set totally different) and hard disk space. The only thing that RAM has to do with this is that code and data must be in physical RAM to be worked on by the processor.

[Darki]

Well, I've been testing it for a while now, and I can't really say I've found a great improvement, not to say that I didn't notice imnprovement at all, but well.

After enabling the LAA I did as I said, tried the game in graphic level 5 at fullscreen and window mode, then at graphic level 4 with both settings, but the errors are still here, and I ended going back to graphics 3 window mode. Even like this, I get those texture errors sometimes.

I didn't make any sort of record of the crashes, but I can say the game "feels" a bit more stable anyways. I've been up to like 4 crashes an hour on hard graphic times, like in a multiparty City run, now it might have crashed once somedays.

I guess I'll be patient and lay low on graphics till christmas that I'll try to revamp my machine a bit.

[Aeris]

Offtopic: Seems like a overclocked/dieing/overheating graphics card issue to me or memory errors usually not enough vram to display everything even on higher settings.

If its overclocked, set it back to default settings since overclocking can cause it to give random issues in the game also turn off added settings in the nvidia control panel if you have any on.

Also is the graphics card free of dust, if not, then you need to open up your computer and clean it out and clean out the dust in the fan (if it has one) or heatsink free of dust if you can.

You shouldn't be crashing that often unless like its really dieing out or its a power issue from the power supply Darki, also do you have the latest drivers if so, donno if this helps but do a clean install if you can, might help with the crashing but better than nothing at all.

[MCF]

Hum, the problem is that I'm one of those whose GameGuard doesn't like the Task manager in any form or flavor, I can't bring it up in any way and if I open it before the game, it crashes.

But this change is pretty simple, so I'm going to do it and go extreme and run the game at graphic setting 4 and 5, and see if I feel any improvement at least at level 4.

and for other people that taskmanager don't work
use process explorer (same as taskmanager but more better)
http://technet.microsoft.com/en-us/sysinternals/bb896653

[Gama]

ill give this a try

asus n53jq

i7 44Q clarksfield 1.73ghz

4gb ddr3

nvidia 425gtm 1gb

and ill let you know if i see any performance boosts.

[Darki]

Offtopic: Seems like a overclocked/dieing/overheating graphics card issue to me or memory errors usually not enough vram to display everything even on higher settings.

If its overclocked, set it back to default settings since overclocking can cause it to give random issues in the game also turn off added settings in the nvidia control panel if you have any on.

Also is the graphics card free of dust, if not, then you need to open up your computer and clean it out and clean out the dust in the fan (if it has one) or heatsink free of dust if you can.

You shouldn't be crashing that often unless like its really dieing out or its a power issue from the power supply Darki, also do you have the latest drivers if so, donno if this helps but do a clean install if you can, might help with the crashing but better than nothing at all.

My card is not overclocked, and I cleaned it almost like new on the third week I started playing the game in hopes to fix the errors, it wasn't THAT dirty to begin with. Also, I should have the latest drivers, unless they updated them last month, but I definitely had the newest aviable ones when the game got out.

Personally I'd suspect that the motherboard and the GPU are not living off their best days. The motherboard has some issues (it doesn't recognize some components anymore, although the computer still works reasonably well), and there are games that show graphical issues that were going fine a year ago, for example, Prototype 1.

My problem is that the game doesn't show too visible indications of a crash. When I play in graphic settings 5, for example, it goes perfectly, not even slowdowns in hard fights with lots of explosions and lights, it just goes shit suddenly while you're playing a perfectly normal run. In graphics settings 3, it does the same, but not that often. The spikes are bothersome but don't seem to be the cause of those crashes.

The power source... well, never though it'd give much problems. Is there a way I could test that?

[Gama]

if its nvidia, avoid the 301 driver get the latest beta driver.

[Gama]

slight performance increase.

Edit:

sorry for double post :(

[IzzyData]

Pso2 has never exceeded 1gb of memory usage for me. I don't know how you guys can possibly have the need for more than 2gb but this wouldn't change a single thing on my system. I'm using the highest textures and all settings on max.

I do have 8gb of ram though. Haven't had any memory issues anywhere.

[Mystil]

Anyone who runs Skyrim surely has more than 2GB.. but yeah I have 4 and never hit this ceiling(but very often in Skyrim..)

[Ana-Chan]

Since I want to avoid a long, confusing and boring post. I'll put it simply, this thread isn't about physical memory. This is a thread about a process' virtual address space and virtual memory which is a very distinct thing. So having 8GB of physical RAM wouldn't have made any difference because PSO2 is still a 32 bit executable.

Also IzzyData, never exceeded 1GB of memory usage, or never exceeded 1GB of working set? There is a major difference between the two.

[IzzyData]

pso2 takes up about 1GB total physical memory. Whatever portion of that is currently being used is obviously going to be smaller than 1GB.

[Ana-Chan]

pso2 takes up about 1GB total physical memory. Whatever portion of that is currently being used is obviously going to be smaller than 1GB.

But as said, this thread isn't about physical memory. So what does it matter how much physical RAM it uses up. For me, PSO2 uses up 1.2GB of its virtual address space at 1440 x 900. At lower resolutions it uses up less. So graphics settings have an impact on how much of the virtual address space is used. So please, could you check the virtual address space usage, not the physical RAM usage?

[IzzyData]

Virtual addresses are going to map to the same exact amount of physical addresses regardless so I don't see what difference it is going to make.

You had 2gb of virtual address space because it is a 32 bit program. Whatever amount of those virtual addresses you use up is going to be mapped onto your physical memory where it needs to be to fit. If the process is reading that it is only using 1gb worth of physical memory addresses than it is also only using 1gb worth of its virtual memory addresses.

And because 1gb is not anywhere close to a 32 bit programs 2gb quota, this fix allowing it to use 3gb's is literally going to give zero performance changes.

Also, the resolution of the game isn't going to affect how much ram it uses. That will only affect how much resources your graphics card is going to use. The amount of files needed to be loaded into memory is the same.

Have fun with this though. I'm sure the placebo effect is working great.

[Ana-Chan]

Virtual addresses are going to map to the same exact amount of physical addresses regardless so I don't see what difference it is going to make.

You had 2gb of virtual address space because it is a 32 bit program. Whatever amount of those virtual addresses you use up is going to be mapped onto your physical memory where it needs to be to fit. If the process is reading that it is only using 1gb worth of physical memory addresses than it is also only using 1gb worth of its virtual memory addresses.

And because 1gb is not anywhere close to a 32 bit programs 2gb quota, this fix allowing it to use 3gb's is literally going to give zero performance changes.

Also, the resolution of the game isn't going to affect how much ram it uses. That will only affect how much resources your graphics card is going to use. The amount of files needed to be loaded into memory is the same.

Have fun with this though. I'm sure the placebo effect is working great.

But that's the big thing, virtual addresses don't have to map to physical RAM as I have mentioned. They can be unallocated or backed by a file.

I would suggest you try reading http://en.wikipedia.org/wiki/Protected_mode about what is happening. Seriously look at some of those dates, and realise that people were running into these address space issues on systems that had way less physical RAM than we do now. Also, look at http://msdn.microsoft.com/en-us/library/windows/desktop/aa366912(v=vs.85).aspx and all of the subsections which describes how the virtual address space works on Windows and also http://msdn.microsoft.com/en-us/library/windows/desktop/aa366556(v=vs.85).aspx to see how files can also be part of the virtual address space. There is also http://support.microsoft.com/kb/940105 that describes how Direct3D9 uses process address space, and how it is well known that the larger the resolution, the more memory it needs.

Yes, I understand that the concept of virtual addresses and how they may not correspond with a physical address is tough. But just because you can't explain it, doesn't mean that it is wrong.

[D-Inferno]

Regarding reporting the RAM limit thing to SEGA, couldn't we have someone on this forum who actually lives in Japan report this?

[IzzyData]

Yes, I understand that the concept of virtual addresses and how they may not correspond with a physical address is tough. But just because you can't explain it, doesn't mean that it is wrong.

Linking a bunch of semi related links and expecting it to be some kind of evidence to your point doesn't work. Reading through them all I see is some old issues on either vista or dx9 that aren't exactly this problem.

I find no evidence that the virtual address space for anything would be larger than the amount that is mapped to physical memory.

[Ana-Chan]

Then I wonder if you really read and understood what was written.

First of all, it is exactly that is described with the Microsoft KB link. PSO2 uses DirectX9, and so the kb link gives an explanation of what happens with DirectX9 and how DirectX10 fixes things. The fact that it is related to Vista has nothing to do with the DirectX9 problem. On XP, Vista and 7, DirectX9 still has to keep an in memory copy of the display resources which is around the same size as the video memory it uses, and as settings and resolutions increase, the required video memory increases and so does the process specific memory usage. The OP did specify the conditions that he was getting it after a bit of prodding, 1080 resolution and some forced on memory hungry settings.

Anyway, isn't the whole "I find no evidence" a subtle use of the burden of proof logic falacy? Basically you are subtly saying that for you (and likely anyone who reads this thread) to believe, someone should actually prove that it is possible for an application to use large portions of it's virtual address space but not use any RAM? If so, I also invite you to prove the converse.

[IzzyData]

This is the only instance I can find where there would be more virtual adresses used than physical ones. Although the difference would be insignificant for a few shared .dlls. Also this is only for windows programs. There probably wont be any shared memory between pso and anything else.


When multiple instances of the same Windows-based application are loaded, each instance is run in its own protected virtual address space. However, their instance handles (hInstance) typically have the same value. This value represents the base address of the application in its virtual address space. If each instance can be loaded into its default base address, it can map to and share the same physical pages with the other instances, using copy-on-write protection.http://www.tenouk.com/WinVirtualAddressSpace.html

You said you were using 1.2gb of virtual address space? I'd love to know what you are using to view that number.

[Ana-Chan]

This is the only instance I can find where there would be more virtual adresses used than physical ones. Although the difference would be insignificant for a few shared .dlls. Also this is only for windows programs. There probably wont be any shared memory between pso and anything else.

I gave you the other major one too, which you passed off as semi related. File mapping maps the contents of a file into the address space of a process. The only time that takes physical RAM is when you write to it, and that is a kernel mode cache that goes away after it flushes the data to disk (and the cache is only the size of the modified contets). For simply reading from the file, it uses nothing but the standard operating system file caches.

Since we don't know how SEGA has implemented the internals, they could be using this method for the data files.


You said you were using 1.2gb of virtual address space? I'd love to know what you are using to view that number.

Process explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653.aspx). You will need to show the virtual size column, but that is the amount of the virtual address space the process has used so far.

[IzzyData]

The difference between the working set and the number it gives for "Virtual size" is all unused memory. It might be allocated and ready to be used but it still wont go much higher than the working set which sits at around 1gb.

Also the only difference I'm seeing between the working set and the physical memory usage is shared memory which isn't very big.

I've been trying to find another program or game that exceeds 2gb virtual size but I don't think I have anything that gets within 500mb. I'm really curious as to what would happen.

Edit: So I found an interesting program. Microsofts sqlserver actually allocated NINE GIGABYTES of space to "virtual size". Here is their comment on it.


As we noted before, this behavior is expected. We reserve but do not commit the memory up front to minimize holes in our virtual address space. This should not affect actual memory usage by other applications.
http://connect.microsoft.com/SQLServer/feedback/details/377495/virtual-size-of-sqlsvr-exe-is-huge-on-a-fresh-start

Which in turn means that the virtual size hardly even matters. The only important factor is the working set. Which again, will never exceed 2gb. The virtual size isn't even going to exceed 2gb.

https://dl.dropbox.com/u/58437091/virtualsize.PNG

[Ana-Chan]

It really seems like you don't understand what the working set is. It is also cute how you class over 200MB as not much.

http://nyaanyaa.ath.cx/stuff/img/pe.png

[IzzyData]

I don't think you understand why this entire thread is a non issue.

[Ana-Chan]

If it was such a non issue, why did the OP have a problem?

You also understand all of the situations where an allocation can fail right? As in, the process doesn't have to have all of it's available address space completely used up.

Also, since you are claiming to not have an issue, or the entire thread is a non issue, you have the same graphic settings as the OP and are not seeing the issue right?

True, for most this is a non issue. Not everyone uses insane resolutions and insane settings. The average user would never need this, but it is always the edge cases that are the problem.

[IzzyData]

Nowhere in the OP did it say this solved an issue for him. Nowhere in this thread did anyone say it actually solved an error. People are just claiming they possibly see a performance increase. Which probably isn't true.

I am playing on 1920x1080 and max settings already so there isn't any way to exceed that amount of resource usage from this game.

Your point is moot. I don't know why you are defending this so hard. How does this benefit you?

[Ana-Chan]

I don't know why you are defending this so hard. How does this benefit you?

I'm not and it doesn't.

But I'm bowing out of this. Since you didn't even notice the misinformation that I used as a bit of a test. So it really does feel like you are just disupting this thread without fully understanding everything that goes on. You didn't even use all of the same settings that the OP mentioned, so it really seems as if you have something to prove for some reason.

I'm just in this for the science. The question is, why are you trying to dispute this thread when the OP clearly stated the circumstances that the problems occured under. Also, how does this benefit you?

[IzzyData]

Because I'm more interested in the truth than spreading useless misinformation that won't actually help people.

[Ana-Chan]

Because I'm more interested in the truth than spreading useless misinformation that won't actually help people.

Yet, when you are potentially faced with the truth, you dispute it if you don't understand it.

Also, does this actually help people? While you won't get the people feeling the placebo effect becasue they ignored everything written and enabled LAA without fully understanding what it does, this also turns away people who are potentially affected by this problem.

That is the same kind of attitude as those who disputed the existance of a problem in GG because they didn't get it, or those who disputed the existance of a problem between Avast and GG because they didn't get it. Problems can be system/configuration specific and it means little to deny the existance of a problem based on the behaviour on your own system. This is the mindset that I often class as the "works for me" mindset, where if something works for them then they assume that it has to work for everyone, it then excludes any investigation into areas that could be the problem (like looking into the extra settings that the OP mentioned and investigating the effect on video and system memory, or investigating the memory usage of the game and noticing the regular increase and decrease in the virtual space usage that does lead to issues if not handled correctly). There was no attempt at an investigation into the values on the OP's machine, instead, you based everything on your own. The people who usually have this "works for me" attitude are the ignorant/uneducated or egotistical.

So right now, the difference is that while there is no major evidence to the contrary then I don't see much need to really care about it or dispute it. The thread was dying a natural death anyway.

[Asuni]

Hm for me I cant save it as pso2.exe I have to rename it

[Ana-Chan]

Hm for me I cant save it as pso2.exe I have to rename it

If you are using Vista or 7, then it is most likely UAC stopping you. This is because you need administrative permission to write to Program Files and Program Files (x86) and one thing that UAC does is disables that.

The two choices you have here is to either run the program that you are using as administrator, this will then give it the rights that it needs to write to where PSO2 is installed, the other option is to save it somewhere outside of the PSO2 directory, where you can write to, and then copy it back into the PSO2 directory, overwriting the original pso2.exe. Explorer should automagically ask you if you really want to do that and get the rights it needs.

Oh, and don't think badly of UAC here.

[Chik'Tikka]

i would like to say i can no longer get this to work, i found out because I've been loading character models a little slower after last patch and found no matter how many time i enable this, when i launch the game, it get "fixed" by the updater+^_^+ for the naysayers, LAA did seem to help with minor texture errors i had on my particular machine+^_^+

[Natsuma]

It doesn't work for me either, pso2.exe gets automatically patched every time I start the launcher.

[Zyrusticae]

Yep, no longer functions thanks to the launcher change.

Don't know why they bothered, nobody cheats by modifying the .exe (too bloody obvious), but oh well...

[Zyrusticae]

Wow, it's really been almost four years since I posted this thread?

Anyway, this still works provided you use either the bat/shortcut method to bypass the launcher or use PSO2 tweaker instead. You can't use the official launcher with it.

It fixes that weird chrome texture bug and prevents the game from crashing when alt-tabbing in fullscreen mode. I strongly recommend it.

[nguuuquaaa]

The Alt+Tabbing problem doesn't happen anymore.
Seriously, thanks for creating and also bumping this up :D