Help Catalog & Troubleshooting

Crash Logs

Help catalog made using the wonderfull help resources done by Discrepancy and Corrupt Bliss


You will find your crash logs in [YOUR_DRIVE]:Nolvus\Instances\Nolvus Ascension\MODS\overwrite\NetScriptFramework\Crash


NetScriptFramework crash logs can be found in Nolvus\Instances\Nolvus Ascension\MODS\overwrite\NetScriptFramework\Crash

Interpreting Skyrim callstacks is very much more of an art than a science.

First thing to understand is what they are. Every single piece of software on your computer is built on functions (things) calling (invoking) other functions. The call stack is how the computer keeps track of who called who, and also at what point they were at when it happened. That way when the second function is finished, the first one can resume where it left off.

That also means they tend to go from generic to specific: generic thing needs to do something, it calls a function that does something a little more specific, which calls a function that does something even more specific, and so on until you get into The Really Fun Stuff (which I promise you is not actually fun) where things actually happen.

But because that's not complicated enough as it is, the thing that is The Call Stack® also tends to include relevant data that gets passed from one function to another. Goes something like "Hey, if we've got this big chunk of memory where we can keep track of functions, why not also use it to help shuffle some data around too?"

What .NET Script Framework can do is (1) tell Windows that it should pop in if something goes screwy, (2) when that happens, peek at the call stack and note down everything inside it, then (3) try to figure out whether each item in it is a function or a piece of data. That (3) is a bit tricky because there's no actual distinction inside the stack of what is what so .NETSF can only make an educated guess (thus the "Probable callstack").

When you look at call stack, there are three basic types of things you'll want to keep an eye out for (examples pulled from some Google searches):

1. The Functions

(SkyrimSE.exe+26B173) TESObjectCELL::unk_26B160+13

Judging by the name, this one operates on cells.

(SkyrimSE.exe+132BEA) Mutex::Lock1_132BD0+1A

A mutex is something that tries to make sure a certain thing is only accessed by one thing of code at a time - so they don't screw each other up. Mutexes are common.

(SkyrimSE.exe+C58790) NiNode::UpdateSelectedDownwardPass_C58660+130

1. The Files


Most stuff happens in SkyrimSE.exe.


This one is HDT-SMP, a physics extension.


Obviously SSE Engine Fixes. Due to the nature of that mod, seeing it in a call stack doesn't necessarily mean it is related to the crash, but rather that it hooked itself into some part of the engine that otherwise would have been a regular SkyrimSE.exe+ABCDEF function.


Most everything else you'll see that isn't a mod will be a system file or library. You can safely assume that these are not buggy, however it's quite possible that a calling function screwed up.

3. The Data

These are the most interesting ones.

