Skyrim Stability Guide by FireFreak111
Skyrim » Bug fixes
Added: 23/01/2014 - 11:03AM
Updated: 13/02/2014 - 06:59AM

726 Endorsements

1.3 Latest version

6,577 Unique D/Ls

8,273 Total D/Ls

176,265 Total Views

Uploaded by FireFreak111


Last updated at 6:59, 13 Feb 2014 Uploaded at 11:03, 23 Jan 2014

Skyrim has been out for over two years now, and throughout that time we have had many INI tweaks revealed over time. Unfortunately, too many have been posted that can do far more harm than good. Most of this comes from inexperience or not knowing what these variables are meant to do. This guide is to simply remove some of these harmful settings. Many know these already, but many still don’t.

This is a short guide, its two main goals are to make sure the core mods to fix Skyrim’s memory management are installed correctly, and to remove specific harmful tweaks to your system. There's also a section on cleaning the buggy Bethesda DLC files and a section with some tips when installing mods.

I recommend testing the game after each mod, and each INI section, so if you have issues for whatever reason, you can narrow it down.

If this guide helps you, please download and endorse to help more people fix their CTD issues.

Separates Skyrim’s Video RAM usage into a separate process with its own 64 bit memory allocation, allowing Skyrim to use focus its 3.1GB RAM limit on System RAM and thus allowing ENBoost to use virtually unlimited VRAM.

It can be used without the ENBSeries graphical features (and works with MSAA (Anti-aliasing)). If you have installed an ENB Preset for graphical reasons, you already have these files and can modify the memory values as instructed below. ENBoost is part of the non-graphical core of ENBSeries.

If you don't have the files, go to Select the newest version from the list (usually at the top of it). Once selected, scroll to the bottom and click the Download button.

Once downloaded, open the RAR and dump the entirety of the contents of the WrapperVersion folder into your Skyrim folder (if it fails, try the InjectorVersion as a last resort), and if all you want is ENBoost, only two lines have to be changed. Otherwise, configure ENBoost for your system. (configuring it yourself (not using an existing file) is highly recommended)

All ENBoost lines are in the enblocal.ini file (use CTRL+F to find the lines below)

For NO ENB Graphical features
UsePatchSpeedhackWithoutGraphics=true (setting to true ends loading of all graphical effects, loads only game fixes + memory patch)
UseDefferedRendering=false (used for graphical effects, harms performance without them)

Changing UsePatchSpeedhackWithoutGraphics disabled the functions of the enbseries.ini file, and Anti-Aliasing techniques ENB offers, while everything else stays available for use. No INI tweaks are needed when the graphical functions are disabled, nor is the helper mod needed.

If you want to use my new optional file which enables only the Detailed Shadows option for ENB to fix shadow blockiness, keep UsePatchSpeedhackWithoutGraphics at false, but still set UseDefferedRendering to false. File atm works for ENB v250.

