Valheim BepInEx Mod Crash: Which Mod Broke It

Valheim BepInEx Mod Crash: How to Find Which Mod Broke It

If your modded Valheim server crashes during world setup with a NullReferenceException, the BepInEx log already names the broken mod. You just have to read the right line. This page walks through a real anonymized crash signature, shows the line that tells you which mod is responsible, and outlines the disable-one-at-a-time loop for the harder cases.

What this crash looks like

Real fingerprint from a server that restarted four times after a mod update before the owner asked for help. The exception came from BepInEx/LogOutput.log:

[Error  : Unity Log] NullReferenceException: Object reference not set to an instance of an object
Stack trace:
BetterArchery.BetterArchery.TryRegisterRecipes ()
   (at <187d31a908ad4c179e2df71a229c9313>:0)
BetterArchery.ObjectDB_CopyOtherDB_Patch.Postfix ()
   (at <187d31a908ad4c179e2df71a229c9313>:0)
(wrapper dynamic-method) ObjectDB.DMD<ObjectDB::CopyOtherDB>
   (ObjectDB,ObjectDB)
ObjectDB.CopyOtherDB (ObjectDB other)
ZNetScene.Awake ()
UnityEngine.SetupCoroutine.InvokeMoveNext ...

The customer's symptom: server entered the world-load phase, threw the exception, and never finished initialising the scene. To them it looked like "no loading, restarted four times and won't start back up".

Reading the stack trace

BepInEx stack traces follow a predictable structure:

1. The exception type and message at the top.
2. The first stack frame is the function where the exception was thrown.
3. Below that, the call chain unwinds through the patched method, the Harmony postfix wrapper, the original Valheim method (usually ObjectDB or ZNetScene), and finally the Unity engine.

The rule: the first non-engine stack frame is the broken mod. In the example above it is BetterArchery.BetterArchery.TryRegisterRecipes. That mod's recipe registration assumed an item that no longer exists in the current Valheim build, hit a null reference, and refused to continue. Every other line in the trace is just the engine's path to that broken function.

Where BepInEx logs live

On a Supercraft node the layout is:

vlh/Valheim/
├── BepInEx/
│   ├── LogOutput.log         # the file you want, contains the stack traces
│   ├── plugins/              # each .dll is one mod
│   │   ├── BetterArchery.dll
│   │   ├── Jotunn.dll
│   │   └── ... etc
│   ├── patchers/             # Harmony patchers, rarely the cause
│   └── config/               # per-mod config files
├── valheim_server_Data/      # game data
└── ...

vlh/process-control/stderr.log    # the same exception, but truncated

BepInEx/LogOutput.log is the full record. stderr.log often shows only the first few frames; do not stop there if the trace looks incomplete.

The fix flow

Step 1: Update the named mod

The first non-engine frame named the mod. Open Thunderstore (or the mod's source page) and check whether a newer version targets the current Valheim build. Mod authors usually ship a patch within a day or two of a major Valheim update. Replace the DLL in BepInEx/plugins/ with the updated version and restart the server.

Step 2: If no newer version exists, remove the mod

Move the named DLL out of BepInEx/plugins/. Restart. The server will boot, the modded recipe will be missing, but the world will load. This is preferable to a crash loop.

Step 3: If the stack trace blames Valheim's own code

Sometimes the first non-engine frame is something like ObjectDB.CopyOtherDB with no mod prefix. That means the Harmony patch that triggered the exception is somewhere else in the loaded plugin set and the trace cannot pinpoint it. Walk the disable-one-at-a-time loop:

1. Move all plugins out of BepInEx/plugins/ into a temporary folder.
2. Restart the server. Confirm it boots cleanly with zero mods.
3. Move half the plugins back. Restart. Crashes? Halve again. Boots? The other half contains the culprit.
4. Repeat the bisection until you are down to one DLL.

For a typical 15–20 mod stack this takes 4–5 restart cycles.

What is not the cause

• The world file. A mod-init exception cannot corrupt the .db / .fwl pair on its own.
• BepInEx itself. The BepInEx loader rarely throws; the patches it loads do.
• Jotunn. Jotunn is a shared library that many mods depend on. If Jotunn appears in the stack, the broken mod is usually the one that called into Jotunn, not Jotunn itself.

Preventing the next crash

Most BepInEx mod-init crashes come from one of three triggers:

• A Valheim patch landed and one of your mods has not been recompiled yet.
• A mod update changed the shape of a config; the mod sees the old config on disk and crashes during init.
• Two mods both patch the same Valheim method and the patches conflict.

Lock your mod versions if you are running a long-lived server. Update one mod at a time and restart between updates so you can match a crash to its trigger. The companion wiki page install mods covers the install flow.

Modded Valheim that survives Steam patches

On Supercraft Valheim hosting BepInEx is supported out of the box and you can roll back a single plugin without rebuilding the whole stack. Pair this with the INCOMPATIBLE_VERSION fix when the crash is followed by a join error from other players.