A CTD occurred during loading, and the crash log could not be analyzed to find the error.

[ck1007197714]

Help! When DynDOLOD.esp is enabled, a crash occurs during the loading of a new save file in the main menu.

I tried disabling the plugins mentioned in the logs, but I still got the exact same error.

Below is the original crash log: https://mclo.gs/b9oOV4v

[sheson]

1 hour ago, ck1007197714 said:

Help! When DynDOLOD.esp is enabled, a crash occurs during the loading of a new save file in the main menu.

I tried disabling the plugins mentioned in the logs, but I still got the exact same error.

Below is the original crash log: https://mclo.gs/b9oOV4v

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

Read https://dyndolod.info/Official-DynDOLOD-Support-Forum#Rudimentary-Troubleshooting

https://dyndolod.info/FAQ#ILS-or-CTD
The DynDOLOD and Occlusion plugins might show up in crash logs a lot, since they are typically the plugins last to overwrite worldspace and cell records, so careful reading and interpretation of the stacks and registers etc. might be required to identify the actual cause of the problem.
It is very unlikely for Occlusion.esp to cause crashes by itself. It is created by copying worldspace and cell records from the winning plugins before it, then update the TVDT Occlusion data which itself can not really cause crashes.

What in the crash log makes you suspect DynDOLOD has anything to do with the crash? Is it 100% repeatable? The stacks seem to indicate a problem with SkyrimSoulsRE.dll,  BetterThirdPersonSelection.dll or with Armor with form ID 0x000D9394. Further down STB_Widgets.dll, 

Only one crash log was provided and the name of the already disabled plugins was deliberately not mentioned. It is unclear  if the provided crash log is original one or one already into troubleshooting.

Use latest version of crash logger https://www.nexusmods.com/skyrimspecialedition/mods/59818

Make sure to use latest version of DynDOLOD DLL NG. Make sure the LOD patch was generated for this load order of plugins.

[ck1007197714]

..\ DynDOLOD \bugreport.txt - 如果存在

..\ DynDOLOD \Logs\[ DynDOLOD |TexGen]_[GAME MODE]_log.txt - 将大型日志文件截断为最后一个有效会话的完整内容，从 [ DynDOLOD |TexGen] 行开始……开始会话

..\ DynDOLOD \Logs\[ DynDOLOD |TexGen]_[游戏模式]_Debug_log.txt

我找不到本教程中提到的路径；我只在DynDOLOD \Logs 中找到了一些日志。

这是使用最新版本的崩溃日志记录器。根据日志，错误信息为：

[RSP+C8 ] 0x29C766080 (TESWorldSpace*)

文件："Occlusion.esp"

以下错误出现在 Lux - Embers XD patch.esp 文件中。我已经将日志中的 SkyrimSoulsRE.dll 和 BetterThirdPersonSelection.dll 更新到最新版本，并确认它们与 1.5.9.7 版本兼容。通过排除法测试，删除 LUX.esp 中的单元格或删除DynDOLOD中的城市世界后，游戏即可正常启动。

https://www.mediafire.com/file/bnowut67envi42w/Logs.rar/file LOG
crash-2025-11-18-04-56-52.log
LODGen_SSE_Tamriel_log.txt
 

Edited November 18 by ck1007197714

[sheson]

1 hour ago, ck1007197714 said:

..\DynDOLOD\bugreport.txt - if it exists

..\DynDOLOD\Logs\[DynDOLOD|TexGen]_[GAME MODE]_log.txt - truncate large log files to the entire last meaningful session, starting with the line [DynDOLOD|TexGen] ... starting session

..\DynDOLOD\Logs\[DynDOLOD|TexGen]_[GAME MODE]_Debug_log.txt

I couldn't find the path mentioned in this tutorial; I could only find a few logs in DynDOLOD\Logs.

This is using the latest version of the crash logger. According to the log, the error message is:

[RSP+C8 ] 0x29C766080 (TESWorldSpace*)

