Ostim Standalone crashing on orgasm (crashlog attached)

[just let me download]

crash-2024-12-27-20-22-10.log

 

I am experiencing a crashing issue in Ostim Standalone that doesn't happen with every orgasm but happens around one in every 3 to every 20 orgasms. I can reproduce this by using an animation scene with an orgasm-on-demand option and spamming it over and over. The crashlog is very sparse with details and badly paints what's going on. It does indicate some map areas and objects but those are actually not relevant, the location does not matter in relation to this CTD. I can be in the Tamriel (exterior) worldpspace, interiors, or modded interiors/exteriors. I do not experience any other CTDs regularly but virtually all of my recent CTDs are related to Ostim SA.

 

Can anyone please help me? I have already asked this on the Ostim Discord a few times and the helpful people there were not able to identify any specific issues. Thank you.

 

I understand the crash log doesn't explain the situation very well. If there is information you need to get a better understanding, please let me know and I'll get it for you.

 

Modlist.txt here: modlist.txt (Keep in mind the lines that start with a dash (-) indicate disabled mods)

 

Some miscellaneous facts that may be relevant:

• I am using 1.5.97
• I have both Visual C++ Redistributables installed and updated (x64 and x86)
• Solo vs non-solo is not relevant
• Not related to Wet Function Redux
• Not related to Dripping While Aroused
• Not related to Smart Timescale
• Not related to the slow-mo on orgasm option in Ostim SA
• Not related to location
• Happens on new game with new character and current character
• Memory addresses associated with VCRUNTIME140.dll at the top of the crashlog are either 001131A or 001150A (this is a key constant in all the crashes)
• Not related to any mods that add moans/climax sounds to Ostim SA.
• Not related to animations - Tested on an A-posing character still resulted in a crash
• Not related to any mods that were made for the purpose of being used with Ostim Standalone, for example: OSL Aroused, OEndurance, OCum Ascended, Ostim on Demand, etc.
• It can take up to 45 minutes to reproduce a crash from just spamming the orgasm button while using any animation that has such a button, so reproducing the crash can take a lot of time

 

I will continually add more information to this list as I learn more about this issue. When an item on the list mentions "not related", it means I tested a new game + new character without the mods/settings enabled and was still able to produce the crash.

Edited January 19, 2025 by just let me download

[The Way You Play]

crash-2025-01-19-19-11-29.logI'm having exactly the same problem on the AE 1170 version. I'll investigate further.

Edited January 19, 2025 by The Way You Play

[traison]

Both of these crashes do indeed seem to be the same, but on different game versions. The common thing in the stack is that it goes from doing something with the player character, to doing something with (presumably) the cell the player is in and this is where it fails.

 

So what I'd do in this case is get it to crash in, say, 3 different cells: outdoors, indoors.

 

If the cell at the top of the stack remains the same, then that cell is the issue. If the cell keeps changing, then all bets are off since we're dealing with a dll most likely triggering the crash.

[just let me download]

11 minutes ago, traison said:

Both of these crashes do indeed seem to be the same, but on different game versions. The common thing in the stack is that it goes from doing something with the player character, to doing something with (presumably) the cell the player is in and this is where it fails.

 

So what I'd do in this case is get it to crash in, say, 3 different cells: outdoors, indoors.

 

If the cell at the top of the stack remains the same, then that cell is the issue. If the cell keeps changing, then all bets are off since we're dealing with a dll most likely triggering the crash.

 

I have a huge number of crashlogs from this issue (inside, outside, wherever) and the log will just report whatever cell I am currently in. Sometimes there is no cell information at all. I have even been able to reproduce this crash in the QASmoke area.

 

The huge difficulty in narrowing down the cause of this crash is that it's very time consuming to determine at what point I am definitely stable. A few times, I have been stable and not crashing while non-stop triggering orgasms until the ~45 minute mark where I then crash while testing minimal load orders.

 

