Jump to content

CTD and Performance patch ENBoost (by Boris Vorontsov)


EssArrBee

Recommended Posts

I use Microsoft Security Essentials myself but I also have Skyrim and ENB related files/folders excluded as a precaution though even before that I had no issue. The same went for SSME, MSE never flipped out on that as other security suites have reportedly done. There's a lot of crap-ware out there and also bloat-ware. I used Avast years ago, but put it out to pasture with Norton, McAfee & PCTools. If I want security theater, I'll go to an airport; don't want it on my PC.

 

Boris has given his answer, it's his creation and he can implement it how he wishes. Curiously, I am in a weird place with the ExpandSystemMemoryX64 settings. Over the past 30 days or so, after much trial and error, I settled on ENB settings that work -as in no (ZERO) CTD's. This is a combination of efforts, I'm sure:

  •  ditching troublesome mods, still have 187 installed
  •  SSME, 512/256 (384/256 works fine, but I set it back to Sheson Default during the CTD issue troubleshooting)
  •  enblocal.ini settings:

[MEMORY]

ExpandSystemMemoryX64=false

ReduceSystemMemoryUsage=true

DisableDriverMemoryManager=false

DisablePreloadToVRAM=false

EnableUnsafeMemoryHacks=false

ReservedMemorySizeMb=640 (I vary this from 128 to 768 at times if I notice a little stutter, doesn't seem to make a discernible difference)

VideoMemorySizeMb=4095

EnableCompression=true

AutodetectVideoMemorySize=false

 

The enblocal settings seem to be the only settings that correlate with any problems I have. That problem being a short little stutter/halting right when I leave the Interior of Dragonsreach. My game is running so well now, I am fixated on that as an issue, lol!

 

But, if I change ExpandSystemMemoryX64 to true I get a CTD within an hour so of play usually when using a gate to a city like Whiterun. So, no ctds = ExpandSystemMemoryX64 OFF for me.

 

I think ENBoost's resource juggling is overly aggressive for my system and I just have a sweet spot without it. The explanation for what ExpandSystemMemoryX64 does never satisfied me (go figure) because Skyrim was already officially patched in Update 1.3.10:

 

    Support for 4-Gigabyte Tuning (Large Address Aware)

So, left with no CTD's for days and having a CTD within an hour or two of enabling the memory64 setting on the three occasions I have done so, I've just decided to leave it off for my modest system.

  • Intel Core i5-3570K
  • MSI R6850 Cyclone 1 GB VRAM
  • MSI Z77A-G45
  • 8GB DDR3 (1333MHz)
  • SanDisk Extreme 128 GB /1 TB HDD
  • 8 Channel High Definition
  • Cooler Master 550w
  • Windows 7 64 bit
  • Mod Load Order

I also think there is some interplay between the Sheson Memory Fix and ENBoost Memory shenanigans...I'm just not sure in what way. This could potentially explain why every since I started using the Sheson-born solution, the ExpandSystemMemoryX64 has become problematic for me.

 

One would think, that with all that creative resource juggling there is bound to be a few stomped toes and black-eyes between the two...but I simply can't say if that is so.

Link to comment
Share on other sites

Kuldebar' date=' thank you very much. I experienced random crashes after 30-60 min of game, but after your post I changed ExpandSystemMemoryX64 to false - and there was no one crash after about 4 hours of game. I'm using ENB 250 now.[/quote']

I wish I could understand why CTD's are less (for some people) with it off.

 

Wow, quite the conversation going on at ENBDEV forums...

 

https://enbdev.com/enbseries/forum/viewtopic.php?f=2&t=2858&sid=94cba13595a8dcd6c24f8c8a0ac64123&start=90#p48099

 

I must admit, I'm kind of in jonwd7's camp on this subject.

 

I think there is an interaction going on between the memory allocation solutions that we currently have on hand.

 

jonwd7:

 

It's very simple, skse_loader + ExpandSystemMemoryX64=true == crash, TESV.exe + ExpandSystemMemoryX64=true == no crash, skse_loader + ExpandSystemMemoryX64=false == no crash.

 

Whether or not you personally have the issue just implies that there is another INI setting at play, not "**** like Avast" as Boris so eloquently put.

 