Memory Variables
VideoMemorySizeMb= (set to your video memory (VRAM), minus the last two digits, so 2000 for 2GB, 1000 for 1GB, etc. Keep a small amount of memory free)
ReservedMemorySizeMb=64 (leave at 64 (default value) unless you have 1GB or less, then consider changing this to 128. If you experience stutter after installing ENBoost, try raising this to 128 first, then to 256 if it still stutters for you)
ExpandSystemMemoryX64=true (consider setting to false if 32 bit)
AutodetectVideoMemorySize=false (set to true if you don't want to worry about having the right value for VideoMemorySizeMb, highly recommended)

Quick side note about ReservedMemorySizeMb. In older versions of ENBoost, Boris had these at a high level. In later versions he optimized ENBoost to use much smaller amounts for this, and thats why by default its at a low level (64). This is the amount of dynamic memory allocated to share between Video RAM and System RAM. With a system that has 2GB of VRAM or more, 64 is a good amount, since you have enough VRAM that you don't want to be switching between the two (stutter can occur because of that switching, but a small amount still needs to be allocated). 128 is good for 1GB of VRAM because your starved on RAM, and its a better backup.
If your suffering serious stuttering when walking as new objects/cells are loaded after installing this, the command that controls this is:
Set this to false to remove this stutter at the cost of less RAM compression (closer to pre-ENBoost levels), and increased risk of CTD with a memory hungry setup.

Other variables
An important variable you should change is:
EnableVSync=false (change to true)

VSync will be disabled unless this is set to true.Additionlly, ENB VSync has been claimed to help reduce the severity of the 1.9 lip sync bug. I highly recommend changing this to true.

Now, quick warning, if you have driver (Nvidia/AMD) Anisotropic Filtering enabled, disable it, and use ENB Anisotropic Filtering, as ENB knows which textures should and shouldnt have Linear filtering. Knowing this fixes many bugs from having it forced everywhere from the driver, especially with Parallax effects. Verify ENB Anisotropic Filtering is enabled by making sure the following lines in enblocal.ini match what's below:

If your underwater looks messed up post install for some reason, install the Underwater fix here

Skyrim Memory Patch 3.0 + Stable uGridsToLoad
Stable uGridsToLoad

There is a bug with vanilla Skyrim related to the handling of cells, where the game is wrongly spawning too many cells, which eventually causes a CTD. Though the problem only causes a CTD with uGridsToLoad at a manually raised value, its still spawning too many cells and increasing memory usage. This mod will fix this problem, and help your game's memory usage. This requires SKSE.

Skyrim Memory Patch

Fixes your core ILS and CTD issues. The true fix for cell transition crashes, infinite loading screens, crashing when nearing Whiterun, etc. New download that doesnt mess with SKSE (from creator of New Vegas Anti Crash)

Drag and drop the entirety of its contents into your root Skyrim folder. It should add two files to the folder, d3dx9_42.dll and ssme.ini.

Skyrim Memory Patch is completely differently different to safety load. When Skyrim is loaded, it sets up two blocks of memory to use. Both are given 256MB. When the game fills up that primary block, it creates another 256MB block, and moves/places the memory there. The CTD's and ILS's are arising from the fact that the core 256MB block on PC fills up way to fast, and the game cant handle switching such core game data (cell data, etc) to the second block, which causes the CTD/ILS.

The Memory Patch changes that first block of memory Skyrim assigns to a 512MB block (double), which is more then enough for uGrids 19 . 99% of people who have used it have reported that all their CTD's, ILS's have ceased to exist, and they can walk through normally CTD heavy areas without the game flinching. I have verified this, as have many others, by setting the game speed to 10x (1000), and flying from somewhere like Riverwood to Solitude to Windhelm to Riften to Whiterun, and then the whole loop again, with no CTD. This is with the engine rapidly switching data and unloading/reloading game objects.

Uninstall Safety Load if used, this replaces that.

Original source here:

Skyrim Project Optimization
A mod I highly recommend to improve performance in interiors by optimizing rendering, it will help keep CPU/GPU load down, possibly helping reduce crashes, all while providing a large free performance boost.

If your using many mods which edit the interiors of houses (layout of the house, moving major objects), this may cause issues. Lighting Overhauls or minor changes (Unoffical Patches) work fine with it.

If you have added/modified any of the variables below in your Skyrim.ini (in My Documents/My Games/Skyrim), I highly recommend you follow the next section, otherwise, enjoy a stable Skyrim :).

If you don't have the lines in any of these sections, there is no need to add them. Removing them sets them to their default values.

Papyrus (Skyrim.ini)
First section is the most important. Papyrus, which is the scripting system Skyrim uses, is very fragile. The most popular tweak for it will overload it, and can hurt performance, and overwork the CPU.

Replace anything you have here (in Skyrim.ini) with the default settings (vanilla master Skyrim.ini uses these numbers):

