The Elder Scrolls V: Skyrim

The Elder Scrolls V: Skyrim

Not enough ratings
Troubleshooting Skyrim (WIP)
By smr1957
Responding to numerous threads asking for help gave me the idea that it might be useful if we had a standardized list of questions to go through when troubleshooting a problem, as well as standardized responses which we could post. This would be useful to ensure that all pertinent information is collected in one place, thereby avoiding having to search through a thread for that info, and would also help to avoid asking questions that have already been asked and answered, while at the same time providing consistency when responding. I am (for the most part) just compiling and collating all these notes and information from my own files; Ilja, cfs111, Nazenn, Avrie, Arthmoor, the Unofficial Patch Project Team, the UESP Wiki, and many others are the ones really responsible for them. (A Work In Progress)
Note: This guide is intended to deal with purely game related problems. Problems relating to hardware and Skyrim's interaction with that hardware, will not be covered.
In order for us to help you solve your problems with the game, please answer the following questions (please start a discussion re: your problem in the forum - do not post here as it will not be replied to in this thread):

If you suspect the issue is a bug, have you checked ?
(NOTE: Due to the nature of the site, you will encounter spoilers. The UESP Wiki for Skyrim contains walkthrough info, detailed notes, and, towards the bottom of the pages, a Bugs section. If bugs have been reported, that is where they will be listed - with the fix, if one is available.)

If you are playing original Skyrim, have you read Player spreadsheet - Player and Modding Resources by Ilja
VERY IMPORTANT if you wish to successfully mod your game

If you are playing Skyrim Special Edition (SSE), have you read Skyrim SE: Guides and Resources by Ilja
VERY IMPORTANT if you wish to successfully mod your game

Did you follow all instructions and directions in approriate post mentioned above?

If you are playing original Skyrim, have you installed SKSE memory fix? (Covered in Player spreadsheet.)

Do you use mods or do you play vanilla game?

Have you installed the appropriate Unofficial patches? (This should be done even if you play vanilla.)

If you use mods, have you sorted your load order with LOOT? (Please post LOOT sorted load order.)

If you are experiencing a crash to desktop (CTD) issue, when, exactly, does this occur? (After Bethesda logo, during initial load screen, during some other load screen, at some certain point in game - please be as exact as possible.)

If you have animation mods, do you have FNIS installed?

Have you removed any mods at any time during your playthrough?

Have you made any changes to the .ini files?

Have you changed uGrids settings?

Have you used console commands?

Have you cleaned the Master files?

Did you clean any other mods?

What is the size of your save files?

Have your save files been increasing in size more than perhaps is usual? (Would need to see a series of save file sizes in order to plot the magnitude of the increase - if any - in size.)

What are your system specs?

Is there any other information that you can provide (and which is not covered in the above questions) which may be pertinent to the solution of your problem?

If you decide not to answer all the questions or read all the linked posts, there may be very little we can do to help, so if you do not know the answer to a question, or do not have the information available, let us know. If you do not do these things, all future posts will be ignored, as I have no desire to wade through a sea of posts searching for the necessary information or to be endlessly repeating myself - or to ask other contributors to the thread to do the same.
SKSE MEMORY FIX (Original Skyrim Only)

An alternate set-up:


NOTE: You can go from defaultHeapInitialAllocMB=768 to defaultHeapInitialAllocMB=1024 , but you cannot go from the higher (1024) to the lower (768). Following from SKSE Installation by Avrie (in SKSE and the mystical memory tweak section):

"...most if not all of the other guides still say to use 768, and if you have limited Ram memory installed you might still be better off using 768. However, if you do have decent Ram, and you plan on installing lots of mods, go with 1024 right from the start. You’re working with the most current information in this guide.

A quick note on save files … The game saves the state of many aspects of the game including scripts permanently in the save files. Which is why it’s such a bad idea to remove a scripted mod from a running game. The “space” we’re discussing also affects the way the game structures the save file. You can always increase the amount safely, but decreasing the amount will adversely affect the stability of the save, and may break scripts. It is NOT recommended. If you feel you need to switch back to 768, please start a new game...."

