ProtonDB has a lot of reports of people having the same issue (all with AMD cards), and most not being able to run the game at all with the RADV drivers. I've been able to play just fine with RADV drivers however. I don't have AMDVLK even installed though, so that might be the difference?

"EndeavourOS Linux" (64 bit)
Kernel Version: 6.7.1-zen1-1-zen
X Window Manager: wlroots wm
Steam Runtime Version: steam-runtime_0.20231127.68515
Driver: AMD AMD Radeon RX 6900 XT (radeonsi, navi21, LLVM 16.0.6, DRM 3.56, 6.7.1-zen1-1-zen)
Driver Version: 4.6 (Compatibility Profile) Mesa 23.3.3-arch1.1

Two problems I did run into with this game:

• When closing the game Steam will sometimes start validating 8.4 GiB of files. Not sure what files or why.
• I was unable to launch the game at all earlier. Not sure what caused it or why, just no window would show up. It looked as if it stalled on launch. Running with PROTON_LOG=1 gave me nothing but the below. The only solution I could find was to delete the compatdata folder for the game.

======================
Proton: 1705700124 proton-8.0-5c
SteamGameId: 1203620
Command: ['/home/johan/games/SteamLibrary/steamapps/common/Enshrouded/enshrouded.exe']
Options: {'forcelgadd'}
depot: 0.20231211.70175
pressure-vessel: 0.20231208.0 scout
scripts: 0.20231208.0
sniper: 0.20231211.70175 sniper 0.20231211.70175
Kernel: Linux 6.7.1-zen1-1-zen #1 ZEN SMP PREEMPT_DYNAMIC Sun, 21 Jan 2024 22:13:51 +0000 x86_64
Language: LC_ALL None, LC_MESSAGES None, LC_CTYPE None
Effective WINEDEBUG: +timestamp,+pid,+tid,+seh,+unwind,+threadname,+debugstr,+loaddll,+mscoree
======================

Edited to add: The game ID is 1203620

Replying to https://github.com/ValveSoftware/Proton/issues/7442#issuecomment-1909589488

i dont have vlk installed either and im running endeavour os with the latest packages installed, the only difference im seeing is that your running a wm while im running kde plasma 5.27.10 and i have tried both kwin x11 and kwin wayland with the same results of it crashing when entering the intro of creating a game

enshrouded.log
here is the enshrouded crash log aswell

thats odd the game is working on kde neon unstable with flatpak steam

edit: if i set reflections to quality the game will crash, setting everything to normal/balanced doesnt make the game crash and its working on endeavour os now so yay :)

