Reduce both values by 256. It's the recommended setting, and heavily advised not to rise at least the second one above that value. Not sure where you get your modding advice from, but i'd avoid that place from now on.

Hi http://www.gamesas.com/user/865826-gruftlord/,

your advice doesn't solve the problem, because my games crashes, when block 2 reaches 256. If I would use the recommended settings with 256 as maximum for block 2, then the game will crash surely.

I could use those settings, if I could reduce memory usage going into block 2. Therefore I asked my question regarding things filling the second memory block.

And it is still a secret to me, why the settings are recognized by SKSE, but they are not effective. From the SKSE source code it is clear, that ScrapHeapSizeMB can be set to max. 512. I think the developers had their reasons for that limit, so it should be safe to use a bigger value than 256.

> Somewhere I found the advice to remove Safety Load, because it's not needed any more.

I (re-)found the text about Safety Load:

Skyrim Stability Guide by FireFreak111

http: www nexusmods com/skyrim/mods/50244/? (I am not allowed to write links, so I replaced some chars...)

It says:

Uninstall Safety Load if used, this replaces that.

It contains: SKSE.ini

Try these last values you linked, remove safety load, and the report back if you still crash. Don't just guess around what you think the developers intentions were. I saw them state on these forums, that the last value should not be changed for stability reasons. Why they allowed a bigger number to begin with i don't know, but from everything i read reducing these values by 256 should fix the issues for you.


Memory allocation is a mysterious beast, and i saw many times the skse developers stating that a lot of info flowing around about it is actually harmfull and wrong. The last mod you linked however seems to repeat the developers very own recommendations. If they seems counterintuitive to you, then that's the way it is. Mysterious beast and all.

You can't make things better by deviating from the recommended settings for the SKSE.ini file. You don't need SafetyLoad, since it is superseded by the SKSE memory patch.

I have been using Stable uGridsToLoad (CellStabilizer.dll) but read that it can cause memory corruption and should only be used if you are trying to play with ugrids above 5. So, I am not sure about that one and am going to play later today without it to see if anything changes with FPS or CTDs.

The next thing you need to do is weigh the various texture replacer mods you are running with your hardware and the game's memory limits. I use http://www.nexusmods.com/skyrim/mods/6491/? to see how much system and video memory the game is using. My old ATI HD 6870 with 1G of VRAM cannot run with many high-res textures. I have used Optimizer Textures or DDSopt to resize the textures from both texture replacer mods and all other mods that include large textures (like SMIM and Immersive Armors). Your memory and VRAM limits will depend on your video cards VRAM.

The game itself is limited to 3.2-3.5G RAM. However, because of my video card, I never get anywhere near that limit.

Thank you GamerRick, I didn't know this tool ! I will try it the next days.

Yesterday I tried again with the recommended settings and I couldn't reproduce the CTD. So, that's a point for you guys telling me to use the recommended settings! But I must admit, that I'm not completely convinced, since I tried to increase Block 2 size according to my observation of game crashes everytime while that block is at 256 MB. This was the reason to change the value and then I wondered, why there was no change in behaviour - it still crashes with 256 MB in Block 2. But as I said, yesterday I could not reproduce it...

I revised my MOD-List and removed SafetyLoad, Stable uGridsToLoad and some others. To have a clean start I reinstalled the game and now it will take some time until I have some new insights.

Yes I know about the problem with big textures and use Optimized High Res DLC Standard, Optimized Vanilla Textures. I'm not using SMIM because I'm afraid of issues, but I have amidianBorn Book of Silence, Immersive Armors, Immersive Weapons, Immersive Roads, Expanded Towns and Cities and JK's Skyrim major Cities. But they affected Buffer 1 and in Gopher's video the big number of Windhelm guards did the same. Nearly everyone reported about memory going beyond Block 1 maximum. I found only one other user reporting the same issue I had, but there was no solution too.

I will report, when my game is ready again.

