Oblivion with SI newly installed to Win7 64-bit won't start a new game or load an old one IF the Data folder is from my previous XP SP3 environment. It generates a 'Buffer Overflow' (BEX) error about 30% of the way into the "new game" or "Load game" loading screen sequence. The location is consistent.

Error Event:

I've been chasing this problem for a couple of weeks now, and with various reports from others of it running on an x64 without tweaks in the same environment, I'm wondering just what is off in my setup.

Couple of clarifications are needed.

1. This is really a migration from XP SP3 to Win7, and my machine is setup as dual boot. Everything still loads fine under XP. Never had a BEX there.

2. The game has always been installed on a different drive from the OS, so I simply renamed the old game folder first. I did a fresh install from retail CD on Win7, but then renamed the "new" folder to something else and renamed my old XP installation folder back to "Oblivion". With no DLCs nor Wrye Bash installed nor any mods/plugins installed in the "new" install, a New character can be constructed. Not so with the old game folder. Both sets of games have their own Oblivion.ini.

3. The XP game has had the LAA (>2GB) patch applied, as have the various loaders and OBSE DLLs.

4. The game is launched with 'Run As Administrator' set on the properties of the game executable and the original and OBSE launchers.

5. I have been trying to use MOM (Multiple Oblivion Manager) but with a single 'Bash Installers' folder, so the secondary folders used by Wrye Bash such as 'AppData' and 'PersonalPath' have been created and pointed to in the 'Bash.ini' and MOM 'Settings', but MOM keeps getting an 'access denied' error when it tries to rename the 'Oblivion' folder despite 'Game Explorer" and DEP being disabled and Everyone having Full Control. (Well, DEP is not really disabled: I added Oblivion.exe, the Oblivion_Launcher, and the OBSE_Launcher to the exceptions list.) Still trying to figure out what system process might be accessing the folder to prevent MOM's access. I've already turned off the Windows Search (and Index) service, so it's not that. But that's a different thread (unless someone here knows the answer).

Given the "new" install without any mods doesn't have the problem nor does the XP environment, obviously the issue lies with OBSE, or a related DLL, or a mod plugin. But how come no-one else seems to be having any BEX issues under Win7 x64? I REALLY don't want to have to re-install 395 mods (via CBash) yet again, especially because I suspect it's not really a mod problem if others haven't encountered it.

Hardware environment:

-Dubious-

Are you running dual monitors? Try Disabling one, see if that helps.

I think most of your headaches are being caused by using two different Operating Sytems for your game.
As somone who has used XP, then Vista, and finally bought a new laptop with 7, bite the bullet and just use one Operating System.
The Anneal All function in the Wrye Bash Installers tab can make reinstalling all of your mods a one click operation.

Good point. I AM using dual monitors. Really hope that isn't the issue, but will test it. Just as soon as I get my script to replace MOM functioning.

-Dubious-

'Anneal All' as an 'auto install' mechanism? Now there's a thought that hadn't occurred to me. Thanks.

-Dubious-

Just updating that the BEX (Buffer Overflow) issue is apparently related to some plugin in the 64-bit environment. Starting from a clean-install and only the DLC plugins, it does not re-appear even with a dual monitor setup. If I ever narrow it down I will report it here.

Also worth mentioning is that the LAA patch ('Large Address Aware', allowing Oblivion to use more than 2GB of memory) appears to force the use of elevated privileges (i.e. RunAs Admin) under Win7 x64. If anyone can find a workaround to that I would appreciate the information.

-Dubious-

Don't install the game to the default directory.......

You can also set the Run as Admin as a permanent condition in the Oblivion.exe properties dialog window.

Thanks for the thought, but the game is (and always has been) installed to my E: drive, and I would prefer to NOT run as admin. (I try to keep the admin User folders clear of unnecessary material.) Unfortunately that doesn't seem to be possible in this case, so I'm just going to have to live with the situation. I had enabled the 'RunAs Admin' property previously when trying to resolve issue with MOM, but even though I have cleared that since, it still prompts for elevated permissions. I even uninstalled and re-installed and it still requires it. Perhaps because a 32-bit app has to run in the WOW32 environment on a 64-bit OS. Just one of the mysteries of Win7.

-Dubious-

If it's installed outside of program files, Run as Admin shouldn't be necessary....... Something strange is going on there....

RESOLVED (apparently):

After reducing my mod list down to about 10 without doing more than small changes in the details of the errors, I decided I might as well start from scratch.

Relatively early I hit the BEX error again with just the official DLC mods and Unoffical patches installed without errors. At this point I was still installing "utilities" and the next on my list was Oblivion Stutter Remover. Once I tweaked OSR to manage the heap, even with the default heap size of 450 the BEX was a thing of the past. Further tweaks and up to 90 mods later the issue still has not surfaced again. This is still a far cry from the 395+ mods I originally had installed (which is why I say this is only "apparently") but I am trying to be much more selective this time around. Good enough for me to call it resolved. Your mileage may vary.

Other comments I found while researching this point out anecdotes that "most problems with HeapStack errors" (which I also had) "can be traced back to mistakes in the OSR settings." Others stated that setting the heapsize greater than 1024 also caused problems.

Overly large heap sizes can waste memory. From a general OS memory addressing standpoint, use multiples of 16. Multiples of 64 are probably best for x64 systems, so 512 would be a better common default than 450. At one point the OSR author commented a heapsize of 640 as working very well for him.

Be sure to take the time to test which heap algorithm works best on your machine to produce the best FPS. I found simply starting a new character and running them around in the prison cell typically produced 3 FPS entries in the OSR log. That's a really small sample, but going with the algorithm that produced the highest single FPS entry has seemed to work so far. (BTW: many report their OSR heap settings as algorithm@heapsize, as in "HA 6@1024".)

-Dubious-