As most players know, there is a mod limit in Darkest Dungeon - if you enable too many mods at one time, the game might crash to desktop when loading.

Different from normal modding problems which usually shows a warning on black screen with bug information when crashes, the crashes caused by mod limit will directly crash to desktop without any warning and bug report.

From my research, there are mainly four types of "overflow" In Darkest Dungeon program which can cause mod limit CTDs. They are the overflow of trinket trinket+item, the overflow of hero class hero skill (combat skill + camping skill), the overflow of save file (mainly about district buff issue), and the overflow of computer memory.

The overflow of trinket occurs because the game only supports certain quantity of trinket entries. If you have installed more, the game crashes when loading.

UPDATE:
Further experiment proves that items will cause the same crash as trinkets and they share space with each other, so the precise trinket cap number here is outdated and only for reference. Since it is very difficult to count all the new items, the precise cap number of trinkets + items is unknown for now.
Through decompilation, now the precise trinket+item cap number is clear -- it is 2048.

The precise limit number does not include duplicate trinkets which have same IDs. We all know if there are same IDs in different mods, they will override each other (if these mods are using the same file name of trinket entries, then the high priority ones will override the low priority ones. But if they are not, as different files in different mods contains the same ID of trinket, then things will be exactly the opposite, which means the low priority ones will override the high priority ones), and this counts as only one trinket, not two or more.

The solution to this type of overflow is non-existent. The only way is to uninstall or delete some trinkets if you meet this kind of CTD.

The solution to this type of overflow is now existent - by using the unofficial "darkest.exe" fix patch made by "局外人", the trinket+item cap can be increased from 2048 to 4096.

Note: this overflow is about trinket entries, which means the definition number of trinkets, or in other words how many trinkets player has installed. It is NOT the quantity of trinkets player has stored in hamlet warehouse. Please do not confuse them.

Further experiment proves that items (supply / gem / estate etc. - any thing that can be put into inventory but not trinkets) will cause crash too.

Since there are two obvious conclusions : First, when the trinket cap is met, both new trinket and new items will cause crash. Second, remove either trinket or items will solve both the trinket overflow and the item overflow. Thus we can know that the overflow of Items shares the same computer memory space with that of trinkets. In other words, they are the SAME, they are actually ONE thing.

The precise cap number of item overflow combined with trinket overflow is unknown. Through decompilation, now the precise trinket+item cap number is clear -- it is 2048. But it is still difficult for common players to count how many new items that a mod has added. Players may count items from fx folder or from panel icons, but it might not be very precise. For the true precise way to count items the player had to fully understand the definitions of items in those "inventory.items.darkest" files under the inventory folder and count them one by one, excluding those that only override vanilla items.

The way to solve this overflow is as same as that of the trinket overflow. Removing either new items or new trinkets will do. BUT be very very careful, since items are often tied to loot or something else important, and are often concerned with core designs, simply removing item definitions in the "inventory.items.darkest" files might cause black screen crash. So I highly recommend you not to remove items, but to remove trinkets instead (or just remove some mods completely), since the items and the trinkets are actually ONE thing in this overflow.

The solution to this type of overflow is now existent - by using the unofficial "darkest.exe" fix patch made by "局外人", the trinket+item cap can be increased from 2048 to 4096.

The overflow of hero class skill is as same as that of trinkets. It occurs because the game only supports certain quantity of hero class skill. If you have installed more, the game crashes when loading.

The number of hero classes is judged by new skill definitions of a hero, thus means if you have reached this limit, installing a mod which don't contain any hero skill definition will NOT cause CTD, but if you add a new skill definition of one more hero class, the game will certainly crash, even if you add only one skill definition for the new hero.

UPDATE:
My friend "Error Code" has made a study on this overflow, his further experiment proves that the true essence of "The Overflow of Hero Class" is actually "The Overflow of Skill", which means the real reason in this overflow which causes game crash on loading is too many skill definitions. Note that here "skill" not only means "Combat Skill", but also includes "Camping Skill".