And again, not sure how I'm "pointing fingers" if I clearly state that no one is to blame in the matter. You can't expect to have a dozen programs all touching memory allocation.

This resonates with what I've been experiencing, it was also why I stopped using the SKSE Alpha and switched to SSME, which still leaves me with my consternation over the ExpandSystemMemoryX64 setting.

Link to comment
Share on other sites

Well ultimately then if only very few people have issues then it is more then likely something unique to their systems, and not the solution as a whole.

 

As it is now then the impression I have is that it works fine for the majority, including myself.

One cannot expect developers to take individual cases seriously, since it is kinda annoying to try to sort out an issue and then in the end get that little info that they where also running with program X and that was what caused it.

 

It could be some autoupdater in the backgrond for some weird program causing issues for all we know.

Or again it could just be that the hardware does not like the stress putting those settings on implies, and hence start to act up.

Link to comment
Share on other sites

@Aiyen

 

Well, "ultimately" a few people are allergic to shellfish, it is therefore useful to pinpoint the exact source of their problem instead of simply saying most people don't have a problem when going to Red Lobster on Thursday nights. I like taking people at their word as a matter of courtesy, until proven otherwise. As exciting and positive as the Sheson patch has been for the Skyrim player-base; we should still be open to the possibility that there might be some downsides we don't entirely understand for some configurations and combinations.

 

Glossing over this topic won't help anyone in the long run.

 

One individual rushing to denounce jonwd7's comment seems rather off base, more of a raving Boris "groupie":

Why does SKSE team even bother with memory features when ENBoost is around already boggles my mind.

ENBoost features never solved the bulk of the systemic CTD's and ILS's that Skyrim suffered, it only addressed VRAM saturation and we derived cascading benefits from that improvement. We had SafetyLoad for a reason, pre-Sheson.

This whole memory **** is just a joke, only ENBoost seems to do what it does, and SKSE/Sheson is building on its functionality. If their patch won't work with ENBoost speak to the people who wrote it, not to Boris. I see no post whatsoever of you in that thread. I use ExpandSystemMemoryX64=true, I even use sheson's .dll stuff just for seeing if there was a difference, and I tried without on win7 x64 and my game doesn't crash.

Wow, just wow. No one else see the problems with this line of reasoning above?

 

Maybe we can give some thought there there just might be  some adverse interaction between ENBoost and some applications of Sheson's Memory patch. Unlike the quote above, they don't do the SAME thing, but they live in the same neighborhood and are bound to cross paths.

Link to comment
Share on other sites

Computer bugs are not like allergies.

 

You are crashing in ways that are more typical of modding problems than in memory problems (opening door of Whiterun = CTD normally means mod conflict or bad mod code (go on esp/script/mesh witch hunt).

 

Skyrim Memory Patch 3.0 allows you to load more things in memory before crashing. Setting too high values for the memory settings is most likely the cause of the CTDs that jonwd7 is experiencing. ENBoost allows you to use more memory than the 32bit nature of the Skyrim engine allows.

Link to comment
Share on other sites

Kuldebar: If any problem is not reproduce-able by a large enough amount of people, then the developers have no chance to fix anything. If they do not have the issue themselves then it is mighty hard to do anything. If they had a large amount of people who could provide feedback on a issue then it would be a different thing, but that is not the case here.

 

Nobody is saying they do not want to look into the issue, but as it is now then from a developer standpoint then the issues a few people have most likely come back to something unique to their systems.

 

Also I find it amusing how you link to all the people who bash at jonwd7's comment, since if you actually look at what he says then it is in no way a proper way to ask for help. And that causes the entire thing to derail further.

 

That said then it would ofc. be nice to be able to actually get this working for more people! The best thing to do is to find people who have the issue and then start comparing hardware and what you have running in the background. If proper technical data can be presented then perhaps something will get done.

 

Also finally thank you for at least not making a car analogy! :p

Link to comment
Share on other sites

Well, "ultimately" a few people are allergic to shellfish, it is therefore useful to pinpoint the exact source of their problem instead of simply saying most people don't have a problem when going to Red Lobster on Thursday nights.

 

This analogy is flawed. It's not like you are a customer, Boris is developping his ENB for free.

The better analogy would be this: Boris' Red Lobster is free on Thursday nights. Some people with obscure allergies have problems after eating there. They compain to him and demand their allergies to be diagnosed so they can continue eating free fish. He gets annoyed and puts out a sign: No people with fish allergies!

 

I like his attitude :)

