DynDOLOD DLL

[Ylikollikas]

When doing the binary search method, I forgot to account for persistent worldspace cell. It indeed seems to be something contained in the persistent worldspace cell. The crash doesn't happen if I just delete persistent worldspace cell and nothing else. I'm going to find it with binary search.

Edited February 28 by Ylikollikas

[Ylikollikas]

Alright, so my binary search lead me to "Tamriel_ShesonObject" cause. First I suspected it is not actually cause, rather removing the master activator would have prevented the real culprit from presenting itself.  However, this was verified by removing all references in worldspace / cell records in dyndolod.esp except the "Tamriel_ShesonObject", which caused the crash to still remain. So it seems Tamriel_ShesonObject is the reference causing the crash.

Basically the situation is:

Only "Tamriel_ShesonObject" -> crash

Everything but "Tamriel_ShesonObject" -> no crash

nvm was too hasty, did few more rounds of death -> reload and the crash did happen

I will investigate more. Also since if someone else who is getting similar crashes could also do similar binary search that'd be great.

Edited February 28 by Ylikollikas

[sheson]

11 hours ago, Ylikollikas said:

Alright, so my binary search lead me to "Tamriel_ShesonObject" cause. First I suspected it is not actually cause, rather removing the master activator would have prevented the real culprit from presenting itself.  However, this was verified by removing all references in worldspace / cell records in dyndolod.esp except the "Tamriel_ShesonObject", which caused the crash to still remain. So it seems Tamriel_ShesonObject is the reference causing the crash.

Basically the situation is:

Only "Tamriel_ShesonObject" -> crash

Everything but "Tamriel_ShesonObject" -> no crash

nvm was too hasty, did few more rounds of death -> reload and the crash did happen

I will investigate more. Also since if someone else who is getting similar crashes could also do similar binary search that'd be great.

 Not everything that is required for a problem to happen is the cause of the problem.

You need to keep the ACTI base record of the reference and the quest it references. Make sure to not accidently create unresolved form IDs causing issues, especially in the reference.

If you only have the reference and its activator base record left in DynDOLOD.esp, clean its masters so the DynDOLOD.esm is not loaded automatically. To test if hiding it makes a difference.

If it seems the DynDOLOD.esm is required for the problem to happen, do the same binary search with it.

If it seems the DynDOLOD.esm is not required, we will have to check the data used by the DynDOLOD DLL plugin. Start by testing without DynDOLOD.DLL plugin in the the load order. If that is the case, also check if removing PapyrusTweaks.dll makes a difference.

If the DynDOLOD DLL is required for the problem and PapyrusTweaks.dll is not, start by removing everything under [Resets] from  ..\skse\plugins\DynDOLOD_Data\DynDOLOD_NG_Tamriel.txt and if that has an effect, do a binary search with those lines. Next would be [Markers] which are all in DynDOLOD.esm and should not do anything if the plugin is not loaded. Then it would be [Objects] which are all in in DynDOLOD.esp and are all removed, too.

[Ylikollikas]

Thanks for the directions on how to proceed. I'm a bit busy for the coming days, so I can't test this stuff soon, but I'll report back when I have time to test this stuff out. Also, someone I know said generating DynDOLOD with non-DLL version fixed the problem for them, so I might eventually test the same. Though staying on NG would be preferred to avoid the need to manually fix large reference bugs.

[Blackread]

Hello sheson,

I'm seeing crashes on loading a save with the latest DynDOLOD 3 Alpha. The basic sequence leading to the crash is: Make a save in an exterior location -> Go somewhere else -> After a while load the save -> Crash.

Here's a video of a repeatable test I deviced. It looks a bit odd, but the crash does happen during normal gameplay too. It's uncut footage including all loading times, the main test starts around 2:25.

Here's the top part of the crash log produced for quick examination:

Spoiler

Unhandled native exception occurred at 0x7FF6A6CF72DF (SkyrimSE.exe+C072DF) on thread 9480!

FrameworkName: NetScriptFramework
FrameworkVersion: 15
FrameworkArchitecture: x64
GameLibrary: SkyrimSE
GameLibraryVersion: 18
ApplicationName: SkyrimSE.exe
ApplicationVersion: 1.5.97.0
VersionInfo: Successfully loaded
Time: 04 Mar 2024 20:01:07.760