Be attention: two combat skills with the same ID in different heroes are considered as two different combat skills, this is obvious since many mod heroes using vanilla hero skill IDs while they are surely acting as different skills. Although this same combat skill ID might bring some troubles to modders if they want to use skill rules on these skills, it would not cause other critical problems. BUT, two camping skills with the same ID in different heroes are exactly the same one, and if the camping skill is shared by at least 7 heroes, it will no longer be considered as a "specific" camping skill, but considered as a "shared" camping skill.

Therefore, although we don't suggest you to install too many heroes, if you insist on using 150+ or even 200+, 250+ heroes, and after you have encountered The Overflow of Hero Class Skill, the only way to solve this overflow is to delete skills, and obviously it is easier and lose less gameplay to delete camping skills rather than to delete combat skills. As I have mentioned above, be attention that deleting the shared camping skills with the same ID in all heroes only result in decreasing only one skill space, so you should delete specific camping skills rather than shared camping skills, in order to free more skill space for more heroes.

The solution to this type of overflow is non-existent too. The only way is to uninstall mods that contain new hero classes if you meet this kind of CTD.

As I have mentioned above, the solution to the Hero Class Skill cap is now existent, you may delete skill definitions -- to be exactly, I suggest to delete specific camping skill definitions -- to solve this Overflow of Hero Class Skill.

But, I still don't recommend you to install too many heroes, since the official command-line "-disable_monster_pre_loading" can only delay the loading of monster resources, not hero resources, and the main program still has the computer memory limit of 4GB, if you install rather too many heroes, it might still make you reach the limit of computer memory, leading to the Overflow of Computer Memory again, even when using the unofficial fix patch. Also the same thing might happen on the Overflow of Trinket+Item, you might reach the Trinket+Item cap first, before you can reach the Hero Class Skill cap, while you are trying to install more heroes.

Anyway, please be ware of other caps and remember to take care all of them (include using the "Darkest.EXE Unofficial Fix Patch", using the official commandline "-disable_monster_pre_loading", increasing the value of "max_resource_entries" in the file "resource_manager.setup", and try not to build those districts which contain district buffs).

The overflow of save file happens when the save files become too large. It is usually not caused by hiring too many heroes, but by building too many district buildings.

The reason is every hero’s district buffs are recorded in the save file. For example if we have a building providing 10 buffs for all heroes, and if the barrack has 100 hired heroes, then there will be 10*100=1000 buffs in the save file, thus causing save file bloat that will eventually crash the game.

What is worse, dead heroes still have district buffs in the save file, though dismissed heroes do not. Eventually the dead heroes pile up and bloat the file until it cannot be loaded. This is fixable with the save file editor (DDSaveEditor), but you have to painstakingly remove each buff entry for each dead hero.

The precise limit of save file is unknown. Normally if the save file is larger than 15MB, it might be difficult or even impossible for DDSaveEditor to open it. When it's larger than 20MB, the game might fail to write data into the save file, leading to CTD when loading next time.

The main file influenced by this type of overflow is persist.roster.json, which records data of hired heroes.

The solution to this type of overflow is building districts as less as possible, especially those that contains many buffs and affect many or even all hero classes. Note that some districts such as bank are not made by buffs, thus they are completely safe to build.

If your save file is already larger than 15MB but still can be loadded, you could dismiss heroes or use DDSaveEditor to remove buffs from heroes and delete existing districts. Note that you have no way to remove districts through gameplay, and even you have already removed districts by using DDSaveEditor, the buffs on existing hired heroes won't be removed automaticly unless you dismiss them. So you have to remove not only the districts in persist.town.json but also the buffs in persist.roster.json if you don't want to dissmiss hired heroes.

Note:
These following districts (in vanilla game) are NOT made of buff, and completely safe to build:
(1) Districts that increase inventory stacking of something.
(2) Districts that alter item's use effect (e.g. Tainted Well). Although it says items will provide new buffs, the coding way of replacing item effect is no concern with district buff.
(3) Districts that alter stress relief amount in town (e.g. Puppet Theater).
(4) Districts that provide stress relief when heroes interact with certain type of Curio. (e.g. The second part of Athenaeum which says Knowledge curios heal 15 stress. Note that the first part of Athenaeum which says some heroes will get +15% blight chance and debuff chance is a district buff)
(5) Districts that provide supply each week (e.g. Sanguine Vintners) or provide supply during embark (e.g. The second part of Granary which says some food will be given free. Note that the first part of Granary which says +15% Healing when Eating is a district buff.)
(6) Other special districts that have unique effect:
The Mill, Bank, Cartographer's Camp, Outsider Bonfire.
(7) The Red Hook (no special effect).