Or just use:
SKSE ini pre-download for lazy users by Sagittarius22 -
and install it by using either Mod Organizer or Nexus Mod Manager.

SKSE is needed for a lot of mods, also, it helps prevent infinite load screens and CTD due to memory issues. With this installed, you do not need Safety Load or SSME - Skyrim Startup Memory Editor. For more information, see also:

Player spreadsheet - Player and Modding Resources by Ilja

Advanced Tips : Memory, .Ini's and Myth Busting (v2.6) by Nazenn -

SKSE, memory and skse.ini by Ilja -
The Unofficial patches are a necessity when it comes to running a bug free game. They fix literally THOUSANDS of bugs. It is important to note, however, that they do not fix bugs retroactively (due to the fact that the bugs may have already been baked into the save file) - thus, it is important to install at the beginning of a new game. For more info, you should read the following, by Nazenn:
And, by the Unofficial Patch Project Team:
Unofficial Skyrim Legendary Edition Patch: Version History[]
Frequently Asked Questions - BUGS[]
Frequently Asked Questions - About the Project[]
Mods Made Obsolete by Unofficial Patches[]


IF YOU HAVE ALL DOWNLOADABLE CONTENT (DLCs) - Dawnguard, Hearthfires, Dragonborn:

Unofficial Skyrim Legendary Edition Patch by Unofficial Patch Project Team -
Fixes numerous (thousands) of bugs. Should be used! - install when beginning new game.

If you have the HighRes Texture Pack installed:
Unofficial High Resolution Patch by Unofficial Patch Project Team -

Your load order would therefore be:

Unofficial Skyrim Legendary Edition Patch.esp
(Your other ESM files)
HighResTexturePack01.esp (if installed)
HighResTexturePack02.esp (if installed)
HighResTexturePack03.esp (if installed)
Unofficial High Resolution Patch.esp (Unofficial High Resolution Patch by Unofficial Patch Project Team - ) (if HighRes Texture Pack is installed)
(The rest of your mods)

IF YOU DO NOT HAVE ALL DLCs (use only the ones for which you have the appropriate DLC):

Unofficial Skyrim Patch - (this is required regardless of which DLCs you have)
Unofficial Dawnguard Patch -
Unofficial Hearthfire Patch -
Unofficial Dragonborn Patch -
If you have the HighRes Texture Pack installed:
Unofficial High Resolution Patch by Unofficial Patch Project Team -

and the load order would be:

(the following, as applicable)
Unofficial Skyrim Patch
Unofficial Dawnguard Patch
Unofficial Hearthfire Patch
Unofficial Dragonborn Patch
(Your other ESM files)


Unofficial Skyrim Special Edition Patch by Unofficial Patch Project Team -

Your load order would be:

Unofficial Skyrim Special Edition Patch.esp
(The rest of your mods)
To post your load order, just click on the 3 verticle dots in the upper right corner of LOOT screen, click on copy load order from the drop-down menu, and then paste.

As regards LOOT telling you to clean mods other than the Masters (Update.esm, Dawnguard.esm, Hearthfires.esm, Dragronborn.esm), DO NOT clean ITMs (unless the mod author or a reliable forum regular says otherwise) as LOOT does not pick up whether these edits (ITMs) are necessary or not, and some mods require them to run correctly. Do, however, clean deleted references, as these may cause problems in your game.

Regarding cleaning of Masters and/or cleaning of other mods, please see the appropriate Guide sections.

Manually Adjusting The Load Order

While LOOT is an excellent tool, it does not always get things right, and sometimes it may be necessary to change the LOOT sorted load order. In order to ensure that LOOT saves these changes, it is necessary to edit the metadata for that particular plugin. From LOOT Docs:

"LOOT uses metadata to supply plugins with messages and Bash Tag suggestions, and to help it sort plugins that it can’t otherwise sort correctly. Users can add to their plugins’ metadata through the metadata editor panel, and plugins with user metadata are indicated with a “Has User Metadata” icon.

The editor panel is accessed by clicking the “Edit Metadata” item in a plugin’s menu, or by double-clicking a plugin name in the sidebar. Only one plugin’s metadata can be edited at a time. While the editor panel is open, the plugin sidebar also displays any non-zero plugin priorities, to aid setting new priority values. The editor can be resized by grabbing the top of the editor’s header and dragging it up or down.

