Best Crash Logger for Skyrim AE .1170

[nunyabidnez]

I'm about at wit's end, random freezing and crashes.  My Papyrus Log consistently shows [Zad-NG]: UpdateControls( ) as the final entry before the crash or freeze, and that particular command is spammed like hell throughout the log.  Once upon a time, I understood it was reasonably accepted the last entry in Papyrus was usually the culprit when it comes to crashes, but I guess that isn't the case anymore?  I'd like to know if there's a crash logger that actually works with AE, all the ones I've seen specifically say they don't, or in the case of Train Wreck doesn't provide any useful information at all.  I do have Fallrim Tools ReSaver, and it shows no orphaned or unattached scripts whatsoever.  Thanks in advance for any advice.

[traison]

54 minutes ago, nunyabidnez said:

Once upon a time, I understood it was reasonably accepted the last entry in Papyrus was usually the culprit when it comes to crashes, but I guess that isn't the case anymore?

 

That is only true if you're lucky. I would never trust that, in any application.

 

54 minutes ago, nunyabidnez said:

I'd like to know if there's a crash logger that actually works with AE...

 

https://www.nexusmods.com/skyrimspecialedition/mods/59818

 

54 minutes ago, nunyabidnez said:

...or in the case of Train Wreck doesn't provide any useful information at all.

 

Trainwreck is fine if you can do the debugging yourself.

 

56 minutes ago, nunyabidnez said:

I do have Fallrim Tools ReSaver, and it shows no orphaned or unattached scripts whatsoever.  Thanks in advance for any advice.

 

Papyrus is only relevant in crashes if the crash log hints at it; until then assume the Papyrus log is irrelevant.

[BDNelson]

Yes, the above link does work with .1170, I'm using it right now. I can find my crash logs in C:\Documents\My Games\Skyrim Special Edition\SKSE folder, they're very detailed.

 

My PC, Blaze, just cleared Embershard Mine, I've had 1 freeze-up and 1 CTD. I'm running "Toys" and its add-on mods too, kinda finicky those. There must be something amiss with your installs or load order to have so many problems so soon. I've been trying to mod up SAE for a long time, I just successfully accomplished that this week. I'm doing a "playing the game" run right now, hope you get that part, lol. I don't plan on adding any more mods at this point, got over 600 now, that seems like enough, 230 + or - plugin slots used. So far, so good.

[nunyabidnez]

Thank you both, really appreciate the advice.  @traison, really value your opinion as I've been a pretty avid follower of your other posts on technical issues, thank you for being such an asset for the community.   I'm not sure if I was doing something wrong with TrainWreck, as it quite literally didn't provide any debugging information at all.  It just basically regurgitated my load order and a couple of other background processes, and that was it.  I don't know how I missed that version of Crash Logger, definitely firing it up.  What kills me is the unpredictability of the issue.  Sometimes I can get three, four, five hours of play with no issues at all, others can't get 20 minutes.  Not even running nearly as many mods as I used to, think I'm only like at 590 or so, counting all the Creation Club stuff.  Thank you both again for the advice.

 

2 hours ago, traison said:

 

That is only true if you're lucky. I would never trust that, in any application.

 

 

https://www.nexusmods.com/skyrimspecialedition/mods/59818

 

 

Trainwreck is fine if you can do the debugging yourself.

 

 

Papyrus is only relevant in crashes if the crash log hints at it; until then assume the Papyrus log is irrelevant.

 

1 hour ago, BDNelson said:

Yes, the above link does work with .1170, I'm using it right now. I can find my crash logs in C:\Documents\My Games\Skyrim Special Edition\SKSE folder, they're very detailed.

 

My PC, Blaze, just cleared Embershard Mine, I've had 1 freeze-up and 1 CTD. I'm running "Toys" and its add-on mods too, kinda finicky those. There must be something amiss with your installs or load order to have so many problems so soon. I've been trying to mod up SAE for a long time, I just successfully accomplished that this week. I'm doing a "playing the game" run right now, hope you get that part, lol. I don't plan on adding any more mods at this point, got over 600 now, that seems like enough, 230 + or - plugin slots used. So far, so good.

 

