ASA Server Won't Start After Genesis (v91): Linux/Proton Fix

ASA Server Won't Start After the Genesis Update (v91): The Linux/Proton Fix

Last verified: July 21, 2026, against admin reports and the confirmed community fix for the July 2 Genesis Ascended (v91) server build.

The symptoms

• Server process starts, then exits within seconds - or loops silently. CPU sits under 1% and RAM under ~500 MB: the engine never actually booted.
• Console/log shows System.PlatformNotSupportedException: Video driver not supported, No displays available, or d3d12.dll access violations.
• RCON never comes up: endless waiting for rcon connection... dial tcp 127.0.0.1:<port>: connect: connection refused.
• On the install/update side you may also see ERROR! Failed to install app '2430930' (Invalid platform) from SteamCMD.
• Maddening detail: some of your servers keep working while others die. Admins reported Island and Aberration broken while Ragnarok ran fine - not because of the map, but because the Ragnarok box had not taken the v91 binary yet. The breakage follows the server build, not the map.

Two separate problems colliding

The community diagnosis (worked out in a pterodactyl/game-eggs thread, confirmed working by multiple admins) is that two distinct failures land at the same time and mask each other:

1. The install failure - "Invalid platform". SteamCMD tries to fetch a Linux build of the ASA dedicated server (app 2430930). There is no Linux build - ASA's server is Windows-only and always runs under Proton/Wine on Linux. Without the platform override, you get empty or corrupted server files.
2. The boot failure - the v91 display/DX12 init. Since v91, ArkAscendedServer.exe initialises a graphical window (X11) and DirectX 12 hardware rendering at startup, even as a dedicated server. Headless container or VM + no GPU = instant death before the server logic ever runs.

Fix part 1: the install ("Invalid platform")

Force SteamCMD to download the Windows server files. The platform override must come before the app_update:

./steamcmd.sh +@sSteamCmdForcePlatformType windows \
  +force_install_dir /path/to/server \
  +login anonymous +app_update 2430930 validate +quit

On Pterodactyl, set the egg's Windows Install variable to 1 (or inject the override into the install script), then reinstall. You want to see Success! App '2430930' fully installed before moving on.

Fix part 2: the boot (display/DX12 crash)

Three changes to the launch, all required:

1. Virtual display: wrap the launch in xvfb-run -a so X11 initialisation has somewhere to land.
2. OpenGL instead of vkd3d: set PROTON_USE_WINED3D=1 in the environment so Direct3D calls route through WineD3D/OpenGL instead of expecting a Vulkan-capable GPU.
3. Downgrade the renderer: append -server -dx11 to the server arguments so Unreal stops asking for DX12.

Put together, a launch line goes from this:

proton run ./ShooterGame/Binaries/Win64/ArkAscendedServer.exe TheIsland_WP?listen ...

to this:

PROTON_USE_WINED3D=1 xvfb-run -a proton run \
  ./ShooterGame/Binaries/Win64/ArkAscendedServer.exe TheIsland_WP?listen ... -server -dx11

Two follow-up notes from the same thread: updating to Proton 10 resolved residual issues for the original reporter, and on Pterodactyl the startup-command change must be applied to each existing server instance - editing the egg does not retroactively update servers that were created from it.

How to verify it worked

• The process survives past the first minute and RAM climbs to normal ASA-server levels (many GB, not 500 MB).
• The waiting for rcon connection... loop ends - RCON accepts the connection once the engine is actually up. First boot after Genesis can be slow; give it several minutes before judging.
• ShooterGame/Saved/Logs/ShooterGame.log advances past engine init into map load lines.

If the server boots but players cannot see or join it, that is a different problem - see ASA server online but can't join and no sessions found. If it boot-loops for reasons that predate v91, the general boot-loop guide covers the classic causes.

If you rent instead of self-host

This whole class of failure is the host's job, not yours. On a managed ASA server the launch environment - virtual display, Direct3D routing, Proton version - is maintained platform-side; Supercraft's ASA stack has run the xvfb-run + PROTON_USE_WINED3D=1 pattern in production since onboarding, which is why the v91 change was a patch-day non-event rather than an outage. If your current host's ASA servers went down with v91 and stayed down, that tells you something about how their launch stack is maintained.

Related guides

• ASA dedicated server setup
• ASA recent patches & updates (2026) - what shipped in v91 and since
• Client/server version mismatch fix
• Self-host hardware sizing - Genesis also grew the client install footprint substantially (server stays ~12 GB)

Looking for managed ARK: Survival Ascended server hosting? Supercraft runs ASA dedicated servers with daily backups, instant setup, and 5 region options.