181 replies to this topic

[kranazoli]

Hi,

 

After a long time I'm going to start a new gameplay. I have set enblocal.ini like this:

 

[MEMORY]
ExpandSystemMemoryX64=true
ReduceSystemMemoryUsage=true
DisableDriverMemoryManager=false
DisablePreloadToVRAM=false
EnableUnsafeMemoryHacks=false
ReservedMemorySizeMb=768
VideoMemorySizeMb=3968
EnableCompression=true
AutodetectVideoMemorySize=false

 

My rig is:

 

ASUS P8P67 Rev 3 | Intel Core i5 2500K | G.Skill Sniper 16GB XMP DDR3 1600Mhz | MSI GTX 980 GAMING 4G | Kingston 96GB V+ SSD | Enermax MODU82+ 625W | Samsung 2333sw FullHD 23"| Windows 7 Prof SP1 x86&x64 |

 

Are those settings right? Or could anyone suggets a better settings?

What I want is to avoid CTDs abd ILS and other stuff as far as possible?

 

If this topic is not the right one, please someone sugget me the correct one.

 

Thanks!

[Greg]

ExpandSystemMemoryX64 should be false and VideoMemorySizeMb seems  a bit small for a GTX 980 with 4GB VRAM. This should be set as follows according to the ENBoost page:
 

VideoMemorySizeMb=<integer in MB, multiples of 1024>
;all 32-bit users and 64-bit users with less than 8GB system RAM, set to formula: [Dedicated Video Memory] + [System RAM] − 204
;64-bit users with ≥ 8GB system RAM, set to formula: [Total Available Graphics Memory] − [170 (for Win7) or 350 (for Win8+)]

Notice: To find Dedicated Video Memory and Total Available Graphics Memory in Windows 7 and 8:

1. Right-click the Desktop and click [Adjust screen resolution].
2. In the middle and right-hand side of the window, click the [Advanced settings] link.
3. In the new window that opens, make sure the [Adapter] tab is the current tab.
4. Under Adapter Information, Dedicated Video Memory and Total Available Graphics Memory are listed.

[kranazoli]

Hi,
 
 
I read about ExpandSystemMomery about in STEP forums and put the question about the latest enb series forum:

TES Skyrim 0.279
https://enbseries.enbdev.com/forum/viewtopic.php?f=2&t=4476

 

"And what about these statement?

ExpandSystemMemoryX64

Warning:It has been reported that this feature can conflict with "Sheson's Memory Patch 3.0" (now included with SKSE) by causing Skyrim to crash if the memory patch fix is used to increase Skyrim's initial heap allocation (Block 1 or DefaultHeapInitialAllocMB in skse.ini) higher than 512MB (or 768MB for some). Therefore, if using the Sheson Memory Patch fix (either standalone or with SKSE), it is recommended to set ExpandSystemMemoryX64 to false.

source: STEP EnbGuide

Thanks!"

 

And got these answers:

 

"ExpandSystemMemoryX64 is very specific thing which do not produce any bugs itself, but the reason of game or mods bugs to appear if they are exist. Kinda same thing happen with 4gb laa patch for oblivion, fallout and old skyrim. There are three levels of same mistake which leads to incompatibility. First one is for 32 bit applications with 2gb memory limit per process, like WinXP and older OS. Second level is 4gb native limit of 32

bit applications and it's the case of ExpandSystemMemoryX64 or 4gb LAA patches. Third is x64 memory ranges and they are not the case of skyrim, because only developers may recompile the same code and bugs will occur, if exists. And the bug itself is when code contains arithmetic operations of memory addresses which may return wrong values if address range is above 2 gb (and 4 gb for x64 version). ExpandSystemMemoryX64 primary goal is to fix memory fragmentation issues which is very problematic thing in almost all games, fragmented memory reduce amount of really available free memory. The best use of this parameter is on vista and higher os. On xp it works too, but have very minor effect."

 

From Boris

 

And something like that:

 

I used ENBoost along with the SKSE Memory Fix and DefaultHeapInitialAllocMB=768 for 100s of hours and I never had any problem. Super stable, no ILS, no CTD.

 