File: "Occlusion.esp"

The error below is in Lux - Embers XD patch.esp. I have updated SkyrimSoulsRE.dll and BetterThirdPersonSelection.dll in the log to the latest versions and confirmed they are compatible with version 1.5.9.7. Through elimination testing, deleting the cell in LUX.esp or deleting the city world in DynDOLOD allows the game to launch normally.

crash-2025-11-18-04-56-52.log
LODGen_SSE_Tamriel_log.txtDynDOLOD_SSE_log.txt

The link for DynDOLOD_SSE_log.txt in your post does not work.

[DynDOLOD|TexGen] means either DynDOLOD or TexGen
[GAME MODE] means SSE for example. See https://dyndolod.info/Help/Game-Mode
So it becomes DynDOLOD_SSE_log.txt or DynDOLOD_SSE_Debug_log.txt for example.

Again, the provided crash log mentions Armor with form ID 0x000D9394 and this time also Parrying.dll. There is also the reference 0x0403D49C using the marker 0x0000003B being mentioned.

The crash log does not mention any DynDOLOD plugins being the last to overwrite any of the listed records. The only mention is the Tamriel worldspace record.

It is unclear what cell record you are deleting from LUX.esp (and what child records are removed with it) or what city world record you are deleting (which would also delete all its children cells and references). Removing the children in a binary search to find if they are involved and which one exactly would be the next troubleshooting step.

[ck1007197714]

Sorry, the upload failed earlier. I've now used Mediafire, which you recommended, to upload the entire LOG folder.

[ck1007197714]

27 minutes ago, sheson said:

The link for DynDOLOD_SSE_log.txt in your post does not work.

[DynDOLOD|TexGen] means either DynDOLOD or TexGen
[GAME MODE] means SSE for example. See https://dyndolod.info/Help/Game-Mode
So it becomes DynDOLOD_SSE_log.txt or DynDOLOD_SSE_Debug_log.txt for example.

Again, the provided crash log mentions Armor with form ID 0x000D9394 and this time also Parrying.dll. There is also the reference 0x0403D49C using the marker 0x0000003B being mentioned.

The crash log does not mention any DynDOLOD plugins being the last to overwrite any of the listed records. The only mention is the Tamriel worldspace record.

It is unclear what cell record you are deleting from LUX.esp (and what child records are removed with it) or what city world record you are deleting (which would also delete all its children cells and references). Removing the children in a binary search to find if they are involved and which one exactly would be the next troubleshooting step.

I checked the equipment with the code 0x000D9394, and it only had modification records for skyrim.esm. I'm not sure why the logs mentioned this.

[ck1007197714]

45 minutes ago, sheson said:

The link for DynDOLOD_SSE_log.txt in your post does not work.

[DynDOLOD|TexGen] means either DynDOLOD or TexGen
[GAME MODE] means SSE for example. See https://dyndolod.info/Help/Game-Mode
So it becomes DynDOLOD_SSE_log.txt or DynDOLOD_SSE_Debug_log.txt for example.

Again, the provided crash log mentions Armor with form ID 0x000D9394 and this time also Parrying.dll. There is also the reference 0x0403D49C using the marker 0x0000003B being mentioned.

The crash log does not mention any DynDOLOD plugins being the last to overwrite any of the listed records. The only mention is the Tamriel worldspace record.

It is unclear what cell record you are deleting from LUX.esp (and what child records are removed with it) or what city world record you are deleting (which would also delete all its children cells and references). Removing the children in a binary search to find if they are involved and which one exactly would be the next troubleshooting step.

Using a process of elimination in the MO2 sorting list on the right, it was found that enabling DynDOLOD, LUX.esp, and Immersive Citizens - AI Overhaul causes this error. Disabling DynDOLOD resolves the issue, or disabling Immersive Citizens - AI Overhaul while keeping DynDOLOD and LUX.esp allows the game to proceed.