On a fully-updated EndeavourOS, with the following stats (and skipping Steam's shader precaching):

GPU: AMD Radeon RX 6650 XT
CPU: AMD Ryzen 5 1600 x12
DE: Gnome 45.3
Kernel: Linux 6.7.1-arch1-1
GPU Driver:  amdgpu
Proton: 8.0-5

The game starts and appears to preprocess the shaders.

However, the problems start once the Keen logo shows up, followed by the main menu.

Under X11, when the window is not selected, the game is choppy, but appears correctly (which seems to be expected behavior from my memory of playing on Windows). When I mouse over the window, or click on the window to make it active, though, the window turns black. I can click a menu element (Play or Settings, for example) a frame or two before it goes black, but if I then make the window unselected to see the current state, it will appear back at the main menu. This is the same in either Windowed mode or Fullscreen mode (toggled with Alt+Enter).

Under Wayland instead, it's the same as X11 under windowed mode. However, if I switch in fullscreen mode with Alt+Enter, then the game wholly appears correctly, regardless of if the window is active or not. I still get a black screen game crash when attempting to load a world, though - about 6 seconds after the loading screen starts, my GPU hangs, first evidenced by my inability to scroll a web browser on my other screen, after which my mouse cursor also stalls.

About 12 seconds after that starts, the game crashes.

The crash log is as follows:

https://gist.github.com/SolarLune/205f98300b60908ad06f206999320bc6

I tried a few times more - setting the graphics quality settings to Max Performance didn't help; it still hung the GPU driver. Changing it from my desktop resolution (1440p) to 720p and turning off FSR2 as antialiasing didn't help either - it hung for a longer period of time this time, and then crashed Wayland (I presume) and kicked me out to the login prompt.

System:
  Kernel: 6.6.13-200.fc39.x86_64 arch: x86_64 bits: 64 compiler: gcc
    v: 2.40-13.fc39 Desktop: KDE Plasma v: 5.27.10 Distro: Fedora release 39
    (Thirty Nine)
CPU: AMD Ryzen 9 7950X3D 16-Core @ 32x 5.759GHz
Graphics:
  Device-1: AMD Navi 31 [Radeon RX 7900 XT/7900 XTX] vendor: Sapphire NITRO+
    driver: amdgpu v: kernel arch: RDNA-3 bus-ID: 03:00.0
  Display: wayland server: X.org v: 1.20.14 with: Xwayland v: 23.2.4
    compositor: kwin_wayland driver: X: loaded: amdgpu
    unloaded: fbdev,modesetting,radeon,vesa dri: radeonsi gpu: amdgpu
    resolution: 1: 2560x1440 2: 2560x1440 3: 2560x1080 4: 2560x1440
  API: EGL v: 1.5 drivers: radeonsi,swrast platforms:
    active: wayland,x11,surfaceless,device inactive: gbm
  API: OpenGL v: 4.6 compat-v: 4.5 vendor: amd mesa v: 23.3.3 glx-v: 1.4
    direct-render: yes renderer: AMD Radeon RX 7900 XTX (radeonsi navi31 LLVM
    17.0.6 DRM 3.54 6.6.13-200.fc39.x86_64)
  API: Vulkan v: 1.3.268 drivers: radv,llvmpipe surfaces: xcb,xlib,wayland
    devices: 2

I was able to start a single player game running Proton Experimental: Bleeding Edge.
I also had to turn off a particular graphical setting regarding some voxel rendering option in order to have normal frames, otherwise it would render less than 1 FPS.

I do still get an crash of the display driver / display environment if I attempt to join a dedicated server.

Replying to https://github.com/ValveSoftware/Proton/issues/7442#issuecomment-1910828896

That seems to be the same problem for me, hosting works tho

Made mesa issue for the hang when entering a world https://gitlab.freedesktop.org/mesa/mesa/-/issues/10500

Edit: reworded as it likely isn't the intro video or entering the world for the first time part that is the cause.

FWIW, I updated to a kernel-vanilla/stable 6.7.1 from Fedora copr, and the bad behavior changed.
I can now connect to dedicated servers and play mostly normally, and Voxel Detail Models can be enabled now without killing frames.

Point Light Shadows are now broken though, and cause really low frames if enabled.
Otherwise, runs great.

Worth noting that there were several hotfixes targeting the game today. I don't know if any of those would have had a direct effect on our issues.

Back with another finding. As per ProtonDB, starting the game and loading into a single-player world works if I have the RADV drivers installed. On EndeavourOS / Arch, this is done through installing vulkan-radeon and vulkan-icd-loader, I believe, and then running the game with the command VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json:/usr/share/vulkan/icd.d/radeon_icd.i686.json %command%.

Also note that the game runs fine on Steam Deck at about 25-30 FPS on all Performance settings.

I'm also having similar problems, the game launches fine but when I join a multiplayer game it starts to load then I get a black screen, then loading screen again and after that the whole system hangs and I have to pull the power to restart computer.

I have also found a way to circumvent this hang, if I start a single player game first and then quit to start screen I am able to join a multiplayer game without the system hanging. Doing it this way I loose about 2/3 of my fps though. going from 60-100 to 19-25, mangohud is telling me my GPUs memory frequency is going down from a locked 1000Mhz in the single player game to a fluctuating 400-600Mhz during multiplayer.

System:
Nobara 39
Mesa 23.3.3
Kernel 6.7.0
Proton, its the same behavior with proton 8, experimental and ge-proton-8-30

The game runs fine on Ubuntu 23.10 with a RTX 3080 and Ryzen 7 5700X, even at some times beating Windows 11 performance on the same machine.

However the only glitch I have found is that sometimes when launching the game, it will launch in windowed rather than full screen, but this can be easily fixed by toggling in game.

Whether this is the game, Proton or Gnome is anyone's guess.

I have similar issues. In order to be able to join a multiplayer dedicated server, i need to sett my settings to "Max Performance". When in game again, i turn them on one by one.

The following options causes issues for me:

• Contact Shadows: Crashes the game. Sometimes i get a crash message, sometimes i need to kill the computer.
• Reflections: Crashes the game. Sometimes i get a crash message, sometimes i need to kill the computer.
• Point Light: Kills frame rates. I drop to 2-3 fps on my 7900XTX

I can have all other settings on max without issues.

System:
Kubuntu on kernel 6.7.6
AMD 7800X3D
Sapphire RX 7900XTX Nitro+
64Gig 6000mhz memory

Edit:
It seems with those 4 settings disabled, I am able to launch the game as is. The strange thing is that sometimes i can enable some of the settings without it crashing. But not always. But i have steadily played with these off now for a two weeks and no more crashes.

Edit 2:
I can also reliably launch the game with Voxel detail models set to max now. It crashes very rarely with this setting on.
Still not possible to launch with the above 3 settings on anything than low/off.

The game feels very stuttery for me on Wayland as VRR is not being used even when forced to always on in Plasma settings. The game only has windowed or borderless mode and trying it in windowed mode then using KWin to fullscreen it (which enables VRR with every other program, you can tell by slight flickering) does not work for Enshrouded.

with the newest patch it crashes a couple of times when trying to load the shader cache and trying to load into a world will stay in the loading screen for a couple of minutes then it kicks you back out to the menu, also some images are broken

this was under latest proton experimental(bleeding edge)

rx 6700 mesa 24.0.3 kernel 6.8

EDIT: latest proton experimental(bleeding edge) the game is now working properly, able to load in and main menu looks correct!

Can confirm, the remaining issue is the never ending 'validation' of around 10GB. Any known fix for this?

Can confirm, the remaining issue is the never ending 'validation' of around 10GB. Any known fix for this?

Yeah I am getting the same issue. 9.2 GB of data is being downloaded every time. I have a feeling it is due to the shader cache.

EDIT: Yeah I left Steam to finish processing the shaders in the background and now I no longer get the 9.2 GB download.

EDIT 2: Nvm, it still seems to trigger big downloads but only after a day or so. Doesn't happen with every launch of Steam.

Another issue I am experiencing is if I set Texture settings to Max Quality, all the textures appear black. If I drop it down by one to Quality, it seems okay.

@kisak-valve Here's the proton logs: steam-1203620.log

To generate these logs, I booted into the game, set the texture quality from Quality to Max Quality to trigger the black texture bug, and then loaded into my world. After spinning the camera around for a few seconds, I immediately quit the game.

Here are my Steam Runtime Diagnostics

For anyone curious, this is what it looks like in game:

https://github.com/ValveSoftware/Proton/assets/241316/6a807e26-a56a-49ea-9d8e-3aec84a4c5e0

Another issue I am experiencing is if I set Texture settings to Max Quality, all the textures appear black. If I drop it down by one to Quality, it seems okay.

Thank you for reporting this issue. I was able to determine this is an NVIDIA driver regression only present in r555. A fix will be shipped in a future driver release. If you wish to reference this bug in the future it is being tracked internally with bug number 4675675.

with the latest enshrouded update the studio improved steamdeck support and added fsr3 which is working perfectly under proton experimental(bleeding edge)

the game also doesnt crash or freeze when switching around graphics settings so there are no more problems that i am seeing now, this under my rx 6700, mesa 24.1.4, kernel 6.10, cachy os

As of last week something broke when running the enshrouded gameserver in proton, should this be tracked here as well? See https://github.com/ValveSoftware/Proton/issues/7995 (it does not appear to be limited to Fedora) and the linked ticket to find some additional testing.

FWIW, I use ProtonGE 9.10-9.12 on my desktop, I use Nvidia 555 on Fedora 40 Workstation (GNOME) and the actual game works just fine.

Steam (native)
ProtonGE 9.12

but yes, the enshrouded dedicated server in a container with proton is broken.

I use kernel 6.6.3, mesa 23.3.0 and amd fury r9 card and the game crashes after 1 minute with proton 9.03, the system is frozen and reset is needed. I also used proton experimental, ge-20 and got even more crashes. Many steam games work very stable with my configuration. I even do not remember such dreadful crashes with them. They were maybe 5 years ago. Now if a game starts running it continues to work in my system. Thus, crashes are a huge problem of this game.

I use kernel 6.6.3, mesa 23.3.0 and amd fury r9 card and the game crashes after 1 minute with proton 9.03, the system is frozen and reset is needed. I also used proton experimental, ge-20 and got even more crashes. Many steam games work very stable with my configuration. I even do not remember such dreadful crashes with them. They were maybe 5 years ago. Now if a game starts running it continues to work in my system. Thus, crashes are a huge problem of this game.

Please provide logs with the crash if you can

By doing PROTON_LOG=1 %command% as your launch command, it will output a file in your home directory to upload here

You can also use something like qjournalctl to look at your last boot log and it should show what error made that happen

steam-1203620.log
My log and journal log https://gist.github.com/pwasiewi/bb087999f0e1a3c7ce75141a3150821c

Updated mesa with launch option: PROTON_LOG=1 RADV_DEBUG=zerovram %command% and the same crash with log:
steam-1203620.log

@pwasiewi You said you used kernel 6.6.3, but in your logs it says you're on 6.11.3-zen1. There's a kernel bug introduced in 6.10 which breaks the zerovram workaround (as described here: https://gitlab.freedesktop.org/drm/amd/-/issues/3812), so that could be why it still crashed for you with RADV_DEBUG=zerovram.

I tested Mesa 24.2.7 (and later 24.3.1) on kernels before and after the regression with RX 6650 XT to make sure it wasn't a new type of hang. I got four hangs with the newer kernel in four hours total, and none with the older kernel in three hours total. My repro rate wasn't great, but I would've expected at least one hang in the time I tested on the older kernel if it was a new/separate issue, so it seems likely that this is the same issue as before.

Until there's a fix for the kernel bug, the game should be fine on a 6.6 kernel (with Mesa 24.0.8 or newer, or RADV_DEBUG=zerovram).

Hey thank you i will report the Problem to Mesa then.

One of the few games I couldn't get to work on the Radeon 9070 XT so far. Works fine with the Radeon 7800 XT with the same setup.

Kernel 6.13.5
Mesa 25.0.0
kernel-firmware-amdgpu-20250302-1.1 (openSUSE Tumbleweed package)

Crashes with this:

[W 00:00:00,574] [graphics] vkQueuePresentKHR failed with error 'VK_SUBOPTIMAL_KHR'
[W 00:00:00,585] [graphics] vkQueuePresentKHR failed with error 'VK_SUBOPTIMAL_KHR'
[W 00:00:00,602] [graphics] vkQueuePresentKHR failed with error 'VK_SUBOPTIMAL_KHR'
[W 00:00:00,618] [graphics] vkQueuePresentKHR failed with error 'VK_SUBOPTIMAL_KHR'
[I 00:00:00,642] [app] start creation step Preload
[W 00:00:00,684] [graphics] vkQueuePresentKHR failed with error 'VK_SUBOPTIMAL_KHR'
[E 00:00:00,696] [graphics] Failed to allocate download buffer memory.
[W 00:00:00,698] [graphics] vkQueuePresentKHR failed with error 'VK_SUBOPTIMAL_KHR'
[E 00:00:00,701] [graphics] Failed to allocate download buffer memory.
[W 00:00:00,705] [graphics] vkQueuePresentKHR failed with error 'VK_SUBOPTIMAL_KHR'
[I 00:00:00,902] [online] User stats received.
[E 00:00:10,863] [graphics] vkWaitForFences() timed out after 10.00 s.. probably a driver crash!
[E 00:00:10,863] [graphics] Vulkan device lost...
[I 00:00:10,863] [DeviceFaultEXT] A GPUVM fault has been detected
[I 00:00:10,864] [DeviceFaultEXT] Caused by 1 in address range [ 18446603339462164480, 18446603339462168575 ]
[E 00:00:10,864] Stopping process due to unrecoverable GPU crash!

Tried Proton Experimental and bleeding-edge.

@C0Nd3Mnd there is a merge request for this referenced here: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34027

I tested it and it works with the 9070 XT, but for now you have to build mesa from source (not released or even merged to main yet)

The game stays locked on the Preprocessing screen. The log indicates a failure to allocate memory but my RAM has still plenty of space according to the task manager.

I tried to launch the game with Proton 9.0-4, Proton Experimental and GE-Proton9-27.

Device: AMD Radeon RX 590 Series (radeonsi, polaris10, ACO, DRM 3.59, 6.8.0-57-generic) (0x67df)
Kernel: 6.8.0-57-generic
Mesa: 25.0.3 - kisak-mesa PPA

enshrouded_2025-04-09T11-16-05.log

EDIT: Retried today, after some updates of the system. Works with Proton 9.0-4.

I have a different issue where the gpu hangs randomly.
It doesn't happens on every play, but only when loading a save. I have included a trace but umr logs are empty, probably because the gpu resets before it could take a trace.

Software information

Archlinux

System information

• GPU: Radeon RX 6700 XT
• Driver: Mesa 1.25.0.3 and GIT (the trace one)
• Proton version: experimental_be

Log files

steam-1203620.tar.gz

radv_dumps_1556046_2025.04.09_18.11.06.tar.gz

dmesg.log

Not sure if this is a proton issue, but noticed the fossilize replay taking ages for this game (also saw people mentioning in reviews that shader precaching was taking a long time).

Noticed that the shadercache file is enormous:

$ stat -c '%s' .local/share/Steam/steamapps/shadercache/1203620/fozpipelinesv6/steam_pipeline_cache.foz
13580667237

13.5Gb cache file.

$ fossilize-list .local/share/Steam/steamapps/shadercache/1203620/fozpipelinesv6/steam_pipeline_cache.foz --tag 4 --size|sort -n -k 2|tail -4
6037bf64a9fe6952 3335367 compressed bytes, 8025120 uncompressed bytes
5087898493216e29 3343291 compressed bytes, 8031903 uncompressed bytes
234b5e467d71bda2 3344574 compressed bytes, 8029806 uncompressed bytes
41146b3da0507261 3344596 compressed bytes, 8030639 uncompressed bytes

Seems it includes the entire shader hlsl source code a couple of times. Probably an issue with the game, but maybe something that could be more efficient in proton too or going wrong? Not too familiar with this stuff.

ie. snippit like this is present 14x times, in the disasm output

$ fossilize-disasm .local/share/Steam/steamapps/shadercache/1203620/fozpipelinesv6/steam_pipeline_cache.foz --filter-module 41146b3da0507261 --output /tmp/ --device-index 0

...
  47   │ OpSource HLSL 620 %21 "#line 1 \"E:/keen/checkouts/Default//holistic/content/shader/platform.hlsl\"
  48   │ 
  49   │ #ifndef KEEN_PLATFORM_HLSL_INCLUDED
  50   │ #define KEEN_PLATFORM_HLSL_INCLUDED
  51   │ 
  52   │ // rebuild counter: 10
  53   │ 
  54   │ #ifndef KEEN_CONCATENATE
  55   │ #   define KEEN_CONCATENATE_HELPER( value1, value2 ) value1 ## value2
  56   │ #   define KEEN_CONCATENATE( value1, value2 ) KEEN_CONCATENATE_HELPER( value1, value2 )
  57   │ #endif
  58   │ 
  59   │ #define KEEN_IDENTITY( value )              value
  60   │ #define KEEN_MAKE_VARNAME( prefix )         KEEN_CONCATENATE( prefix, KEEN_IDENTITY( __LINE__ ) )
  61   │ #define KEEN_STATIC_ASSERT( EXPRESSION )    typedef uint KEEN_MAKE_VARNAME( keen_static_assert ) [ (EXPRESSION) ? 1 : -1 ]
  62   │ 
  63   │ #if defined( KEEN_FLOAT16 )
  64   │ typedef float16_t float16;
  65   │ typedef float16_t2 float16_2;
  66   │ typedef float16_t3 float16_3;
  67   │ typedef float16_t4 float16_4;
  68   │ #endif
  69   │ 
  70   │ #if defined( KEEN_PLATFORM_PS5 )
  71   │ #   define KEEN_STRUCT_BUFFER           RegularBuffer
...

successfully connected on 2 servers with proton experimental-10.0-20250612c

regards

successfully connected on 2 servers with proton experimental-10.0-20250612c

regards

Thanks heaps! Can confirm working as expected now with Proton Experimental.

Linux/AMD workaround for Enshrouded not launching: jemalloc fix

Posting this because I just spent an embarrassing amount of hours debugging this and I don't want anyone else to go through the same thing.

I'm on Linux with a 7900 XTX running Enshrouded through Proton. Game was working totally fine for almost 3 hours, had a crash mid-session, and after that it just refused to launch. Hit Play, it thinks for a few seconds, then the button goes back to green. No error window, no crash popup, just... nothing.

I tried everything:

• Multiple Proton versions (GE-Proton, Experimental, Hotfix, 9.0-4, 10.0-4)
• Nuking the prefix over and over
• Clearing shader caches
• Verifying game files
• Deleting the game config
• Full reinstall
• Reinstall to a completely different drive
• Resetting Steam Linux Runtime Sniper (which actually did fix a secondary issue — 8,248 files had to be reacquired)
• Rebooting
• Forcing GPU selection with MESA_VK_DEVICE_SELECT
• Blocking NvLowLatencyVk.dll through Wine DLL overrides

None of it worked.

What actually fixed it: swapping the memory allocator to jemalloc.

How to tell if you have the same problem

Set your launch options to this and try launching once:

PROTON_LOG=1 RADV_PERFTEST=gpl %command%

Let it fail, then check ~/steam-1203620.log and search for:

malloc(): unaligned tcache chunk detected

If that line is in there, you're probably dealing with the same thing.

Your game log (enshrouded.log in the game directory) will cut off somewhere around Vulkan device setup, usually near a line about DLSS.

The fix

Install jemalloc for your distro:

• Arch: sudo pacman -S jemalloc
• Fedora: sudo dnf install jemalloc
• Ubuntu/Debian: sudo apt install libjemalloc2
• NixOS: add jemalloc to your systemPackages or use nix-shell

Find where libjemalloc.so ended up:

find /usr -name "libjemalloc.so*" 2>/dev/null

Then set your Enshrouded launch options to:

LD_PRELOAD=/path/to/libjemalloc.so RADV_PERFTEST=gpl %command%

For Arch that's usually:

LD_PRELOAD=/usr/lib/libjemalloc.so RADV_PERFTEST=gpl %command%

For Fedora:

LD_PRELOAD=/usr/lib64/libjemalloc.so RADV_PERFTEST=gpl %command%

Why this works (best I can tell)

Enshrouded ships with NvLowLatencyVk.dll, which is NVIDIA's Reflex Vulkan layer. On AMD hardware under Proton, this DLL still loads and hooks into Vulkan initialization even though it doesn't do anything useful. During Vulkan startup, Wine's vulkan-1.dll goes through an unload/reload cycle, and the Reflex hooks seem to cause some heap corruption in that process. glibc catches it and kills the process before the game ever gets to the menu.

With jemalloc handling memory allocation instead, the game gets past that init sequence, properly detects "non-Nvidia GPU," skips DLSS, creates the Vulkan device, and runs normally. I played for a few hours after applying this with zero issues. jemalloc is used by Firefox, Redis, and a bunch of other production software so it's not some sketchy hack.

I want to be clear, I'm not 100% certain this is the definitive root cause. But I am certain that this is the workaround that got it running after testing literally every other option. The malloc tcache error is consistent and reproducible, and jemalloc consistently gets past it.

Note for the devs if you see this

The game already correctly detects non-NVIDIA GPUs later in init (there's a log line that says "Skipping DLSS on non-Nvidia GPU.") If that vendor check happened earlier and prevented NvLowLatencyVk.dll from initializing its Vulkan hooks on AMD hardware, this whole class of crash probably goes away for Linux AMD users. Making the Reflex DLL a soft dependency or gating its load behind a GPU vendor check would be a clean fix.

Also worth noting: once you're in game on AMD, set NVIDIA Reflex to Off in the settings. It does nothing on AMD hardware and it's tied to the DLL that causes the problem in the first place.

Setup for reference

AMD Ryzen 9 / RX 7900 XTX / Mesa RADV 26.x / kernel 6.12 LTS / tested across GE-Proton, Proton Experimental, Proton Hotfix, Proton 9.0-4, and Proton 10.0-4. All same crash, all fixed by jemalloc.

Hope this helps somebody. If you see that malloc tcache line in your Proton log, give jemalloc a shot before you pull your hair out.

I have a different issue that I couldn't find any answer to. Game loads, loads world and in most places it works normally. However, when I interact with tower(spire?) then it will start loading and never finish. In logs I managed to find this which seems to be the issue:

Player EntityId 1 teleported From (3508.231934, 921.000000, 1956.755981) to (3504.750000, 973.000000, 1969.750000)
[I 00:00:39,678] [rendering] pending scene render finished flags: { ModelLoader, VoxelMeshing }
[I 00:00:39,817] [rendering] pending scene render finished flags: { GpuCache, ModelLoader, VoxelMeshing }
[I 00:00:39,851] [rendering] pending scene render finished flags: { ModelLoader, VoxelMeshing }
[I 00:00:40,197] [rendering] pending scene render finished flags: { GpuCache, ModelLoader, VoxelMeshing }
[I 00:00:40,231] [rendering] pending scene render finished flags: { ModelLoader, VoxelMeshing }
[I 00:00:41,299] [rendering] pending scene render finished flags: { ModelLoader }
[I 00:01:01,931] -------------- Session ----------------
[I 00:01:01,931] Machines:
[I 00:01:01,931]   m#0(128): up 0 (0), down 0 (0), remote 0 (0), limit 256, lost 0, ping 0 ms, EstablishingBaseline
[I 00:01:01,931] ---------------------------------------
[I 00:01:31,958] -------------- Session ----------------
[I 00:01:31,958] Machines:
[I 00:01:31,958]   m#0(128): up 0 (0), down 0 (0), remote 0 (0), limit 256, lost 0, ping 0 ms, EstablishingBaseline
[I 00:01:31,958] ---------------------------------------
[I 00:02:01,961] -------------- Session ----------------
[I 00:02:01,961] Machines:
[I 00:02:01,961]   m#0(128): up 0 (0), down 0 (0), remote 0 (0), limit 256, lost 0, ping 0 ms, EstablishingBaseline
[I 00:02:01,961] ---------------------------------------
[I 00:02:16,360] [rendering] pending scene render finished flags: { ModelLoader, Weather }
[I 00:02:16,391] [rendering] pending scene render finished flags: { ModelLoader }
[E 00:02:28,897] [gpu_data_cache] failed to allocate 177,152 bytes of device memory for gpu texture '' (free: 32,642): out of memory
[E 00:02:28,897] [gpu_data_cache] failed to allocate 352,256 bytes of device memory for gpu texture '' (free: 32,642): out of memory
[E 00:02:28,897] [gpu_data_cache] failed to allocate 46,080 bytes of device memory for gpu texture '' (free: 32,642): out of memory
[E 00:02:28,897] [gpu_data_cache] failed to allocate 92,160 bytes of device memory for gpu texture '' (free: 32,642): out of memory

Enshrouded will not finish loading due to could not allocate 92160 bytes of texture data (free: 41858 bytes)

So games works normally until it teleports me somewhere and starts to load larger texture then it just stops trying or clear the vram up? It's the only game I had issue with.

pop_os 24:04, Proton Hotfix, AMD Ryzen 5 5600X (12) @ 4.654GHz, AMD ATI Radeon RX 470, Mesa 26.1.6

Hi,
I received a github notification so I had a look just because I was curious. And I saw strange settings. Maybe it's the log file.
Antialiasing set to DLSS with an AMD GPU (journal says skipped later) , Monitor saying no HDR while HDR is enabled (HDR not supported reported later).
I also found

• device does support all required mesh shaders!
• device does not support ray query!
• [fog_of_war] invalid magic
• [Client] Initialize 'LoadScene' done
• many [graphics] Could not create texture 'blabla_scatter'

While devs will probably have a look, if you didn't try this, maybe.... set AA to FSR2 (FSR3 is a VRAM glutton :) ) and disable HDR.

Hey, @Kawazu0

I put the settings on the Ultra Performance preset just changing the AA with no HDR just like you said, but the problem continues.
On the ProtonDB Discord there was another person with a similar problem.

Hello! I'm having similar problems. Enshrouded is stuck on infinite loading screen when joining world after 10/15 update
OS / Environment: CachyOS (Linux) via Steam Proton
Game: Enshrouded

Previous / Persistent Issues (Pre-Update! I was unable to fix this):
Fast Travel: Triggered an infinite loading screen. Workaround was exiting to the main menu and rejoining.
Beds & Chairs: Character would get stuck in place upon interacting; pressing W to walk out failed to move the character.

Current issue Description:
After today’s major update (10/15/2026), I can no longer load into my world. Clicking "Join" results in an infinite loading screen with the Enshrouded logo in the bottom-right corner.

OS: CachyOS x86_64
Kernel: Linux 7.2.9-2-cachyos
CPU: AMD Ryzen 5 2600 (12) @ 3.90 GHz
GPU: AMD Radeon RX 580 2048SP

Steps Tried / Current Status:
Fully updated game to the latest patch.
Checked game integrity
Tried every version or proton known to man kind
Cleared caches and all that good stuff
Followed AI instructions on solving this with ZERO success, they don't know what they are talking about.
Tried those command launch options on steam with zero noticeable change.
Tweaked graphics. All on Max performance, AA off, reducing 3D scale etc.

steam-1203620.log

I can provide any other information if needed

@Skammas91 Proton forks aren't supported here, first try and see if the issue happens with proton experimental, if it does I'd try and see if a new game world has the same issue. I don't know much of the game but at least a new world works on my end.

EDIT

Using experimental fixed it for me.

System:

OS: Arch Linux, KDE Plasma (Wayland)
Kernel: 7.2.9-arch1-1
GPU: AMD Radeon RX 7700S (Navi 33 / RADV NAVI33)
Mesa: 26.2.4
Proton versions tested: Proton default (Steam), GE-Proton10-34, GE-Proton11-1
Symptom:
Enshrouded (1203620) launches and immediately shows a Windows-style error dialog: "Your Steam client is not running!" — this occurs with all Proton versions tested. Steam is running and the user is logged in. Clicking OK closes the game.

Notes:

Error occurs on first launch of Enshrouded 1.0
No relevant crash logs generated in ~/.steam/steam/logs/
Other Steam games launch and run correctly under GE-Proton11-1
Using RADV (confirmed via vulkaninfo)

29. @Skammas91 Proton forks aren't supported here, first try and see if the issue happens with proton experimental, if it does I'd try and see if a new game world has the same issue. I don't know much of the game but at least a new world works on my end.

Sorry, I meant that I tested different types like the Proton Experimental, Proton-cachyos, GE-Proton, Wineland etc. None of it worked.
Just to double check i tested again and nothing =(. I also tried creating new characters and worlds with no success.

@Skammas91 using forks is fine but when bringing logs you want to be bringing upstream ones. Tried the highest preset but that made no difference on my end and the game still worked fine.

There are 2 things I can think of that may make a difference on your end, one is wiping the prefix so that it can be remade when you next play the game (note that this will make it so the game will have to rely on steam cloud to get your saves back). The other is moving the game back to your main drive, as it looks like you have it in a secondary partition, and, specially if it's something like ntfs, it may be causing issues.

@simifor I did as you suggested. In fact, I deleted the game completely as well as deleted the prefix folders. Fresh install on my main drive. Tested with proton stable and experimental. No success unfortunately. And it get weird by the second because before the update I could at least play the game. I hope this is a proper log:

steam-1203620.log

If is not correct could you teach me how to make one? Anyway thanks for all the attention so far.

Is anyone else seeing an immediate crash when attempting to turn off V-Sync? I am using Proton Experimental (1791989105 experimental-11.0-20261014-x86_64)

steam-1203620.log

           PID: 25295 (enshrouded.exe)
           TID: 25309 (keen Steamworks)
           UID: 1000 (archuser)
           GID: 1000 (archuser)
        Signal: 6 (ABRT) si_code: SI_TKILL
     Timestamp: Mon 2026-10-19 13:28:48 CDT (13s ago)
  Command Line: $'S:\\steamapps\\common\\Enshrouded\\enshrouded.exe'
    Executable: /home/archuser/.local/share/Steam/steamapps/common/Proton - Experimental/files/lib/wine/i386-unix/wine64-preloader
 Control Group: /user.slice/user-1000.slice/[email protected]/app.slice/[email protected]
          Unit: [email protected]
     User Unit: [email protected]
         Slice: user-1000.slice
     Owner UID: 1000 (archuser)
       Boot ID: e200ba0b30954ea5847ad80a49edb9c2
    Machine ID: c234ad9c499f4d6dbca2851f462a9c16
      Hostname: arch-desktop
       Storage: /var/lib/systemd/coredump/core.enshrouded\x2eexe.1000.e200ba0b30954ea5847ad80a49edb9c2.25295.1792434528000000.zst (present)
  Size on Disk: 526.9M
       Message: Process 25295 (enshrouded.exe) of user 1000 dumped core.
                
                Stack trace of thread 25309:
                #0  0x00007f228e4256ea n/a (/run/host/usr/lib/libc.so.6 + 0x256ea)
                #1  0x00007f2288766b32 n/a (/home/archuser/.local/share/Steam/linux64/steamclient.so + 0x2b66b32)
                #2  0x00007f22887651c6 n/a (/home/archuser/.local/share/Steam/linux64/steamclient.so + 0x2b651c6)
                #3  0x00007f2288765231 n/a (/home/archuser/.local/share/Steam/linux64/steamclient.so + 0x2b65231)
                #4  0x00007f2288764e44 n/a (/home/archuser/.local/share/Steam/linux64/steamclient.so + 0x2b64e44)
                #5  0x00007f228dc66213 n/a (/run/host/usr/lib/libgcc_s.so.1 + 0x22213)
                #6  0x00007f228dc6697a n/a (/run/host/usr/lib/libgcc_s.so.1 + 0x2297a)
                #7  0x00007f228e4a1075 n/a (/run/host/usr/lib/libc.so.6 + 0xa1075)
                #8  0x00007f228e499487 n/a (/run/host/usr/lib/libc.so.6 + 0x99487)
                #9  0x00007f228dcdd102 pthread_exit_wrapper (/home/archuser/.local/share/Steam/steamapps/common/Proton - Experimental/files/lib/wine/x86_64-unix/ntdll.so + 0x6c102)
                [#10](/issue/ValveSoftware/Proton/10) 0x00007f228dcdd145 abort_thread (/home/archuser/.local/share/Steam/steamapps/common/Proton - Experimental/files/lib/wine/x86_64-unix/ntdll.so + 0x6c145)
                [#11](/issue/ValveSoftware/Proton/11) 0x00007f228dceaecb virtual_setup_exception (/home/archuser/.local/share/Steam/steamapps/common/Proton - Experimental/files/lib/wine/x86_64-unix/ntdll.so + 0x79ecb)
                [#12](/issue/ValveSoftware/Proton/12) 0x00007f228dcbe65c setup_raise_exception (/home/archuser/.local/share/Steam/steamapps/common/Proton - Experimental/files/lib/wine/x86_64-unix/ntdll.so + 0x4d65c)
                [#13](/issue/ValveSoftware/Proton/13) 0x00007f228dcbfe74 abrt_handler (/home/archuser/.local/share/Steam/steamapps/common/Proton - Experimental/files/lib/wine/x86_64-unix/ntdll.so + 0x4ee74)
                [#14](/issue/ValveSoftware/Proton/14) 0x00007f228e43e6f0 n/a (/run/host/usr/lib/libc.so.6 + 0x3e6f0)
                [#15](/issue/ValveSoftware/Proton/15) 0x00007f228e43e5d0 n/a (/run/host/usr/lib/libc.so.6 + 0x3e5d0)
                [#16](/issue/ValveSoftware/Proton/16) 0x00007f228e425685 n/a (/run/host/usr/lib/libc.so.6 + 0x25685)
                [#17](/issue/ValveSoftware/Proton/17) 0x00007f22887669eb n/a (/home/archuser/.local/share/Steam/linux64/steamclient.so + 0x2b669eb)
                [#18](/issue/ValveSoftware/Proton/18) 0x00007f22887651c6 n/a (/home/archuser/.local/share/Steam/linux64/steamclient.so + 0x2b651c6)
                [#19](/issue/ValveSoftware/Proton/19) 0x00007f2288765231 n/a (/home/archuser/.local/share/Steam/linux64/steamclient.so + 0x2b65231)
                [#20](/issue/ValveSoftware/Proton/20) 0x00007f2288764e44 n/a (/home/archuser/.local/share/Steam/linux64/steamclient.so + 0x2b64e44)
                [#21](/issue/ValveSoftware/Proton/21) 0x00007f228dc66213 n/a (/run/host/usr/lib/libgcc_s.so.1 + 0x22213)
                [#22](/issue/ValveSoftware/Proton/22) 0x00007f228dc6697a n/a (/run/host/usr/lib/libgcc_s.so.1 + 0x2297a)
                [#23](/issue/ValveSoftware/Proton/23) 0x00007f228e4a1075 n/a (/run/host/usr/lib/libc.so.6 + 0xa1075)
                [#24](/issue/ValveSoftware/Proton/24) 0x00007f228e499487 n/a (/run/host/usr/lib/libc.so.6 + 0x99487)
                [#25](/issue/ValveSoftware/Proton/25) 0x00007f228dcdd102 pthread_exit_wrapper (/home/archuser/.local/share/Steam/steamapps/common/Proton - Experimental/files/lib/wine/x86_64-unix/ntdll.so + 0x6c102)
                [#26](/issue/ValveSoftware/Proton/26) 0x00007f228dcdd145 abort_thread (/home/archuser/.local/share/Steam/steamapps/common/Proton - Experimental/files/lib/wine/x86_64-unix/ntdll.so + 0x6c145)
                [#27](/issue/ValveSoftware/Proton/27) 0x00007f228dcbaf56 quit_handler (/home/archuser/.local/share/Steam/steamapps/common/Proton - Experimental/files/lib/wine/x86_64-unix/ntdll.so + 0x49f56)
                [#28](/issue/ValveSoftware/Proton/28) 0x00007f228e43e6f0 n/a (/run/host/usr/lib/libc.so.6 + 0x3e6f0)
                [#29](/issue/ValveSoftware/Proton/29) 0x00007f2287410734 n/a (/home/archuser/.local/share/Steam/linux64/steamclient.so + 0x1810734)
                [#30](/issue/ValveSoftware/Proton/30) 0x00007f22873fbcbe n/a (/home/archuser/.local/share/Steam/linux64/steamclient.so + 0x17fbcbe)
                [#31](/issue/ValveSoftware/Proton/31) 0x00007f2286ee5258 n/a (/home/archuser/.local/share/Steam/linux64/steamclient.so + 0x12e5258)
                [#32](/issue/ValveSoftware/Proton/32) 0x00007f2289045a85 ISteamUtils_SteamUtils011_GetIPCountry (/home/archuser/.local/share/Steam/steamapps/common/Proton - Experimental/files/lib/wine/x86_64-unix/lsteamclient.so + 0xeba85)
                [#33](/issue/ValveSoftware/Proton/33) 0x00007f228dcba446 __wine_unix_call_dispatcher (/home/archuser/.local/share/Steam/steamapps/common/Proton - Experimental/files/lib/wine/x86_64-unix/ntdll.so + 0x49446)
                [#34](/issue/ValveSoftware/Proton/34) 0x00007f228dcda47e start_thread (/home/archuser/.local/share/Steam/steamapps/common/Proton - Experimental/files/lib/wine/x86_64-unix/ntdll.so + 0x6947e)
                [#35](/issue/ValveSoftware/Proton/35) 0x00007f228e498042 n/a (/run/host/usr/lib/libc.so.6 + 0x98042)
                [#36](/issue/ValveSoftware/Proton/36) 0x00007f228e52072c n/a (/run/host/usr/lib/libc.so.6 + 0x12072c)
                ELF object binary architecture: AMD x86-64

The Polaris loading problem seems to be some kind of Mesa issue. I could also reproduce it on RX 470 and filed a report here: https://gitlab.freedesktop.org/mesa/mesa/-/work_items/16636

Same infinite loading screen here since the 10/15 update, and on NVIDIA, so it isn't only Mesa/RADV: RTX 4090, driver 595.99.02, Proton Experimental experimental-11.0-20261014, Flatpak Steam. It happens in every mode (single-player and joining a dedicated server). A fresh prefix, verifying files, a cleared shader cache, a new character, Proton Hotfix and GE-Proton11-3 all made no difference.

I left it on the loading screen for an hour. In enshrouded.log the local server finishes loading ([game_server] Switching state from LoadEcsScene to Run, at about 57 s), but the session never leaves baseline. This repeats every 30 s for the whole hour:

m#0(128): up 0 (0), down 0 (0), remote 0 (0), limit 256, lost 0, ping 0 ms, EstablishingBaseline

Rendering keeps going the whole time, so it's stuck waiting, not hung.

Logs (steam-1203620.log with PROTON_LOG=1, and enshrouded.log): https://gist.github.com/jjanow/4bcbd0bcb98d47a3427ea21128557db9

Correction to my earlier comment: the endless loading screen in my case isn't a Proton problem, and it isn't networking. It's a bug in Enshrouded 1.0. Root cause found and confirmed.

The client stalls at [Client] Initialize 'Login' done and never logs CheckForBlockedPlayers. The EstablishingBaseline / 0-bytes session lines I posted were only a symptom of that: the client never got far enough to send anything.

Cause: at startup the game loads your Steam blocked list (ISteamFriends::GetFriendCount(k_EFriendFlagBlocked | k_EFriendFlagIgnored)) into a fixed-size table with room for 1,024 entries. My account has 1,142 blocked users. Above the limit the game never loads the list, and every "is this player blocked?" check returns an error instead of yes/no, so the CheckForBlockedPlayers step waits forever. This doesn't depend on Proton, the GPU or the driver, and should happen on Windows too.

Confirmed: I raised that size constant in enshrouded.exe (build of 2026-10-18: the mov dword [rsp+0x78], 0x400 at RVA 0x4afc21, changed to 0x2000). With that change the game loads straight into the world: CheckForBlockedPlayers → LoadScene → TitleScreen complete, and the session reaches OperatingNormally.

Does this affect you? It probably does if your enshrouded.log stops right after [Client] Initialize 'Login' done (no CheckForBlockedPlayers line) and you have more than about 1,000 users blocked on Steam. Getting your blocked list to 1,024 or fewer should avoid it until Keen raises or removes the limit. A Steam file verify or a game update undoes the exe edit.

Other reports in this thread are separate issues. The Polaris loading hang is Mesa issue #16636, and the RADV GPU hangs are driver bugs.

Hello, having the similar problem, however its not connected with the blocked users, I have none.

System:
OS: openSUSE Tumbleweed, GNOME 50.5, Wayland
Kernel: Linux 7.2.11-1-default
GPU: AMD Radeon RX 570
CPU: AMD Ryzen 7 5700X
Mesa: 26.2.4
Using radv
Proton versions tested: Proton Experimental, Stable, 10

Symptom:
Enshrouded (1203620) launches into menu correctly, after starting offline or online game, I'm stuck on loading screen, Loading text on the bottom right.
EDIT: I can leave it loading 20 minutes, with no change. When AltTabing multiple times, sometimes generic error message finally appear and game crashes.

Last records in the log:
[os] Query size of value 'Update Revision' in 'HARDWARE\DESCRIPTION\System\CentralProcessor\0' failed with error '2'.

Full log:
enshrouded_2026-10-16T23-35-09.log

Same error message discussed on reddit

Update: the blocked-list hang I described above is fixed in today's Enshrouded update (build 26082781, 2026-10-21). With the stock, unpatched enshrouded.exe and the same 1,142 blocked users, the client now goes Login → CheckForBlockedPlayers → LoadScene → TitleScreen normally.

The game no longer loads the whole blocked list into the fixed-size table. It now asks Steam about each player as they come up, so the size of your blocked list doesn't matter anymore. If you applied the exe edit from my earlier comment, just let Steam update the game; no workaround is needed.

@DSchmidt96 with no blocked users this wasn't your problem. On an RX 570 (Polaris) the loading hang is more likely the Mesa issue #16636 mentioned above.

Any idea how to fix this Mesa issue? I'm completely lost =(