PS:

 

Windows says, my Total VRAM is: 7919

Moris VRAM Size Tool says it is: 11904

 

Which one I use - 170? (I use Win7 x64)

Edited by kranazoli, 25 July 2015 - 07:08 AM.

[Greg]

Use 7919 reported by Windows.

[Pretendeavor]

In case you guys need some more user reports.. I can confirm increased instability (CTDs) with ExpandSystemMemoryX64=true and the SKSE memory patch >= 768. Because of SR:LE+REGS+Dyndolod I use higher values than 768 and keep crashing unless I set it to false.

[TechAngel85]

In case you guys need some more user reports.. I can confirm increased instability (CTDs) with ExpandSystemMemoryX64=true and the SKSE memory patch >= 768. Because of SR:LE+REGS+Dyndolod I use higher values than 768 and keep crashing unless I set it to false.

Thank you for reporting!

[Yippee38]

The guide says this:

 

Notice: To find Dedicated Video Memory and Total Available Graphics Memory in Windows 7 and 8:

1. Right-click the Desktop and click [Adjust screen resolution].
2. In the middle and right-hand side of the window, click the [Advanced settings] link.
3. In the new window that opens, make sure the [Adapter] tab is the current tab.
4. Under Adapter Information, Dedicated Video Memory and Total Available Graphics Memory are listed.