[sheson]

1 hour ago, ck1007197714 said:

I checked the equipment with the code 0x000D9394, and it only had modification records for skyrim.esm. I'm not sure why the logs mentioned this.

It showed up in both crash logs, so it might be of interest. Cross check which records use it via the Referenced By tab in xEdit. Of interest is any base record, like the vanilla 0x000C2CD8 container, which again is used by a reference 0x000C2CED in the smoke test cell. Maybe something else uses it. It is possible a DLL plugin make use of it in the game.

46 minutes ago, ck1007197714 said:

Using a process of elimination in the MO2 sorting list on the right, it was found that enabling DynDOLOD, LUX.esp, and Immersive Citizens - AI Overhaul causes this error. Disabling DynDOLOD resolves the issue, or disabling Immersive Citizens - AI Overhaul while keeping DynDOLOD and LUX.esp allows the game to proceed.

If you have a plugin being involved in the issue, use binary search to only keep the record(s) required for the crash to happen. E.g. remove half the records, test, if crash does not happen remove the other half. Typically start with the worldspaces, then the cells of the remaining worldspace, then references of the remaining cell.

I suggest to fix or look into these:
Error: Worldspace Editor ID changed from to StormLightningHoldingWorld StormLightning.esp StormLightningHoldingWorld [WRLD:06000801]
Use xEdit to correct the empty EditorID in ESLifier_Cell_Master.esm. Newer versions of ESLifier should not cause empty EditorIDs anymore.

Clean all plugins for which deleted references are reported. See https://dyndolod.info/Messages/Deleted-Reference.

Check and fix all plugins for which Warning: Found a NULL reference are reported.

Check and fix the Duplicate Cell errors if possible - or test things with removing one of the conflicting mods - which probably requires generating new output from scratch.

Fix or remove broken plugins for which Warning: internal file FormID is a HITME are reported. See https://dyndolod.info/Messages/Internal-File-FormID-Is-A-HITME

[ck1007197714]

2 hours ago, sheson said:

It showed up in both crash logs, so it might be of interest. Cross check which records use it via the Referenced By tab in xEdit. Of interest is any base record, like the vanilla 0x000C2CD8 container, which again is used by a reference 0x000C2CED in the smoke test cell. Maybe something else uses it. It is possible a DLL plugin make use of it in the game.

If you have a plugin being involved in the issue, use binary search to only keep the record(s) required for the crash to happen. E.g. remove half the records, test, if crash does not happen remove the other half. Typically start with the worldspaces, then the cells of the remaining worldspace, then references of the remaining cell.

I suggest to fix or look into these:
Error: Worldspace Editor ID changed from to StormLightningHoldingWorld StormLightning.esp StormLightningHoldingWorld [WRLD:06000801]
Use xEdit to correct the empty EditorID in ESLifier_Cell_Master.esm. Newer versions of ESLifier should not cause empty EditorIDs anymore.

Clean all plugins for which deleted references are reported. See https://dyndolod.info/Messages/Deleted-Reference.

Check and fix all plugins for which Warning: Found a NULL reference are reported.

Check and fix the Duplicate Cell errors if possible - or test things with removing one of the conflicting mods - which probably requires generating new output from scratch.

Fix or remove broken plugins for which Warning: internal file FormID is a HITME are reported. See https://dyndolod.info/Messages/Internal-File-FormID-Is-A-HITME

The problem was identified as LUX.esp through a process of elimination. If LUX is not enabled during the DynDOLOD generation process, and is subsequently disabled, all plugins can be enabled upon entering the save file.

[sheson]

3 hours ago, ck1007197714 said:

The problem was identified as LUX.esp through a process of elimination. If LUX is not enabled during the DynDOLOD generation process, and is subsequently disabled, all plugins can be enabled upon entering the save file.

The Lux.esp in your load order does not seem to be the latest 7.0 version or the update for it.

