Random crash

[Cerral]

Hi, my game crashes regularly. I've learnt a little (really a little) to read the crash logs and I've uninstalled the mods as I went along, which was causing a problem. But I don't understand the latest crash logs, so I'm asking for a little help. Thanks in advance.

 

 

2025-01-28-20-19-05.log

[traison]

This crash kinda looks like it was caused by a Papyrus script. The answer might be in  RSP+68 or RSP+90. If you want more, switch to a crash logger more suitable for remote assistance.

[Cerral]

50 minutes ago, traison said:

This crash kinda looks like it was caused by a Papyrus script. The answer might be in  RSP+68 or RSP+90. If you want more, switch to a crash logger more suitable for remote assistance.

 Thank you. I'm going to try using what you recommend again, although I've never managed to get it to work. It doesn't generate a log when my game crashes.

[traison]

32 minutes ago, Cerral said:

It doesn't generate a log when my game crashes.

 

 

Some options for that:

1. The crash loggers we have only handle unhandled exceptions. It's possible for an application to handle an exception and terminate the application. This will look like a CTD, but its technically very different.
2. You have another application which handles unhandled exceptions.
3. There's a bug in Crash Logger. Might be worth checking its log file to see if it had anything to say about it.

[Cerral]

1 hour ago, traison said:

 

 

Some options for that:

1. The crash loggers we have only handle unhandled exceptions. It's possible for an application to handle an exception and terminate the application. This will look like a CTD, but its technically very different.
2. You have another application which handles unhandled exceptions.
3. There's a bug in Crash Logger. Might be worth checking its log file to see if it had anything to say about it.

My game has finally crashed. And I've also found the crash log, it doesn't go into the right folder. No problem, it works. If I'm reading it correctly, it's Realistic Water Two that's giving me problems. Is that it?

crash-2025-01-29-17-09-11.log

Edited January 29, 2025 by Cerral

[traison]

Not sure if these functions just allocate large amounts of memory on the stack or if the callstack was unwound incorrectly here. The crash occured because it tried to dereference RAX which at the time of the crash was 0x0. That's a null pointer. After that it could be either of these 2:

• Find out what a BSTCommonScrapHeapMessageQueue<BSPackedTask> is, and how it relates to what you were doing in the game at the time of the crash.
• There's a problem with form id 0x000AF5FB of type MovableStatic in cell "POIPineForest24" (0x00009BB5) last modified by RealisticWaterTwo.esp.

1 hour ago, Cerral said:

it's Realistic Water Two that's giving me problems. Is that it?

 

I haven't looked up what 0x000AF5FB is, and I can't know if it was modified by RW2 or not without access to your setup. Right now I wouldn't say RW2 is the issue, but the issue is in a cell RW2 was last to modify. Considering RW2 most likely changes all cells with anything larger than a puddle in it, it seems like one of those mods that will show up in most game world related issues.

[Cerral]

27 minutes ago, traison said:

Not sure if these functions just allocate large amounts of memory on the stack or if the callstack was unwound incorrectly here. The crash occured because it tried to dereference RAX which at the time of the crash was 0x0. That's a null pointer. After that it could be either of these 2:

• Find out what a BSTCommonScrapHeapMessageQueue<BSPackedTask> is, and how it relates to what you were doing in the game at the time of the crash.
• There's a problem with form id 0x000AF5FB of type MovableStatic in cell "POIPineForest24" (0x00009BB5) last modified by RealisticWaterTwo.esp.

 

I haven't looked up what 0x000AF5FB is, and I can't know if it was modified by RW2 or not without access to your setup. Right now I wouldn't say RW2 is the issue, but the issue is in a cell RW2 was last to modify. Considering RW2 most likely changes all cells with anything larger than a puddle in it, it seems like one of those mods that will show up in most game world related issues.

I'm going to explore all that. At the time of the crash, I wasn't doing anything special, apart from walking around Lake Ilinalta.

[Cerral]

