Crash when reloading save and going outdoors

[MonolithK]

I am incredibly sorry if I am mistaken, I shared my crash log and was advised to disable DynDOLOD (it did seem to ease my problems) so I opted to post here assuming perhaps some additional insight could be shared as not much has changed in my LO.
For clarities sake, I believe I am using the latest version of DynDOLOD 3 provided on Nexus, so the latest public release.

Scenario:
I use Alternate Start, I choose to start with a home on the farm
I load at the farm
Set up all my MCM's (this step doesn't really seem relevant to the issue but I nearly always do this in every instance so I opted to mention it)
Save game
Close Game
Boot Game
Load Save
Go outside and then it crashes at the loadscreen

Its worth mentioning, the crash seems to only happen when I boot the game, If I went outside before save and reboot I wouldn't actually crash, at least not immediately it seems.

Notworthy added mods: Equipment Durability NG, Engaging Combat, Skyshards offer skills, Skyrim Skill Uncapper (the removal of any of these did nothing seemingly)

Testing:
I checked my crash log which mentioned a type of access violation to do with "EngineFixes" which led me to believe the problem was routed there. However the results left me quite confused as my setup on that front has essentially, not changed at all. I decided to fiddle with settings a little bit.
For reference, I am using "SrtCrashFix_AE" too, which means that I must have "AnimationLoadSignedCrash" set to False In "EngineFixes" mod which I already had done.

I decided to remove "SrtCrashFix_AE" and keep "AnimationLoadSignedCrash" set to false which seemingly also alleviated the issue, I wouldn't crash, at least not immediately (I haven't tested further in this exact setup).

Then i tried this:
I kept "SrtCrashFix_AE" off but then switched "AnimationLoadSignedCrash" to true as a test, which then brought the crash upon me again immediatly.
At this point I was utterly baffled and when I had posted for help under CrashLogger to which the DynDOLOD suggestion was made to me.

In these next tests my setting are as follow:
"SrtCrashFix_AE" enabled
"AnimationLoadSignedCrash" false

When deactivating exclusivelyDynDOLOD.dll the crash stopped
When then, when deactivating the entirety of DynDOLOD_Output (all the dyndolod generation excluding texgen) the crash also went away when I went outside, I however did then crash going back indoors but I assume because in this instance I had actually used a save that was already dependent on the Dyndolod_Output.

 

Relevant DynDOLOD/Texgen Logs: https://ufile.io/a8juvo4e
Crash Log as provided on the crash logger page: https://pastebin.com/5VwcNR1Z

Hopefully I've provided as much clear information as possible and once again, I am always thankful to the support given here, I am not always the most tech smart, so I am just coming here based on what I've been able to figure out and guess so far, so I am incredibly sorry if I am blaming DynDOLOD incorrectly at the very least I may gain some further insight. I've been at this for approximately two or three days and due to my game taking a very long time to boot its a bit of a struggle to keep it up whilst also being a bit clueless!
 

Edited November 22 by MonolithK

[sheson]

8 hours ago, MonolithK said:

I am incredibly sorry if I am mistaken, I shared my crash log and was advised to disable DynDOLOD (it did seem to ease my problems) so I opted to post here assuming perhaps some additional insight could be shared as not much has changed in my LO.
For clarities sake, I believe I am using the latest version of DynDOLOD 3 provided on Nexus, so the latest public release.

Scenario:
I use Alternate Start, I choose to start with a home on the farm
I load at the farm
Set up all my MCM's (this step doesn't really seem relevant to the issue but I nearly always do this in every instance so I opted to mention it)
Save game
Close Game
Boot Game
Load Save
Go outside and then it crashes at the loadscreen

Its worth mentioning, the crash seems to only happen when I boot the game, If I went outside before save and reboot I wouldn't actually crash, at least not immediately it seems.

Notworthy added mods: Equipment Durability NG, Engaging Combat, Skyshards offer skills, Skyrim Skill Uncapper (the removal of any of these did nothing seemingly)

Testing:
I checked my crash log which mentioned a type of access violation to do with "EngineFixes" which led me to believe the problem was routed there. However the results left me quite confused as my setup on that front has essentially, not changed at all. I decided to fiddle with settings a little bit.
For reference, I am using "SrtCrashFix_AE" too, which means that I must have "AnimationLoadSignedCrash" set to False In "EngineFixes" mod which I already had done.