Did you do the test with just Lux.esp enabled/disabled or also with all the other plugins and patches enabled/disabled requireing it? There are quite a bit of plugins and patches depending on it it - including at least one plugin that need to be cleaned. It is also possible the issue is caused by the broken plugin with the HITME error.

Make sure to use the correct version of Lux and the plugins depending on it.

I suggest to eliminate all other uneeded plugins. The issue might be a record that is forwarded into a DynDOLOD plugin. Once a problematic plugin is found, doing the binary search of eliminating half of its records per step to narrow it down to a single record is typically pretty quick in order to find the actual source of the issue.

[ck1007197714]

On 2025/11/18 at PM7点47分, sheson said:

The Lux.esp in your load order does not seem to be the latest 7.0 version or the update for it.

Did you do the test with just Lux.esp enabled/disabled or also with all the other plugins and patches enabled/disabled requireing it? There are quite a bit of plugins and patches depending on it it - including at least one plugin that need to be cleaned. It is also possible the issue is caused by the broken plugin with the HITME error.

Make sure to use the correct version of Lux and the plugins depending on it.

I suggest to eliminate all other uneeded plugins. The issue might be a record that is forwarded into a DynDOLOD plugin. Once a problematic plugin is found, doing the binary search of eliminating half of its records per step to narrow it down to a single record is typically pretty quick in order to find the actual source of the issue.

Resolved. Removing Lux Orbis and Lux - Via from Skyrim's dynamic LODs allowed me to successfully enter the game, and in-game dynamic objects are now working correctly (Lux is the latest version).

Edited Friday at 03:59 PM by ck1007197714

[sheson]

1 hour ago, ck1007197714 said:

Resolved. Removing Lux Orbis and Lux - Via from Skyrim's dynamic LODs allowed me to successfully enter the game, and in-game dynamic objects are now working correctly (Lux is the latest version).

Avoiding the problem to happen by removing plugins means the issue is being worked around not and the actual cause not really investigated and addressed.

These mods are known to work without issue since years nor has a similar issue with other mods/plugins been reported. if you have a repeatable CTD that is caused by a specific plugin, you can narrow it down to a specific record. Once it is known, we can try to determine and address the actual problem.

1) back up the plugin
2) remove half the records
3) if problem stops happening, restore back and remove the other half of records.
4) if problem still happen, repeat step 1)

do this until only the problematic record remain.

[ck1007197714]

11 hours ago, sheson said:

Avoiding the problem to happen by removing plugins means the issue is being worked around not and the actual cause not really investigated and addressed.

These mods are known to work without issue since years nor has a similar issue with other mods/plugins been reported. if you have a repeatable CTD that is caused by a specific plugin, you can narrow it down to a specific record. Once it is known, we can try to determine and address the actual problem.

1) back up the plugin
2) remove half the records
3) if problem stops happening, restore back and remove the other half of records.
4) if problem still happen, repeat step 1)

do this until only the problematic record remain.

To be precise, I deleted the DynDOLOD data for Lux Orbis and Lux - Via from the following cell:

00000074

Cell

<Persistent Worldspace Cell>

Because through elimination, I found that out of 4000+ addons, 2000+ worked fine with DynDOLOD enabled, while the others crashed. This suggests it's not an issue with the addons themselves, but rather a problem with the sheer number of addons; some data might be exceeding its limit.

Additionally, I tested Lux Orbis and Lux - Via separately. LUX+DynDOLOD worked fine and allowed me to enter the game. It seems the LUX series might be conflicting with my addons, but I haven't found the cause.

[sheson]

2 hours ago, ck1007197714 said:

To be precise, I deleted the DynDOLOD data for Lux Orbis and Lux - Via from the following cell:

00000074

Cell

<Persistent Worldspace Cell>

Because through elimination, I found that out of 4000+ addons, 2000+ worked fine with DynDOLOD enabled, while the others crashed. This suggests it's not an issue with the addons themselves, but rather a problem with the sheer number of addons; some data might be exceeding its limit.

