How to read my crash log Skyrim SE

[Guest]

I realize this must have been asked & covered a Trillion times, I did do a google search and didn't quite find what I was looking for.

Documents/My Games/Skyrim Special Edition/SKSE There is a crash log generated but I do not know how to read it or fix my issue.

Any help much appreciated. 

[traison]

Generally crash logs aren't meant for the average player. To understand them, you'd have to know what a compiler is and understand the basics of the x86/x84-64 assembly language. That doesn't mean you couldn't gain some information from them regardless, just need to know where to look and get good at guessing the things you do not understand:

 

The faulting offset

 

If the error code is not obvious, look it up in the official documentation. Do not assume that just because you got error code 5 (access denied) that you need to run Skyrim with elevated privileges or anything like that - this is the world of assembly, you need to see everything from the CPU's perspective. Error code 5 is the result of an instruction that tried to access memory it wasn't allowed access to. Usually something tried to read from or write to a null pointer - the kernel (or perhaps some other component, not sure?) doesn't allow you to do that: mov [rax],0x10 when rax is 0x0 is such a case.

 

Callstack

 

The callstack is read from top to bottom, where the topmost entry is usually the offset where the crash occured. The other entries below it are return addresses from CALL instructions. Typically the higher up something is, the more likely it is to be involved in the crash. The memory offsets and instructions probably won't make sense, but sometimes you get lucky and see a 3rd party module as entry #2 or #3 and at that point its kind of obvious what should be done next - disable it and test again.

 

Registers

 

The registers is a snapshot of the CPU state as it was when the crash occured. The reason it crashed is in the registers. If you're lucky you may find something readable here like a module name or a string. Like with the stack however, not all registers are involved in the crash. Some registers may contain data that was recently used, some may contain data that would have been used in the future. The answer to which registers are related is in the assembly code at RIP - the faulting offset in a crash log.

 

Stack

 

The stack is like your workbench, it may contain things that were, things that are and things that will be. Someone experienced in assembly can rebuild the callstack from it, if they know the calling conventions used. Usually the same idea applies here as for the callstack: the higher up something is, the more likely it is that its involved in the crash.

 

Caveats

 

Since the crash logger in .Net Script Framwork is somewhat popular I suppose I should mention this as well: If the callstack does not end in entries from kernel32 and ntdll, assume the callstack was read incorrectly and assume it is invalid. In usermode code there is to my knowledge no other way to create threads than through the api provided by these dlls. The .Net Script Framework occasionally produces these logs, and it makes figuring things out considerably more difficult.

 

The crash loggers we have are, as far as I know, handlers for unhandled exceptions. It is possible for an exception to occur and for one of the default handlers to handle it. The game itself has one, and the Steam dll has another. It is also possible for a handled exception to result in the application terminating - this is going to look identical to a CTD, except that is technically very different. Catching these handled exceptions requires the use of something more intrusive, like a debugger capable of intercepting exceptions.

 

Speaking of exception handlers, if you see a VC++ dll high up in the callstack (or maybe even as the faulting offset), what you're seeing is most likely not a bug in VC++ but rather some fancy exception handler. At this point you need to look further down the callstack to find the actual problem. This then most likely also means that the registers and stack were modified by the exception handling function(s).

 

If you see a VC++ dll or any other system dll high up in the callstack, do not start by assuming you found a rare bug but rather inspect the following callstack entry. Most likely what occured was that some previous code passed erroneous arguments to a (in the case of vc++) standard library function and then (perhaps deliberately) neglected to catch exceptions.

 

And speaking of system dlls in general; if a crash occurs in a system dll such as a directx dll, again do not assume you've found a rare bug, but rather think smart and consider what kind of mods you have that alter the way rendering functions. ENB for instance uses a proxy library that replaces d3d11.dll, and the entire idea of ENB is pretty much to alter the way DX works - changing shaders and fixing things broken in Skyrim's rendering.

 

Any dll you load (through SKSE or otherwise) has the potential to alter the bytecode of any other image currently loaded or loaded in the future. If you get a crash in some offset at SkyrimSE.exe, it does not necessarily mean the issue is in SkyrimSE.exe. It could for instance mean that SSE Engine Fixes (just an example) made a bytecode edit at that offset to fix something, and you have something else that doesn't agree with that fix - the only way to solve this mess is with a debugger, or trial-n-error.

 

Edit: I suppose this list could go on forever, but probably the more important thing here is that this is where experience will fill the gaps. If you're serious about getting into this; read more logs, fiddle with disassemblers and debuggers. Start with something easy like notepad, as Skyrim has DRM and debugger traps - something probably don't want to run into on your first adventures.

 