Possible relevant objects (2)
{
  [  43]    TESObjectSTAT(Name: DoNotPlaceSmallCritterLandingMarkerHelper, FormId: 000C2D47, File: `Skyrim.esm`)
  [  43]    TESObjectREFR(FormId: FF000BD6, BaseForm: TESObjectSTAT(Name: DoNotPlaceSmallCritterLandingMarkerHelper, FormId: 000C2D47, File: `Skyrim.esm`))
}

Probable callstack
{
  [0]   0x7FF6A6CF72DF     (SkyrimSE.exe+C072DF)          MutexRW::EnterReadLock_C072D0+F
  [1]   0x7FF6A62097D8     (SkyrimSE.exe+1197D8)          BSExtraDataList::GetLeveledNPC_1197B0+28
  [2]   0x7FF6A6386482     (SkyrimSE.exe+296482)          TESObjectREFR::unk_296470+12
  [3]   0x7FF6A666E5AD     (SkyrimSE.exe+57E5AD)          unk_57E330+27D
  [4]   0x7FF6A666D607     (SkyrimSE.exe+57D607)          unk_57D1A0+467
  [5]   0x7FFD2862051B     (skse64_1_5_97.dll+1051B)      
  [6]   0x23400000000                                     
  [7]   0xA60000003D                                      
  [8]   0x234CD007AF0                                     
  [9]   0x234CD007040                                     
  [10]  0xA686AFF3B0                                      
  [11]  0x23173D7BF79                                     
  [12]  0xFFFFFFFFFFFFFFFE                                
  [13]  0x232B4D9F520                                     
  [14]  0x50002                                           
  [15]  0x7FF6A76111A8     (SkyrimSE.exe+15211A8)         
  [16]  0xA686AFF2F8                                      
}

Registers
{
  AX:       0x2508             (u16):[9480]
  BX:       0x81               (u8):[129]
  CX:       0x81               (u8):[129]
  DX:       0x7FF6A760F2B0     (SkyrimSE.exe+151F2B0) (void*)
  SI:       0x231E58A38B0      (void*)
  DI:       0x81               (u8):[129]
  BP:       0xA686AFEDF9       (void*)
  SP:       0xA686AFECF0       (void*)
  IP:       0x7FF6A6CF72DF     (SkyrimSE.exe+C072DF) (void*)
  R8:       0x0                (NULL)
  R9:       0xF                (u8):[15]
  R10:      0x7FFDBF580000     (VCRUNTIME140.dll+0) (char*) "MZ?"
  R11:      0xA686AFED70       (void*)
  R12:      0x1                (u8):[1]
  R13:      0x23147F28100      (void*)
  R14:      0x2344635FF80      (BaseFormComponent*)
  R15:      0xFF000BD8         (u32):[4278193112]
  Flags:    0x10206           
  XMM0:     (double)-5.16813666798352E-315 / (float)0.212248
  XMM1:     (double)-1.24855195698456E+122 / (float)7.64104E-20
  XMM2:     (double)-5.16813666798352E-315 / (float)0.212248
  XMM3:     (double)0 / (float)0
  XMM4:     (double)0.00121353297694337 / (float)1.202304E-21
  XMM5:     (double)2.07507571253324E-322 / (float)5.885454E-44
  XMM6:     (double)0 / (float)0
  XMM7:     (double)0 / (float)0
  XMM8:     (double)0 / (float)0
  XMM9:     (double)0 / (float)0
  XMM10:    (double)0 / (float)0
  XMM11:    (double)0 / (float)0
  XMM12:    (double)0 / (float)0
  XMM13:    (double)0 / (float)0
  XMM14:    (double)0 / (float)0
  XMM15:    (double)0 / (float)0
}

Full crash log along with DynDOLOD logs here: https://mega.nz/file/sPlDHADb#eP0vryOYQeVPwuYiHEDCT_DoPAFc02nXDmvKr3bPqUA

Another user also gave similar reports about crashing on load with this crash log: https://pastebin.com/vgx3Kiz7

I've also seen this crash at 902691 but the one at C072DF is a lot more common for me. The other user said that after regenerating LODs without Large Ref Bug Workarounds they were no longer crashing, but I haven't verified this myself. I have however been unable to replicate the crash without a DynDOLOD output.

Edit: I also noticed that while the link to the DLL NG download on dyndolod.info says Alpha-15, the downloaded file is actually Alpha-14.

Edited March 4 by Blackread