The editor’s header displays the name of the plugin being edited, “Save Metadata” and “Cancel” buttons, and a row of tabs. The MAIN tab’s page contains the following inputs:
•The “Enable Edits” toggle must be on for LOOT to use any user-added metadata, otherwise it will be ignored.
•The “Global Priority” input sets the plugin’s global priority value, which is used to modify plugin position relative to all other plugins. Plugins with higher priority values load after plugins with lower priority values. Plugins have a default global priority of 0.
•The “Priority Value” input sets the plugin’s local priority value, which is used to modify plugin position relative to other plugins that conflict, load archives or are empty. Plugins with higher priority values load after plugins with lower priority values. Plugins have a default local priority of 0.

The other tab pages contain metadata tables, which are detailed below. New rows can be added, and existing user-added rows can be removed, though rows containing metadata from the masterlist cannot. The LOAD AFTER, ... tables can have rows added by dragging and dropping plugins from the sidebar into the table area.
This is a list of plugins which, if present, the current plugin must load after, but which are not required. This metadata can be used for resolving specific compatibility issues. Each entry has three fields:
•The filename is the path, relative to the game’s Data folder, of the file to be checked for. This field is required. It gives the filenames of installed plugins as autocomplete suggestions.
•The display name is optional, and if specified will be used instead of the filename in any error messages that are displayed if a problem is encountered relating to the file."


If you just wish to have a particular mod load after another, the following is a step by step explanation of how to do so. I have used Immersive Armors by Hothtrooper44 - as an example, since it is a mod which many people have errors in placement with. First, a short explanation of the proper placement order:

Hothtrooper44_Armor_Ecksstra.esp should load before Hothtrooper44_ArmorCompilation.esp

From Immersive Armors' Posts section:
maelstrom09 0 kudos 17 posts
what is Hothtrooper44 Armor Ecksstra .esp? is it a high texture replacer?
what should be loaded first Hothtrooper44 ArmorCompilation or Hothtrooper44_Armor Ecksstra?
posted @ 5:52, 28 Nov 2015

Eckss 191 kudos 1724 posts
It's not a replacer. It's necessary because IA has more assets than will fit into 1 .bsa file.
Hothtrooper44 Armor Ecksstra .esp activates more than half of the textures in IA and should be loaded before Hothtrooper44 ArmorCompilation.esp.
posted @ 7:18, 28 Nov 2015

