How to Read & Fix Arma Reforger Server Crashes

When an Arma Reforger server crashes, the Enfusion engine writes a native crash dump with a .dmp extension that records exactly what failed: the terminating signal, the faulting module, a backtrace, and the list of loaded modules. Reading that dump is how you turn a vague crash into a specific fix. This guide explains what a Reforger crash dump contains, what the Dump Reader surfaces for you, including mod attribution for script crashes, and how to act on each finding. Good crash-diagnosis guides for Reforger are scarce, so this is meant to be the definitive one.

Why Arma Reforger Servers Crash

A Reforger server crash falls into a handful of broad buckets: a native engine fault, a script-level error from a mod that cascades into a hard stop, a memory exhaustion situation, or a corrupted file or bad config. The Enfusion engine handles native faults by writing a crash dump rather than failing silently, which is what makes diagnosis possible. The dump tells you which bucket you are in.

Tip: Before opening a dump, note what changed recently: a mod added, a Workshop update, a config edit, or a player-count spike

Note: Native crashes show a clear terminating signal and a faulting module

Note: Script crashes from mods often surface as a specific mod being attributed in the dump

Note: Memory exhaustion crashes correlate with RAM climbing steadily before the stop

What a Reforger .dmp Crash Dump Is

When the server process crashes, Enfusion writes the native .dmp file into the server’s dumps directory, while the matching session logs (including crash.log) live under the profile logs directory. The Dump Reader pulls both and pairs them for you. The .dmp is a snapshot of the process at the moment it died. On its own it is binary and hard to read, which is why a reader that parses it into human-readable findings is so valuable. The dump is generated automatically; you do not have to enable anything.

1. After a crash, locate the most recent .dmp file in the server’s crash output
2. Note its timestamp and match it against when players reported the crash
3. Match the .dmp against the console log from the same time window
4. Open the dump in a crash dump reader to turn it into readable findings

Note: A .dmp is paired with log files; the log gives the narrative and the dump gives the precise fault state

Reading Dumps with the Dump Reader

The Dump Reader parses a Reforger .dmp inside the panel and surfaces the parts that matter without you needing external debugging tools. It pulls out the terminating signal, the faulting module, the backtrace, and the list of loaded modules, and crucially it attributes script crashes to the responsible mod where it can. That mod attribution is the difference between guessing and knowing.

1. Open the Dump Reader in the LPV5 panel (under Server, in the Diagnostics section of the sidebar)
2. Select the .dmp file from the crash you are investigating
3. Read the terminating signal to learn how the process died
4. Read the faulting module to learn where it died
5. Read the backtrace to follow the chain of calls into the crash
6. Check the loaded modules list and any mod attribution for script crashes

Tip: The reader does the binary parsing for you, so you can focus on interpreting the findings

Understanding the Terminating Signal

The terminating signal tells you the category of failure. An access violation or segmentation fault means the process tried to touch memory it should not have, which is a classic native fault. An abort signal usually means the engine itself detected an unrecoverable condition and chose to stop. A memory-exhaustion crash usually shows up as a SIGABRT (the engine aborting on a failed allocation) or as a SIGKILL with no dump at all (the kernel OOM-killer). The reader confirms memory pressure by comparing the crashing process’s resident memory against your plan RAM, not from the signal alone.

Tip: A memory-exhaustion crash means look at your plan size and modlist weight, not at a backtrace

Note: Access violation or segfault: the process touched invalid memory, often a native or mod-native fault

Note: Abort: the engine deliberately terminated after detecting an unrecoverable state

Note: Memory exhaustion: the server ran out of RAM, which is a capacity problem, not a code bug. It surfaces as a SIGABRT (failed allocation) or a SIGKILL with no dump (the kernel OOM-killer), not as a dedicated out-of-memory signal

The Faulting Module and Loaded Modules

The faulting module is the binary or component that was executing when the crash happened. If it is a core engine module, you are likely looking at an engine-level issue, a bad asset, or memory corruption. If the faulting module ties back to a mod, that mod is your prime suspect. The loaded modules list is the full inventory of what was running, which helps you see whether a recently added mod or dependency was present.

Tip: A faulting module that maps to a mod points the investigation straight at that mod

Tip: A faulting module in core engine code with no mod nearby suggests a bad asset or a hardware or memory issue

Tip: Cross-reference the loaded modules list against your modlist to spot anything unexpected

Warning: Do not assume the faulting module is always the root cause; memory corruption can crash an innocent module that just happened to run next

Reading the Backtrace

The backtrace is the sequence of function calls that led into the crash, read from the crash point outward. It is the story of how the process arrived at the fault. You do not need to understand every frame; you are looking for the topmost meaningful frame and for any frame that names a mod or a recognizable subsystem such as AI, vehicles, or networking.