Notice that the MS values is ~660x smaller than what some recommend (800)?  To put it simply, 60fps requires around 16.6ms max to be spent on rendering each frame. Allowing up to 800ms of CPU time to one task is not a good idea, it needs to share CPU time with other things. Also notice the small memory values. Setting these larger is not a good idea, just read the link below to know why.

One variable you should change is fPostLoadUpdateTimeMS this is how much time the game spends on load setting up scripts. Max recommended here is 2000 (500 by default, 2000 is used for the consoles for stability), it should help with a more script-heavy setup (which you shouldn’t have, scripts hammer your CPU). This will increase load time as the variable goes up.

If you are running such a setup, and your scripts start to misbehave/perform badly, you could increase the MS values in increments (to 1.8, then 2.4). The first one (fUpdateBudgetMS) is the core amount of allocated time to the Papyrus update loops. Increasing this will help scripts remain stable on script-heavy setups, but if they reach the maximum amount of allocated times at high values, the framerate will drop. The second variable (fExtraTaskletBudgetMS) is how much time is additionally allocated to the Papyrus scripting engine in intensive situations. This won't have any effect unless the scripting engine is highly stressed. Again, framerate will drop if this time is used.

Explanation of these settings is here:

Bethesda Developer confirming this:

General (Skyrim.ini)
There are often changes to many variables here to apparently increase memory usage. These values should be left alone, especially the iPreloadSizeLimit variable, as this variable is actually related to the preloading of the intro video. Allocating 4GB to that is obviously going to mess your game. The Skyrim Memory Patch and Stable uGridsToLoad are combined the true solution to uGridstoLoad crashing. Also, the uInterior Cell Buffer variable should not be changed, uGridstoLoad has no effect on it.

Remove these lines if you have added them to your Skyrim.ini:
uInterior Cell Buffer=

If you have this variable added, if your game is working well after the Skyrim Memory Patch try removing this variable, as it is by default 1000, (some recommend 99999+ for some reason). This may have helped in the past, but now the Memory Patch should have properly fixed it.

Remove this line if you have added it to your Skyrim.ini:

The next variable is one many people will instantly ignore changing if you've changed uGridsToLoad, but this variable in newer Skyrim patches is automatically changed by the engine depending on your current situation (including your uGridsToLoad variable). Changing it above its default is again not helping your game at all.

Restore this back to 36 if you've changed it.
uExterior Cell Buffer=36

I can confirm this variable doesn't need changing. uGridsToLoad=7, uExterior Cell Buffer=36, Speed at x10, Collisions off. Flying around the map at high speeds with cells loading/unloading. No CTD, works fine.

Threading Changes
Following is the DEFAULT settings Skyrim uses:

Here's the simple truth. If you have 4 cores, or 2 cores, Don't change this. Just don't. Remove it from your INI file if you have.

Skyrim by default uses 4 cores of your CPU (iNumHWThreads=4). These cores/threads are each allocated to different tasks. The variables are perfectly set to leave room for different tasks. For example, notice the gap between Rendering and AI, there is one thread free. This is used for the 1 default Havok thread. There is a gap between the AI threads too, used for 3 of the HWThread's. 5 is shared with AI Thread 2. This is a wildcard of sorts. This works for 4 cores, and should be left alone.

Let's just leave it at this: If you want to change this value, if you've followed this guide correctly, just change it. There is no additional tweaking needed. no uExteriorCellBuffer change (engine auto-changes this), no messing with memory variables, no increasing the size of the SSME values, just change it and launch.

There are serious risks when changing this variable. Papyrus (scripts) will become overloaded with work, and will eventually start performing badly. (uGridsToLoad 9+, 7+ on a script-heavy setup). The engine will be working harder rendering many objects will full detail (uGridsToLoad 9+). VRAM usage will begin to rise in large amounts (uGridsToLoad 7+). Quests with events that trigger on cell load will trigger before your close (uGridsToLoad 7+). Most importantly, your save will slowly become cluttered with more data slowly being stored in your save as more AI and objects in the distance update and change, and as quest scripts trigger and run (uGridsToLoad 7+)