[traison]

When working on technical issues that appear to have a random component to them, I find that learning how to break it is usually the fastest way to the solution. Not only does it cut down on the repeat time allowing you to test every minute rather than every 3 hours on average like you said; but usually when you learn how to break it, you're also half way to the solution already.

 

Post the crash log here when you get it and I'll have a look at it.

[nunyabidnez]

56 minutes ago, traison said:

When working on technical issues that appear to have a random component to them, I find that learning how to break it is usually the fastest way to the solution. Not only does it cut down on the repeat time allowing you to test every minute rather than every 3 hours on average like you said; but usually when you learn how to break it, you're also half way to the solution already.

 

Post the crash log here when you get it and I'll have a look at it.

 

So, if I even remotely understand the log (which I will readily admit looks to be a completely foreign, yet slightly discernible language to me), there seems to have been an Access Violation when trying to read memory?  The Call Stack seems to all point to SkyrimSE with the exception of two tbbmalloc.dll entries, which I've read are SSE Engine Fix related, and that's a requirement for many of the mods we run.  I've posted a copy, really do appreciate any words of wisdom or assistance in figuring out just what it's telling me.

crash-2025-08-03-17-26-59.log

[traison]

That crash was caused by a particle emitter's float interpolator in the mesh Effects\FXfireWithEmbers02.nif used by form id 0x00033DA9 in form id 0x0000963B "WhiterunExterior15". Reference id 0xFF00152C "Mercenary" also had something to do with this. Maybe they were on fire?

 

Quickest way out of this is probably to find the mod that provides the mesh and disable it. Otherwise you'll have to inspect this is NifSkope and try to figure out why a float interpolator is crashing the game.

[Grey Cloud]

28 minutes ago, traison said:

Reference id 0xFF00152C "Mercenary" also had something to do with this. Maybe they were on fire?

Crashed and burned? 

I'll get my coat.

[nunyabidnez]

2 hours ago, Grey Cloud said:

Crashed and burned? 

I'll get my coat.

That.  Was.  So.  BAD!!!  I actually grinned, though, nicely done.

[nunyabidnez]

2 hours ago, traison said:

That crash was caused by a particle emitter's float interpolator in the mesh Effects\FXfireWithEmbers02.nif used by form id 0x00033DA9 in form id 0x0000963B "WhiterunExterior15". Reference id 0xFF00152C "Mercenary" also had something to do with this. Maybe they were on fire?

 

Quickest way out of this is probably to find the mod that provides the mesh and disable it. Otherwise you'll have to inspect this is NifSkope and try to figure out why a float interpolator is crashing the game.

Whoa.  So, just for my curiosity's sake, how were you able to make that call?  I see in the STACK section there's an entry with "Mercenary", with FormID and a bunch of other information, but how do you know it's what made the crash?  Is there a specific in there that would indicate a crash?  I do see where it's showing that as a formtype 43, which I know is from oldrim and can be problematic, so I will figure out which mod that's from and figure out how to make it a 44. 

And, on a unrelated but related note, does crash logger only work on crashes and not freezes?  I ran through later on and actually had nearly an hour uninterrupted before it froze hard, but there was no log generated for it.  Thank you again for your information and time, I really do appreciate it.

[traison]

2 hours ago, nunyabidnez said:

So, just for my curiosity's sake, how were you able to make that call?  I see in the STACK section there's an entry with "Mercenary", with FormID and a bunch of other information, but how do you know it's what made the crash?

 

https://www.loverslab.com/topic/223820-how-to-read-my-crash-log-skyrim-se/#elControls_4263467_menu

 

You'll probably be disapointed, but I don't know what caused that crash. I can guess what it might be, but crash logs do not contain everything. Relatively speaking they actually contain very little information. If you actually want to know what caused a crash you have to use a debugger, and step through the instructions leading up to the crash. The stack for instance only contains whatever is pushed onto it. Usually functions push a few registers onto the stack at the beginning to make room for the work they do. Then they pop them back at the end so that the code its about to jump back to can resume its work. These are the only ones we can see. There's no knowledge of the cpu registers at any other point in time except for at RIP (i.e. right at the time of the crash) and there's only a tiny microscopic fraction of knowledge of what's in other memory spaces outside of the stack.

 