[soupdragon]

First time using Dydolod.dll I'm getting a "Dyndolod requires SKSE" message everytime game starts. MCM menu is totally blank.

DynDOLOD-DLL-SE.1.5.97.7z installed

DynDOLOD-Scripts.2.82.8.7z installed and overwrites other scripts from resources etc

SKSE version 2.0.20 installed the game reports it fine no other issues reported

edit: ok deleted both of those tried NG version from Nexus instead still nothing happening but at least I have a Dyndolod.log this time and reports

Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Worlds.txt
Error opening file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Worlds.txt
problem with worlds config file

sounds like I need to have another run at it with with the other dll I'll have another go tomorrow, need sleep

edit2: if anyone finds this in future use the NG version from Nexus that one works the version thats listed on STEPS is  defunct

[sheson]

On 3/4/2024 at 7:48 PM, Blackread said:

Hello sheson,

I'm seeing crashes on loading a save with the latest DynDOLOD 3 Alpha. The basic sequence leading to the crash is: Make a save in an exterior location -> Go somewhere else -> After a while load the save -> Crash.

Full crash log along with DynDOLOD logs here: https://mega.nz/file/sPlDHADb#eP0vryOYQeVPwuYiHEDCT_DoPAFc02nXDmvKr3bPqUA

I've also seen this crash at 902691 but the one at C072DF is a lot more common for me.  I have however been unable to replicate the crash without a DynDOLOD output.

Edit: I also noticed that while the link to the DLL NG download on dyndolod.info says Alpha-15, the downloaded file is actually Alpha-14.

Test the game with DynDOLOD DLL NG and Scripts Alpha-16.
If this does not change anything, read all the posts between Ylikollikas and me https://stepmodifications.org/forum/topic/13716-dyndolod-dll/?do=findComment&comment=277649 There is a next troubleshooting step to do once time permits...

The Nexus link is fixed.

[sheson]

2 hours ago, soupdragon said:

First time using Dydolod.dll I'm gettinga "Dyndolod requires SKSE" message everytime game starts. MCM menu is totally blank.

DynDOLOD-DLL-SE.1.5.97.7z installed

DynDOLOD-Scripts.2.82.8.7z installed and overwrites other scripts from resources etc

SKSE version 2.0.20 installed the game reports it fine no other issues reported

edit: ok deleted both of those tried NG version from Nexus instead still nothing happening but at least I have a Dyndolod.log this time and reports

Reading file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Worlds.txt
Error opening file Data/SKSE/Plugins/DynDOLOD_Data/DynDOLOD_NG_Worlds.txt
problem with worlds config file

sounds like I need to have another run at it with with the other dll

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts.

https://dyndolod.info/FAQ#DynDOLOD-requires-SKSE:
SKSE is not installed, outdated or not running at all.
Make sure you have the correct SKSE version for the current Skyrim version that is used and none of its file are overwritten by other mods.
Check the logs in c:\Users\[USERNAME]\Documents\My Games\[Skyrim|Skyrim Special Edition|Skyrim VR]\SKSE\

DynDOLOD DLL NG and Scripts is not a drop-in replacement for DynDOLOD DLL SE. See https://dyndolod.info/Help/Large-Reference-Bugs-Workarounds
It also requires a working SKSE installation, so you need to fix that anyways.

[aljoxo]

On 3/4/2024 at 1:48 PM, Blackread said:

Hello sheson,

I'm seeing crashes on loading a save with the latest DynDOLOD 3 Alpha. The basic sequence leading to the crash is: Make a save in an exterior location -> Go somewhere else -> After a while load the save -> Crash.

Here's a video of a repeatable test I deviced. It looks a bit odd, but the crash does happen during normal gameplay too. It's uncut footage including all loading times, the main test starts around 2:25.

Here's the top part of the crash log produced for quick examination:

  Reveal hidden contents

Unhandled native exception occurred at 0x7FF6A6CF72DF (SkyrimSE.exe+C072DF) on thread 9480!

FrameworkName: NetScriptFramework
FrameworkVersion: 15
FrameworkArchitecture: x64
GameLibrary: SkyrimSE
GameLibraryVersion: 18
ApplicationName: SkyrimSE.exe
ApplicationVersion: 1.5.97.0
VersionInfo: Successfully loaded
Time: 04 Mar 2024 20:01:07.760