Change if you want a higher view distance with the risks above:
uGridsToLoad=5 (change to what you desire at your own risk, use only odd numbers)

Havok (Skyrim.ini)
Believe it or not, changing this value is not a good idea. Havok is set to 1 thread by default because there's only one thread to spare. Increasing this to 4 will cause Havok to share thread's with tasks like AI and Rendering, which will ultimately hurt your CPU more. Even with an 8 core CPU, just leave it to 1 thread. We don't know enough about Skyrim's thread allocation to be sure that it won't share the second thread with tasks like AI.

Remove the following from your file if you've added it.

BudgetCaps (Skyrim.ini)
I'll be short and direct. Remove this section from your INI file if you've added it. There is no need to change these variables, there is no concrete evidence this helps anything, and a majority have people have had great success with the Skyrim Memory Patch without changing these variables. Please just remove this entire section from your file if you've added it, you're likely increasing memory usage for no reason.

The DLC .esm's and Update.esm's are delivered to us by our trusty Bethesda unclean, which causes mods to not function correctly and can cause CTD's with some mods.

I will leave this one to our good friend... Gopher :).

TES5EDIT Download:

Manual guide (for those who don't want to watch an easy video):

1. No such thing as a clean save.
Two quick things on this issue. One, once you install scripts into your save, they have left their mark, they have spawned their stuff, and they have made their imprint on your game. The only clean save is the one before your mod was installed. Secondly, mods like Civil War Overhaul or the Unofficial Patches need a NEW save to take effect, as they alter important scripts run from the very start of your save. You will experience failure of scripts and even a possible CTD without a new save.

2. Script Mod Overload.
Look, we all want location damage, footprints, a complete old school overhaul plus every single minor addition that makes the game more immersive. Papyrus, the scripting engine, can't handle too much. It's simple logic that too many script mods will overload the engine. Mods that are really, really old, or have a comment section with 500 warnings saying don't use this mod (looking at you... WARZONES), they have scripts that will kill your game eventually. ESPECIALLY if you use uGridsToLoad (two additional grids in your radius to process scripts from.) Be careful with these mods.

3. Distant Detail
Short warning about these, but flagging models to load at full distance with full detail will really hurt your GPU. Skyrim Distance Overhaul accomplishes this using actual LOD's (reduced quality models, like vanilla Skyrim), so that the models don't need every twig loaded in full texture resolution. Compromise for your GPU's sake :).

4. Sound Mods.
Many newer sounds mods are stable, work well, and are good for your saves (such as Audio Overhaul), but many of the older ones will cause serious issues, break down, run rampant scripts, use over-sized sound files and more. Its best you read ~2 pages of the comment section to understand the general opinion and issues with the mod. (there might not even be any)

Some known unstable mods:
Crimson Tide - Blood
Locational Damage (when used with many script mods)

Some unstable mods possibly fixed by the Memory Patch:
Open Cities Skyrim
Deadly Spell Impacts

In Skyrim, timescale is basically in-game time compared to real world time. How many seconds in the game world pass in one second of our world. By default this is set at 20. This is what every NPC, script, event and even dragon attacks are designed around. Many lower this variable to allow the game to feel more realistic, with the days passing by less frequently, taking more time.

Instability can arise when you lower the timescale beyond 6. Scripts will begin to seriously misbehave, many NPC's may stop their schedules, cell's wont cleanup as often, AI may get stuck, and encounters may not work. Even at 6, some events may not work.

The mod linked here will dynamically change the timescale based on interactions with the NPC's and events that have issues below a timescale of the vanilla 20, and at all other times will keep it at 6.

Use this mod only if you wish for the timescale to be lowered, and for in-game days to pass by slower.

I hope this guide fixes many of the irritant CTD's/lag misguided tweaks can cause, and ensures as many people as possible fix the true root of the vast majority of CTD's (Skyrim Memory Patch).

If this guide helped you, please download and endorse to help more people fix their CTD issues.