For the districts in other mods, you can judge them whether contain buffs or not by refering to the vanilla examples above. Note that some mods have modified the vanilla districts too, in that situation the conclusion might be different.

The last overflow is the most common one when installing too many mods - the overflow of computer memory, also called the overflow of monsters, or known as "memory allocation failed".

This is due to the 32-bit main program Darkest.exe being unable to acquire enough memory when too many mods are installed.

This is solvable with an official command from Red Hook known as:
-disable_monster_pre_loading
This command delays the loading of monster resource when loading the game (after all you cannot disable the loading of herose or system UI, otherwise the game cannot run at all). Certain monster resource is loaded only when you start a battle which contains that kind of monster. When this happens, you will feel obvious game lag when battle begins.

But the command only extends the limit by delaying the loading of monsters, it doesn't change the maximum 2GB memory allocation of 32-bit program. Obviously it is unrealistic to remake a 64-bit version of main program Darkest.exe. But still there is a way to expand the memory allocation of 32-bit program from 2GB to 4GB by using a tool from Microsoft's Visual Studio.

By using a tool from Microsoft's Visual Studio, we can re-compile Darkest.exe, open one of its "switch", allow it to acquire not 2GB but 4GB of memory on 64-bit operating systems. To the details, the tool is the command "editbin /LargeAddressAware" from Visual Studio. If you are not familiar with it, you can ask a C++ programmer for more details. It's easy to use and the result is very effective, just replace the old Darkest.exe with the new one made by the command, and it will be able to utilize more memory.

Here is an easy-to-use individual "editbin" re-compile package made from Visual Studio 2008:
https://drive.google.com/file/d/1DUAOEa8jvzVLq6lz8ecp6n-4l5MrTPnF/view?usp=sharing

After you have done it, you can check the new exe by using the command "dumpbin.exe /headers". If the progress is successful, you will see a line like " Application can handle large (>2GB) addresses" within the command result.

Note that while this essentially doubles the mod limit on 64-bit systems that can provide the appropriate memory, there is still a limit of 4GB memory allocation. Fortunately, by combining this solution and the official command "-disable_monster_pre_loading" together, chance of CTD will be substantially reduced.

Unfortunately this solution to memory allocation cannot solve the other three overflows.

Note that every time Red Hook updates the game version, the main program Darkest.exe will be changed back. You must repeat the progress above to re-compile the new version Darkest.exe, if you want to regain the benefit from 4GB memory allocation.

----------------------
Additional notes:
The 4GB expanded main program (made by LAA, the LargeAddressAware command).
The official commandline "-disable_monster_pre_loading".
Besides these two above, there is a 3rd solution to the Overflow of Computer Memory, which players should be highly aware of -- the "max_resource_entries".

For details:
Please open the file "DarkestDungeon\shared\resource_manager.setup" with notepad, then change the value of "max_resource_entries" from 8192 to a significantly larger number (e.g. 90000) (e.g. 900000, max limit is about 975622~975773), otherwise there might be blackscreen crash or even worse bugs if you have installed many mods.

If you found that the main program cannot be launched after modifying "max_resource_entries" (not crash on loading savefiles, but completely unable to launch the main program from the very beginning), please lower this value as appropriate until the main program can be launched correctly (for example 90000).

Update: It has been proved that on some players system environment, especially on win11 OS, assigning a value of 900000 to the resource entry file will be risky, as it can trigger "memory allocation failed" warning and severe memory overflow even in situations where mod quantity is not large. Based on the first fact that a larger value of resource entry is NOT "the more the better", while excessive assignment value can indeed cause system to crash, and the second fact that on the 64-bit main program of the test branch, Redhook has used a default value of 32768 for the resource entry file, therefore, it is now recommended to set max_resource_entries to 90000, instead of 900000, especially on win11 systems, to avoid potential risk of memory overflow which should not have happened.