Possible relevant objects (2)
{
  [  43]    TESObjectSTAT(Name: DoNotPlaceSmallCritterLandingMarkerHelper, FormId: 000C2D47, File: `Skyrim.esm`)
  [  43]    TESObjectREFR(FormId: FF000BD6, BaseForm: TESObjectSTAT(Name: DoNotPlaceSmallCritterLandingMarkerHelper, FormId: 000C2D47, File: `Skyrim.esm`))
}

Probable callstack
{
  [0]   0x7FF6A6CF72DF     (SkyrimSE.exe+C072DF)          MutexRW::EnterReadLock_C072D0+F
  [1]   0x7FF6A62097D8     (SkyrimSE.exe+1197D8)          BSExtraDataList::GetLeveledNPC_1197B0+28
  [2]   0x7FF6A6386482     (SkyrimSE.exe+296482)          TESObjectREFR::unk_296470+12
  [3]   0x7FF6A666E5AD     (SkyrimSE.exe+57E5AD)          unk_57E330+27D
  [4]   0x7FF6A666D607     (SkyrimSE.exe+57D607)          unk_57D1A0+467
  [5]   0x7FFD2862051B     (skse64_1_5_97.dll+1051B)      
  [6]   0x23400000000                                     
  [7]   0xA60000003D                                      
  [8]   0x234CD007AF0                                     
  [9]   0x234CD007040                                     
  [10]  0xA686AFF3B0                                      
  [11]  0x23173D7BF79                                     
  [12]  0xFFFFFFFFFFFFFFFE                                
  [13]  0x232B4D9F520                                     
  [14]  0x50002                                           
  [15]  0x7FF6A76111A8     (SkyrimSE.exe+15211A8)         
  [16]  0xA686AFF2F8                                      
}

Registers
{
  AX:       0x2508             (u16):[9480]
  BX:       0x81               (u8):[129]
  CX:       0x81               (u8):[129]
  DX:       0x7FF6A760F2B0     (SkyrimSE.exe+151F2B0) (void*)
  SI:       0x231E58A38B0      (void*)
  DI:       0x81               (u8):[129]
  BP:       0xA686AFEDF9       (void*)
  SP:       0xA686AFECF0       (void*)
  IP:       0x7FF6A6CF72DF     (SkyrimSE.exe+C072DF) (void*)
  R8:       0x0                (NULL)
  R9:       0xF                (u8):[15]
  R10:      0x7FFDBF580000     (VCRUNTIME140.dll+0) (char*) "MZ?"
  R11:      0xA686AFED70       (void*)
  R12:      0x1                (u8):[1]
  R13:      0x23147F28100      (void*)
  R14:      0x2344635FF80      (BaseFormComponent*)
  R15:      0xFF000BD8         (u32):[4278193112]
  Flags:    0x10206           
  XMM0:     (double)-5.16813666798352E-315 / (float)0.212248
  XMM1:     (double)-1.24855195698456E+122 / (float)7.64104E-20
  XMM2:     (double)-5.16813666798352E-315 / (float)0.212248
  XMM3:     (double)0 / (float)0
  XMM4:     (double)0.00121353297694337 / (float)1.202304E-21
  XMM5:     (double)2.07507571253324E-322 / (float)5.885454E-44
  XMM6:     (double)0 / (float)0
  XMM7:     (double)0 / (float)0
  XMM8:     (double)0 / (float)0
  XMM9:     (double)0 / (float)0
  XMM10:    (double)0 / (float)0
  XMM11:    (double)0 / (float)0
  XMM12:    (double)0 / (float)0
  XMM13:    (double)0 / (float)0
  XMM14:    (double)0 / (float)0
  XMM15:    (double)0 / (float)0
}

Full crash log along with DynDOLOD logs here: https://mega.nz/file/sPlDHADb#eP0vryOYQeVPwuYiHEDCT_DoPAFc02nXDmvKr3bPqUA

Another user also gave similar reports about crashing on load with this crash log: https://pastebin.com/vgx3Kiz7

I've also seen this crash at 902691 but the one at C072DF is a lot more common for me. The other user said that after regenerating LODs without Large Ref Bug Workarounds they were no longer crashing, but I haven't verified this myself. I have however been unable to replicate the crash without a DynDOLOD output.

Edit: I also noticed that while the link to the DLL NG download on dyndolod.info says Alpha-15, the downloaded file is actually Alpha-14.