Same applies for SSE
(Eckss is co-developer of Immersive Armors (hence the ECTSStra), so as to placement of IA components in relation to each other, Eckss' statement overrules LOOT - or anyone else, for that matter.)

Now, how to change it so that LOOT places Hothtrooper44_ArmorCompilation.esp after Hothtrooper44_Armor_Ecksstra.esp

1. Open LOOT. When LOOT loads, you will see a list of your mods in the left hand pane.
2. Locate Hothtrooper44_ArmorCompilation.esp
3. Double click (left mouse button) on Hothtrooper44_ArmorCompilation.esp
4. In LOOT's right hand pane, you will see a light blue panel open up; it will look something like this:

Main...Load After...Requirements...Incompatibilities...Messages (... 4 other items...)

5. Click on Load After (It will now display: File Name ...Display Name ...Condition - and, in the line immediately below, there will be a plus sign: + ).
6. Now, in the left hand pane again, locate Hothtrooper44_Armor_Ecksstra.esp
7. Using the left hand mouse button, click on Hothtrooper44_Armor_Ecksstra.esp, and, while holding down the left hand mouse button, drag Hothtrooper44_Armor_Ecksstra.esp to the right hand pane where it says Filename - a small + sign will appear. (steps 7 & 8 = Drag and Drop)
8. Release the left mouse button. Hothtrooper44_Armor_Ecksstra.esp will now appear directly under where it says Filename in the right hand panel.
9. Click on the Blue indicator immediately to the left of the red X in the light blue panel (when you hover over it, it should say Save Metadata in white print on a grey rectangle.
10. The information is now saved by LOOT, and whenever you sort your load order using LOOT, it will correctly place the Immersive Armor .esps in relation to each other.
11. Sort your load order with LOOT.
12. Hothtrooper44_ArmorCompilation.esp should now appear after Hothtrooper44_Armor_Ecksstra.esp in your load order.
13. Click Apply.
14. All done - close LOOT.
A CTD maybe caused by a number of issues. The following guides may be of use in solving it:

If the above do not work, it is possible that it could be a memory issue, and you may need more that just the SKSE memory fix; or, if you use an ENB, it could be related to that. In these cases, see:
From Arthmoor:
"3. There is no such thing as a clean save. It does not matter who tells you there is, it doesn't exist in Skyrim. You cannot remove any mod, not even the patch, without there being some data that's been permanently changed. Doing this repeatedly WILL damage your save and WILL eventually lead to it becoming corrupt and unusable. Bethesda's own developers have confirmed the only way to properly remove a mod is to load a save made BEFORE that mod was introduced into the game. If you started a new game with 10 mods installed, you're going to be stuck with those 10 forever."

Unofficial Skyrim Legendary Edition Patch by Unofficial Patch Project Team -
Posts section, second stickied post
posted @ 2:08, 8 Feb 2016 , stickied at 2:08, 8 Feb 2016

and Ilja:
"You can't remove mods from ongoing game. Skyrim bakes script data to save file. There is no such thing as a clean save, when mod is removed. "Clean save" is for mod updates only. This includes work done with Save Script Cleaner. That tool cleans obsolete entries and orphaned scripts from the game, but script data will remain in the save file, causing Papryus to constantly check it and creating errors.

If you removed scripted mods from ongoing game, then you will have to start a new game." - Ilja

"You can't uninstall most mods from ongoing game. Skyrim bakes script data to save files and unisntalling the mod does not remove it. It only causes errors in Papyrus scripting system.

Even if mod does not use any scripts, it's changes would need to be subjects of Skyrim vanilla respawn/refresh system." - Ilja

Your options are:
1) continue with the mod in place (NOT an option if the mod is actively breaking or bugging the game)
2) load a save made before the removed mod was installed
3) start a new game

Pure mesh/texture replacment mods are safe to remove. So are mods using vanilla assets and vanilla spawns.
Setting uGrid values higher than 5 will potentially break your game (5 is the default setting).

"When you raise your uGrids above 5 you aren't just making your game render things further out, you are making your game process EVERYTHING further out, including scripts and quests. This has a huge impact on your engines stability, and it breaks certain quests which aren't meant to activate that soon and end up bugging out.
Stable uGridsToLoad has a memory corruption issue which puts you at a huge risk for CTDs, broken scripting, rendering bugs and other instability. It is not concidered stable to use. This issue was confirmed by the author of the mod" - from post #9 by Nazenn:


"One thing more, if you have changed your Ugrids you cant change it back to 5. You are stuck whit it where you have set it.
Unless you start one new game." - from post #23 by Uncle64[Swe]:

Read whole thread for detailed discussion:

Examples of problems:

In addition: do not use uGrids to load - See:
Masterlist : Dangerous, Outdated and Superseded Mods by Nazenn

"Dangerous - Game breaking and highly unstable mods
This is the highest risk category that a mod can be placed into. For a mod to be classified as a dangerous mod it must cause repeated, irreparable damage to a save game. Mods that cause this much instability cannot be safely removed or the save file fixed by any method and as such troubleshooting cannot be provided for load orders that include these files. Mods placed here should not be relied upon for any sort of game stability either in the short or long term, although they may have varying effects noticeable in game.


Stable uGridsToLoad - Rating: Two (2) - Very unstable mostly due to lack of knowledge of good modding practices
Last version checked: 1.0
After this mod was released, the author was informed that a memory allocation issue inside the mods code was causing problems with memory allocation, and issue that was rediscovered recently. This was revealed to be an issue where the mod is calling the wrong memory functions which eventually results in memory corruption. Memory corruption is an issue that is considered very high risk however the effects are not well known for Skyrim due to the fact that this is an issue that originates from proper software code and is not Skyrim specific. Potential effects based on the way that this issue can affect other programs are poor performance, various glitches to systems within Skyrim's engine and even crash to desktops. Overall this should be considered a high risk to the games overall stability.
There is no direct replacement for this mod. People looking for better long distance appearance in their game should not touch uGrids settings in their ini files due to overall stability concerns anyway. The recommended solution for this is to use DynDOLOD instead. "
"Console is a debug tool. It does not pass event and AI scripts, or undo scripts that have been already been ran. I have stressed several times that using resurrect is among those commands that you should never use in Skyrim.