Also, a disclaimer: I'm not an expert on any of this. Sure, I've dabbled with assembly for probably 10 years now and done all kinds of remarkable things like temporarily deleted my OS and fixed a game bug where the solution confused the developers. I'm what you might call a dangerous amateur - someone that knows just enough to do a lot of damage.

Edited March 31 by traison
Some corrections 6 months later.

[Guest]

3 hours ago, traison said:

aren't meant for the average player.

Thanks, that explanation made my eyes cross!     

I assumed one could use the info to see what is causing the crashes, just figuring out which tool to read it so that issue would be apparent and would let me know which mod/mods were causing it. 

[traison]

You can go blind into a crash log as well, as in, open notepad and pick out everything from the crash log that you can read. File names, strings, game objects like form ids and actor names. Then basically try everything (Edit: *). You just need to keep in mind that not everything you've picked out will be relevant. If there was one thing you should pick out from my previous post its the order of relevance of things, such as the topmost entry of the callstack being the most relevant, and the registers (in most cases) being a direct pointer to where the problem is. You can get through half the crash logs on LL with this information alone (Edit again: **).

 

* By try everything I mean inspect game objects in xEdit, undo edits made by mods, solve conflicts if there are any. Look up file names in your mod manager, change or remove the files - if a sword is causing issues, take the vanilla iron sword mesh from the BSA file, rename it and use it instead. Once you poke something that changes the way the error behaves/looks, you most likely know where the problem is and you're already close to the solution.

 

** This is literally what I do when someone posts a crash log, unless there is immediately something odd about it.  That's why I sometimes post "If this doesn't solve your problem, let me know and I'll have a proper look at the log."

Edited December 31, 2023 by traison

[traison]

I'll post this too in case it makes things easier; this is about as easy as reading a crash log gets. Using the crash log that @adude1 just posted (sans the stack etc.):

Spoiler

Unhandled native exception occurred at 0x7FFC5D5AF1F9 (SchlongsOfSkyrim.dll+F1F9) on thread 17512!

FrameworkName: NetScriptFramework
FrameworkVersion: 15
FrameworkArchitecture: x64
GameLibrary: SkyrimSE
GameLibraryVersion: 18
ApplicationName: SkyrimSE.exe
ApplicationVersion: 1.5.97.0
VersionInfo: Successfully loaded
Time: 31 Dec 2023 15:54:47.576

Possible relevant objects (3)
{
  [  58]    TESEffectShader(FormId: 0004FA1D, File: `Skyrim.esm`)
  [ 142]    TESNPC(Name: `Bandit Highwayman Warrior`, FormId: FF007F85)
  [ 142]    Character(FormId: FF00867C, BaseForm: TESNPC(Name: `Bandit Highwayman Warrior`, FormId: FF007F85))
}

Probable callstack
{
  [0]   0x7FFC5D5AF1F9     (SchlongsOfSkyrim.dll+F1F9)    
  [1]   0x85                                              
  [2]   0x2                                               
  [3]   0x217F9571918                                     
  [4]   0x1                                               
  [5]   0x7FF764997E80     (SkyrimSE.exe+2F27E80)         
  [6]   0x5BA5EFEA20                                      
  [7]   0x181D001                                         
  [8]   0x239172                                          
  [9]   0x6666666666666667                                
  [10]  0x7FFCB3DF68BB     (skse64_1_5_97.dll+868BB)      
  [11]  0x239166                                          
  [12]  0x217F95718E8                                     
  [13]  0x5BA5EFEBB0                                      
  [14]  0x238E27                                          
  [15]  0x239172                                          
  [16]  0x145534B53                                       
  [17]  0x105061002000140                                 
  [18]  0x5B0000000F                                      
  [19]  0x9033E4D6828E                                    
  [20]  0x5BA5EFEBB0                                      
  [21]  0x5BA5EFEDF0                                      
  [22]  0x7FFCB3D7F734     (skse64_1_5_97.dll+F734)       
  [23]  0x1                                               
  [24]  0x5                                               
  [25]  0x5BA5EFEDF0                                      
  [26]  0x8                                               
  [27]  0x5B                                              
  [28]  0x7FF76239F21B     (SkyrimSE.exe+92F21B)          SkyrimVM::unk_92F030+1EB
  [29]  0x7FF76239B822     (SkyrimSE.exe+92B822)          SkyrimVM::unk_92B800+22
  [30]  0x7FF761FF0FCE     (SkyrimSE.exe+580FCE)          anonymous_namespace::Win32FileType::unk_580EE0+EE
  [31]  0x7FF761FEDADE     (SkyrimSE.exe+57DADE)          unk_57D1A0+93E
  [32]  0x7FFCB3D8051B     (skse64_1_5_97.dll+1051B)      
  [33]  0x218FF00867C                                     
  [34]  0x2197B1313F0                                     
  [35]  0x21945187AF0                                     
  [36]  0x21945187040                                     
  [37]  0x5BA5EFF390                                      
  [38]  0x7FFCCE120E8D     (clr.dll+190E8D)               
  [39]  0x7FF761FFB0A1     (SkyrimSE.exe+58B0A1)          BGSSaveLoadManager::unk_58AE30+271
  [40]  0x7FF761FF9D20     (SkyrimSE.exe+589D20)          BGSSaveLoadManager::unk_589A60+2C0
  [41]  0x7FFCB3D806E8     (skse64_1_5_97.dll+106E8)      
  [42]  0x217F959A700                                     
  [43]  0x2                                               
  [44]  0x21945193730                                     
  [45]  0x21945187040                                     
}

