Valheim BepInEx logs: reading LogOutput.log to fix mods

When a modded Valheim server misbehaves, the answer is almost always in BepInEx/LogOutput.log in the server root, and almost always in the first error rather than the last. Read it in three passes. First, is there a BepInEx banner at all - if not, Doorstop never injected the loader and no mod matters yet. Second, the Loading [...] lines and anything that says Could not load or Skipping - that is your real plugin list, with missing dependencies named outright. Third, the first Error after start-up, with the mod's name in its stack trace. When the log is a wall of exceptions with no clear first cause, stop reading and bisect: move half the plugins out, restart on a copy of the world, and halve again. Thirty mods take five rounds.

Where the logs are#

A modded Valheim install writes to more than one place, and the one you need depends on which side failed.

Two properties of LogOutput.log catch people out:

• It is overwritten on every start by default. Restarting a crashed server to "see if it happens again" destroys the evidence of the first crash. Download or copy the file first. Logs worth keeping makes the case in general.
• It is only as detailed as the level set in `BepInEx.cfg`. The defaults record errors, warnings, messages and info, which is enough for most diagnosis.

The loader's logging settings live in BepInEx/config/BepInEx.cfg. In current BepInEx 5 releases they look like this:

[Logging.Disk]WriteUnityLog = falseAppendLog = falseEnabled = trueLogLevels = Fatal, Error, Warning, Message, Info

Adding Debug to LogLevels (or setting it to All) makes some mods much chattier, which helps when an author has asked for a debug log. Set it back afterwards; a debug log on a busy server grows quickly. AppendLog = true keeps old runs in the same file instead of overwriting, useful while chasing a crash that only happens overnight. Key names have been stable across BepInEx 5, but compare with your own file rather than pasting blindly.

On RE:NODE the console shows the server's output live from the first line, and the file manager opens LogOutput.log in the browser, so you can read it without downloading - but take a copy before restarting all the same.

What a healthy start looks like#

You cannot spot the abnormal without knowing the normal. A clean modded start runs through the preloader, then the chainloader, then one line per plugin:

[Message:   BepInEx] BepInEx 5.4.2202 - valheim_server[Message:   BepInEx] Preloader started[Message:   BepInEx] Preloader finished[Message:   BepInEx] Chainloader ready[Message:   BepInEx] Chainloader started[Info   :   BepInEx] 4 plugins to load[Info   :   BepInEx] Loading [Jotunn 2.20.1][Info   :   BepInEx] Loading [ServerDevcommands 1.70][Info   :   BepInEx] Loading [EpicLoot 0.10.3][Info   :   BepInEx] Loading [DiscordConnector 3.1.0][Message:   BepInEx] Chainloader startup complete

Real logs have more lines between these - runtime details, patcher lines, each plugin's own messages - and the version numbers will differ. What matters is the shape:

• The banner names the process. On a server it says valheim_server; on a client, valheim.
• The count in N plugins to load should match the number of mods you think you installed.
• Every mod has a Loading line with its version. A mod with no line did not load.
• Chainloader startup complete appears. After it, Valheim's own start-up continues, ending with the world loading and the session line.

Each line has the form [Level : Source] text. The source is BepInEx for the loader, the plugin's name for a mod's own messages, Unity Log for messages Unity itself produced, and sometimes HarmonyX for the patching library mods use. The level is one of Fatal, Error, Warning, Message, Info or Debug.

No banner: Doorstop and the preloader#

If LogOutput.log is missing, or its timestamp is from before the latest start, BepInEx never ran. The server started as plain vanilla Valheim. Every mod-related symptom is downstream of this, so fix it first.

Doorstop is the small injector that makes Unity load BepInEx before the game. On Linux it works through environment variables set by start_server_bepinex.sh; on Windows it is winhttp.dll and doorstop_config.ini in the server root. Valheim mods with BepInEx on a server shows the full layout. The failures, by the message you see in the console:

