DynDOLOD DLL

[Mousetick]

9 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.

I don't think DynDOLOD (specifically, the DynDOLOD .esm, .esp, and Occlusion.esp plugins) is the cause of the crash.

As we tentatively found in the other topic regarding this issue, based on analysis of various crash logs and Papyrus logs, the crashes appear to involve references to ACTI base objects with locally attached scripts. These references and/or activator base objects can come from vanilla or from mods.

It just so happens that DynDOLOD places references in the world to its own ACTI with a locally attached script, so they seem to be affected too: they're the 'victim' of the bug, so to speak, rather than the perpetrator. Your test results seem to confirm that.

Furthermore, the crashes are random over time and space, and the few Papyrus logs that were examined point to some kind of in-memory data corruption at runtime. Static data like ESP/ESM plugins, if they are free of any error in xEdit, cannot by themselves cause such kind of runtime data corruption. It's much more likely to be caused by buggy code:

• Either native code from SkyrimSE.exe (extremely unlikely or it would have been experienced by many more users a long time ago).
• Or native code from SKSE or NetScriptFramework DLL plugins (DynDOLOD.dll included).
• Or VM code from compiled Papyrus scripts added or modified by mods.
• Or a combination of several of the above.

You may want to read the other topic (A new crash I am trying to diagnose) in its entirety, particularly regarding the WARNING messages in the Papyrus log, which may be used as an indicator of corruption and as an "early warning system" of an impending crash. In that topic I also try to offer suggestions for troubleshooting.

[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.

[sheson]

4 hours ago, Ylikollikas said:

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.

Test and report back whenever you have the time. We will continue to troubleshoot until the problem is fixed.

Ignoring or avoiding a problem is not a fix. Not reporting a problem here means the requirements to use and participate in the DynDOLOD 3 alpha test are not met. I share DynDOLOD 3 Alpha and the experimental large reference bugs workarounds publicly with the requirements to help with the testing and to report bugs in order to have them fixed for everybody. Whatever issues others users have, they can typically also be avoided by removing specific mods.

[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

[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.

[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.

[sheson]

4 hours ago, soupdragon said:

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.

Great. Thanks for letting us know.

[tabaras]

Sorry if this has been already answered elsewhere but I can't seem to find an answer... Do I need to rerun Dyndolod after updating "DynDOLOD DLL NG and Scripts" to the latest version? Thanks in advance