My question is: The culprit behind these crashes must be a .dll then, correct?

Edited January 19, 2025 by just let me download

[traison]

1 hour ago, just let me download said:

My question is: The culprit behind these crashes must be a .dll then, correct?

 

Can't tell for sure without about a week of reverse engineering work. Unless you can find some common denominator with all the cells you've crashed in, it seems more likely to me the Ostim dll is doing something it shouldn't be doing. Since the dll is not visible in the callstack that leaves bytecode edits and jumps to code caves as the likely options - both require a debugger in Skyrim while its running and a whole lot of work to detect.

 

1 hour ago, just let me download said:

Sometimes there is no cell information at all.

 

May want to post one of those, as from what I've seen so far, it's breaking the mold.

[just let me download]

11 minutes ago, traison said:

 

Can't tell for sure without about a week of reverse engineering work. Unless you can find some common denominator with all the cells you've crashed in, it seems more likely to me the Ostim dll is doing something it shouldn't be doing. Since the dll is not visible in the callstack that leaves bytecode edits and jumps to code caves as the likely options - both require a debugger in Skyrim while its running and a whole lot of work to detect.

 

 

May want to post one of those, as from what I've seen so far, it's breaking the mold.

 

Huge apologies about the "no cell" crash log, I may have mis-remembered because I can't find it from the past 3 months' worth of crash logs. If I find it, I will post it here. Sorry about that.

[traison]

Is the source code available for the Ostim dll you're using?

[just let me download]

19 hours ago, traison said:

Is the source code available for the Ostim dll you're using?

 

This is the Github page for the current version of Ostim, if it helps: https://github.com/VersuchDrei/OStimNG

 

Thank you very much for taking the time to look into this.

Edited January 21, 2025 by just let me download

[traison]

This is messing with everything from furniture and actors to the ufo camera and ai packages. I was expecting this to be some small utility library; this thing is massive. Had a ~30 minute look around, found some questionable things but nothing that immediately looks like its going to break cells.

 

This is a job for a debugger, and for that I'd have to be on your computer with my tools.

[just let me download]

On 1/19/2025 at 5:28 PM, traison said:

 

Can't tell for sure without about a week of reverse engineering work. Unless you can find some common denominator with all the cells you've crashed in, it seems more likely to me the Ostim dll is doing something it shouldn't be doing. Since the dll is not visible in the callstack that leaves bytecode edits and jumps to code caves as the likely options - both require a debugger in Skyrim while its running and a whole lot of work to detect.

 

 

May want to post one of those, as from what I've seen so far, it's breaking the mold.

 

Pardon the tag, but since you asked - today I just had a random crash also related to VCRUNTIME140.dll but with a different memory address at the end. What's special about this crash is that it happened completely outside of an Ostim scene. I was just walking up the stairs at the Bards' College. It was not my first time moving around the college either. crash-2025-02-01-23-41-39.log

 

This time the current cell doesn't appear in the Registers section like all previous cases, but some of the NPCs inside the Bards College are named in the log. I didn't initiate an Ostim scene in this cell (Bards College) but I did start one in the Blue Palace. I was traveling to the B.C. from the palace.

 

I don't know if this is coincidence or not, but yesterday or the day before, I disabled this setting in PO3's Save Unbaker, I'll copy/paste the entire section in the config file:

 

;Unbake persistent reference position/rotation
;Only affects immovable references (ie. statics, furniture, anything that cannot be moved using scripts)
Persistent Ref Transforms = false

 

 

Edited February 2, 2025 by just let me download

[traison]

The latest crash was caused by form id 0x000198D1 "Illdi" last modified by "Synthesis NPCs.esp". Its possible it tried to play the idle animation attached to form id 0x0006BA98 "SittingChairShoulderFlex". If it hasn't been changed, this IDLE sends the animation event called "idleChairShoulderFlex". I can't think of any way to list hkx files behind animation events right now so you'll have to figure that bit out yourself.