I think this needs a note because if somebody were to look at their system and see two different numbers for Dedicated Video Memory and Total Available Graphics Memory, they would most likely use the larger of the two numbers.  However, if the two numbers are different because they are using SLI (might also be true of Crossfire, but I don't know), they would want to use the lower number.  AFAIK, SLI does not make all of the video memory available as one lump sum of memory.  Each card uses its own dedicated memory.  If people don't know this, they would use the wrong number, and potentially run into problems.

 

Edited by Yippee38, 27 July 2015 - 09:42 AM.

[FuzzyDuck]

Hey, sorry to drop in but...
My rig is an AMD Radeon 7870 with 2VRAM and 16 GB of Ram and Windows 7.

 

To the VideoMemorySizeMb setting, what would be the optimal for me to put?
I really didn't understand the notes undearneath, i use an 64Bits with Win 7, i've got moar then 8 RAM, so i should use what formula, 

this one > [Dedicated Video Memory] + [System RAM] − 2048

or this one > [Total Available Graphics Memory] − [170 (for Win7) or 350 (for Win8+)]

[Greg]

If you have 8MB or more RAM with Windows 7 x64, use the second formula:

 

[Total Available Graphics Memory] − 170

[FuzzyDuck]

Ohh, thx :3 
I've..Got really confused with the  "≥" symbol XD
Thx ;3

[keithinhanoi]

Hi,
 
 
I read about ExpandSystemMomery about in STEP forums and put the question about the latest enb series forum:

TES Skyrim 0.279
https://enbseries.enbdev.com/forum/viewtopic.php?f=2&t=4476

 

"And what about these statement?

ExpandSystemMemoryX64

Warning:It has been reported that this feature can conflict with "Sheson's Memory Patch 3.0" (now included with SKSE) by causing Skyrim to crash if the memory patch fix is used to increase Skyrim's initial heap allocation (Block 1 or DefaultHeapInitialAllocMB in skse.ini) higher than 512MB (or 768MB for some). Therefore, if using the Sheson Memory Patch fix (either standalone or with SKSE), it is recommended to set ExpandSystemMemoryX64 to false.

source: STEP EnbGuide

Thanks!"

 

And got these answers:

 

"ExpandSystemMemoryX64 is very specific thing which do not produce any bugs itself, but the reason of game or mods bugs to appear if they are exist. Kinda same thing happen with 4gb laa patch for oblivion, fallout and old skyrim. There are three levels of same mistake which leads to incompatibility. First one is for 32 bit applications with 2gb memory limit per process, like WinXP and older OS. Second level is 4gb native limit of 32

bit applications and it's the case of ExpandSystemMemoryX64 or 4gb LAA patches. Third is x64 memory ranges and they are not the case of skyrim, because only developers may recompile the same code and bugs will occur, if exists. And the bug itself is when code contains arithmetic operations of memory addresses which may return wrong values if address range is above 2 gb (and 4 gb for x64 version). ExpandSystemMemoryX64 primary goal is to fix memory fragmentation issues which is very problematic thing in almost all games, fragmented memory reduce amount of really available free memory. The best use of this parameter is on vista and higher os. On xp it works too, but have very minor effect."

 

From Boris

 

And something like that:

 

I used ENBoost along with the SKSE Memory Fix and DefaultHeapInitialAllocMB=768 for 100s of hours and I never had any problem. Super stable, no ILS, no CTD.

 

Just to clarify here -

 

The "Sheson Memory Patch 3.0" does not change the way TESV.exe (Skyrim's app) allocates memory in its 4GB memory space. Those two "blocks" of heap memory were already programmed by Bethesda to be created when TESV.exe is started. By default, TESV.exe allocates 256MB of memory to both of those blocks.

 

The problem is that when the "Block 1" / Default Heap usage hits 256MB, the routine the programmers used to automatically increase the size of the "Block 1" / Default Heap is flawed, and causes a memory exception error, leading to the instant CTD. This almost always happens as the player is crossing the invisible border of an exterior worldspace cell.

 

Sheson pinpointed the exact two bytes in the TESV.exe binary code which tell the program the default amount memory to allocate to those two blocks of heap memory, and the SKSE team incorporated Sheson's method of writing new values to those two bytes of the program code during SKSE initialization process, before TESV.exe actually starts running.

 

So, this allows the user to manually increase the default "Block 1" / Default Heap allocation, and as a result avoids the problem of the memory exception error, because if you set the default allocation higher than the actual highest memory usage of the "Block 1" heap, then the flawed routine to increase the heap's size never has to be run, and you don't get CTDs for that reason.

 

Sheson also included access to adjust another block of heap memory, called "Block 2", because some people found that when the "Block 1" heap allocation was set to 768MB or higher, then Skyrim would crash upon startup. The workaround for this was to set the initial "Block 2" heap (called the "Scrap Heap" in the SKSE.ini) to 512MB instead of its default 256MB.

 

However, with the great help of Hishtup, I figured out that the "Block 2" scrap heap only needs to be raised to 512MB when ExpandSystemMemoryX64 is set to true. If ExpandSystemMemoryX64 is set to false, then the "Block 1" / Default heap can be set higher than 768MB without the need to set the "Block 2" scrap heap to 512MB. 

 

Also very important - in my extensive testing using a program that allows you to track the exact usage of these two blocks of heap memory, I discovered that the "Block 2" scrap heap" never uses more than 256MB, even when you set it to 512MB. However, when its set to 512MB, that extra 256MB of allocated memory is "locked" out, and TESV.exe can't use it for any purpose.

 

The last thing in my testing that I found is that setting ExpandSystemMemoryX64 to true did not significantly increase available free memory in TESV.exe as compared to it being set to false. And it especially doesn't outweigh the loss of 256MB of memory if you have to set the "Block 2" scrap heap to 512MB because you need to set the "Block 1" default heap over 768MB.

 

Again - the benefits of setting ExpandSystemMemoryX64 to true do not outweigh the downside of having to set the "Block 2" scrap heap up to 512MB to avoid Skyrim crashing because "Block 1" is set to 768MB or higher.

 

Because of all of that, the STEP Guide recommends setting ExpandSystemMemoryX64 to false.

 

However, I think the wording of the recommendation is a little unclear because of the way the DefaultHeapInitialAllocMB setting works in SKSE.ini --

 

Every time I said "over 768MB" for the "Block 1" / Default Heap allocation above, I am talking about the "effective" allocation, which is what TESV.exe actually allocates, as would be seen in either the .log file the SKSE produces or by using Sheson's Memory Block Log SKSE plugin.

 

So, this translates to DefaultHeapInitialAllocMB=1024 in the SKSE.ini file. Remember that the value in the SKSE.ini file must be 256 above the number of MB you want the program to actually use, again which can be verified using  Sheson's Memory Block Log SKSE plugin.

 

Therefore, if someone says they are running with DefaultHeapInitialAllocMB=768, and ExpandSystemMemoryX64=true, and have no problems with CTDs or instability, I am NOT surprised at all.

 

The problems can start as soon as you find that you need to set DefaultHeapInitialAllocMB to something over 768 in your SKSE.ini file.

 

For example, with ExpandSystemMemoryX64 set to true, and I set DefaultHeapInitialAllocMB to 800 (which equates to an "effective" allocation of 544MB), Skyrim will crash upon startup, unless I set ScrapHeapSizeMB=512 ("Block 2"), and you now know by doing this, it means I am wasting 256MB of memory. So I would want to set ExpandSystemMemoryX64=false in enblocal.ini, and set ScrapHeapSizeMB=256 in SKSE.ini, and I'm not wasting 256MB of memory and Skyrim doesn't crash.

 

Boris is right to say that the code he uses to change memory allocation when ExpandSystemMemoryX64 is set to true does not cause bug on its own, but rather what is happen is some kind of interaction between TESV.exe allocation of the two heap memory blocks and his routine under certain circumstances.

 

The STEP recommendations here are not something pulled out of the dark randomly. Quite a lot of time has been spent and investigation into the reasons for the CTDs, and my explanation above has been confirmed by enough people by now that it's consistent and repeatable.

 

If in doubt, I recommend you try some tests yourself - in the name of science! 

Edited by keithinhanoi, 01 August 2015 - 06:45 AM.

[oqhansoloqo]

 

However, with the great help of Hishtup, I figured out that the "Block 2" scrap heap only needs to be raised to 512MB when ExpandSystemMemoryX64 is set to true. If ExpandSystemMemoryX64 is set to false, then the "Block 1" / Default heap can be set higher than 768MB without the need to set the "Block 2" scrap heap to 512MB. 

 

Again - the benefits of setting ExpandSystemMemoryX64 to true do not outweigh the downside of having to set the "Block 2" scrap heap up to 512MB to avoid Skyrim crashing because "Block 1" is set to 768MB or higher.

 

While I admire your extensive knowledge about a lot of Skyrim-related technical issues, my system is not suffering from these memory constraints that you brought up as being issues when using ExpandSystemMemoryX64 set to true.

 

My SKSE.ini settings:

[Memory]
DefaultHeapInitialAllocMB=768
ScrapHeapSizeMB=256

 

In enblocal.ini I have ExpandSystemMemoryX64 set to true.  I rarely ever suffer from CTDs.  According to what you just said, if I set that enblocal.ini setting to true then I would have to set block 2 to 512.  I didn't have to do this.  I also don't get CTDs from having block 1 set to 768.

[TechAngel85]

Because of all of that, the STEP Guide recommends setting ExpandSystemMemoryX64 to false.

 

However, I think the wording of the recommendation is a little unclear because of the way the DefaultHeapInitialAllocMB setting works in SKSE.ini --

If you can think of any why to clarify the recommendation, please do so: https://wiki.step-pr...SystemMemoryX64

 

I've never been a fan of Z's technical warning as most would not be able to understand it. I just added a link to your post above though.

[keithinhanoi]

While I admire your extensive knowledge about a lot of Skyrim-related technical issues, my system is not suffering from these memory constraints that you brought up as being issues when using ExpandSystemMemoryX64 set to true.

 

My SKSE.ini settings:

[Memory]
DefaultHeapInitialAllocMB=768
ScrapHeapSizeMB=256

 

In enblocal.ini I have ExpandSystemMemoryX64 set to true.  I rarely ever suffer from CTDs.  According to what you just said, if I set that enblocal.ini setting to true then I would have to set block 2 to 512.  I didn't have to do this.  I also don't get CTDs from having block 1 set to 768.

 

I'm sorry that it's such a long post, but it really has to be read to the end:

 

Every time I said "over 768MB" for the "Block 1" / Default Heap allocation above, I am talking about the "effective" allocation, which is what TESV.exe actually allocates, as would be seen in either the .log file the SKSE produces or by using Sheson's Memory Block Log SKSE plugin.

 

So, this translates to DefaultHeapInitialAllocMB=1024 in the SKSE.ini file. Remember that the value in the SKSE.ini file must be 256 above the number of MB you want the program to actually use, again which can be verified using  Sheson's Memory Block Log SKSE plugin.

 

Therefore, if someone says they are running with DefaultHeapInitialAllocMB=768, and ExpandSystemMemoryX64=true, and have no problems with CTDs or instability, I am NOT surprised at all.

 

The problems can start as soon as you find that you need to set DefaultHeapInitialAllocMB to something over 768 in your SKSE.ini file.

 

For example, with ExpandSystemMemoryX64 set to true, and I set DefaultHeapInitialAllocMB to 800 (which equates to an "effective" allocation of 544MB), Skyrim will crash upon startup, unless I set ScrapHeapSizeMB=512 ("Block 2"), and you now know by doing this, it means I am wasting 256MB of memory. So I would want to set ExpandSystemMemoryX64=false in enblocal.ini, and set ScrapHeapSizeMB=256 in SKSE.ini, and I'm not wasting 256MB of memory and Skyrim doesn't crash.

 

So, with your settings, I would expect no CTDs.

 

Keeping ScrapHeapSizeMB=256 and ExpandSystemMemoryX64=true, if you increase your DefaultHeapInitialAllocMB to 1024 ("effective" 768MB in-game), there's a good chance you will see Skyrim crash as I and other have.

 

If no crash, try going higher, all the way up to the maximum - DefaultHeapInitialAllocMB=1280 ("effective" 1024MB in-game), and it's almost guaranteed that Skyrim will crash. When you've found a value for DefaultHeapInitialAllocMB that causes Skyrim to crash, then set ScrapHeapSizeMB=512, and Skyrim should start and work fine (I was running like this for quite some time, actually). After that, set ScrapHeapSizeMB back to 256, and set ExpandSystemMemoryX64=false. Skyrim should also work fine, but it's just gained 256MB in its memory space to make use of.

 

Here's something of a chart to make it clearer:

 

ExpandSystemMemoryX64=true

DefaultHeapInitialAllocMB=768

ScrapHeapSizeMB=256

Result --> No CTD / Stable

 

ExpandSystemMemoryX64=true

DefaultHeapInitialAllocMB=1024 (or even > 768)

ScrapHeapSizeMB=256

Result --> CTD on startup for some users

 

ExpandSystemMemoryX64=true

DefaultHeapInitialAllocMB=1280 (or even > 1024)

ScrapHeapSizeMB=256

Result --> CTD for most everyone

 

ExpandSystemMemoryX64=true

DefaultHeapInitialAllocMB=769 or higher

ScrapHeapSizeMB=512

Result --> No CTD on startup / Mostly stable but 256MB of memory wasted

 

ExpandSystemMemoryX64=false

DefaultHeapInitialAllocMB=769 or higher

ScrapHeapSizeMB=256

Result --> No CTD / Stable and you didn't waste 256MB of memory

 

I hope that helps explain it better.

 

I really really wish SKSE hadn't decided to make it so the DefaultHeapInitialAllocMB value has to be 256 higher than what you want in-game. It leads to so much confusion...

 

If you try these tests and have different results, by all means - please let us know. It's really important to know if there are some exceptions to this.

Edited by keithinhanoi, 01 August 2015 - 09:00 AM.

[oqhansoloqo]

 

I hope that helps explain it better.

 

That was really good.  Thank you - the examples help a lot.  So why would someone want to set block 1 higher than this example?:

 

ExpandSystemMemoryX64=true

DefaultHeapInitialAllocMB=768

ScrapHeapSizeMB=256

 

What benefit could I gain by doing this instead?:

 

ExpandSystemMemoryX64=false

DefaultHeapInitialAllocMB=769 or higher

ScrapHeapSizeMB=256

 

In other words - Is it better to have the expanded X64 system memory or have more MB (greater than 768) in block 1?  If it's not better to have more than 768, does the game run worse or better with the use of expanded X64 system memory (set to true)?  My hunch would be that it's better.