Edit: And in some cases where a function requires a large amount of input parameters, some of the later ones may be pushed on to the stack before the call instruction jumps to the function code. To make things more confusing, all of this assumes a certain kind of calling convention. There's no set rules for this in assembly, the rules are set by the compiler that made the machine code. Functions do not actually exist in assembly either, they're more of an illusion created by the call and ret instructions.

 

Edit again: And when I say "I don't know what caused the crash" I mean which game object or function caused it. The technical reason for why you crashed I can tell with 100% certainty. It was because tbbmalloc.dll tried to dereference RAX which led the CPU to read memory it wasn't allowed to read. But that's not really helpful is it. You probably want to know which of your funny hats isn't working right.

 

Another thing to be disapointed about perhaps is that unless there's something off about the log, I generally do not spend more than 5 minutes looking at these before I come up with some idea. Usually I get it right the first time, but there's been plenty of cases where I've had to actually look into it properly to get it right. It might be easy to think I'm just wasting people's time by doing that; and yes there's things I could do to mitigate this but to put a long story short, I'd go nuts if I spent an hour or two seriously looking into every issue that pops up. Difficult issues may require a week of work.

 

2 hours ago, nunyabidnez said:

...figure out how to make it a 44.

 

Open it in the CK, and save it.

 

2 hours ago, nunyabidnez said:

And, on a unrelated but related note, does crash logger only work on crashes and not freezes?

 

Freezes are not crashes. Nor is the application suddenly closing a crash. A crash is an exception that didn't get handled by an exception handler. Thus they're called unhandled exceptions. Another way to put that is that it's entirely possible to seemingly crash, without it actually being a crash. It's also possible to crash without the crash logger detecting it, if another exception handler was registered later and it caught the exception and decided to not pass it to the next handler. At least I think that's possible. Sort of the same reason why you shouldn't have 2 crash loggers at the same time.

Edited August 4, 2025 by traison

[nunyabidnez]

@traison, thank you so much for that explanation and information.  I googled the hell out of "how to read skyrim crashlogger log", and your LL post never popped up.  Tons of reddit posts that said "Your crash is in the first five listings in the call stack", and that was about the extent of the information they provided.  Thank you again, looks like I got some reading to do.

[traison]

2 hours ago, nunyabidnez said:

...looks like I got some reading to do.

 

Are you perhaps suggesting there was nothing you could do with Effects\FXfireWithEmbers02.nif? No mod that overwrites it?

[nunyabidnez]

4 hours ago, traison said:

 

Are you perhaps suggesting there was nothing you could do with Effects\FXfireWithEmbers02.nif? No mod that overwrites it?

More that I had to do some digging to see if there were any known issues / conflicts beyond what the author addressed and then how to actually work with any issues.  The extent of my modding expertise can basically be summed up by "Does it work, if not what have others done to make it work, if not that uninstall", lol, but I really like how Lux looks and would hate to lose it.  That, and read up more on your guidance for log interpretation.

 

[traison]

FXfireWithEmbers02.nif exists in Skyrim - Meshes0.bsa, so instead of removing the entire mod, start by deleting the file from the mod. Move it onto your desktop, or rename it for instance. If the problem goes away you can consider actually fixing it.

Edited August 4, 2025 by traison

[nunyabidnez]

1 minute ago, traison said:

Instead of removing the entire mod, start by deleting the file from the mod. Move it onto your desktop, or rename it for instance. If the problem goes away you can consider actually fixing it.

So,... I did find that I had a plugin related to particle effects active which should not have been, deactivated that and gave it a run.  And now my crashlog is even worse, lol, with what appears to be a multitude of issues with Immersive Weapons Display, which I didn't touch at all.  But, I did use Loot to set my load order, I had been doing it manually as I'd read Loot wasn't as good as it used to be but thought I was probably screwing something up.  I'm going back now to ensure dependencies are correct for IWD, obviously they're not, lol.  But I did not see a single entry concerning the particle effects, so that's a positive, right?

[nilead]