Edited February 2, 2025 by traison

[just let me download]

I just got a CTD on game save load, these have been popping up over the past few weeks occasionally (once every few days): crash-2025-02-02-02-52-57.log It also mentions VCRUNTIME140.dll several times. Other pieces that stand out are:

"__non_rtti_object"

""Access violation - no RTTI data!""

 

I've already ensured that my VC Redistributables are installed correctly and uncorrupted by using this tool to remove and reinstall them fresh: https://www.softpedia.com/get/System/System-Miscellaneous/MultiPack-Visual-C.shtml#download

 

This is one really puzzling CTD. I have checked out my save file with Resaver and found no errors.

[traison]

If your crash occurs in a system object, like in these latest cases: the kernel api or visual c runtime; I would start by assuming the issue is actually in whatever came before it. Finding a bug like this in a widely-used system component, while not impossible, seems high unlikely.

 

Considering RTTI is runtime type information that to me would indicate that there's a type cast performed on an object which doesn't support it. My first thought is that this smells like something a bytecode edit might have done, so basically any dll in your load order is a suspect.

 

I would start off with the following:

1. Inspect reference id 0xFF001230. Anything special about this one?
2. If 0xFF001230 is a reference to form id 0x0003DE56 then also inspect "Default Face NPCs Fixed.esp" and "Synthesis NPCs.esp" and the files these mods contain, especially dlls.
3. Figure out what the relationship is between this NPC and reference id 0xFF000823 "Tundra Raider". Did the "Tundra Raider" for instance cast a a spell on 0xFF001230, and if they did, what kind of dll mods do you have that would be intersted in spells and the things related to spell casting (like animations, rendering, causing damage, creating entities, ...)?
4. TrueDirectionalMovement.dll might have been involved, but it seems highly unlikely it caused this.

If that leads nowhere, then the only option might be to disassemble the function which returns to SkyrimSE.exe+018DC60 to see what it is doing.

[just let me download]

5 hours ago, traison said:

If your crash occurs in a system object, like in these latest cases: the kernel api or visual c runtime; I would start by assuming the issue is actually in whatever came before it. Finding a bug like this in a widely-used system component, while not impossible, seems high unlikely.

 

Considering RTTI is runtime type information that to me would indicate that there's a type cast performed on an object which doesn't support it. My first thought is that this smells like something a bytecode edit might have done, so basically any dll in your load order is a suspect.

 

I would start off with the following:

1. Inspect reference id 0xFF001230. Anything special about this one?
2. If 0xFF001230 is a reference to form id 0x0003DE56 then also inspect "Default Face NPCs Fixed.esp" and "Synthesis NPCs.esp" and the files these mods contain, especially dlls.
3. Figure out what the relationship is between this NPC and reference id 0xFF000823 "Tundra Raider". Did the "Tundra Raider" for instance cast a a spell on 0xFF001230, and if they did, what kind of dll mods do you have that would be intersted in spells and the things related to spell casting (like animations, rendering, causing damage, creating entities, ...)?
4. TrueDirectionalMovement.dll might have been involved, but it seems highly unlikely it caused this.

If that leads nowhere, then the only option might be to disassemble the function which returns to SkyrimSE.exe+018DC60 to see what it is doing.

 

Thanks for your assistance. I must admit I don't have the knowledge needed to act on some of your advice but I'm doing what I can.

 

Reference ID 0xFF001230 could not be found in xEdit so I assume it was spawned by other means (ie: a script). I'm not sure how to investigate it further.

 

So far the only thing I have been doing is disabling non-essential mods containing .dlls but so far that has not improved things.

[traison]

9 minutes ago, just let me download said:

Reference ID 0xFF001230 could not be found in xEdit so I assume it was spawned by other means (ie: a script). I'm not sure how to investigate it further.

 

An earlier save is most likely your only window to see what those references are. I don't think ReSaver shows stuff like this, maybe it does.