Ostim crashing on scene end.

[mouse_bitez]

Sometimes, when I end an Ostim scene, my game immediately crashes. In the crash log, it mentions Vigilant. I was in Act 4 of Vigilant, just outside. (However, this has happened in other locations too.) Other places where it's crashed are the Master Bedroom in the Clockwork mod, and the mansion in Vigilant too. 

I had Sexlab for a while, and just recently decided to check out Ostim to see what that's all about. I honestly like Ostim more now and wish I could switch over, but my game is hellbent on keeping Sexlab. The two mods don't seem to clash much on their own, so I just kept both. The crashes really didn't start happening until I installed some Ostim animation packs. In the scene that caused this crash, I used both an animation pack, and regular animation. After both, I ended the scene and crashed.

Here's my crash log. I know my mod list is a bit all over the place, I just kept adding shit over the course of a year.

Can anyone who's more savvy than me identify what's going on here?
 

crash-2025-02-08-06-31-02.log

[traison]

Your crash was caused by architecture\AoM\Coldharbour\CHfxwallREdmist.nif. BSEffectShaderPropertyFloatController could indicate some kind of tweening function.

 

I would start by removing that file to see if it fixes the issue. You'll probably end up with exclamation marks floating around the place, but if its not longer crashing you know what needs to be fixed.

[mouse_bitez]

19 hours ago, traison said:

Your crash was caused by architecture\AoM\Coldharbour\CHfxwallREdmist.nif. BSEffectShaderPropertyFloatController could indicate some kind of tweening function.

 

I would start by removing that file to see if it fixes the issue. You'll probably end up with exclamation marks floating around the place, but if its not longer crashing you know what needs to be fixed.

I don't know where that nif file is. I went to the file path and only found textures.

Even so, I'm not sure why that has anything to do with Ostim crashing. Here's another crash log, this time I was in the master bedroom in the Clockwork mansion. Why does it mention "clockwork\architecture\victorianinterior\furniture\tapcold01.nif"? I have no idea. How does that affect ostim closing a scene whatsoever?

crash-2025-02-06-09-51-42.log

[traison]

That latest crash is similar, but not identical to the previous one. It crashed in the same location, but how it got there is different. This to me seems like its crashing in some kind of utility function.

 

3 hours ago, arlo2 said:

Why does it mention "clockwork\architecture\victorianinterior\furniture\tapcold01.nif"?

 

Because it is used by form id 0x3101AB9F "Cold Water" from "Clockwork.esp". In this case however it seems like the issue is in form id 0x31015F71.

 

3 hours ago, arlo2 said:

How does that affect ostim closing a scene whatsoever?

 

• Ostim has a dll, thus it has full access to the entire memory space of SkyrimSE.exe and any loaded modules. It can change any byte if it wants to, and that doesn't need to be visible anywhere in this crash log.
• Ostim may have its own threads where it does things, and perhaps some of what it does requires changes to be made in the game world for instance (play animation, stop animation, add actor to faction, remove spell from actor, ...) and this happens at a time when another thread is accessing this data as well - a race condition.
• Maybe ending the scene triggers events in mods that also want to do their own thing.
• ...

Without reverse engineering the code around where its crashing, it's difficult to tell on a larger scale what is actually going on. We know which object was involved in the crash becuse it was in a part of the stack that belongs to a stack frame created for one of the callstack entries. We know exactly why it crashed: in both of these its been trying to dereference memory addresses it doesn't have permissions to. But whether there were bytecode edits along the way, or what the functions in the callstack were actually doing, that remains a mystery: sure, it tried to get to memory where it can't go, but was it trying to do this as a part of Nif processing, memory copying or perhaps some string comparison?

 

Like I mentioned previously, this kind of looks like its crashing in a utility function of some kind. One place that's relatively easy to get into which may shed light on this is the offset in VCRUNTIME140. I had my dll open for inspection, but the offset does not line up, so you have different version than me. Thus, I need the following from you:

1. The exact version number of your VCRUNTIME140.dll.
2. A checksum of the dll, in case I have to download it from some questionable site.

Get me that, or the dll itself, and I'll have a look at it with a disassembler.

Edited February 9, 2025 by traison

[mouse_bitez]

14 hours ago, traison said:

That latest crash is similar, but not identical to the previous one. It crashed in the same location, but how it got there is different. This to me seems like its crashing in some kind of utility function.

 

 

Because it is used by form id 0x3101AB9F "Cold Water" from "Clockwork.esp". In this case however it seems like the issue is in form id 0x31015F71.

 

 

• Ostim has a dll, thus it has full access to the entire memory space of SkyrimSE.exe and any loaded modules. It can change any byte if it wants to, and that doesn't need to be visible anywhere in this crash log.
• Ostim may have its own threads where it does things, and perhaps some of what it does requires changes to be made in the game world for instance (play animation, stop animation, add actor to faction, remove spell from actor, ...) and this happens at a time when another thread is accessing this data as well - a race condition.
• Maybe ending the scene triggers events in mods that also want to do their own thing.
• ...

Without reverse engineering the code around where its crashing, it's difficult to tell on a larger scale what is actually going on. We know which object was involved in the crash becuse it was in a part of the stack that belongs to a stack frame created for one of the callstack entries. We know exactly why it crashed: in both of these its been trying to dereference memory addresses it doesn't have permissions to. But whether there were bytecode edits along the way, or what the functions in the callstack were actually doing, that remains a mystery: sure, it tried to get to memory where it can't go, but was it trying to do this as a part of Nif processing, memory copying or perhaps some string comparison?

 

Like I mentioned previously, this kind of looks like its crashing in a utility function of some kind. One place that's relatively easy to get into which may shed light on this is the offset in VCRUNTIME140. I had my dll open for inspection, but the offset does not line up, so you have different version than me. Thus, I need the following from you:

1. The exact version number of your VCRUNTIME140.dll.
2. A checksum of the dll, in case I have to download it from some questionable site.

Get me that, or the dll itself, and I'll have a look at it with a disassembler.

I'm not sure how to check the version of my dll file, or how to get a checksum. I found my vcruntime140.dll file, and had to put it into a zip folder. I guess LL doesn't allow dll files on their own.

vcruntime140.zip

[traison]

That's the 32 bit vc runtime. Skyrim is a 64 bit process, thus uses 64 bit modules.

 

Find the correct one:

1. Process Explorer's modules -list
   1. Grab Process Explorer from Sysinternals (Microsoft).
   2. Start procexp64 and SkyrimSE.exe.
   3. Once Skyrim is in the main menu, alt-tab out.
   4. Ctrl+L in procexp, if the lower pane is not visible by default.
   5. DLLs (tab)
   6. Locate vcruntime140.dll, view the Path column for where it was loaded from.
2. Assume its the default one
   1. C:\Windows\System32\vcruntime140.dll

Edited February 10, 2025 by traison