Additionally, I tested Lux Orbis and Lux - Via separately. LUX+DynDOLOD worked fine and allowed me to enter the game. It seems the LUX series might be conflicting with my addons, but I haven't found the cause.

The persistent cell 0x74 will have references as its children which you should also try to remove halfs until only one record remains. If your assumption is correct, it will not be possible to narrow it down the issue to a single or handful reference.

A known limit would be number max number of 2^20 ref handles, which EngineFixes should warn about when loading the game. Make its settings about warning are on/default.

https://dyndolod.info/FAQ#ILS-or-CTD
Large load orders with many plugins might surpass the reference handle cap. SSE Engine Fixes prints a warning. Consider using the large reference bugs workarounds with the DynDOLOD DLL NG as it requires less references. Otherwise, try setting Temporary=1 in ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GameMode].ini may help in these situations, however converting large new land plugins to ESM is the preferred solution.

You are already using DynDOLOD DLL NG, so setting Temporary=1 is not going to help much.

Run the xEdit script https://gist.github.com/aers/953a50c61b3028bce7e5376e8590abed to count the number of persistent refs and see which plugin(s) might be worth converting to ESM with Persistentify Those Plugins.

[ck1007197714]

2 hours ago, sheson said:

The persistent cell 0x74 will have references as its children which you should also try to remove halfs until only one record remains. If your assumption is correct, it will not be possible to narrow it down the issue to a single or handful reference.

A known limit would be number max number of 2^20 ref handles, which EngineFixes should warn about when loading the game. Make its settings about warning are on/default.

https://dyndolod.info/FAQ#ILS-or-CTD
Large load orders with many plugins might surpass the reference handle cap. SSE Engine Fixes prints a warning. Consider using the large reference bugs workarounds with the DynDOLOD DLL NG as it requires less references. Otherwise, try setting Temporary=1 in ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GameMode].ini may help in these situations, however converting large new land plugins to ESM is the preferred solution.

You are already using DynDOLOD DLL NG, so setting Temporary=1 is not going to help much.

Run the xEdit script https://gist.github.com/aers/953a50c61b3028bce7e5376e8590abed to count the number of persistent refs and see which plugin(s) might be worth converting to ESM with Persistentify Those Plugins.

Found the reason, Found 51034 temporary and 63822 persistent (114856 total) loaded references in [F9] DynDOLOD.esp.
Found 935164 temporary and 212937 persistent loaded references, for a grand total of 1148101 loaded references.

Should the upper limit be 1,048,576?

[ck1007197714]

4 hours ago, sheson said:

The persistent cell 0x74 will have references as its children which you should also try to remove halfs until only one record remains. If your assumption is correct, it will not be possible to narrow it down the issue to a single or handful reference.

A known limit would be number max number of 2^20 ref handles, which EngineFixes should warn about when loading the game. Make its settings about warning are on/default.

https://dyndolod.info/FAQ#ILS-or-CTD
Large load orders with many plugins might surpass the reference handle cap. SSE Engine Fixes prints a warning. Consider using the large reference bugs workarounds with the DynDOLOD DLL NG as it requires less references. Otherwise, try setting Temporary=1 in ..DynDOLOD\Edit Scripts\DynDOLOD\DynDOLOD_[GameMode].ini may help in these situations, however converting large new land plugins to ESM is the preferred solution.

You are already using DynDOLOD DLL NG, so setting Temporary=1 is not going to help much.

Run the xEdit script https://gist.github.com/aers/953a50c61b3028bce7e5376e8590abed to count the number of persistent refs and see which plugin(s) might be worth converting to ESM with Persistentify Those Plugins.

The issue has been successfully resolved. Some ESPs that were originally large-scale missions have been ESM-ified. Now, with all mods enabled, players can enter the game and fast travel normally.Thank you for your help.

Edited Saturday at 12:53 PM by ck1007197714