If the character you resurrected was dead, then using the command does not undo death scripts that have already been ran. Game AI gets confused and in 99% of cases you will just have a no-good character wandering around. In worse cases, death scritps will have run other scripts and suddenly "alive" character starts to cause conflicts in the game.

If the character you "resurrected" is alive (and in this case a quest character), then scripts affecting to this character now has double targets, messing up the game AI royally.

Load a save from before using unsafe console command. Do not try to undo it in any other way, because Skyrim stores script data to save files and there is absolutely no way to clean them 100% from them. Even Bethesda didn't manage to do so." - Ilja

"If you don't know what you're doing, using console commands can cause your game to malfunction! Executing the wrong command can cause your game to stop working normally; furthermore, you may not become aware of such malfunctions right away, and you may not be able to trace their cause. They can cause problems like making quests impossible to complete, altering your game's display, all kinds of game behaviors, your ability to play your character, and your ability to play the game at all. Solutions are not always easy, and may involve losing saved games or reinstalling your game.
Create a permanent saved game before using the console. (This mitigates only some kinds of risks.) If you need to use the console to fix a glitch, try to use the least powerful command possible." cited by cfs111 -
Mini tutorial on the console here;
General Discussion and Tutorial Pages

Player.placeatme and Resurrect
Two commands that should never be used on unique NPCs.

"...the command player.placeatme <BaseID> will create a new copy of an object and place it at the player's position. This is fine with most items or generic creatures.With unique NPCs however, a second copy will usually cause problems with quests and such. In that case, one could move the NPC to the player with the command sequence:
prid <RefID>
moveto player
For most items, creating extra copies does no harm, so player.additem <BaseID> <quantity> can be used to add the desired quantity of items to the player's inventory. Quest-specific items, however, will suffer from the same problems as unique NPCs, since the quest will often be tied to specific RefIDs for objects, not their BaseIDs. Also, RefIDs can only be used if the object in question is loaded into memory; visiting the cell of the object can assure this. See the console article for further commands and uses of form IDs for other types of things."

Resurrecting Named Characters
"You should never resurrect any named characters in Skryim. Game runs death scripts for each of them. Using resurrect command does not undo these scripts and there is no known way to reverse them.

Resurrecting character that has death script records in save file usually ends up badly. In best case scenario you get a useless NPC that is not tied to any quest and is cut out of the progress. In worse case scenario you get NPC that is comes constantly more and more bugged, tangling game scripts even further and ends up making a real mess out of your game.

Resurrect is among commands that has been classed as dangerous and should not be used in a game. It is a developer test command and should be treated as such. If you already made a mistake of using that command, then load a save before that." - Ilja

See also:

"Recycleactor does refresh the character, but as far as I know, it does not undo death scripts.

I can't see why it would, seeing that it basically just restores the character. That character may be "refreshed", but death scripts and stand-in triggers should still be active." - Ilja

Explanation of Resurrect function:
by Ilja
"I think it is best to explain resurrect a bit further. I might actually make a full post about it.

Biggest risks come down to scenes. Each character participating scenes has an alias. These aliases are required to be filled by Papyrus, when the scene starts. Here are few common cases about how the use of console can affect to them.

Scene starts, but character is dead. There is no character to fill alias. If script does not intercept the event, then Papyrus will try to fill the alias - over and over again. This will reserve all available Papyrus time, often preventing other scripts from running.

In this case locating the missing character, resurrecting them and bringing them to scene to fill alias can be helpful. Of course, you would need to have a log and know what you are looking at, including how to get rid of such character later, so that using console would not break the game even further.

Second scenario. Scene starts. Game considers one of the participants dead, but player has actually resurrected that character. Scripts may bring this character in to scene and attempts to fill alias. This may or may not work, depending on scene and other scripts (including mod scripts) running around.