The second heap is not the cause of the crash. That will sit at 256 for me during games for long periods of time without issue. The only memory related crashes for me happen when the first stack goes over the allotted memory. Besides, the settings you were using are basically the same as setting it to 768 and 256 since the 1st block is simply Block 1-Block 2. 1024-512=768-256. You get the same value but the bigger size 2nd block is never actually used, it can't go over 256.

You can adjust block 1 to go higher, and for anyone using a lot of texture/large mods you are going to have to raise it higher than 768, since this actually only gives you 512 in the first block(768-256=512). I have mine set to 1156(gives 900 in the first block) with over 240 mods and ENB active and have had no memory related crashes in many hours of gameplay. Just make sure to keep ExtendedMemoryx64 set to false in the enblocal.ini or it will CTD on startup if the 1st block is set to more than 768. I had to do this because with this on and at 768 it was still CTD'ing when it hit the memory limit. I use Memory Blocks log to track it, which writes to a file and you can check after it crashes to see where the memory was. I also use Skyrim Performance Monitor as well in game just to see where I am at and the FPS, etc...its an excellent tool.

Thus is the nature of memory allocation tweaks. It's basically space magic that doesn't adhere to our mere mortals' simplistic ways of finding coherence. Sufficently advanced and all that.


Bottom line: It's not as simple as say installing more ram on your PC. More complex stuff goes on with these allocation things and due to the nature of skyrim being 32bit, there are lower as well as upper limits to what will run stable. The recommendation from the skse devs/space mages was to stick to the recommended settings and only think about changing if you get memory related crashes. Though not all crashes are memory related and not all memory related cashes can be fixed. If you do get memory related crashes, it was advised only to increase the first value. And only in small steps. Adhering to that has in most cases proven beneficial.

Yup, I was still crashing when I ran out of memory because I use tons of texture mods, ENB, etc...raising block 1 has pretty much made my game completely stable along with ENBoost. Without ENBoost I was still getting crashes using ETaC pretty much everytime I went in or out of a city. ENBoost combined with the memory patch are MUSTS for anyone who uses a lot of mods and wants stability.

I am not a space wizard hacker. But since skyrim never meant to have block 2 change in size its possible there is a hard coded limit somewhere in the engine. 256mb is the number of 4 byte words addressable by an unsigned 16 bit int or a signed 32 bit int so its possible the engine is using one of those to refer to the location of something in block 2 and when that overflows the game crashes. Going further on a limb the engine might check that block 2 isn't full before trying to add more to it and if it is clean out something it no longer needs, which is why filling it up when its only 256mb doesn't crash the game.

Also IIRC ENB has an option to unload textures from general RAM once they have been loaded to your gfx cards VRAM. This should allow you to use many more or larger textures without running into skyrim's ~3.2gb memory limit since VRAM isn't included in that. (The 3.2gb limit is because skyrim is natively a 32 bit program. Its 32 bit memory addresses can hold 2^32 bytes, or 4gb, but about 0.8gb is reserved for system and driver use. VRAM is separate from the computer's general purpose RAM and isn't addressed by the same system so you can have however much VRAM your gfx card has in addition to skyrim's ~3.2gb of general memory. However to get into VRAM a texture has to first be loaded into RAM and then transferred to your gfx card and vanilla skyrim does not take the texture out of RAM once it has been transferred and is no longer needed.) I don't remember what the setting is in ENB as I never used enough textures for it to matter.

It's a memory corruption bug, originally acknowledged by the author in 2013, but was never fixed. It is present regardless of what setting you're using for uGridsToLoad and will in fact be of higher risk the larger you make that setting, so it simply should not be used at all if you want to avoid the memory corruption issue.

Thanks for that reply. I couldn't remember if I had seen anything from you on that DLL, whereas I am pretty sure it was you that said Safety-Load is no longer needed.

Not on that particular post, no, but I do agree that Safety Load is no longer needed as well. The SKSE memory patch made that obsolete.