This is the object with the Id 0x000AF5FB at the exit of Bleak Falls Barrow.

 

Spoiler

As for the ‘BSTCommonScrapHeapMessageQueue<BSPackedTask>’ message, I don't know how to interpret it and especially how to go about it.

1 hour ago, traison said:

Not sure if these functions just allocate large amounts of memory on the stack or if the callstack was unwound incorrectly here. The crash occured because it tried to dereference RAX which at the time of the crash was 0x0. That's a null pointer. After that it could be either of these 2:

• Find out what a BSTCommonScrapHeapMessageQueue<BSPackedTask> is, and how it relates to what you were doing in the game at the time of the crash.
• There's a problem with form id 0x000AF5FB of type MovableStatic in cell "POIPineForest24" (0x00009BB5) last modified by RealisticWaterTwo.esp.

 

I haven't looked up what 0x000AF5FB is, and I can't know if it was modified by RW2 or not without access to your setup. Right now I wouldn't say RW2 is the issue, but the issue is in a cell RW2 was last to modify. Considering RW2 most likely changes all cells with anything larger than a puddle in it, it seems like one of those mods that will show up in most game world related issues.

 

[traison]

Your issue is in Clutter\Bones\HumanRibcageFull.nif and the mod that provides it. If you have no mod altering this mesh (remember to check inside BSA archives), then disable that object and try approaching Bleakfalls Barrow again:

1. prid 0x000AF5FB
2. disable
3. markfordelete

If its still not working, try approaching from a different direction, like for instance from Whiterun. And if its still not working, post another crash log with that object disabled and deleted, perhaps from your approach from Whiterun.

[Cerral]

14 hours ago, traison said:

Your issue is in Clutter\Bones\HumanRibcageFull.nif and the mod that provides it. If you have no mod altering this mesh (remember to check inside BSA archives), then disable that object and try approaching Bleakfalls Barrow again:

1. prid 0x000AF5FB
2. disable
3. markfordelete

If its still not working, try approaching from a different direction, like for instance from Whiterun. And if its still not working, post another crash log with that object disabled and deleted, perhaps from your approach from Whiterun.

I went back to where my game had crashed without any problems this time. What's more, no mod modifies this object. I have a feeling I'm going to have a really hard time finding out why my game crashes the way it does. I've removed a lot of mods, and it can crash after 10 minutes of play or sometimes after 4 hours. Fast travel, for example, often crashes my game (not all the time), even in places I go to frequently. That's why I travel on foot.

I've had 2 new crashes, one in an area not modified by mods, the other due to an NPC (apparently) with whom I speak without any problem. In both cases, I used the carriage.

crash-2025-01-29-21-36-50.logcrash-2025-01-30-10-38-19.log

 

[traison]

One thing to keep in mind if you're crashing all over the place, and every time the crash log is different (which is the case right now), is that all the objects that turn up in the registers and/or the stack could simply have been in the wrong place at the wrong time. A fact of crashlogs however is that, as long as the crashing thread context was retrieved correctly the information in the log (the stack, the state of the cpu etc.) is what crashed the application. What we don't see in these logs however is whatever interferance was caused from the outside. For instance, lets say you have a dll which, in some non-standard way, injects NPCs into the world, skipping normal game mechanics for adding an NPC. This then could lead to a situation where some NPC AI handling code (in an entirely different thread) crashes for seemingly no reason without ever exposing the dll that added the NPC in its crash log callstack.

 

My point being, this kinda smells like you have some 3rd party messing things up. Ranging from a dll (SKSE plugin) making rogue edits, to issues with an unstable RAM overclocking. Either that or you actually have several different reasons why the game is crashing and you just happen to find them all now.

 

21-36-50:

 

The callstack was unwound incorrectly, and this a different issue from 19-09-11.

 

The callstack for may have looked like this (just guesswork, not based on assembly code):

SkyrimSE.exe+14F2CDD

SkyrimSE.exe+14F40DC

SkyrimSE.exe+14F3929