`ERROR: ld.so: object 'libdoorstop_x64.so' from LD_PRELOAD cannot be preloaded` - the library is not where LD_LIBRARY_PATH points. Usually the archive's wrapper folder was copied, leaving BepInExPack_Valheim/doorstop_libs instead of doorstop_libs in the root.

`/bin/bash^M: bad interpreter` - the start script has Windows line endings, typically after being edited on a PC and uploaded. Convert it back:

$ sed -i 's/\r$//' start_server_bepinex.sh$ chmod +x start_server_bepinex.sh

`Permission denied` running the script - it lost its executable bit in transfer. The chmod above fixes it.

No error at all, no banner - the server was started with the normal command rather than the BepInEx one, or the environment variables were not set. On a panel host, check the startup command or variables the host uses for BepInEx.

Windows: no banner - winhttp.dll is missing from the folder containing valheim_server.exe, or doorstop_config.ini has it disabled. The ini's key names differ between Doorstop 3 and 4; open the file and look for the enabled switch and the target assembly path, which should point at BepInEx\core\BepInEx.Preloader.dll.

When the banner appears but start-up stops between Preloader started and Chainloader ready, the problem is in a patcher, not a plugin. Patchers live in BepInEx/patchers and run before the game's code loads. HookGenPatcher, which Jotunn needs, is the usual one on Valheim servers. A patcher built for a different game version fails here, and so does one placed in plugins where it does not belong - the error usually names the assembly.

Missing dependencies and skipped plugins#

Once the chainloader runs, BepInEx tells you plainly about every plugin it refused. These lines are the cheapest diagnosis in the whole log.

$ grep -nE "Could not load|Skipping|Error loading" BepInEx/LogOutput.log

The missing-dependency line names the dependency by its GUID, not its display name, and often with a minimum version:

[Error  :   BepInEx] Could not load [EpicLoot 0.10.3] because it has missingdependencies: com.jotunn.jotunn (v2.20.0 or newer)

That GUID is what the dependent mod asked for. Search the mod's Thunderstore page or its dependency list to map it back to a package. Two situations produce this line even though you are sure the dependency is installed. Either the dependency itself failed earlier in the log - find its own Could not load or Error loading line - or an older version is installed than the minimum. And because Jotunn needs HookGenPatcher, a HookGenPatcher in the wrong folder can make Jotunn fail and every Jotunn mod after it report a missing dependency. Fix the first link in the chain and the rest usually clear.

The process filter line is the one that tells you a mod is client-only. Mods that only make sense with a screen often declare that they run in valheim.exe. On valheim_server they are skipped with a warning, which is harmless; remove them from the server to keep the log quiet.

Exceptions: finding the mod responsible#

An exception in the log is a block: a header line naming the exception type, then a stack trace of method calls, most recent first. Most look worse than they are.

[Error  : Unity Log] MissingMethodException: Method not found:void Humanoid.UseItem(Inventory,ItemDrop/ItemData,bool)Stack trace:ExampleMod.Patches.Humanoid_UseItem_Patch.Prefix (Humanoid __instance) ...(wrapper dynamic-method) Humanoid.DMD<Humanoid::UseItem>(Humanoid, ...)

The trace above is a made-up but typical shape. Reading it:

1. The type. MissingMethodException, MissingFieldException and TypeLoadException mean a mod was compiled against a different game version and is calling code that has changed. After a Valheim patch, these are expected until authors update. Nothing in the config will fix them.
2. The mod. Look down the trace for a namespace that is not Valheim's own class names or UnityEngine - here ExampleMod.Patches. That is the mod whose code was running.
3. The patched method. Lines with DMD<...> are game methods that a mod has patched through Harmony. The method name tells you what the player was doing - using an item, placing a piece - which helps when you need to reproduce the fault.

NullReferenceException is the vaguest. In a mod's stack trace it usually means the mod expected something that was not there: a missing config value, an item from a mod that did not load, or an object a client-only mod expected on a headless server. Check whether that mod's dependencies loaded before suspecting the mod itself.

One exception on start that is followed by a normal Chainloader startup complete and a working server may be cosmetic. The same exception repeating every few seconds is not - it costs CPU and fills the disk, and the mod named in it should be removed or fixed. Game server logs explained has more on separating noise from signal.