Again, Papyrus will get stuck, trying to figure out which alias it needs to fill. Solution sounds easy: load a previous save and kill the character.

Reality is not that easy. Scene may have been initialized several saves ago, if you have been running around the area. Script to cut it may fail, because it is going against Bethesda's design, while trying to fill alias for a present "dead" character. Again: you might have to start making logs and trying to figure out when and where the scene got stuck - if you even figure out what is going on.

The more characters you have resurrected, the more changes the game has to use at some point initialize a scene. This also means that game has even more changes to fail filling aliases and completing the scene.

Civil War is a PITA in this. There are plenty of scenes and civilian characters are prompted to locations around times. This means that game will try to fill more than few aliases at the same time. Each character that is affected - and not necessarily even a quest giver or merchant - will be positioned.

For example: Battle of Whiterun, where some characters you have moved away from the city through HF DLC (or mods) will be there to get involved. If game finds such characters, then it will bring them in to scenes. Them being "dead" may still cause game to attempt fill aliases and cause Papyrus exceed it's limits.

I really do not recommend resurrecting characters, just because you can. If you do resurrect a character, then do that only for 1st scenario (if you know what you are doing) and then get rid of them for good. Otherwise: find and load an earlier save, where scene is not stuck."
To clean the Master files, see:

Cleaning the Official Master ESMs[]


Why Clean the Master Files?

From Arthmoor - Why Clean the Master Files[] :
"Firstly because the masters have entries that are identical to the same records in Skyrim.esm or other DLC esms'. They exist because Bethesda may have looked at something in the CK and an unneeded entry was auto included in the plugin even though the item was not altered in any way. The Official Creation Kits are notoriously buggy and randomly create dirty / wild edits, often when the author of the plugin is completely unaware. Wherever that plugin is placed in your load order its records overwrite all the conflicting records from plugins loaded before it ( the rule of one ) resetting the settings back to the values contained in the Official Bethesda DLC. It won't cause crashes, it just changes the values of plugins loaded before it. Which can alter mods that you have for Weapon Damage, Armor, Lighting, Food Effects and so on. The masters are very early in your load order but there is potential for a mod to be made as a fake.esm, and placed among them, and so ITMs in a later loading master may cause problems for that mods esm. Chance is remote that a master will affect another master, and this procedure is best used on all of your mods plugins, but cleaning everything of ITMs ( Identical to Master records ) causes no harm, is more optimal giving the game less to process in your load order, and so it is best to get rid of these completely unnecessary dirty edits.

The Second reason is that Bethesda chose to delete some things that are in the Official DLC. Any mods loaded with references to deleted records from the Official Bethesda DLC will cause your game to crash. This problem particularly affects older mods ( especially mods that were made before newer official patches were released, with more deleted references the old mod did not anticipate - It will also become problematic for the Skyrim Special Edition community where old Original Skyrim mods are being converted to SSE, and Bethesda have deleted even more records from the plugins before they released the newer plugins for that version of the game). xEdit can restore and properly assign values to these records that will disable them and still allow mods to access them. This is done using the "Undelete and Disable References" option."

From Arthmoor - Manual Cleaning Skyrim and Skyrim SE Master files[] :
"The most obvious benefit is that if someone is not using the unofficial patch, Dawnguard has dirty edits that break house upgrades for Hearthfire. Failing to run the ITM removal will result in people complaining they can't buy Breezehome upgrades and that the steward is stealing their money. So there's no truth to the claim that ITMs in official DLC are harmless.

This also applies with SSE btw, since those dirty edits remained when Bethesda updated. So that problem WILL still exist for anyone who doesn't clean them and isn't using the USSEP.

UDRs are well known to cause CTDs whether the references are in scripts or not so that advice clearly still holds."
(For in depth discussion, read the rest of the thread)

This is a very common problem if you have had Enderal installed and then uninstalled/deleted it. To fix, (courtesy of velvetsanity):
"Go to Documents\My Games\Skyrim and delete Skyrim.ini, then start the game once using the vanilla launcher to recreate it. It's a common issue when switching back from enderal"