1. Start at the top of the backtrace, which is closest to the crash
2. Identify the first frame that names a real subsystem or mod
3. Note whether the chain runs through AI, vehicle, physics, or networking code
4. Combine that with the faulting module to form a single working theory

Tip: A backtrace that repeatedly passes through one subsystem points you at that subsystem’s recent changes

Mod Attribution for Script Crashes

Many Reforger server crashes are not native faults at all but script-level failures inside a mod that escalate until the server cannot continue. These are the hardest to diagnose by gut feel, because the server simply stops. The Dump Reader attributes script crashes to the responsible mod where the dump and logs make that possible, so you can name the offending mod instead of bisecting your whole modlist.

1. Check whether the reader has attributed the crash to a specific mod
2. If a mod is named, that mod is your prime suspect
3. Disable or remove the attributed mod and restart the server
4. Confirm the server is now stable, then report the issue to the mod author with the dump details

Tip: Mod attribution can save hours; it replaces trial-and-error bisection with a direct lead

Tip: If no mod is attributed but you suspect mods, fall back to bisecting: remove half the modlist, test, and narrow down

Acting on the Findings

Once the dump has told you the signal, the faulting module, the backtrace, and any mod attribution, you take a clear action. The fix depends on the category: a mod crash means removing or updating that mod, a memory crash means a bigger plan or a lighter modlist, a corrupted-file crash means restoring a backup, and an engine crash with no mod involved means reporting it with the dump.

1. Mod-attributed or mod-faulting crash: remove or update the mod, restart, and verify stability
2. Out-of-memory crash: move to a larger plan or trim heavy mods, then retest
3. Crash after a config change: revert config.json or restore a backup from before the change
4. Repeating engine crash with no mod involved: keep the .dmp and logs and report it with full detail
5. After any fix, watch the next few hours of console output to confirm the crash does not recur

Note: Loafbox plans give you dedicated CPU threads, which removes contention as a variable when you are isolating a crash

Preventing Future Crashes

Most Reforger crashes are preventable with a little discipline. Keep mods current so you are not running a version with a known fault, change one thing at a time so any new crash has an obvious cause, back up before risky changes, and right-size your plan so memory pressure is never the issue.

Tip: Change one mod or one config field at a time so a new crash has a single obvious suspect

Tip: Take a backup before adding mods, swapping scenarios, or editing config.json

Tip: Schedule daily restarts to clear accumulated memory before it becomes a crash

Tip: Keep mods on auto-update so you are not stuck on a version with a known bug

Warning: Stacking several changes at once turns the next crash dump into a guessing game; isolate your changes

Frequently Asked Questions

Where are Arma Reforger server crash dumps stored?

The Enfusion engine writes a native .dmp crash dump automatically when the server process crashes. The .dmp lands in the server’s dumps directory, while the matching session logs live under the profile logs directory. On Loafhosts you can open these directly in the Dump Reader rather than downloading and parsing them yourself.

What is a .dmp file in Arma Reforger?

A .dmp file is a native crash dump, a binary snapshot of the server process at the exact moment it crashed. It records the terminating signal, the faulting module, a backtrace, and the loaded modules. A crash dump reader parses it into readable findings.

How do I find out which mod crashed my server?

The Dump Reader attributes script-level crashes to the responsible mod where the dump and logs allow it. If a mod is named, remove or update it and retest. If no mod is attributed, bisect your modlist by disabling half at a time until the crash stops.

What does the terminating signal in a crash dump mean?

It tells you the failure category. An access violation or segfault means the process touched invalid memory. An abort (SIGABRT) means the engine deliberately stopped after an unrecoverable condition, frequently a failed allocation when the server has run out of RAM and needs a bigger plan or a lighter modlist. A SIGKILL with no dump is usually the kernel OOM-killer.

My Reforger server keeps crashing under load. What should I check?

Watch memory usage as the player count climbs. If RAM rises steadily before each crash and the dump shows an out-of-memory signal, it is a capacity problem. Move to a larger plan, such as a higher Loafbox tier with more headroom, or trim heavy mods.

Can a bad config.json cause a server crash?

An invalid config.json usually prevents the server from starting rather than crashing it mid-session, but a bad scenario reference or a misconfigured value can cause failures once running. If a crash started right after a config edit, revert config.json or restore a pre-change backup.

What does the faulting module tell me?

The faulting module is the component that was executing when the crash happened. If it maps to a mod, that mod is the prime suspect. If it is core engine code with no mod nearby, suspect a bad asset or memory corruption. Confirm with the backtrace before concluding.

What do I do if the dump points at the engine and no mod?

If the faulting module is core engine code, there is no mod attribution, and the crash repeats, keep the .dmp file and the matching logs and report it as an engine issue with full detail. Also rule out memory pressure and a corrupted file by restoring a known-good backup.