Noise you can ignore#

A headless server logs things that sound alarming and mean nothing. On a Valheim server these are routinely harmless:

• Messages about shaders, graphics devices or audio. The server has no GPU and no sound; Unity says so.
• Fallback handler could not load library lines on Linux, for libraries a headless server never uses.
• Warnings from a mod saying an optional integration was not found - for example, a mod noting that another mod it can work with is not installed.
• Steam lines about the server's own ID and the session, which belong to Valheim, not BepInEx.

Learn what your own server prints on a good day. Download one clean LogOutput.log after a successful start and keep it. When something breaks, compare the new log with the known-good one; the first line that differs is usually the start of the problem.

Bisecting a broken mod set#

Sometimes the log does not point at a single mod. A server that crashes after twenty minutes, an error with no mod in its trace, a world that behaves strangely only with everything installed. Then you stop reading and bisect: remove half the mods, test, and keep halving the half that contains the fault.

The procedure:

1. Back up the world and the whole BepInEx folder.
2. Point the server at a copy of the world (a different -world name with copied .db and .fwl files) or a fresh test world if the fault does not depend on it.
3. Create a folder outside plugins, such as BepInEx/plugins_off. It must be outside: BepInEx loads .dll files from subfolders of plugins too, so a plugins/disabled folder disables nothing.
4. Move half the mods into it. Keep libraries such as Jotunn in place, and keep each mod with its dependencies - a mod moved away from its library only produces a missing-dependency line and teaches you nothing.
5. Start the server and reproduce the fault.
6. If the fault is gone, it is in the half you moved: swap halves. If it remains, it is in the half still loaded. Either way, halve the suspect group again.
7. Stop when the suspect group is one mod. Confirm by adding everything back except that one.

Rounds needed is the base-two logarithm of the mod count, rounded up.

Faults caused by two mods together break the simple version: the fault disappears from both halves. When that happens, keep one half loaded and bisect the other against it. Mod conflicts and dependencies goes further into interactions between mods, and what to do when a mod update breaks covers the case where the trigger was an update.

On a host where the server restarts automatically after a crash, a mod set that crashes on start can loop. On RE:NODE three crash restarts in an hour put a warning on the server page and open a ticket, so stop the server before starting a bisect rather than letting it cycle - why your game server keeps restarting explains the loop.

Sharing a log for help#

Mod authors and community helpers will ask for the full LogOutput.log, not a screenshot of the last lines. The useful version:

• The whole file, from the first line. The cause is near the top; the visible bottom is the consequences.
• From the failing run, taken before any restart overwrote it.
• Both sides when a client is kicked or crashes on joining: the server's log and the player's own LogOutput.log from their profile.
• Your mod list with versions, which the Loading lines already are:

$ grep -o 'Loading \[[^]]*\]' BepInEx/LogOutput.log | sort

Logs contain player names and platform IDs from connection lines, and the server's address. Remove those before posting a log in a public channel.

FAQ#

Why is LogOutput.log empty or missing?

BepInEx did not start. Either the server was launched without Doorstop - wrong start command, missing environment variables on Linux, missing winhttp.dll on Windows - or BepInExPack was unpacked into a subfolder. Fix the injection; the log appears on the next start.

The log shows no errors but a mod does nothing. What now?

Check it has a Loading line. If it does, the mod loaded and the cause is elsewhere: it is client-side and installed only on the server, it is disabled by default in its config, or its settings are synced from somewhere you did not edit.

Is it safe to delete LogOutput.log?

Yes. BepInEx creates a new one on the next start. Copy it first if you are in the middle of chasing a fault.

How do I find which mod is lagging the server?

The log helps only if the mod is throwing errors, visible as the same exception repeating. Otherwise bisect with a test world and a stopwatch, or watch CPU in the server's graphs while removing suspects.

What does the log line count in N plugins to load include?

Every plugin BepInEx found in plugins and its subfolders, including ones it will then skip or fail to load. A number higher than your mod count means duplicates or forgotten files.