I know your pain. One thing i miss dearly having switched from SE to AE is NetScriptFramework. Even being a total scrub that one allowed me to resolve issues consistently.  Good old days. Best of luck.

[nunyabidnez]

2 hours ago, traison said:

FXfireWithEmbers02.nif exists in Skyrim - Meshes0.bsa, so instead of removing the entire mod, start by deleting the file from the mod. Move it onto your desktop, or rename it for instance. If the problem goes away you can consider actually fixing it.

I'm thinking I may just have to nuke this build and stir the ashes, and try again.  Seem to have resolved the Immersive Display issue, and now it's appearing to throw errors about one particular Immersive Wench somehow having a schlong, and I don't even have SoS in my modlist.  At least one direct reference to it, others could possibly be The New Gentleman with talk of genital base and other, but still none of the Immersive Wenches should have that at all.  I'm thinking I've just hard saved some significant issues and am just compounding them with attempts to correct these individual issues that seem to be causing crashes.  I've attached the last two crashlogs, if you're even remotely interested, but I already feel bad enough monopolizing your time so if you're not, don't worry about it.  Like I said, I'll probably do a hard wipe and start again.  At least I was only up to like level 8, lol!

crash-2025-08-04-21-15-19.log crash-2025-08-04-19-48-07.log

[traison]

2025-08-04-21-15-19

Current theory is that logs like this is caused some external application with kernel level access. Basically something crashed Skyrim in such a way that the exception address was never filled in or intentionally set to null. Nothing in this crash log can be trusted. Sometimes we see logs like this when the game is installed in Program Files and Windows Defender gets all excited about something.

 

2025-08-04-19-48-07

ImmersiveEquipmentDisplays.dll most likely indirectly caused this one. It appears to have started some kind of recursive scan of the skeleton belonging to reference id 0xFF0011DE form id 0x0001B5E3 "Whiterun Guard", and it died when going through an NiNode named "CME WeaponDaggerAnkle". I'd say IED falls in the category of mods that look cool on paper but have a lot of potential for causing issues. I would look for a different version of the mod, newer, older, doesn't matter. If that's not an option, disable it and test again. This could also be a skeleton issue, and since this is a male NPC, consider changing or removing TNG.

 

24 minutes ago, nunyabidnez said:

I don't even have SoS in my modlist.

 

Maybe not, but TNG seems to at least use the terminology:

meshes\auxbones\SOS\Character Assets\TngSkeleton.hkt

 

24 minutes ago, nunyabidnez said:

I'm thinking I may just have to nuke this build and stir the ashes, and try again.

 

That seems unnecesaarily violent.

Edited August 4, 2025 by traison

[nunyabidnez]

20 hours ago, traison said:

2025-08-04-21-15-19

Current theory is that logs like this is caused some external application with kernel level access. Basically something crashed Skyrim in such a way that the exception address was never filled in or intentionally set to null. Nothing in this crash log can be trusted. Sometimes we see logs like this when the game is installed in Program Files and Windows Defender gets all excited about something.

 

2025-08-04-19-48-07

ImmersiveEquipmentDisplays.dll most likely indirectly caused this one. It appears to have started some kind of recursive scan of the skeleton belonging to reference id 0xFF0011DE form id 0x0001B5E3 "Whiterun Guard", and it died when going through an NiNode named "CME WeaponDaggerAnkle". I'd say IED falls in the category of mods that look cool on paper but have a lot of potential for causing issues. I would look for a different version of the mod, newer, older, doesn't matter. If that's not an option, disable it and test again. This could also be a skeleton issue, and since this is a male NPC, consider changing or removing TNG.

 

 

Maybe not, but TNG seems to at least use the terminology:

meshes\auxbones\SOS\Character Assets\TngSkeleton.hkt

 

 

That seems unnecesaarily violent.

I did disable IED, and thought perhaps it might have brought some resolution, but alas, then the "schlong" crash happened after perhaps an hour or so of runtime.  So you think the second log was more of an anomaly than an accurate register?  I do not run my game from Program Files, have Steam set to it's own directory.  I have not nuked this install yet, I'll give another run through and see if it replicates the weird log. 

