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
Description
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
(SkyrimSE.exe+26B173)
Most stuff happens in SkyrimSE.exe.
(hdtSMP64.dll+454F)
This one is HDT-SMP, a physics extension.
(EngineFixes64.dll+769E4)
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.
(KERNEL32.DLL+17BD4)
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
Description
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)
After identifying the probable call stack as a potential .STRINGS crash, scroll down to Registers and look for R14 to confirm.
Troubleshooting
Description
Easy to identify on the first line via the offset:
And within the probable call stack
Known Causes
Troubleshooting
Description
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)
Known Causes
Troubleshooting
Description
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
Troubleshooting
Description
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
Troubleshooting
When determining save bloat some of these questions might be useful
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.
Description
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.
Known Causes
Troubleshooting
Description
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
Troubleshooting
Description
This crash does not have a consistent offset (SkyrimSE.exe+######) but there are usually consistent.
Basically look for mihailmmasithis.esp mentioned a few times anywhere within the log.
Known Causes
Troubleshooting
Description
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.
Known Causes
Troubleshooting
Description
A0D789 is related to the animation limit and can happen infrequently. Easy to identify in the initial offset
Known Causes
Troubleshooting
Description
Game crashes at startup
Known Causes
Troubleshooting
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
Description
Game crashes at startup
Known Causes
Troubleshooting