Attached files are crashlogs generated from the crash after loading save, discussed above by Blackread. On 1.6 the crash address appears to be 09432E2 instead of 1.5's 902691 / C072DF. 

These logs were collected from 3 wabbajack lists (Fahluaan, Vagabond, and Nordic Souls)

Nordic Souls and Fahluaan have both swapped from DynDOLOD NG to regular DynDOLOD scripts in recent updates (this past weekend) and the crashes ceased to occur. 

I have worked with Ylikollikas and other Wabbajack list developers over the past month trying to diagnose this crash, and with the removal of Dyn NG seemingly stopping the crash, I'm fairly confident in saying the issue was a part of DynDOLOD NG version 13+ (though ylik and I originally believed it to be an issue with DynDOLOD alpha 154+ which came out around the same time), as the crash on load popped up in several Wabbajack lists after the move to NG version 13. I would have liked to test this by trying downgraded version 12 at some point but I did not have access to the archive file anywhere so I was unable to.

 

crash-2024-02-12-05-34-36.log crash-2024-02-14-05-24-21.log crash-2024-02-14-05-41-43.log crash-2024-02-15-04-32-05.log crash-2024-02-16-23-12-00.log crash-2024-02-18-19-11-57.log crash-2024-02-19-19-53-16.log crash-2024-02-20-21-25-10.log crash-2024-02-21-20-01-28.log crash-2024-02-21-22-49-03.log crash-2024-02-22-19-53-19.log 1-crash-2024-02-09-20-46-20.log 1-crash-2024-02-13-03-57-35.log Crash_2024_2_22_15-11-58.txt Crash_2024_2_22_15-32-22.txt crash-2024-02-04-10-58-17 (1).log crash-2024-02-04-13-03-52 (1).log crash-2024-02-05-21-26-00.log crash-2024-02-10-19-34-47.log

Edited March 5 by aljoxo

[sheson]

59 minutes ago, aljoxo said:

Attached files are crashlogs generated from the crash after loading save, discussed above by Blackread. On 1.6 the crash address appears to be 09432E2 instead of 1.5's 902691 / C072DF. 

These logs were collected from 3 wabbajack lists (Fahluaan, Vagabond, and Nordic Souls)

Nordic Souls and Fahluaan have both swapped from DynDOLOD NG to regular DynDOLOD scripts in recent updates (this past weekend) and the crashes ceased to occur. 

I have worked with Ylikollikas and other Wabbajack list developers over the past month trying to diagnose this crash, and with the removal of Dyn NG seemingly stopping the crash, I'm fairly confident in saying the issue was a part of DynDOLOD NG version 13+ (though ylik and I originally believed it to be an issue with DynDOLOD alpha 154+ which came out around the same time), as the crash on load popped up in several Wabbajack lists after the move to NG version 13. I would have liked to test this by trying downgraded version 12 at some point but I did not have access to the archive file anywhere so I was unable to.

 

crash-2024-02-12-05-34-36.log 65.42 kB · 0 downloads crash-2024-02-14-05-24-21.log 79.54 kB · 0 downloads crash-2024-02-14-05-41-43.log 85.18 kB · 0 downloads crash-2024-02-15-04-32-05.log 129.55 kB · 0 downloads crash-2024-02-16-23-12-00.log 72.22 kB · 0 downloads crash-2024-02-18-19-11-57.log 135.14 kB · 0 downloads crash-2024-02-19-19-53-16.log 75.89 kB · 0 downloads crash-2024-02-20-21-25-10.log 78.99 kB · 0 downloads crash-2024-02-21-20-01-28.log 75.19 kB · 0 downloads crash-2024-02-21-22-49-03.log 69.03 kB · 0 downloads crash-2024-02-22-19-53-19.log 135.71 kB · 0 downloads 1-crash-2024-02-09-20-46-20.log 82.29 kB · 0 downloads 1-crash-2024-02-13-03-57-35.log 78.65 kB · 0 downloads Crash_2024_2_22_15-11-58.txt 227.16 kB · 0 downloads Crash_2024_2_22_15-32-22.txt 227.5 kB · 0 downloads crash-2024-02-04-10-58-17 (1).log 82.96 kB · 0 downloads crash-2024-02-04-13-03-52 (1).log 75.42 kB · 0 downloads crash-2024-02-05-21-26-00.log 86.9 kB · 0 downloads crash-2024-02-10-19-34-47.log 76.88 kB · 0 downloads

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts.