I decided to remove "SrtCrashFix_AE" and keep "AnimationLoadSignedCrash" set to false which seemingly also alleviated the issue, I wouldn't crash, at least not immediately (I haven't tested further in this exact setup).

Then i tried this:
I kept "SrtCrashFix_AE" off but then switched "AnimationLoadSignedCrash" to true as a test, which then brought the crash upon me again immediatly.
At this point I was utterly baffled and when I had posted for help under CrashLogger to which the DynDOLOD suggestion was made to me.

In these next tests my setting are as follow:
"SrtCrashFix_AE" enabled
"AnimationLoadSignedCrash" false

When deactivating exclusivelyDynDOLOD.dll the crash stopped
When then, when deactivating the entirety of DynDOLOD_Output (all the dyndolod generation excluding texgen) the crash also went away when I went outside, I however did then crash going back indoors but I assume because in this instance I had actually used a save that was already dependent on the Dyndolod_Output.

 

Relevant DynDOLOD/Texgen Logs: https://ufile.io/a8juvo4e
Crash Log as provided on the crash logger page: https://pastebin.com/5VwcNR1Z

Hopefully I've provided as much clear information as possible and once again, I am always thankful to the support given here, I am not always the most tech smart, so I am just coming here based on what I've been able to figure out and guess so far, so I am incredibly sorry if I am blaming DynDOLOD incorrectly at the very least I may gain some further insight. I've been at this for approximately two or three days and due to my game taking a very long time to boot its a bit of a struggle to keep it up whilst also being a bit clueless!
 

When then, when deactivating the entirety of DynDOLOD_Output (all the dyndolod generation excluding texgen) .. I however did then crash going back indoors but I assume because in this instance I had actually used a save that was already dependent on the Dyndolod_Output.

The crash log when crashing without DynDOLOD output was not provided. There is no such thing as a save being dependent on the DynDOLOD output. DynDOLOD has nothing to do with animations, it is just references and base records that no other mod or plugin uses or rely on. If you believe the unattached script instances are a problem after removing the output, remove them with FallrimTools - Script cleaner and more. The save is then clean from DynDOLOD.

I suggest to properly troubleshoot and fix the crash that happens without DynDOLOD in the load order. I would start by Rerunnning FNIS, Nemisis or Pandora for the current load order, whichever you use.

[MonolithK]

Quote

The crash log when crashing without DynDOLOD output was not provided. There is no such thing as a save being dependent on the DynDOLOD output. DynDOLOD

