ARK: Survival Ascended Server Will Not Start or Keeps Crashing
Read the log before you restart. An ASA dedicated server writes ShooterGame/Saved/Logs/ShooterGame.log. The filename never changes, which is exactly the problem: launching again rotates that file away. Restarting to see if it works this time destroys the most detailed record of why the last boot died. Two things usually survive a restart: crashcallstack.txt, which is rewritten per fatal error rather than rotated, and the dated ServerGame logs written when the server runs with game logging enabled. Copy ShooterGame.log elsewhere first anyway, because it is the fullest account you will get.
Crashed is one word covering at least five unrelated failures. A server that exits in two seconds and one that dies forty minutes in have nothing in common except the word. This page separates them.
Step 1: Get the Log, Intact
On a self-hosted box the log sits under the server install at ShooterGame/Saved/Logs/ShooterGame.log. On our platform the install shape is /home/<user>/arksa/, with the game in bin/ and data/Saved symlinked in so worlds survive a game upgrade, putting the file at /home/<user>/arksa/data/Saved/Logs/ShooterGame.log.
Two files there matter:
ShooterGame.log, the game's own log: world load progress, mod fetches, joins and leaves, and the fatal error block if there was one. Not the launcher or service output, which looks fine while the game dies.crashcallstack.txt, small, rewritten on every fatal error, not rotated on launch. When the main log has been lost to a restart, this is often the last surviving evidence.
Check the modification time on both: a file older than the last boot attempt describes a different crash.
Learn two shapes at the end of the log. A game-level fatal error ends with an error block naming the failure and a call stack under it. An operating system kill ends with nothing: the last line is an ordinary world-load or save line, then the file stops. That difference decides your next move.
Step 2: The Diagnostic Ladder
Time the failure. How long the process survives is the most informative fact you have, because each window points at a different layer.
| What you observe | Likely layer | First check |
|---|---|---|
| Exits within seconds, world load never begins | Launch line, binary, environment | Last 40 lines of the log. A bad argument, a missing file or a port bind failure all surface before any map work. |
| Starts, prints load progress, dies before the world is up | Map, mods, or the save | Which map the log names, and whether a mod is being fetched when it stops. |
| Runs half a minute to a couple of minutes, dies every time | Mod resolution | An unfetchable mod ID crashes ASA shortly after boot, not at boot. Look for a mod query error. |
| Runs minutes or hours, then vanishes with no error block | Memory or the host | System memory. An operating system kill leaves no crash text. |
| Runs fine until players connect, dies shortly after | A mod driven by player activity, or headroom gone on first load-in | Whether it dies on the same player, the same area, or any join at all. |
| Runs, stays up, never appears in the server list | Not a crash | A listing problem. See no sessions found and online but cannot join. |
That last row matters more than it looks. Many will not start reports are servers that started fine and are merely invisible, and validating files never fixes those.
Step 3: Match the Cause
| Cause | Symptom | Fix |
|---|---|---|
| A mod no longer matching the game build | Clean boot until the mod layer loads, then a fatal error. Usually begins the day a patch lands. | Boot with no mods, then bisect. See mod broke after update. |
| A mod ID that cannot be fetched | Survives roughly 40 seconds, then dies. A mod query error in the log, a requested mods failure in the crash file. | Remove the offending ID. Delisted and mistyped IDs behave identically. |
| A map mod that changed or was removed | Boot fails on world load, or a fallback map loads instead of yours. | Confirm the map still exists on CurseForge and that a sponsored map still has its companion ID. |
| Corrupted or partially written save | A mod-free boot on the same build dies in world load, but a new world boots fine. | Restore, do not repair. Covered below. |
| Out of memory during world load | Death at a consistent point in the load, or a process vanishing with no crash text. | Measure free memory during a boot. Covered below. |
| Port already in use | Exit within seconds, the log complaining about binding before anything else. | An old process from the last crash is usually still holding it. |
| INI syntax error or a stray character | A setting silently ignored, or the file refused outright. A pasted smart quote or control character is the classic. | Diff against a known good file. See the settings reference. |
| A game update landing mid-session | Was running, went down on its own, will not come back on the old files. | Update to the current build. A newer client also cannot connect: see version mismatch. |
| Disk full | Boot dies at the first write, or a save truncates and the next boot fails on it. | Check free space first. ASA plus mods plus backups is a large footprint. |
Out of Memory Deserves Its Own Look
ASA is genuinely memory hungry. A modest map sits around 9 to 10 GB resident, and larger DLC and community maps climb well past that. A machine that comfortably ran an ASE server will not necessarily run an ASA one.
The two signatures look completely different:
- The game runs out of memory itself. A fatal error block is written at the end of the log and the crash file updates. The server knew it was dying and said so.
- The operating system kills it. Nothing is written anywhere: the log's last line is a normal one, no call stack, no crash file update, the process simply gone. On Linux the kernel records the kill in the system log rather than anything ARK owns, which is why this reads as crashed for no reason.
The second shape wastes the most time: there is no error string to search for. A silent log twice means check memory before touching mods.
The important correction: more players is not the main driver. The map and the accumulated contents of the world are. Years of structures, tames and dropped items cost memory whether anybody is connected or not, because the server simulates them regardless. Cutting the slot count changes nothing for a server that dies during world load, since the world loads before a player can join. See ASA self-host hardware sizing.
Mods Are the Most Common Cause
ASA mods come from CurseForge, not the Steam Workshop, and they update on the author's schedule rather than yours. A server that booted last night and refuses tonight, with nothing changed on your side, has almost always had a mod updated underneath it. Install mechanics are in installing and managing ASA mods, fetch and load-order problems in ASA mods not loading.
Bisect rather than remove one at a time. Twenty mods, one at a time, is up to twenty boot cycles at several minutes each; halving gets there in about five.
- Back up the entire
Saveddirectory before touching anything. - Remove every mod from the launch line and start. This only establishes that a clean boot is possible on this build with this world. If it still fails with no mods, stop: the problem is the binary or the save.
- Add back the first half of the list and start. If it boots, the culprit is in the other half.
- Take whichever half fails and halve it again. Repeat.
- With one mod left, confirm by booting with only that mod, then with everything except it.
Keep the list in the same order throughout. Order carries priority, and reshuffling mid-bisect adds a second variable to an experiment built to isolate one.
Save Corruption: Restore, Do Not Repair
World data lives in ShooterGame/Saved/SavedArks/. The world is a .ark file named after the map, player data uses .arkprofile, tribe data .arktribe. Alongside them ARK keeps backup copies: an anti-corruption copy written around server start, and a rolling set governed by -MaxNumOfSaveBackups, which the official ARK Community Wiki documents as defaulting to 20 with the oldest deleted as new ones appear. Save frequency is AutoSavePeriodMinutes, default 15. Both keys are in the wiki's server configuration reference.
The honest position on a corrupted world: it is a restore, not a repair. No supported tool reads a damaged .ark and writes a healthy one. What you do is work backwards through the backup copies until one boots. Copy, never move, so a failed attempt does not cost you the chance to try an older one.
Confirm the save is the problem first: boot the same build, with no mods, on a brand new world. If that works and the old world does not, the world is the suspect. Recovery steps are in ASA save corruption recovery, backup layering in the unofficial backup strategy, the restore workflow in ARK backups and restoration.
What to Collect Before Asking for Help
Whoever you ask wants the same five things. Having them ready turns a two-day thread into a ten-minute answer.
| Item | Why it decides the answer |
|---|---|
| The log from the failed boot, not a later one | Everything else is guessing. Send the last few hundred lines, not the one line that looked wrong. |
| The mod list, with IDs, in load order | Names are ambiguous, IDs are not, and order changes behaviour. |
| The map, with its exact identifier | Separates base, DLC and community maps, which fail differently. |
| The last change made, however small | Including changes made for you: a mod update, a patch, a host reboot. |
| When it last worked | Bounds the search to that window. |
Related Reading
- ASA boot loop fix, for endless restarts rather than a server that stays down
- ASA will not start after the Genesis update
- ASA dedicated server setup, for the launch line layout
- ASA settings reference, GameUserSettings.ini and the Game.ini section
/Script/ShooterGame.ShooterGameMode - ASA breeding and taming rates
- General ARK server troubleshooting
Managed ARK: Survival Ascended server hosting. Supercraft runs ASA dedicated servers on AMD EPYC hardware with CurseForge mods, every released map, raw INI access, daily snapshots and four regions. Logs are archived on every launch rather than overwritten, so a failed boot's evidence survives the restart.