tModLoader Server Won't Start on Linux: MissingMethodException & ARM Crash

tModLoader Server Won't Start on Linux: the MissingMethodException Crash and Why ARM VPS Hosting Fails

Last verified: June 2026.

There is a category of tModLoader problem that has nothing to do with mods, ports, or version mismatches between players. The server process never finishes booting. You launch it, the console prints a fatal exception, and the world never comes online. This guide covers two distinct, related self-host failures: a Linux startup crash that throws System.MissingMethodException: Microsoft.Xna.Framework.Game..ctor(Boolean), and the simpler, harder wall that the dedicated server cannot run on ARM hardware at all. Both are "the process won't even start" problems, which is why they belong in their own guide rather than in the multiplayer connectivity fixes or the large-world performance tuning.

Symptom 1: System.MissingMethodException on the Game constructor

The launch crash typically looks something like this in the console or in server.log:

Unhandled exception. System.MissingMethodException: Method not found:
'Void Microsoft.Xna.Framework.Game..ctor(Boolean)'.
   at Terraria.Main..ctor()
   at Terraria.Program.LaunchGame(...)

A MissingMethodException is the .NET runtime saying: the code asked for a method with a specific signature, and the assembly that should provide it does not contain that method. In tModLoader's case the engine constructs Microsoft.Xna.Framework.Game, but the FNA assembly that ships with the build (FNA is the open-source reimplementation of Microsoft's XNA, and is what tModLoader uses in place of the original MonoGame/XNA layer) does not expose the exact constructor the engine was compiled against. This was reported on a 1.4.4-preview build, and the underlying shape of the failure is the same across builds: the managed assemblies, the native libraries, and the runtime do not all agree.

The mismatch comes from one of a few places, and you should not assume which without reading the log:

• A stale or partial install. An update that copied new managed DLLs over old native libraries (or the reverse) leaves the FNA layer out of step with the engine that calls into it.
• The wrong or missing .NET runtime. tModLoader is a .NET application and expects a specific runtime line. If the host has the wrong major version, or only an ASP.NET or SDK package that the launcher does not recognise as a valid runtime, resolution of XNA/FNA methods can fail. There are documented cases of tModLoader not detecting an otherwise-present .NET runtime, which produces exactly this class of "method not found" symptom. We deliberately do not name an exact version number here, because the required runtime moves with each tModLoader release; read your build's own requirement rather than trusting a number copied off a forum.
• Missing native dependencies. FNA loads native libraries at startup (FNA3D, SDL2, and friends). When those are absent or the wrong build, you can also see a sibling crash, TypeInitializationException from FNAPlatform or a "could not find a suitable graphics device" message rather than a clean MissingMethodException. They share the same root cause family: the runtime environment does not match what the binary was built for.

How to read the launch log: dependency crash vs mod crash

The single most useful diagnostic skill here is telling apart a runtime/dependency crash from a mod crash, because the fixes are completely different. Open server.log (on a hosted Supercraft server it lives under /executables/tModLoader-Logs/; the tModLoader logs guide covers the full layout) and look at where in the boot sequence the exception is thrown.

If the crash lands in the engine constructor or the FNA platform layer and you never see a single mod name, stop disabling mods. You are chasing the wrong problem. No amount of editing enabled.json fixes a runtime that is missing a method, because the server dies before it ever reads your mod list.

Symptom 2: tModLoader does not run on ARM (x86-64 is mandatory)

This is the harder wall, because no fix on your side can clear it. People reach for a cheap or free ARM box to host modded Terraria for their friends, most often Oracle Cloud's always-free Ampere A1 tier, but also other ARM cloud instances and Raspberry Pi boards. The server then fails to start, frequently with a MonoMod "method or operation is not implemented" exception during boot rather than the FNA constructor error above.

The reason is not a misconfiguration. The official tModLoader documentation states it plainly: "Currently ARM support does not exist for TML or the Dedicated Server", and "there is no known way to run any TML applications on ARM." tModLoader ships and is supported only for x86-64. The blocker is in the lower layers tModLoader depends on (the MonoMod runtime-patching library and the FNA native stack), not something the platform exposes a switch for.

Why the "free ARM VPS" trap is so common

Oracle's free Ampere tier is genuinely generous on paper: multiple ARM cores and a healthy slice of RAM at no cost. For many server games that is a fine starting point. For modded Terraria it is a dead end, and the failure mode is confusing because the box itself is healthy, SteamCMD may even appear to install files, and only at launch does everything fall apart. If you have spent an evening fighting a tModLoader server on an Ampere instance or a Pi, the problem was never your config. The architecture was wrong from the first command. The same goes for any "ARM Ampere" or "Graviton-style" instance: the price is attractive precisely because ARM capacity is cheap, but tModLoader cannot use it.

Diagnostic and fix checklist

Work through these in order. The first two questions decide everything else.

1. Confirm the architecture first. Run uname -m on the host. If it prints aarch64 or arm64, stop. tModLoader will not run here; move to an x86-64 host. If it prints x86_64, the architecture is fine and the crash is a runtime/dependency issue, so continue.
2. Read the log and classify the crash. Open server.log, scroll to the bottom, and decide: did it die in the engine/FNA layer before loading mods (dependency crash), or after naming a mod (mod crash)? Only treat it as a startup-runtime problem if it is the former.
3. Install the correct .NET runtime for your build. Match the runtime line your tModLoader version requires rather than whatever happens to be installed. A missing or wrong-major runtime is a leading cause of "method not found" at launch. Verify the launcher actually detects it, not just that a package is present.
4. Install the required native libraries. On a bare Linux box the FNA stack needs its native dependencies (SDL2 and the FNA3D libraries it loads). Missing natives surface as DllNotFoundException, TypeInitializationException from FNAPlatform, or "no suitable graphics device". A headless dedicated server still links the graphics layer at startup, so these libraries must be present even though nothing is rendered.
5. Reinstall cleanly if the install is mixed. If managed DLLs and native libraries are out of step from a partial update, a clean reinstall of the dedicated-server files realigns the FNA assembly with the engine that calls it. Do not patch a half-updated tree.
6. Stop touching mods if the crash is pre-mod. Disabling mods cannot fix a runtime mismatch. Resolve the runtime first, then return to mod loading.

How managed x86 hosting removes both problems

Both of these failures are environment problems, and a managed host eliminates the environment as a variable. On a managed Terraria dedicated server the tModLoader runtime, the matching .NET line, and the native FNA dependencies are preinstalled and kept in step with the build, so the MissingMethodException class of crash simply does not occur, there is nothing for you to mismatch. Just as importantly, the hardware is x86-64, so the ARM wall never comes up. You cannot accidentally provision an Ampere box and lose an evening to it.

There is a second, quieter reason managed x86 wins for Terraria specifically: the engine is single-threaded, so it lives or dies on single-core clock speed, not core count. The cheap ARM cores that make a free tier attractive are exactly the wrong shape for a Terraria tick loop even before the support problem. A host that runs high-frequency x86-64 cores, the right runtime, and an open port gives you a server that starts on the first try and holds its tick rate during a boss fight.

FAQ

Next Steps

• Read the logs to classify a crash
• Fix connection and mod-sync problems
• Set up a dedicated server the right way
• Enable the tModLoader branch on your server
• Back to Terraria Wiki Home

Looking for managed Terraria server hosting? Supercraft runs Terraria dedicated servers on x86-64 hardware with the tModLoader runtime preinstalled, daily backups, instant setup, and 5 region options. Plans from $5.99/mo.