(Character*) -> (FormId: 00063D80, File: \Skyrim.esm`, BaseForm: TESNPC(Name: `Bandit Trollman`, FormId: FF000CB8))

Pretty much self-explanatory. Remember that form IDs starting with FF are temporary ones created by the game, but the rest (like 00063D80) you can look up in xEdit.

(BSFadeNode) -> (Name: `GiantCampfire01Burning`)

Clearly something to do with a giant campfire.

0x1EB80C2A010(char) "7=?Enif"

Who knows? Strings like this are sometimes useful, sometimes not. Crashes involving meshes and textures often have a filename somewhere in the stack, and that *alone makes .NETSF totally worth using.

Remember the whole "generic function calls specific function calls more specific function"? That means that the top of the call stack (SP+0, with the most recent stuff) is going to be much more directly related to the problem than something further down in the list. But that doesn't necessarily mean it's responsible for the problem - it's simply closer to where the problem was detected.

And that last point bears repeating: the call stack and crash dump tells you where the problem was detected. The actual source of the problem may or may not be reflected elsewhere in the dump. It's like homicide: yeah, the one dude shot the other dude in the face, but that only happened because something earlier lead up to it.

So without specific knowledge of what you're looking at (something very, very few people have), troubleshooting is mostly a matter of gathering clues together to get a lead of where the issue might be. Possibly using clues from multiple crash dumps.”

Formatted. All credit to tasairis. Original post and comment can be found on Reddit


STRINGS error occurs from having unique characters in the skyrim.ini’s sLanguage=ENGLISH line.

.STRINGS is a quick and easy check! As @Foxy has pointed out, the log's relevant objects are always the same.

Possible relevant objects (2)

  • [ 46] BGSStoryManagerBranchNode(FormId: 0000005B)
  • [ 188] PlayerCharacter(FormId: 00000014, BaseForm: null)

After identifying the probable call stack as a potential .STRINGS crash, scroll down to Registers and look for R14 to confirm.

  • R14: 0x7FF65C471FE0 (SkyrimSE.exe+1541FE0) (char*) ".STRINGS"


  • Remove the unique caracter in your skyrim.ini’s sLanguage=ENGLISH line


Easy to identify on the first line via the offset:

  • Unhandled native exception occurred at 0x7FF60DB5DDDA (SkyrimSE.exe+D6DDDA) on thread 13752!

And within the probable call stack

  • [0] 0x7FF60DB5DDDA (SkyrimSE.exe+D6DDDA) unk_D6DD70+6A

Known Causes

  • There are two separate known causes, and the difference cannot be determined just by looking at the log as they often contain the same elements
  • Cause 1: D6DDDA most often occurs when either RAM or VRAM have been exceeded (system not strong enough to run the installed Nolvus variant)
  • Cause 2: In rare cases D6DDDA can occur due to broken/corrupt meshes (.nif) or textures (.dds)


  • D6DDDA can occur even with the requisite RAM and VRAM, though less common. If the individual meets the minimum PC specs for their install preset, advise them to shutdown PC, wait 30 seconds, then try again. This will clear the RAM cache which might be full depending on if they just installed or other things.
  • Set your Windows Pagefile Size as explained here
  • If the above does not resolve the error and the individual meets the requirements for their install preset, check the log for loose file streams under Stack
  • (BSResource::anonymous_namespace::LooseFileStream*)
  • (char*) "textures\dbm resources\new museum\"
  • LooseFileStreams and their referenced textures/meshes may not always be reliable even if referenced in the Possible relevant objects and Probable callstack. In some cases simply reinstalling the mod the bad mesh is from may resolve the issue, otherwise a reinstall should be advised.


Shadow Scene Node crash as explained by Discrepancy:

Additional Note: They are almost never consistently reproducible (meaning the crash can repeat, but you can’t always get it to repeat by doing the exact same steps)

  • We can identify 12FDD00 in the offset.
  • Unhandled native exception occurred at 0x7FF7BAC8DD00 (SkyrimSE.exe+12FDD00) on thread 38084!
  • Under Possible relevant objects we can find each of Discrepancy's points.

Known Causes

  • The direct cause of Shadow Scene Node crashes is unknown.


  • The best help we can provide is to recommend loading an earlier save, travelling to a different cell from the original crash, and play for a few days in game away from the area.


Massive thanks to @Discrepancy for providing a solution to this crash. The cause of JContainers is unconfirmed, but may have to do with corrupt C++ Redistributables or .NET Framework (my best guess at the very least).

Previously only a windows reinstall could fix completely, otherwise those experiencing JContainer crashes had to disable their custom skill framework and go to bed mods.

All JContainer crash logs will have (JContainers64.dll+10AE45) in the header, Probable callstack, and referenced in the Registers.

Known Causes

  • Something within Windows, though its exact source is unconfirmed.


  • Link the individual to Discrepancy's patch settings hub and have them add the mod into MO2. Be sure that the patch is placed after the custom skills framework, so as to overwrite the necessary files.


Save Bloat can occur in a variety of different ways. Combat saving, saving on a horse, saving with scripts running, using autosaves and quicksaves, to name a few examples. Identifying save bloat can be difficult sometimes, but most often you'll see a large amount of Possible relevant objects, a massive Probable callstack, and a slew of (NULL) references in the Stack. This comes from unresolved scripts, missing masters, etc.

The absolute best way to completely avoid save bloat issues is to follow @Jerilith's Safe Save guide.

As Jerilith has mentioned, dying a few times in a single session does not guarantee a broken save, but it quickly compounds upon itself. Best practice is to load an older save in a different cell, quit to menu, or quit to desktop after repeated deaths.

Known Causes

  • Combat saving
  • Autosave and quicksaves
  • Saving while scripts are running
  • Reloading after death


When determining save bloat some of these questions might be useful

  • Are you able to reload the save you crashed on?
  • Can you load a previous save?
  • Have crashes become more consistent the longer you play?
  • Have you added or removed *any* mods during your playthrough?
  • Did you turn on and use autosaves?

In most cases after excessive save bloat it's time to start over. However, recommending Fallrimtools may not be a bad solution if the individual has been adding/removing/disabling mods throughout their playthrough.

Note: F5 in Nolvus is not a quicksave, but has been changed to function as a normal save. F5 roughly every 10 minutes won't break things. Save count also does not contribute substantially to save bloat as long as one adheres to proper saving practices.


Shadowrend is part of the AE CC content. As I understand it is an axe or sword that can cause crashes. Shadowrend has a wide reach, and I believe you don't even need to be in possession (fact check?) for it to cause occasional crashes. No known absolute fix for it at the moment.

  • Specifically looking for ccbgssse018-shadowrend.esl within the Possible relevant objects. There may be other items contained within the list, but generally shadowrend tends to trump.

Known Causes

  • Shadowrend weapon/CC addition.


  • As with Shadow Scene Node crashes, the best help we can provide is to recommend loading an earlier save, travelling to a different cell from the original crash, and play for a few days in game away from the area.
  • This avoids the shadowrend, and hopefully allows the issue to resolve itself. If a player manages to load their same shadowrend save and continue playing on it there is a chance the issue can compound upon itself, causing more frequent crashes and issues.


Load Order (LO) can cause crashing in a variety of different ways. Misplacing mods can cause overwrites, conflicts, or load mods incorrectly.

This has happened on a few occasions after a fresh install. Incorrect LO in general will cause crashes, but an alphabetized order will definitely break things.

Known Causes

  • Not adjusting plugin order after adding mods
  • Placing mods incorrectly
  • Running LOOT without setting up the rules


  • Apply order via Dashboard. !applyorder can be entered in discord for a quick image help.
  • Adjust order according the the recommendations of the mod page


This crash does not have a consistent offset (SkyrimSE.exe+######) but there are usually consistent.

  • TESNPC(Name: `Wraith of Sithis`, FormId: FE2EC80B, File: `mihailmmasithis.esp`)
  • Actor(FormId: FF0028A1, BaseForm: TESNPC(Name: `Wraith of Sithis`, FormId: FE2EC80B, File: `mihailmmasithis.esp`))

Basically look for mihailmmasithis.esp mentioned a few times anywhere within the log.

Known Causes

  • Using the Sithis Finger staff to summon your own Wraith of Sithis
  • Encountering a Wraith of Sithis or Gravelord that spawns within the game in locations such as Mara’s Temple and Soul Cairn
  • The root of the cause is related to an effect used by the Wraith that happens to be modified by the Odin spells mod.


  • The patch is available on the Discrepancy's patch settings hub. This patch can be installed mid-game, and always should not load after any of the flat maps. When installed, the plugin should be moved above FNIS.esp.


Skeleton crashes are non-repeatable one-offs that can occur. As @Jerilith has eloquently described it: “It’s essentially like Skyrim saying ‘oh fuck, the npc character has bones, time to break’”.

This crash does not have a consistent offset (SkyrimSE.exe+######) but there are usually consistent “Possible relevant objects” listed.

  • NiNode(Name: `NPC L UpperarmTwist1 [LUt1]`)
  • BSFadeNode(Name: `skeleton.nif`, Owner: `Character(FormId: 000EC185, File: `AnotherOakwood.esp <- Skyrim.esm`, BaseForm: TESNPC(Name: `Frostbite Spider`, FormId: FF003720))`)

Known Causes

  • Maybe (we are not sure) XP32 Maximum Skeleton and the bone structure it provides or a custom mod that overrides it.


  • Restart game.


A0D789 is related to the animation limit and can happen infrequently. Easy to identify in the initial offset

  • Unhandled native exception occurred at 0x7FF71A2ED789 (SkyrimSE.exe+A0D789) on thread 5988!

Known Causes

  • None confirmed; theories below
  • Possibly related to Animations and anim limit (fact check?)


  • Reload game and continue playing
  • Alternatively, install the A0D789 patch by kingeric1992 from here as a regular mod in Mod Organizer 2


Game crashes at startup

  • PDPerfPlugin.dll+F125

Known Causes

  • DLAA provided by the Skyrim upscaler mod is not compatible with RTX card. If you don't have a RTX NVIDIA card or an AMD card, you will crash
  • If you have an RTX card, it may come from a bad configuration in Windows or a driver issue.


Uncheck these 2 plugins (In mo2, left panel under 1.1 SKSE PLUGINS)

Then open MO2 and click on this

Set bUseTAA to 1 and click on Save


Game crashes at startup

  • the crash log should conatin usvfs_x64.dll

Known Causes

  • An antivirus (mostly weebroot or bitdefender) is blocking the mo2 file system


  • Disable your antivirus or create an excpetion for the entire Nolvus directoy
  • change your antivirus