Registers
{
  AX:       0x0                (NULL)
  BX:       0x85               (u8):[133]
  CX:       0xFFFFFFFA         (u32):[4294967290]
  DX:       0x7FF763301610     (SkyrimSE.exe+1891610) (void*)
  SI:       0x1                (u8):[1]
  DI:       0x0                (NULL)
  BP:       0x2                (u8):[2]
  SP:       0x5BA5EFE9D0       (char*) "?"
  IP:       0x7FFC5D5AF1F9     (SchlongsOfSkyrim.dll+F1F9) (void*)
  R8:       0x8                (u8):[8]
  R9:       0x0                (NULL)
  R10:      0x7FF761A70000     (SkyrimSE.exe+0) (char*) "MZ?"
  R11:      0x5BA5EFE960       (SkyrimVM**)
  R12:      0x30D17            (u32):[199959]
  R13:      0x0                (NULL)
  R14:      0x1E153C0          (u32):[31544256]
  R15:      0x7FF764997E80     (SkyrimSE.exe+2F27E80) (SkyrimVM*)
  Flags:    0x10246           
  XMM0:     (double)5.2462840440208E-315 / (float)0.7917709
  XMM1:     (double)6.00955839238212E-315 / (float)262144
  XMM2:     (double)7.91603898582748E-315 / (float)1.844674E+19
  XMM3:     (double)0 / (float)0
  XMM4:     (double)0 / (float)0
  XMM5:     (double)0 / (float)0
  XMM6:     (double)0 / (float)0
  XMM7:     (double)0 / (float)0
  XMM8:     (double)0 / (float)0
  XMM9:     (double)0 / (float)0
  XMM10:    (double)0 / (float)0
  XMM11:    (double)0 / (float)0
  XMM12:    (double)0 / (float)0
  XMM13:    (double)0 / (float)0
  XMM14:    (double)0 / (float)0
  XMM15:    (double)0 / (float)0
}

 

Q: First things first, what's the problem description?

A: User regenerated DynDOLOD.

 

Q: Where's the faulting offset?

A: SchlongsOfSkyrim.dll+F1F9. My experience tells me SOS doesn't like its load order changing, and DynDOLOD contains a plugin. So at this point it's already somewhat safe to say its a common "bug" in SOS, but lets continue regardless.

 

Q: Is the callstack ok?

A: No, it does not end in the correct entries (ntdll and kernel32) so most likely not. An experienced user may then work from the top down to try to identify where the error occured. I'd say entry #1 because 0x85 is not a valid return address. We basically get no new reliable information from the callstack.

 

Edit:

Q: How do I know the return address (0x85) is not valid?

A: First of all, the value is too low, typically images are not loaded this low. But if we assume the reader does not know that, another giveaway is that the address does not reside within any known module. If it was within a known module it would be listed as: SkyrimSE.exe+0x85. While this is not guaranteed to be the case everywhere, an image can allocate memory outside of any known block but for the sake of simplicity, just assume this doesn't happen. You'd need a debugger to inspect and validate addresses like this.

 

Q: Registers

A: IP (short for RIP in x64 and EIP in x86) (i.e. the Instruction Pointer or in the case of crash logs: the faulting offset) points to SOS, we already knew this. R11 contains a pointer to a pointer to SkyrimVM. Typically the word "VM" (maybe short for virtual machine?) is assocated with the Papyrus Engine. Plan B for this issue thus could be to inspect the stack for anything scripting related (game objects containing scripts, or maybe even script names). R15, another pointer to SkyrimVM.

Edited December 31, 2023 by traison