Only reports errors you have yourself, for which you can provide additional logs as requested and can answer questions and can troubleshoot.
Generating LOD without DynDOLO DLL NG is a troubleshooting step. Using DynDOLOD 3 alpha means a user is participating in the alpha test and is required to report problems to this forum so issues can be properly troubleshooted and fixed in a timely manner.

All of these crash logs seem to be with outdated DynDOLOD DLL NG and Scripts Alpha-13. Use the latest DynDOLOD DLL NG and Scripts Alpha-16. 
Have you tested without BetterThirdPersonSelection.dll in the load order as a troubleshooting step for the crashes where it is mentioned in the call stack?
The crash logs seem to report plugins being loaded after DynDOLOD/Occlusion. DynDOLOD/Occlusion should usually be generated last and be last in the load order.
Make sure there are no plugins that require any of the generated plugins as master. Make sure there are no ignorant patches that try to fix "problems" in the generated LOD patch which instead should be properly reported and fixed in the tool, configs, load order or whatever.

In case a crash happens with LOD patches generated with latest DynDOLOD 3 Alpha and with DynDOLOD DLL NG and Scripts Alpha-16, read the posts between Ylikollikas and me how we narrowed it down so far with binary search and what the next troubleshooting step would be.

[aljoxo]

29 minutes ago, sheson said:

Read the first post and/or https://dyndolod.info/Official-DynDOLOD-Support-Forum#Post-Logs which DynDOLOD log and debug log to upload when making posts.

Only reports errors you have yourself, for which you can provide additional logs as requested and can answer questions and can troubleshoot.
Generating LOD without DynDOLO DLL NG is a troubleshooting step. Using DynDOLOD 3 alpha means a user is participating in the alpha test and is required to report problems to this forum so issues can be properly troubleshooted and fixed in a timely manner.

All of these crash logs seem to be with outdated DynDOLOD DLL NG and Scripts Alpha-13. Use the latest DynDOLOD DLL NG and Scripts Alpha-16. 
Have you tested without BetterThirdPersonSelection.dll in the load order as a troubleshooting step for the crashes where it is mentioned in the call stack?
The crash logs seem to report plugins being loaded after DynDOLOD/Occlusion. DynDOLOD/Occlusion should usually be generated last and be last in the load order.
Make sure there are no plugins that require any of the generated plugins as master. Make sure there are no ignorant patches that try to fix "problems" in the generated LOD patch which instead should be properly reported and fixed in the tool, configs, load order or whatever.

In case a crash happens with LOD patches generated with latest DynDOLOD 3 Alpha and with DynDOLOD DLL NG and Scripts Alpha-16, read the posts between Ylikollikas and me how we narrowed it down so far with binary search and what the next troubleshooting step would be.

These logs were generated with alpha 13 and 14. My own logs are in there as well but those were the logs I had gathered for this issue. I have not tested alpha 15 or 16 since I reverted to using non-NG for the moment to fix the crash at the moment because I only have so much time to troubleshoot this crash and leaving my list in a broken state with a critical crash. 

BTPS and FSMP are completely unrelated to the crash, they only show up in the callstack because they show up in any callstack for any crash that occurs during a load screen since they hook the onframe function.

The plugins loaded after DynDOLOD/Occlusion in these cases have absolutely no influence on whether or not the crash would occur, this was tested.  

As for the next troubleshooting steps you linked, we already tested Papyrus Tweaks' potential impact, the issue was present on version 13/14 with or without papyrus tweaks active and with or without papyrus tweaks' native speed setting. 

 

I will regenerate lod later this week if I have time using the new version of NG to try and reproduce the crash, but based on Blackread's earlier post, the issue appears to still be present on version 15/16. 

Edited March 5 by aljoxo
Alpha 16+ note

[sheson]

1 hour ago, aljoxo said:

These logs were generated with alpha 13 and 14. My own logs are in there as well but those were the logs I had gathered for this issue. I have not tested alpha 15 or 16 since I reverted to using non-NG for the moment to fix the crash at the moment because I only have so much time to troubleshoot this crash and leaving my list in a broken state with a critical crash. 

BTPS and FSMP are completely unrelated to the crash, they only show up in the callstack because they show up in any callstack for any crash that occurs during a load screen since they hook the onframe function.