That's interesting, maybe I'm mistaken, I seemed to have not crashed when DynDOLOD DLL was gone specifically so I assumed that potentially if it crashed with output that something might be too tied to the save when this came up.
Anyhow, I reproduced this set up now, I may have phrased this poorly and my memory may have failed me when typing the post, it appears the game doesn't outright crash, but rather it simply is "not responding" in task manager when going back indoors in this specific set up, it will enter this state during the load screen. This may have been why I didn't provide the log. Would it be better to instead generate the papyrus log for this instance? (Also please believe me I am not being lazy, I am spending hours at this and just booting my game takes me ages already, I don't mean to offend, genuinely do want to comply!)
In this scenario I had:
AnimationLoadSignedCrash = false  
Srt_CrashFixAE Enabled

Quote

If you believe the unattached script instances are a problem after removing the output, remove them with FallrimTools - Script cleaner and more. The save is then clean from DynDOLOD.

I mean I can take your word for it, the only thing I can say is the load screen freeze (which I mistakenly described as an outright CTD) 
always is guaranteed after disabling DynDOLOD_Output which incluides the ESM/ESP and Occlusion. 

Quote

I suggest to properly troubleshoot and fix the crash that happens without DynDOLOD in the load order. I would start by Rerunnning FNIS, Nemisis or Pandora for the current load order, whichever you use.

Current test: Loading the save with DynDOLOD. Scripts+dll+resources+Output+texgen entirely disabled
Result: Load screen "Not Responding" in task manager (seemingly infinite black screen)  similar to before.

I just managed to produce this crash when going outside on the same save (when only disabling dyndolod dll so I will provide it as an extra:https://ufile.io/xsygaoyf
Although I safely assume this log will be redundant to provide but just as a precaution.

I am not sure how to diagnose a "Not responding" load screen sadly in this scenario which seems to be the information you want right now, my only assumption is the papyrus log. 

Edit: Tested with Reproduced pandora export, seemingly not fixed, at the moment I don't believe Pandora is the problem, unless you'd suggest also trying Nemesis too.

 

Edited November 23 by MonolithK

[sheson]

43 minutes ago, MonolithK said:

That's interesting, maybe I'm mistaken, I seemed to have not crashed when DynDOLOD DLL was gone specifically so I assumed that potentially if it crashed with output that something might be too tied to the save when this came up.
Anyhow, I reproduced this set up now, I may have phrased this poorly and my memory may have failed me when typing the post, it appears the game doesn't outright crash, but rather it simply is "not responding" in task manager when going back indoors in this specific set up, it will enter this state during the load screen. This may have been why I didn't provide the log. Would it be better to instead generate the papyrus log for this instance? (Also please believe me I am not being lazy, I am spending hours at this and just booting my game takes me ages already, I don't mean to offend, genuinely do want to comply!)
In this scenario I had:
AnimationLoadSignedCrash = false  
Srt_CrashFixAE Enabled

I mean I can take your word for it, the only thing I can say is the load screen freeze (which I mistakenly described as an outright CTD) 
always is guaranteed after disabling DynDOLOD_Output which incluides the ESM/ESP and Occlusion. 

Current test: Loading the save with DynDOLOD. Scripts+dll+resources+Output+texgen entirely disabled
Result: Load screen "Not Responding" in task manager (seemingly infinite black screen)  similar to before.

I just managed to produce this crash when going outside on the same save (when only disabling dyndolod dll so I will provide it as an extra:https://ufile.io/xsygaoyf
Although I safely assume this log will be redundant to provide but just as a precaution.

I am not sure how to diagnose a "Not responding" load screen sadly in this scenario which seems to be the information you want right now, my only assumption is the papyrus log. 

Edit: Tested with Reproduced pandora export, seemingly not fixed, at the moment I don't believe Pandora is the problem, unless you'd suggest also trying Nemesis too.

 

Both provided crash logs are similar and seem to be related animations in EngineFixes.DLL, the player character, the skeleton and maybe Synthesis.esp. Maybe with EngineFixes alternative memory management etc. Troubleshoot that.
I would test without engine fixes., without Synthesis.esp and/or generate it from scratch for the current load order, test without any mod that has to do with animations etc. If required do proper troubleshooting with an older save or a new save.

Removing the DynDOLOD.DLL 2.45, means the DynDOLODpuot plugin will fall back to PapyruUtil.dll for dynamic LOD. However, the crash log does not point anything related to dynamic LOD or LOD in general.

If DynDOLOD output, its requirements and the remaining unattached script instances are all removed it can not really cause anything. You might want to test what happens, hiding the *.SKSE co-save file so the game only loads the *.ess game save, since PapyrusUtil or other DLL mods use it to store things, while the DynDOLOD.DLL you are using uses the game save. If a plugin for which data exists in the save files does not exist, that data is discarded with the next save. So I would also try to create a "clean" save after loading such a save in the same interior and then remove any unattached script instances from that as mentioned earlier.

[MonolithK]

Quote

Maybe with EngineFixes alternative memory management etc. Troubleshoot that.

Alternate Memory Management = False results in "Not Responding" on main menu
It did however seemingly generate a crash log?: https://ufile.io/ogid2oa3

Quote

I would test without engine fixes

Main Menu CTD, Can't personally make guesses from this variety of the log (not that the format doesn't add up to me just I don't immediately recognise anything especially since the access violation codes are intelligible to me)
Log:  https://ufile.io/lp9n9afa
 

Quote

without Synthesis.esp and/or generate it from scratch for the current load order

I willl attempt these steps shortly
As well as a clean no DynDOLOD save with no content related as much as I can as an extra test.

Edit:
New save, all DynDLOD content entirely removed and Seasons of Skyrim (Synthesis and bashed redone too). When I reload and go outside, all is okay and then back in doors I get "Not Responding" yet again. I will have to further troubleshoot my mods, but now I am genuinly at a loss as the Crash Log suggestion was the only lead I had. Apologies, I will attempt any fixes that I can now.

At least with this it seems certain the problem does not lie with DynDOLOD
And you seem to believe It'd be correct to look towards animation mods as culprits? I mostly ask because, my set up on that front hasn't changed at all since the past so I'm surprised I am getting an issue so consistantly suddenly. Wintersun appears to be the closest culprit I could think of as far as "animation" might go.

Edit 2; Definitely got the crash with and without synthesis including on new saves and with a fresh generation of synthesis.

Edited November 24 by MonolithK

[sheson]

This more and more looks like some kind of memory or counter overflow issue. Since I do not have these or investigate these, there are probably better locations to ask about and troubleshoot these. Check the virtual memory / page file settings of the OS. Let the OS handle it automatically. If that is already the case, then manually set a page file the same size as the main memory, which seems to be 32 GB.

Other than that, try to remove mods that use a lot of memory in your setup. Just use trial and error, e.g. remove first what can easily be removed and has a large install size in assets that require to be loaded at all/most times, like models and textures used everywhere for example.

[MonolithK]

Quote

Check the virtual memory / page file settings of the OS. Let the OS handle it automatically. If that is already the case, then manually set a page file the same size as the main memory, which seems to be 32 GB.

I am not quite sure in how to do this part, a quick google search is also throwing me off a bit (the page part), however it does seem like Windows has it set to automatic as far as I can understand so far!
 

Quote

Other than that, try to remove mods that use a lot of memory in your setup. Just use trial and error, e.g. remove first what can easily be removed and has a large install size in assets that require to be loaded at all/most times, like models and textures used everywhere for example.

I genuinely don't mind scaling back, especially if it can restore my game to being playable lol!
However two primary questions to ask:

1. Is this "memory" problem a case of the game being at fault, or for example, if I added more ram would I be set to go and continue with this modlist? Once again, don't mind dialling everything back a bit, I'd just like to have a bit more understanding of what it is I am facing from your perspective, if I've pushed the game to the limit or my computer for example.

2.When you say mods that are "always" there would that include "Sunhelm" or "Immersive Speechcraft", perhaps even "Wintersun". I understand these mods do not have a large install size but would you weigh these as significant contributions on your eyes or would you says I should focus on toning down graphics primarily? E.g. Removing "Happy Little Trees". I understand you'd suggest "Happy Little Trees" most out of all mods I mention here, but I am curious how significant you think the others could be in the grand scheme of things. Another reason is because, Community Shaders can be demanding technically, but I believe the filesizes are also rather tame. There is also "BS:Bruma" and "Chantarelle", my question for these is do these count as "all the time" or do they not contribute much? In my eyes I view these as "not always present" but they do bare large filesizes

I will be attempting to tone down and remove some things, I just want ensure I am targeting things that are at all worthwhile.

Edited November 24 by MonolithK

[sheson]

29 minutes ago, MonolithK said:

I am not quite sure in how to do this part, a quick google search is also throwing me off a bit (the page part), however it does seem like Windows has it set to automatic as far as I can understand so far!
 

I genuinely don't mind scaling back, especially if it can restore my game to being playable lol!
However two primary questions to ask:

1. Is this "memory" problem a case of the game being at fault, or for example, if I added more ram would I be set to go and continue with this modlist? Once again, don't mind dialling everything back a bit, I'd just like to have a bit more understanding of what it is I am facing from your perspective, if I've pushed the game to the limit or my computer for example.

2.When you say mods that are "always" there would that include "Sunhelm" or "Immersive Speechcraft", perhaps even "Wintersun". I understand these mods do not have a large install size but would you weigh these as significant contributions on your eyes or would you says I should focus on toning down graphics primarily? E.g. Removing "Happy Little Trees". I understand you'd suggest "Happy Little Trees" most out of all mods I mention here, but I am curious how significant you think the others could be in the grand scheme of things. Another reason is because, Community Shaders can be demanding technically, but I believe the filesizes are also rather tame. There is also "BS:Bruma" and "Chantarelle", my question for these is do these count as "all the time" or do they not contribute much? In my eyes I view these as "not always present" but they do bare large filesizes

I will be attempting to tone down and remove some things, I just want ensure I am targeting things that are at all worthwhile.

The crash logs show that only 50% to 60% of main memory is used, so it does not seem to run out of memory. So this maybe because some kind of limit for something is reached. It maybe animations related or not.

I mean mods with meshes or textures that are used everywhere, like fauna, mountains, landscapes, etc. just to reduce the overall memory footprint for testing. New world mods that use ESM plugins are typically fine. There will be a reference cap warning from Engine Fixes if the number of certain records become a problem.

[MonolithK]

Quote

The crash logs show that only 50% to 60% of main memory is used, so it does not seem to run out of memory. So this maybe because some kind of limit for something is reached. It maybe animations related or not.

I have tried with roughly most of my animation related mods turned off sadly and I believe the issue still persisted. Will try a fresh take on this again exclusively.

Quote

I mean mods with meshes or textures that are used everywhere, like fauna, mountains, landscapes, etc. just to reduce the overall memory footprint for testing. New world mods that use ESM plugins are typically fine. There will be a reference cap warning from Engine Fixes if the number of certain records become a problem.

Ahh okay, I see then so we are just doing further testing! My apologies!
Well so far, I've hit a crash with just removing a few still (loading a save).

In this instance: BnP male/female textures, happy little trees, skyland AIO and some exported Bodyslide high poly meshes from casual clothes. Appears to be a similar crash at least
3 Logs: https://ufile.io/m9dtri8e
Access error variates but nothing substantial seemingly that stand outs in particular 1st log may be the best for reference but it still included Happy Little Trees, 3rd log is a new save. I it might not be memory, the only reason I will say is because the mod that seemed the "heaviest" when I added it was actually Happy Little Trees, there's also "Depths of skyrim" which I forgot to deactivate, it generally adds more content underwater but this would also be the next most heavy mod I can think of that I'd added.

Is it possible something in my Skyrim Install is "corrupt" that could potentially explain these errors? I am using MO2 which makes me thing its rather unlikely but its one of the few notions I can think of.

Edited November 24 by MonolithK

[sheson]

1 hour ago, MonolithK said:

I have tried with roughly most of my animation related mods turned off sadly and I believe the issue still persisted. Will try a fresh take on this again exclusively.

Ahh okay, I see then so we are just doing further testing! My apologies!
Well so far, I've hit a crash with just removing a few still (loading a save).

In this instance: BnP male/female textures, happy little trees, skyland AIO and some exported Bodyslide high poly meshes from casual clothes. Appears to be a similar crash at least
3 Logs: https://ufile.io/m9dtri8e
Access error variates but nothing substantial seemingly that stand outs in particular 1st log may be the best for reference but it still included Happy Little Trees, 3rd log is a new save. I it might not be memory, the only reason I will say is because the mod that seemed the "heaviest" when I added it was actually Happy Little Trees, there's also "Depths of skyrim" which I forgot to deactivate, it generally adds more content underwater but this would also be the next most heavy mod I can think of that I'd added.

Is it possible something in my Skyrim Install is "corrupt" that could potentially explain these errors? I am using MO2 which makes me thing its rather unlikely but its one of the few notions I can think of.

You can see in the crash logs that memory usage is consistent around 18GB, so reducing meshes/textures did not seem to have an effect on that.

That would be the point to do some binary search, e.g. disable half the stuff and if it makes a difference, disable the other half and repeat that until you only have the lowest number of mods left that are required for the problem to occur. That is often quicker than it sounds.

If something is correct, like invalid assets, broken plugins with unresolved form IDs for example, then the crash log typically points right to it.
While the crash log seems to indicate hdtSMP64.dll in particular, we know from experience, it is most likely only mentioned because it runs in the main game loop, so all the information in the stacks could just be unrelated.

[MonolithK]

20 hours ago, sheson said:

You can see in the crash logs that memory usage is consistent around 18GB, so reducing meshes/textures did not seem to have an effect on that.

That would be the point to do some binary search, e.g. disable half the stuff and if it makes a difference, disable the other half and repeat that until you only have the lowest number of mods left that are required for the problem to occur. That is often quicker than it sounds.

 

I actually tried before sadly with no success, last night I began this process again however and I think I've found some success! I haven't pinpointed the exact culprit but it seems to me like the culprit is lurking in a category of mods I've labelled as "gameplay" this would include Sunhelm for example. After deactivation approximately 80% of the mods in there I seem to be getting no crash I think.
However obviously I need to further test and round down, as from prior tests the issue did seem to have some degree of inconsistency (very unlikely but sometimes the game would work). At the moment I have tested about 30% of my "gameplay" mods. I will continue, hopefully this isn't just a coincidence. A part of my is worried the issue might actually have been something wrong with my load order priority, but I feel like that would still be too extreme. 

Quote

If something is correct, like invalid assets, broken plugins with unresolved form IDs for example, then the crash log typically points right to it.
While the crash log seems to indicate hdtSMP64.dll in particular, we know from experience, it is most likely only mentioned because it runs in the main game loop, so all the information in the stacks could just be unrelated.

I'll actually keep an eye out on this, to my memory I actually did have some extra hdstsmp addon of sorts beyond just the default mod so maybe I should take a second look either way.

I will try to report back with the "problem" mod if I am lucky enough to find it, although I don't feel entirely hopeful.

 

EDIT: I seem to have a pretty good selection of mods that could be responsible now, still no exact cause found yet but the culprits don't seem to be a large pool.

AddItemMenuSE - Highly suspicious but not sure why its suddenly causing problems (had it for ages)
Campfire 1.12.1SEVR Release
Campfire 1.12.1 and Frostfall 3.4.1SE
Alternate Conversation Camera
Sunhelm Survival
Sunhelm Compatibility Patches
Sunhelm Simple Weather Icons
Sunhelm AutoEatDrink
Sunhelm Waterborne Diseases
Dirt and Blood
Dirt and Blood Expanded
 

EDIT2: Can't believe it and I am utterly stumped on how its suddenly become a problem, but at the moment it seems like Campfire is the problem. I am however COMPLETELY confused on how this has happened. When I have Campfire disabled, the Crashes seem to have totally stopped unless I'm speaking too soon. But as it is tit seems like Campfire is the problem. But I do not at all understand how on earth it has become a problem. I am unsure yet if its related to patches etc but this seems to be my deduction so far.

EDIT3: Enabled Campfire again in my load order with no additional patches and I managed to produce the crash almost instantly. It does indeed seem to me that something is wrong with Campfire for me and i am not sure why.

In Papyrus tweak NG I am using "BSpeedUpNativeCalls = true" this is the only potential reason I can think of.

These two logs were produced after I began to realise the cause was Campfire, there is only a mild interesting difference I noticed. The access violation totally changed from "EngineFixes" to "Skyrim.exe" once I disabled supporting patches for campfire. The crash seems to be the same one I've been dealing with however. The newer log has the patches disabled, the older log has the campfire patches enabled.
 

Logs:
https://ufile.io/olr6pweo

Edited November 25 by MonolithK

[sheson]

On 11/25/2024 at 3:36 AM, MonolithK said:

 

I actually tried before sadly with no success, last night I began this process again however and I think I've found some success! I haven't pinpointed the exact culprit but it seems to me like the culprit is lurking in a category of mods I've labelled as "gameplay" this would include Sunhelm for example. After deactivation approximately 80% of the mods in there I seem to be getting no crash I think.
However obviously I need to further test and round down, as from prior tests the issue did seem to have some degree of inconsistency (very unlikely but sometimes the game would work). At the moment I have tested about 30% of my "gameplay" mods. I will continue, hopefully this isn't just a coincidence. A part of my is worried the issue might actually have been something wrong with my load order priority, but I feel like that would still be too extreme. 

I'll actually keep an eye out on this, to my memory I actually did have some extra hdstsmp addon of sorts beyond just the default mod so maybe I should take a second look either way.

I will try to report back with the "problem" mod if I am lucky enough to find it, although I don't feel entirely hopeful.

 

EDIT: I seem to have a pretty good selection of mods that could be responsible now, still no exact cause found yet but the culprits don't seem to be a large pool.

AddItemMenuSE - Highly suspicious but not sure why its suddenly causing problems (had it for ages)
Campfire 1.12.1SEVR Release
Campfire 1.12.1 and Frostfall 3.4.1SE
Alternate Conversation Camera
Sunhelm Survival
Sunhelm Compatibility Patches
Sunhelm Simple Weather Icons
Sunhelm AutoEatDrink
Sunhelm Waterborne Diseases
Dirt and Blood
Dirt and Blood Expanded
 

EDIT2: Can't believe it and I am utterly stumped on how its suddenly become a problem, but at the moment it seems like Campfire is the problem. I am however COMPLETELY confused on how this has happened. When I have Campfire disabled, the Crashes seem to have totally stopped unless I'm speaking too soon. But as it is tit seems like Campfire is the problem. But I do not at all understand how on earth it has become a problem. I am unsure yet if its related to patches etc but this seems to be my deduction so far.

EDIT3: Enabled Campfire again in my load order with no additional patches and I managed to produce the crash almost instantly. It does indeed seem to me that something is wrong with Campfire for me and i am not sure why.

In Papyrus tweak NG I am using "BSpeedUpNativeCalls = true" this is the only potential reason I can think of.

These two logs were produced after I began to realise the cause was Campfire, there is only a mild interesting difference I noticed. The access violation totally changed from "EngineFixes" to "Skyrim.exe" once I disabled supporting patches for campfire. The crash seems to be the same one I've been dealing with however. The newer log has the patches disabled, the older log has the campfire patches enabled.
 

Logs:
https://ufile.io/olr6pweo

You do have MaxStdio=8192 and SaveGameMaxSize=true in the EngineFixes.toml, right?

[MonolithK]

Hello! Sorry I've been doing multiple cases of troubleshooting since, I'm not even sure if I've fixed the problem yet honestly. However it is my belief that I tracked part of the problem belonging to an MCM settings that starts always turned on and the option in the MCM itself naturally prone to causing problems. I have since disabled and have definitely had much more stability.

I was lucky, as part of my new troubleshooting zone was in the dragonborn DLC which let me recreate part of the problem far more consistently and let to me at least resolvie part of the problem. Since, then I have received a crash log attributed to "Engine Fixes" as usual but I am doing further testing in an attempt to see if further adjustments or any mods have slipped past me (mods I may have forgotten to update) doing a very thorough comb, I had one suspicion with "Creation kit fixes" due to the .dll files provided in it, I have since upgraded to "CK platform Extended" in the hopes that this may have been somewhat responsible for my issues, although, it is nothing that I am certain about. I will be able to provide a new crash log in the coming days/hours most likely as I am almost certain the issue persists, I am just scrambling to further round it down which took a few days of severe crash courses in game but I am 90% the issue still exists, just not as large scale where I could reproduce it very frequently so I'll need a bit more time to produce a newer log in a refined load order. I also recently upgraded to using DynDOLOD DLL NG (literally two days ago) so I am just trying to do a more thorough inspection overall.

On 11/29/2024 at 8:09 AM, sheson said:

You do have MaxStdio=8192 and SaveGameMaxSize=true in the EngineFixes.toml, right?

I have the savegame size fix applied!  however:
"MaxStdio = 2048" is what I have set in that option, would you recommend tweaking it to the number you've suggested?
 

Edited yesterday at 04:47 AM by MonolithK

[sheson]

2 hours ago, MonolithK said:

Hello! Sorry I've been doing multiple cases of troubleshooting since, I'm not even sure if I've fixed the problem yet honestly. However it is my belief that I tracked part of the problem belonging to an MCM settings that starts always turned on and the option in the MCM itself naturally prone to causing problems. I have since disabled and have definitely had much more stability.

I was lucky, as part of my new troubleshooting zone was in the dragonborn DLC which let me recreate part of the problem far more consistently and let to me at least resolvie part of the problem. Since, then I have received a crash log attributed to "Engine Fixes" as usual but I am doing further testing in an attempt to see if further adjustments or any mods have slipped past me (mods I may have forgotten to update) doing a very thorough comb, I had one suspicion with "Creation kit fixes" due to the .dll files provided in it, I have since upgraded to "CK platform Extended" in the hopes that this may have been somewhat responsible for my issues, although, it is nothing that I am certain about. I will be able to provide a new crash log in the coming days/hours most likely as I am almost certain the issue persists, I am just scrambling to further round it down which took a few days of severe crash courses in game but I am 90% the issue still exists, just not as large scale where I could reproduce it very frequently so I'll need a bit more time to produce a newer log in a refined load order. I also recently upgraded to using DynDOLOD DLL NG (literally two days ago) so I am just trying to do a more thorough inspection overall.

I have the savegame size fix applied!  however:
"MaxStdio = 2048" is what I have set in that option, would you recommend tweaking it to the number you've suggested?
 

There is no reason to not set Maxstdio to the supported maximum.

When troubleshooting remove everything that is not required for the crash to happen until only the parts remain that are absolutely required for the crash to happen. Only then start changing parts or records of the remaining things to narrow it down.