Darkest Dungeon Main Program "Darkest.exe" Unofficial Fix Patch, made by "局外人".

A friend of mine had made a marvelous main program fix patch through reverse engineering, to solve some very stubborn bugs including some of the overflows mentioned above.

This patch is made by "局外人", and is now posted on his friend Deovolente's Afdian & Patreon. For more details, please click one of the following links:
Afdian(Chinese): https://afdian.com/p/f163f0101f9f11eebada5254001e7c00
Patreon(English): https://www.patreon.com/posts/important-bug-64803991

The following is a brief description of this patch:
- This "Darkest.exe" Bug Fix Patch is made by "局外人". Based on Redhook Steam version 25688.
(Be ware, Redhook had updated Darkest Dungeon on Oct.11.2022, but that update is only about Steam Deck support, no concern with gameplay, thus please ignore that newest version, re-overwrite the "Darkest.exe" file again, in order to continue using this old-version main program fix patch, unless you are using Steam Deck features)
- This "Darkest.exe" Bug Fix Patch is made through reverse engineering, aimed at solving many old and critical crashes or bugs.
- This "Darkest.exe" Bug Fix Patch contains the steam on-line Darkest.exe and the off-line Darkest.exe. Please cover each file into their correct folder.
- This "Darkest.exe" Bug Fix Patch contains decompiling, might triggers false alarm by anti-virus software. Please add it into trust list.
- This "Darkest.exe" Bug Fix Patch contains the following contents:
(1) 4GB memory allocation is already included. -- It's the main two solution to the overflow of memory. The other solution is the commandline "-disable_monster_pre_loading", don't forget to use it.
(2) Won't output and showing some unnecessary red-colored bug report infomations when effect name is started with "unsafe".
(3) Fix the ActorDot crash (when ActorDot launcher not alive on the battlefield and then reload this save slot).
(4) Fix the overflow of trinkets & items. Now trinkets & items max types number is 4096 (doubled comparing to vanilla).
(5) Fix the crash about BuffFX when several bufffx is triggered at one time.
(6) Fix the crash about ActorDot when using teleport skill.
(7) Fix the crash that caused by custom heirlooms when being looted in dungeon and trying to bring them back to hamlet. (Note that heirloom and estate are different things. Custom heirlooms for example: Exaelus' diamond, Sunward's koban. The reason that these custom heirlooms cannot be designed to drop in dungeon, is just right because of this annoying crash. This is partially why the diamond had to be designed as quest reward and koban had to be designed as town event rewards at that time)

Note:
- There are two "darkest.exe" in the patch, the one in the "_windows" folder is for steam online playing, the other in the "_windowsnosteam" folder is for offline playing, don't confuse them.
- This patch is only for windows platform, don't use it on NS or linux, and don't forget to backup your current official "darkest.exe".
- The same as before, every time Red Hook updates the game version, the main program Darkest.exe will be changed back. You must repeat overwriting the Darkest.exe with this patch, if you want to continue benefiting from those unofficial fixes.
- To stress this again: Redhook had updated Darkest Dungeon on Oct.11.2022 about Steam Deck support. If you really need to use Steam Deck features on Darkest Dungeon, then you should not use this old-version patch.

------------------------------------------------
Note for modders, especially code programmers:

The Unofficial Fix Patch do have fixed the "owner-less ActorDot crash when reloading". (We all know that if somehow the caster of an ActorDot is dead, and then player reload the game, this ActorDot will cause crash, which is actually a savefile permanent soft-lock). But, there is a side effect that I forget to mention in my guide or readme. The reason that I didn't mention it is that most players can do nothing with that side effect, and actually it will not cause any critical result. But for modders, especially code programmers, they should know this side effect, otherwise it might confuse them when they are using the Unofficial Fix Patch to do tests on ActorDots. This side effect of fixing "owner-less ActorDot crash", or in other words the "cost" of fixing that crash, which is need to be known by code programmers, is as follows :