Link to comment
Share on other sites

Well' date=' "ultimately" a few people are allergic to shellfish' date=' it is therefore useful to pinpoint the exact source of their problem instead of simply saying most people don't have a problem when going to Red Lobster on Thursday nights.[/quote'']

This analogy is flawed. It's not like you are a customer, Boris is developping his ENB for free.

The better analogy would be this: Boris' Red Lobster is free on Thursday nights. Some people with obscure allergies have problems after eating there. They compain to him and demand their allergies to be diagnosed so they can continue eating free fish. He gets annoyed and puts out a sign: No people with fish allergies!

 

I like his attitude :)

It's his creation and he can implement it how he wishes. As for his interpersonal skills, that's something quite different.

Link to comment
Share on other sites

Wow, I really didn't expect that small storm following my seemingly innocent question about ExpandSystemMemoryX64 set as false in the last few Skyrim ENB binary releases.

 

Still, it shows it would help a lot if we had a much clearer idea what that and the other ENBoost options do, exactly.

 

Personally, I don't get any CTDs at the Skyrim menu with ExpandSystemMemoryX64=true in enblocal.ini and applying sheson's patch via SKSE 1.7.0 alpha with DefaultHeapInitialAllocMB=768 / ScrapHeapSizeMB=256 in skse.ini. 

 

However, I can't say whether ExpandSystemMemoryX64=true versus false definitively leads to CTDs an hour into a game or not simply because I've not had enough chances to play more than an hour solid (busy adult-father-working real life.) Even if I did get CTDs that far into my game, I'd need to examine mini-crashdumps and other hard data before I could agree that this one setting is the culprit.

 

Anyhow, after another exhaustive set of keyword searches through the ENB Forums, I've found some very interesting tidbits from Boris that has changed the picture I've put together of what the [MEMORY] settings do.

 

Because of this, I've decided it would be better to post my understanding of each setting, one at a time, in a thread on the ENB Forums, and (politely) ask Boris to say either "yes, it works like that," or "no, here's what it actually does..."

 

Stay tuned....

Link to comment
Share on other sites

Thanks a lot KeithinHanoi, I'm looking forward to better understanding those settings. ExpandSystemMemoryX64=true hasn't seemed to cause issues for me running a patched skse loader (512/256) so far, but my testing is by no means rigorous.

CPU i7 4770k @ 3.5GHz

RAM 16GB (2 x 8GB DDR3 1866)

GPU NVidia GTX 670 2GB

120 GB SDD (Windows 8.1 64bit OS)

1TB 7200 RPM HDD (Skyrim)

Link to comment
Share on other sites

Thanks a lot KeithinHanoi, I'm looking forward to better understanding those settings. ExpandSystemMemoryX64=true hasn't seemed to cause issues for me running a patched skse loader (512/256) so far, but my testing is by no means rigorous.

 

Well, I'm not sure I deserve thanks, because my last few posts on the ENB Forums seemed to have done more damage than good - even if indirectly.

 

So, I had a chance to ask about the ExpandSystemMemoryX64 setting after Boris suggested disabling it to mindw0rk, who has been getting random Microsoft Visual C++ Runtime error messages.

 

Well, apparently complaints about ExpandSystemMemoryX64=true finally got to him, and he found out that with ExpandSystemMemoryX64 enabled, Enhanced Character Edit does not work with SKSE 1.7.0 installed (but does work with SKSE 1.6.16), so he announced that ExpandSystemMemoryX64 has officially been removed in the latest updated 0.251 binary (along with his great flair for word choice).

 

*sigh*

 

So I guess we'll never really know exactly what ExpandSystemMemoryX64 does, because as of today, it is gone - unless he changes his mind...

 

Sorry, everyone.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...

Important Information

By using this site, you agree to our Guidelines, Privacy Policy, and Terms of Use.