SkyrimSE.exe+14F3C54

...

 

This crash was caused by RM's face overlay, layer 0 aka. "Face [Ovl0]". The overlay was attached to form id 0x3451139A "Mango" from "Honeypopcorn Skyrim Overhaul.esp" in cell 0x00009A39 "PBDC3" last modified by "DeviousCarriages.esp". It has issues processing a BSLightingShader. There's a null pointer somewhere; R8 was 0x0 when it tried to dereference it.

 

10-38-19:

 

This a different issue from 19-09-11.

 

This sort of looks like it could have originated from Papyrus. It had something to do with Havok physics. The keyword to search for in this crash is "EnableFunctor" in the context of "SkyrimScript".

[Cerral]

1 hour ago, traison said:

One thing to keep in mind if you're crashing all over the place, and every time the crash log is different (which is the case right now), is that all the objects that turn up in the registers and/or the stack could simply have been in the wrong place at the wrong time. A fact of crashlogs however is that, as long as the crashing thread context was retrieved correctly the information in the log (the stack, the state of the cpu etc.) is what crashed the application. What we don't see in these logs however is whatever interferance was caused from the outside. For instance, lets say you have a dll which, in some non-standard way, injects NPCs into the world, skipping normal game mechanics for adding an NPC. This then could lead to a situation where some NPC AI handling code (in an entirely different thread) crashes for seemingly no reason without ever exposing the dll that added the NPC in its crash log callstack.

 

My point being, this kinda smells like you have some 3rd party messing things up. Ranging from a dll (SKSE plugin) making rogue edits, to issues with an unstable RAM overclocking. Either that or you actually have several different reasons why the game is crashing and you just happen to find them all now.

 

21-36-50:

 

The callstack was unwound incorrectly, and this a different issue from 19-09-11.

 

The callstack for may have looked like this (just guesswork, not based on assembly code):

SkyrimSE.exe+14F2CDD

SkyrimSE.exe+14F40DC

SkyrimSE.exe+14F3929

SkyrimSE.exe+14F3C54

...

 

This crash was caused by RM's face overlay, layer 0 aka. "Face [Ovl0]". The overlay was attached to form id 0x3451139A "Mango" from "Honeypopcorn Skyrim Overhaul.esp" in cell 0x00009A39 "PBDC3" last modified by "DeviousCarriages.esp". It has issues processing a BSLightingShader. There's a null pointer somewhere; R8 was 0x0 when it tried to dereference it.

 

10-38-19:

 

This a different issue from 19-09-11.

 

This sort of looks like it could have originated from Papyrus. It had something to do with Havok physics. The keyword to search for in this crash is "EnableFunctor" in the context of "SkyrimScript".

A lot of things to sort out. I'll look into it in 3 or 4 days, as I'm off on a business trip for the next 3 days. Thanks for your help. I'll call on you again in a few days.

[Cerral]

On 1/30/2025 at 2:09 PM, traison said:

One thing to keep in mind if you're crashing all over the place, and every time the crash log is different (which is the case right now), is that all the objects that turn up in the registers and/or the stack could simply have been in the wrong place at the wrong time. A fact of crashlogs however is that, as long as the crashing thread context was retrieved correctly the information in the log (the stack, the state of the cpu etc.) is what crashed the application. What we don't see in these logs however is whatever interferance was caused from the outside. For instance, lets say you have a dll which, in some non-standard way, injects NPCs into the world, skipping normal game mechanics for adding an NPC. This then could lead to a situation where some NPC AI handling code (in an entirely different thread) crashes for seemingly no reason without ever exposing the dll that added the NPC in its crash log callstack.

 

 

I uninstalled all the mods, then I reactivate them one by one and check that they work. I've just had my first crash in 3 days since activating the mods one by one. Except for the current test, where I've reinstalled Lux and all the patches that go with it.

 

crash-2025-02-11-13-19-00.log

[traison]

That latest crash was caused by Havok physics and it originated from DynamicCollisionAdjustment.dll.