< After player reloading the game, if an ActorDot will lead to permanent crash because of its caster's absence, then the Unofficial Fix Patch will transform it into an "static" ActorDot and prevent it from crash. This "static" ActorDot will no longer need or perform a visual animation to function (which is why it will not crash), but it will also be stuck in its current layer (the duration elements of AD), which means it will always execute its current duration element, and will never meet its end, until the battle completes. >

Please note that, only those ActorDots which shall cause crash will be transformed into never-end ActorDots , any other normal ActorDots will not be influenced. Additionally, if player don't reload the game during the battle when an existing ActorDot's caster is absent, which means "owner-less ActorDot crash" will not happen at all, then there will be no side effects at all too. So please don't worry, the Unofficial Fix Patch will not interfere normal gameplay if there is no potential risk of ActorDot permanent crash.

Since these never-end ActorDots will surely become permanent crash if players don't use the Unofficial Fix Patch, this side effect is completely just the price for fixing that annoying crash, so most players don't need to know its details. But for modders, especially code programmers, this side effect might interfere the tests about ActorDots if they reload the game when "owner-less ActorDot crash" is just about to happen, and then it might confuse them or lead them to false conclusions (They might be puzzled about why that ActorDot always executes its current duration element everytime it triggers, or why it strangely becomes a permanent ActorDot, if they don't know the details of the side effect). So this is why I now add this note here to explain all these complex details about this side effect of fixing ActorDot crash. I must apologize for not mentioning it in the guide from the very beginning, and apologize for all the potential inconvenience if it has brought to any modder and player.

Redhook has now updated the 64-bit version to official release branch on 2025-05-01.

"Darkest.exe" Unofficial Fix Patch has been updated on 2025-06-29.
For more details, please check the corresponding chapter below.

Details about the new official 64-bit exe on the testing branch are as follows (which I also posted in the discuss section under Red Hook's update announcement):
The new official 64-bit exe has solved the overflow of computer memory completely, due to memory allocation of 64-bit program is no long limited to 4GB, but almost no cap.
The new official 64-bit exe has solved the overflow of trinket+item, as it has doubled the trinket definition number cap from 2048 to 4096, the same as the unofficial fix patch.
Other fixes done by the unofficial fix patch is not included in the new official 64-bit exe, at least for now. (We have already reported these problems to Red Hook)

From the chapters above, we should have known that: on legacy 32-bit, the cap of trinket overflow (to be precisely, the cap of trinket & item definition entries) is 2048, and the unofficial fix patch had expanded it into 4096.

Now, for the newly updated 64-bit main program, Red Hook has officially expanded this cap from 2048 to 4096, the same as what the unofficial fix patch had achieved on legacy 32-bit.

The overflow of Hero (actually is The overflow of Skill) still require more tests to make it clear.

Besides, remember that players can still choose to delete definitions of non-public camping skills to free more slot to install more heroes when encountered this overflow.
Note: To delete definitions of public camping skills is NOT recommended, as public camping skills of the same ID are treated as only one skill.

The overflow of save file still require more tests to make it clear.

Note: the savefile might not be compatible between legacy 32-bit & new 64-bit. This might indicate that Red Hook has done something on the structure of savefile, thus this type of overflow might possibly be fixed, but we still require more tests to confirm it.

From the chapters above, we should have known that: in the legacy 32-bit, there are three solution to help us solve the overflow of computer memory. They are:
The 4GB expanded method (also known as the LAA command from Microsoft).
The official launch command line "-disable_monster_pre_loading".
The parameter "max_resource_entries" in file "resource_manager.setup".

Now, for the new 64-bit version, they have been changed as follows:

The 4GB expanded method is no longer needed, completely abandoned. This is due to 64-bit version main program can theoretically handle computer memory almost unlimited (16EB=16777216TB), although windows OS can only support 128G computer memory for each program. No matter unlimited or 128G, they are obviously extremely larger than 4GB, thus LAA command is no longer needed at all.

Similarly, as 64-bit now can handle at least 128GB, "-disable_monster_pre_loading" is no longer needed too, as we no longer have to delay the monster resource loading to free more memory for the program. Besides, some bugs have been confirmed to be caused just by this official launch command line, such as the crash on Drowned Anchor. Thus although keep using this command line might help us speed up the savefile loading, we still strongly recommend players NOT to use this command line on 64-bit program.

Lastly, the parameter "max_resource_entries" has been enlarged from 8196 (in legacy 32-bit) to 32768 (in 64-bit) by Red Hook.
As the default value is 32768 now, we may just keep it as 32768, or slightly enlarge it to 65,536~99,999, but don't enlarge it too much, otherwise it might cause crash instead, the similarly as in legacy 32-bit.

Further experiments from modder "Mhdss" and "Kaze*" indicate that when player has installed too many mods, the obviously lag in 64-bit might be solved by further more enlarging the value of "max_resource_entries". However, if the value has been set too large, it might cause trouble instead as in 32-bit, and it seems to be depended on hardware of player's own PC (mainly about the physical computer memory, as 32GB computer memory works significantly better than 16GB computer memory).
Thus here we recommend players who has encountered obviously lag in 64-bit to enlarge this value from 32768 to 90000, or even larger, e.g. 900000 / 2000000 / 5000000 (for 16GB physical computer memory, the value is recommend to be set lower than 3000000, and for 32GB physical computer memory, the value is recommend to be set lower than 5000000). And please be careful when enlarging this value, as different players with different PC hardware environment might result in different max value threshold, thus if you found yourself unable to launch the exe or the game becomes unstable, please lower the value back, until the game becomes stable again.

Red Hook has updated the coming-in-hot testing branch on 2025-06-26, and has fixed two important bugs (the bug that loot frame will disappear in endless quest, and the bug that uploader cannot locate base color folder due to path change).

Based on this official update, the Unofficial Fix Patch made by "局外人" has been updated on 2025-06-29, you can find the download link as before -- on his friend Deovolente's Afdian & Patreon:
Afdian(Chinese): https://afdian.com/p/f163f0101f9f11eebada5254001e7c00
Patreon(English): https://www.patreon.com/posts/important-bug-64803991

The Readme of Unofficial Fix Patch is as follows:

This Darkest.exe Bug Fix Patch is made by "局外人". Based on Steam Darkest Dungeon | PC Platform (Windows OS) | Coming-in-Hot (Testing) Branch | Build 25688 | 64-bit main program.

This Darkest.exe Bug Fix Patch is made through reverse engineering, aimed at solving many old and critical crashes or bugs.

This Darkest.exe Bug Fix Patch contains the steam on-line <64-bit> Darkest.exe and the off-line <64-bit> Darkest.exe. Please cover each file into their correct folder.

This Darkest.exe Bug Fix Patch contains decompiling, might triggers false alarm by anti-virus software. Please add it into trust list.

This Darkest.exe Bug Fix Patch contains the following contents:

(1) Fix the "Owner-less ActorDot crash" -- when ActorDot launcher is not on the battlefield (e.g. is dead), and then player reload this save slot, the owner-less ActorDot will crash when triggered.

(2) Fix the "Teleport ActorDot crash" -- when teleport skill is used and player return to the same battle, and player does NOT reload this save slot, then the ActorDot on monster will crash when triggered.

(3) Fix the "custom heirloom return to hamlet crash" -- when custom heirloom being looted in dungeon and trying to bring them back to hamlet, game will crash due to the lack of framework. (Custom heirlooms for example: Exaelus' diamond, Sunward's koban, Abigail Williams' Saint Quartz Fragment)

(4) Fix the crash about BuffFX -- when several bufffx is triggered at one time under certain very rare situation.

Note #1:
Due to official 64-bit version has almost completely solved the Overflow of Computer Memory, we shall no longer provide unofficial fix patch for the 32-bit version.
We apologize for the inconvenience that it may cause to players.

Note #2:
This patch is based on the official main program for the PC platform (Windows OS), thus may not run on the Mac platform (OSX) or Steam Deck platform (Linux Ubuntu).
We apologize for the inconvenience that it may cause to players.

Note #3:
Due to Red Hook has updated the 64-bit version, the 4GB expanded method (also known as the LAA command from Visual Studio) is no longer needed, completely abandoned.

Note #4:
Similarly, "-disable_monster_pre_loading" is no longer needed too, as we no longer have to delay the monster resource loading to free more memory for the program.
Besides, some bugs have been confirmed to be caused just by this official launch command line, such as the crash on Drowned Anchor.
Thus although keep using this command line might help players speed up the savefile loading, we still strongly recommend players NOT to use this command line on 64-bit program.

Note #5:
Red Hook has already officially expanded the limit of "Overflow of Trinket+Item" (the definition cap of trinket+item) from 2048 to 4096 in the 64-bit main program.
It is the same cap as what the unofficial fix patch had achieved on legacy 32-bit, thus there is no need to repeat the fix on this unofficial fix patch.
In the future, we might plan to further more enlarge this cap, or not. We are sorry that we cannot make promise on it, as it may depend on many other problems.

Thank you all for your patience.

------------------------------------------------
Note for modders, especially code programmers:

(1) The side effect when fixing "owner-less ActorDot crash"

The same as 32-bit Unofficial Fix Patch, while the 64-bit Unofficial Fix Patch do have fixed the "owner-less ActorDot crash", there will be a side effect which is just the "cost" of fixing that crash:

< After player reloading the game, if an ActorDot will lead to permanent crash because of its caster's absence, then the Unofficial Fix Patch will transform it into an "static" ActorDot and prevent it from crash. This "static" ActorDot will no longer need or perform a visual animation to function (which is why it will not crash), but it will also be stuck in its current layer (the duration elements of AD), which means it will always execute its current duration element, and will never meet its end, until the battle completes. >

Please note that, only those ActorDots which shall cause crash will be transformed into never-end ActorDots , any other normal ActorDots will not be influenced. Additionally, if player don't reload the game during the battle when an existing ActorDot's caster is absent, which means "owner-less ActorDot crash" will not happen at all, then there will be no side effects at all too. So please don't worry, the Unofficial Fix Patch will not interfere normal gameplay if there is no potential risk of ActorDot permanent crash.

(2) The side effect when fixing "teleport ActorDot crash"

A bit different as 32-bit Unofficial Fix Patch, while the 64-bit Unofficial Fix Patch do have fixed the "teleport ActorDot crash", there is almost no side effect, as long as players do NOT restart in the teleported battle. The fixed "pre-teleport" ActorDots will become completely silent, no longer trigger-able, and even does not occupy the "same-ID" ActorDot slot, which allow heroes to re-deploy normal ActorDot of the same ID to the same monster, result in almost no side effect when heroes re-enter the teleported battle, just as if all ActorDots on monsters are automatically removed after teleportation.

But, if players restart in the teleported battle after they have re-deployed the normal ActorDot of the same ID to the same monster, due to the old silent ActorDot will re-link and re-function after restart, there will be TWO same ID ActorDot on the same monster, obviously causing double result when this ActorDot is triggered. Thus, please notice this change when encountering "teleport ActorDot crash" and having restarted in the teleported battle, modders should be careful not to be confused by this "double same ID ActorDot" phenomenon in this situation, and we suggest players and modders not to restart in the teleported battle when playing or testing teleport skills.

------------------------------------------------
Information provided by "shiningseablack" about how to use Unofficial Fix Patch on Steam Deck:

"There is actually a way to install the main program patch. Go to Content > Compatibility > Check to force using compatibility tools > Launch the game, then steam deck itself will automatically download windows exe, then enter desktop mode to install patches."

------------------------------------------------
Warning:
By some unknown reason, the 64-bit darkest dungeon will crash on certain mods, if not launching the game through steam library, but by directly clicking the exe. It has been confirmed this crash is caused by the lacking of command line "-skipvalidation", as Red Hook will automatically add this command line when launching from steam library.

And in some players environment, by some other unknown reason, the command line is lost even when they do have launched the exe from steam library, when they are using the unofficial exe fix patch. Thus, please manually add this command line "-skipvalidation" into steam launch parameter to ensure it can function correctly, otherwise the game might crash on loading when certain mods are enabled.