[traison]

36 minutes ago, nunyabidnez said:

I do not run my game from Program Files, have Steam set to it's own directory.

 

That was just an example. I wonder if throwing an exception in a hidden thread would also cause something like that. It would widen the potential source to include user-space code as well if so. Anyhow, I'm not actually sure if the source of that problem can be found with traditional tools. You can keep threads from hiding, and you can get a debugger into the kernel (if that even helps any), but we're quite far from "just look at it with a debugger" now. Fairly certain reinstalling isn't going to fix it though.

 

I suppose one might try Googling this, but Google (and search engines in general) these days are absolutely horrible at finding answers to anything more complex than "how do I turn on my printer". We're way-way-way past the point where DIY is the only way forwards. I'll see if I can find something.

[traison]

Sooo... looking at this thing, the issue could be coming from a corrupt stack (assuming this is possible in Skyrim's code). Apparently a ret instruction can jump to 0x0 and cause this. Which according to my logic would also mean a jmp instruction can do the same. Crash Logger seems to get confused by this since it dumped the wrong thread context. It kinda looks like WinDbg could debug this problem. A minidump might be enough for that, assuming it contains the context of all threads at the time of the crash.

 

Have a look at configuring WER to create a minidump for you when Skyrim crashes. Disable Crash Logger so that it doesn't get in the way. Careful with uploading it online, as it may contain more information than you think. PM me if you want to upload it directly to my server.

 

Edit: SKSE may also be able to create minidums. It may even be configured to already do so. It may also be something that's only in the debug build of it. Try Googling this if you think it will be easier to configure than WER.

 

If the minidump is not enough, a full process memory dump is needed; meaning it will create a file the size of however many GiB's Skyrim is using at the time of the crash. Loading these files in WinDbg can take hours, so I probably won't get into that.

Edited August 5, 2025 by traison

[nunyabidnez]

I truly do think I managed to hard save some intrinsic flaw, made three attempts to run again last night and each time hard crashed, each time the crash log was showing completely different results, the last one similar to the anomalous one from a couple days ago.  Lack of patience got the better of me after that and I've wiped that build and will be doing a clean reinstall.  I guess I'll find out if it was a Skyrim problem or perhaps something with my window install, wish I'd never "upgraded" to 11.  Thank you again for your time, expertise and input, I'm definitely keeping this topic favorited for future reference.

 

On 8/5/2025 at 4:51 PM, traison said:

Sooo... looking at this thing, the issue could be coming from a corrupt stack (assuming this is possible in Skyrim's code). Apparently a ret instruction can jump to 0x0 and cause this. Which according to my logic would also mean a jmp instruction can do the same. Crash Logger seems to get confused by this since it dumped the wrong thread context. It kinda looks like WinDbg could debug this problem. A minidump might be enough for that, assuming it contains the context of all threads at the time of the crash.

 

Have a look at configuring WER to create a minidump for you when Skyrim crashes. Disable Crash Logger so that it doesn't get in the way. Careful with uploading it online, as it may contain more information than you think. PM me if you want to upload it directly to my server.

 

Edit: SKSE may also be able to create minidums. It may even be configured to already do so. It may also be something that's only in the debug build of it. Try Googling this if you think it will be easier to configure than WER.

 

If the minidump is not enough, a full process memory dump is needed; meaning it will create a file the size of however many GiB's Skyrim is using at the time of the crash. Loading these files in WinDbg can take hours, so I probably won't get into that.

 

[traison]

I was secretly hoping this would come to a point where I'd get a chance to remote to your desktop and see this exception for myself in a debugger. Would have been interesting. It's always funny/interesting when it's not your own game that's broken I guess. Another time perhaps. Good luck with the rebuild.

[nunyabidnez]

22 hours ago, traison said:

I was secretly hoping this would come to a point where I'd get a chance to remote to your desktop and see this exception for myself in a debugger. Would have been interesting. It's always funny/interesting when it's not your own game that's broken I guess. Another time perhaps. Good luck with the rebuild.

 

Lol, with my track record and history of weird stuff happening with my builds, you might still get that chance!  Thank you!