Need Help with Crash Log

[flutie]

2025-08-25-18-38-37.log.txt

Been reading several reddit posts on how to interpret the log file. It started with male chars using Himbo, textures and meshes morphing, kinda like a werewolf transformation from a bad B movie. Cheeks will puff out, suck in, was funny to watch though. I just need to be pointed in the right direction. Thanks

[traison]

Something is using ConsoleUtilSSE.dll to execute "smp reset". This has been posted several times before. Switch to the NG fork of ConsoleUtilSSE.

[flutie]

13 hours ago, traison said:

Something is using ConsoleUtilSSE.dll to execute "smp reset". This has been posted several times before. Switch to the NG fork of ConsoleUtilSSE.

I should have bet a line in Vegas that it would have been you to answer. Thank you for the help. Just out of curiosity, what part pointed to the problem? I want to get a basic understanding of your super hero powers to read that long log. Or point to a good tutorial

[traison]

Switch to a better crash logger, and reading them will become easier.

 

There's a short writeup about reading them here.

 

In this case it was previous experience that answered the question, but if we assume I didn't have that I would read it as follows:

 

Q: Where is the faulting offset?

A: SkyrimSE.exe+0CE9843. Offset is in SkyrimSE.exe which would require a debugger to inspect, so ignoring that for now.

 

Q: What was the assmebly code at the faulting offset?

A: "call qword ptr [rdi+10h]". It tried to dereference RDI+0x10. The RDI register at the time of the crash was 0x1C367926480. According to trainwreck this is a pointer to a Script object. The 0x10 offset from that was an invalid pointer, since we ended up trying to read memory we didn't have access to: EXCEPTION_ACCESS_VIOLATION

 

Q: What is the 2nd entry in the callstack? Search for it in the stack.

A: SkyrimSE.exe+033D8D9. Shows up at RSP+48.

 

Q: Anything interesting above RSP+48?

A: "smp reset"

 

Q: Anything interesting below RSP+48?

A: "EngineFixes.dll" and "FormCaching" whatever that is. "smp reset" and ConsoleUtilSSE.dll.

 

Q: Is ConsoleUtilSSE.dll in the callstack?

A: Yes.

 

Theory: ConsoleUtilSSE.dll was used to execute "smp reset", and since "smp reset" was in the stack above RSP+48 it's relatively safe to assume that something went wrong when executing or otherwise processing that request.

 

Q: Anything else further down in the stack?

A: BSScript::Internal::VirtualMachine*

 

Conclusion: A Papyrus script used ConsoleUtilSSE.dll to... <see theory above>

 

Other questions that may be interesting:

Spoiler

Q: What is the faulting offset?

A: The address where the exception occured. Same place where the (R)IP register was pointing.

 

Q: Why start with the 2nd entry in the callstack?

A: If you searched for the faulting offset, you noticed its first in the callstack. I personally think this is an error; it shouldn't be there. Callstack entries are the return addresses pushed onto the stack by the CALL instruction. The faulting offset was not created by a CALL instruction, nor is it even on the stack.

 

Q: Why start reading the stack from the point where the 2nd callstack entry is?

A: The stack itself can contain entries that are irrelevant to the problem. Assuming otherwise and always starting reading it from the top risks you reading irrelevant information. Typically you don't see these kinds of logs, but there's been a few here on LL that have started in the middle the stack where everything above was most likely old and only partially related.

 

Q: If the 2nd callstack entry is far down the stack, how do I know how far I should read above that?

A: If we assume you can't tell what is a return address from a CALL instruction, I would say read 5-10 lines. There is nothing special about return addresses in the stack, so in theory there is no way tell what is what without a debugger or knowledge of calling conventions used and the "function" called. Once you've read a hundered logs you might be able to eyeball-guess it.

 

Q: Why didn't I blame EngineFixes.dll for this, since it was in some way involved before the ConsoleUtilSSE.dll name came up?

A: I don't see what "smp reset" has to do with FormCaching. Removing or otherwise changing EngineFixes.dll would have been the next step. When the first idea doesn't work, simplify the stack and callstack. Remove things you can easily remove; if you're lucky, you accidentally remove the problem.

 

Q: Why not read further down the stack? Why not blame hdtSMP64.dll for this, as it clearly set this thing in motion?

A: Without previous experience this might be tricky one, especially since "smp reset" and hdtSMP64.dll look very much related, and they are. There's a few hints that would suggest SMP is not the problem though. Firstly, the callstack entry for hdtSMP64.dll appears to be in a function called onFrame. Secondly, why would SMP be executing console commands when it definitely has access to the function behind the console command, this would be a massive amount of overhead? Thirdly, ConsoleUtilSSE.dll is not a requirement of hdtSMP64.dll.

 

Q: Using all these instructions, wouldn't it lead the investigator to remove hdtSMP64.dll and thus seemingly fixing a nonexistant problem?

A: Maybe, it depends on whether or not "smp reset" got to the point where it interacted with hdtSMP64.dll or not. If it crashed before the smp dll, the crash wouldn't go away. If it crashed trying to do something with the smp dll then this would be an easy deadend to fall in yes. If you think there's another approach then reverse, start over and avoid the path leading to hdtSMP64.dll; and now ConsoleUtilSSE.dll should be looking suspcious.

 

Q: How can a Papyrus script control what a DLL does?

A: ConsoleUtilSSE has a script with native function declarations. This one specifically looks quite promising:

function ExecuteCommand(String a_command) global native

 

Edited August 26, 2025 by traison

[traison]

I went ahead and wrote a 10 page paper on reading crash logs. It's in my signature for now. Maybe you'd be a good candidate for letting me know where it fails and what needs to be improved. Not sure it can be made much shorter, so that's probably not an option.

[flutie]

2 hours ago, traison said:

I went ahead and wrote a 10 page paper on reading crash logs. It's in my signature for now. Maybe you'd be a good candidate for letting me know where it fails and what needs to be improved. Not sure it can be made much shorter, so that's probably not an option.

thanks, will give it a go

[traison]

There is now also a video for those that are allergic to walls of text. Attached it to the blog post thingie.

[belegost]

On 8/27/2025 at 6:33 PM, traison said:

It's in my signature

There are signatures? O_o

 

Oh, riiight... I turned them off globally when I created my account, forgot they ever existed and led a happy, content life on this forum.

I'm not turning them back on.

 

Edited September 12, 2025 by belegost

[traison]

1 hour ago, belegost said:

There are signatures?

 

Advertisement, for Like -farming. LL Likes will be worth more than Bitcoins in 25 years.

[belegost]

1 hour ago, traison said:

in 25 years

Not my problem then. People don't live that long.