The plugins loaded after DynDOLOD/Occlusion in these cases have absolutely no influence on whether or not the crash would occur, this was tested.  

As for the next troubleshooting steps you linked, we already tested Papyrus Tweaks' potential impact, the issue was present on version 13/14 with or without papyrus tweaks active and with or without papyrus tweaks' native speed setting. 

 

I will regenerate lod later this week if I have time using the new version of NG to try and reproduce the crash, but based on Blackread's earlier post, the issue appears to still be present on version 15/16. 

When doing troubleshooting, remove everything that is not required for a problem to happen, so these things/mods do not show up in logs and are properly ruled out. Upload those "better" logs instead.

The logs provided by Blackread show that DynDOLOD DLL NG And Scripts Alpha 14 is being used. That is why I suggested to test with latest DynDOLOD DLL NG and Scripts first.

[soupdragon]

Got a wierd issue with DynDOLOD.dll and SERuinsWayshrine01 [ACTI:0200F891] in Dawnguard.esm thats reused by a mod Wayshrines of Tamriel that doesn't modify the base record it just adds more of them throughout Skyrim: its crashing Dyndolod.dll for some reason

Crash log reports bhkRigidBody i.e. the collision object. Extracted the mesh as a loose file from vanilla Skyrim - Meshes0.bsa and it still crashes dyndolod.dll. Deleted collision objects in nifskope: crashing stops. Model is DLC01\Architecture\SnowElfRuins\SERuinsWaygate01.nif. On closer inspection its the collision-that-moves on the animated part of the mesh (SKYL_ANIMSTATIC) that has the issue the regular static collision object, no problem (SKYL_STATIC).

No other mods reuse that model and there is no loose mesh override in that mod or its BSA. Even extracting the loose file from the vanilla BSA and dropping it in the meshes folder so nothing overrides it, its still crashing. Remove collision objects, crashing stops.

DynDOLOD_SSE_Debug_log

DynDOLOD_SSE_log

LODGen_SSE_DLC2SolstheimWorld_log (only worldspace generated, to speed things up)

TexGen_SSE_log

Crash_2024_3_6_3-49-58.txt crashlog from NetScriptCrashLogger incase its of any use

https://ufile.io/x9q0ux2b

[sheson]

3 hours ago, soupdragon said:

Got a wierd issue with DynDOLOD.dll and SERuinsWayshrine01 [ACTI:0200F891] in Dawnguard.esm thats reused by a mod Wayshrines of Tamriel that doesn't modify the base record it just adds more of them throughout Skyrim: its crashing Dyndolod.dll for some reason

Crash log reports bhkRigidBody i.e. the collision object. Extracted the mesh as a loose file from vanilla Skyrim - Meshes0.bsa and it still crashes dyndolod.dll. Deleted collision objects in nifskope: crashing stops. Model is DLC01\Architecture\SnowElfRuins\SERuinsWaygate01.nif. On closer inspection its the collision-that-moves on the animated part of the mesh (SKYL_ANIMSTATIC) that has the issue the regular static collision object, no problem (SKYL_STATIC).

No other mods reuse that model and there is no loose mesh override in that mod or its BSA. Even extracting the loose file from the vanilla BSA and dropping it in the meshes folder so nothing overrides it, its still crashing. Remove collision objects, crashing stops.

DynDOLOD_SSE_Debug_log

DynDOLOD_SSE_log

LODGen_SSE_DLC2SolstheimWorld_log (only worldspace generated, to speed things up)

TexGen_SSE_log

Crash_2024_3_6_3-49-58.txt crashlog from NetScriptCrashLogger incase its of any use

https://ufile.io/x9q0ux2b

The crash log and the log and debug log from DynDOLOD do not seem to match. The crash has a non ESL flagged SC08WayshrineTamriel.esp, while the generation shows an ESL flagged SC08WayshrineTamriel.esp.

In any case, test with DynDOLOD DLL NG and Scripts Alpha-17.

If there still is a problem, make sure that the reported reference (16000975 in the crash log) has the No Repawn flag set.

[soupdragon]

10 hours ago, sheson said:

In any case, test with DynDOLOD DLL NG and Scripts Alpha-17.

That did it, thanks.

n.b. I believe I removed the esl flag to get a static form i.d. for identifying the object ingame as its easier than a dynamic (FExxxxxx)

n.n.b. It is indeed flagged NoRespawn, thanks again.