Been messing around with it today aswell..
GPU: 7800 XT
Video driver version: amdgpu
Kernel version: Linux fedora 6.8.8-300.fc40.x86_64
Proton version: Proton Exp. Bleeding Edge and 9.0-1
Game launches fine using both proton9.0-1 and bleeding edge but I couldn't notice any differences
UI is terribly slow to use.
Helicopter rides are hit and miss and sometimes causes disconnects and maybe one frame every 5 seconds
This is a log from my last attempt using bleeding edge. I hit connect around line 6500 and ended with a helicopter disconnect

steam-2479810.log

GPU: 7900XTX
CPU: Ryzen 7700
Mesa drivers
Nobara 39
Proton version Experimental/9.0-1/Bleeding edge

In menu there are some lags, but nothing seriose. But loading into game almost always ended up with network connection issue for first time after launching the game and take ridiculously long time.
While in game, mostly I have around 150 fps on FHD EPic settings but UI env is laggy as hell. Interact with something like, Vendors or Inventory has so long response witch make it nearly unplayable due to inposibility to loot corpses mid combat. Also there are random freezes for about 10 seconds randomly, often ended with dead screen.
Freezes comes also when completing subtask or task, find new location etc.
Flying with heli is one big lag. Unlaging on ground in target location like 20 seconds after heli leaves.
Graphics ok, no issues or artefacts.

To add my experience:
GPU: Radeon 6950XT
CPU Ryzen 9 5950X
Mesa: 24.0.3
Distro: PopOS 22.04LTS
Proton Version(s): HotFix/Experimental/9.0.1

From the logs:
Initially loading the game and after hitting deploy took 4 minutes (I timed it) and resulted in a Network Disconnect, but second try took 2 minutes but worked. Once in game, I got roughly the same framerate as I do running similar settings under Windows, however UI interactions cause freezes for 2-3 seconds and sometimes back-to-back. In this log I just messed around in the base camp, but typically helicopter rides start out well, then freeze for extended time and more often than not disconnects me.

Log running Proton Hotfix:
steam-2479810.log

GPU: Nvidia RTX 3060Ti
CPU: AMD Ryzen 5 3600
Drivers: Nvidia proprietary 550.78
Distro: NixOS 23.11
Proton Version: Experimental

UI freezes a lot, additionally after a freeze, the GPU utilization goes up to 95-100% and fps drops to 20 max. Helicopter rides drop down the fps to 1-2 with long freezes until I'm kicked off from the heli, after which the FPS goes back up to 20.

Log for Proton Experimental
steam-2479810.log

Proton: GE Proton 9.5 / Proton Experimental
flags: PROTON_LOG=1 %command%
GPU: AMD Radeon RX 6800XT
CPU: AMD Ryzen 7 5700x
RAM: 16GB
Video: kisak-mesa 24.0.7
Distro: Linux Mint 21.3
Kernel: Linux 6.5.0-28-generic / Linux 5.15.0-106-generic

Getting the same errors than most people. First connect gets a 0x00030004 network error (maybe server related?)
Getting long loading times, heavy stutters in inventory. Also getting some stutters from time to time. Heli is freezing but gets through

GE Proton 9.5 (Kernel 6.5.0-28)
steam-2479810.log

Proton Experimental (Kernel 5.15.0-106-generic)
steam-2479810.log

With the latest Patch (Patch 1) problem is non existant. We just get long Game start time (a few minutes)!

OS: Manjaro Linux
KERNEL: 6.6.30-2-MANJARO
CPU: AMD Ryzen 7 5800H with Radeon Graphics
GPU: NVIDIA GeForce RTX 3070 Laptop GPU
GPU DRIVER: 550.78
Proton: GE Proton 9.5
Launch Options: VKD3D_VULKAN_DEVICE=1 mangohud gamemoderun %command%

I am now running the game fine after the developers added EAC support for linux but I see the same ~10min initial load time to the main menu. Steam Log attached in case it is useful.

steam-2479810.log

I am running GE Proton 9.5, but have also confirmed Proton Experimental and Experimental (bleeding-edge) as working.

OS: Fedora 40
KERNEL: 6.8.10-300.fc40.x86_64
CPU intel 14900ks
GPU: NVIDIA RTX 4090
GPU DRIVER: 550.78
Proton: Experimental-9.0-20240522
Launch Options: gamemoderun mangohud %command%

No issues with loads, I load almost instantly into the game. Actually faster than I do on Windows.
I do enable DLSS quality in game otherwise the frame rate is too low for my liking.
steam-2479810.log

Forgot to mention that split_lock_detect is set to off on my system...

To do this edit /etc/default/grub add the highlighted line and run grub2-mkconfig then reboot.

Proton: GE Proton 9.6-1
GPU: AMD Radeon RX 6850XT
CPU: AMD Ryzen 7 5800X3D
RAM: 64GB
Video: Mesa 24.1.0-arch1.1
Distro: Arch Linux
Kernel: Linux 6.9.3-zen1-1-zen

36 Hours, No Crashes or Long Load Times

I have about 36 hours on this game and haven't experienced any crashes or long loading times.

Until Latest Update

However, after the latest update, I was getting kicked because of EAC. I found that this was due to an old workaround that Star Citizen lug-helper left over in my /etc/hosts. Commenting out or removing this line out in my /etc/hosts fixed that issue:

127.0.0.1	modules-cdn.eac-prod.on.epicgames.com #Star Citizen EAC workaround

EAC To Blame?

I can now join games again, but it takes about 10 minutes to get to the Main Menu, like others are experiencing.

This leads me to believe that the 10 minute load time in the beginning has to do with EAC; potentially with EAC initializing?

May try split_lock_detect

I haven't tried split_lock_detect=off in my kernel options yet, but running lscpu | grep split_lock_detect doesn't return anything, suggesting that it isn't supported by my CPU. I'll give it a try anyway and report back.

Game Version: GZW 5.3.2-70657-Shipping-Heroic Production Cloud

In terms of the 10 minute startup time, it seems like I keep getting this in my proton logs when I first start the game up:

59433.230:00cc:00d0:warn:seh:dispatch_exception RPC_S_SERVER_UNAVAILABLE exception (code=6ba) raised

Here's my proton logs:

steam-2479810.log

After that, it continues to repeat this over and over again until the Main Menu finally loads:

59765.788:0190:0294:fixme:mfplat:bytestream_file_Close 0000000021147110
59765.794:0190:05f0:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
0:04:18.522416199 406349 0x7ba750097760 ERROR             audio-info audio-info.c:302:gst_audio_info_from_caps: no rate property given
0:04:18.596719710 406349 0x7ba7b8073190 ERROR             video-info video-info.c:546:gst_video_info_from_caps: no format given
0:04:18.601615121 406349 0x7ba7b8073190 ERROR             audio-info audio-info.c:302:gst_audio_info_from_caps: no rate property given
59765.881:0190:02d0:fixme:mfplat:topology_loader_Load iface 000000002114E020, input_topology 00000000492B2D00, ret_topology 000000006B1DFCE8, current_topology 0000000000000000 stub!
59765.903:0190:02d0:fixme:mfplat:audio_renderer_get_service_GetService Unsupported service {866fa297-b802-4bf8-9dc9-5e3b6a9f53c9}, interface {0a9ccdbc-d797-4563-9667-94ec5d79292d}.
59765.903:0190:02d0:fixme:mfplat:media_source_QueryInterface {6ef2a662-47c0-4666-b13d-cbb717f2fa2c}, 000000006B1DFBC8.
wine: setpriority -10 for pid -1 failed: 3
59765.905:0190:05f8:warn:threadname:NtSetInformationThread Thread renamed to L"audio_client_timer"
59766.004:0190:02d0:fixme:mfplat:stream_queue_sample Dropping sample 0000000049313D10, time 853333, clocktime 1137338, systime 597660179618.
59766.020:0190:02d0:fixme:mfplat:stream_queue_sample Dropping sample 0000000049313DC0, time 1066666, clocktime 1238979, systime 597660281259.

Right before this begins repeating, the logs show:

59504.402:0190:02e4:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
59507.275:0190:02e4:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\msdmo.dll" at 00006FFFFAFD0000: builtin
59507.279:0190:02e4:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\winegstreamer.dll" at 00006FFFFB000000: builtin
59507.280:0190:02e8:warn:threadname:NtSetInformationThread Thread renamed to L"wine_mmdevapi_notification"
59507.296:0190:02ec:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
59507.298:0190:02f0:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
0:00:00.093227314 406349 0x7ba750001a90 ERROR             video-info video-info.c:546:gst_video_info_from_caps: no format given
59507.383:0190:02d0:fixme:mfplat:topology_loader_Load iface 000000002113A5F0, input_topology 000000002111FD30, ret_topology 000000006B1DFCE8, current_topology 0000000000000000 stub!
59507.384:0190:02f8:warn:threadname:NtSetInformationThread Thread renamed to L"SlateLoadingThread1"
59507.384:0190:02f8:trace:seh:dispatch_exception code=406d1388 flags=0 addr=00006FFFFFC1CE87 ip=6fffffc1ce87
59507.384:0190:02f8:trace:seh:dispatch_exception  info[0]=0000000000001000
59507.384:0190:02f8:trace:seh:dispatch_exception  info[1]=00000000730efe80
59507.384:0190:02f8:trace:seh:dispatch_exception  info[2]=00000000000002f8
59507.384:0190:02f8:warn:threadname:dispatch_exception Thread renamed to "SlateLoadingThread1"
59507.385:0190:02f8:trace:seh:call_vectored_handlers calling handler at 00006FFFFB85BA70 code=406d1388 flags=0
59507.385:0190:02f8:trace:seh:call_vectored_handlers handler at 00006FFFFB85BA70 returned ffffffff
59507.388:0190:02d0:fixme:mfplat:media_source_QueryInterface {6ef2a662-47c0-4666-b13d-cbb717f2fa2c}, 000000006B1DFBC8.
59507.407:0190:028c:warn:vkd3d-proton:d3d12_command_list_QueryInterface: {09e0bf36-54ac-484f-8847-4baeeab6053f} not implemented, returning E_NOINTERFACE.
59507.423:0190:02b0:info:vkd3d-proton:dxgi_vk_swap_chain_recreate_swapchain_in_present_task: Got 3 swapchain images.
59507.458:0190:02fc:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
59507.458:0190:0300:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_timerqueue"
59507.462:0190:0304:warn:threadname:NtSetInformationThread Thread renamed to L"FAsyncLoadingThread"
59507.462:0190:0304:trace:seh:dispatch_exception code=406d1388 flags=0 addr=00006FFFFFC1CE87 ip=6fffffc1ce87
59507.462:0190:0304:trace:seh:dispatch_exception  info[0]=0000000000001000
59507.462:0190:0304:trace:seh:dispatch_exception  info[1]=000000007808fe80
59507.462:0190:0304:trace:seh:dispatch_exception  info[2]=0000000000000304
59507.462:0190:0304:warn:threadname:dispatch_exception Thread renamed to "FAsyncLoadingThread"
59507.462:0190:0304:trace:seh:call_vectored_handlers calling handler at 00006FFFFB85BA70 code=406d1388 flags=0
59507.462:0190:0304:trace:seh:call_vectored_handlers handler at 00006FFFFB85BA70 returned ffffffff
59507.471:0190:0308:warn:threadname:NtSetInformationThread Thread renamed to L"ScreenSaverInhibitor"
59507.471:0190:0308:trace:seh:dispatch_exception code=406d1388 flags=0 addr=00006FFFFFC1CE87 ip=6fffffc1ce87
59507.471:0190:0308:trace:seh:dispatch_exception  info[0]=0000000000001000
59507.471:0190:0308:trace:seh:dispatch_exception  info[1]=000000006a24fe80
59507.471:0190:0308:trace:seh:dispatch_exception  info[2]=0000000000000308
59507.471:0190:0308:warn:threadname:dispatch_exception Thread renamed to "ScreenSaverInhibitor"
59507.471:0190:0308:trace:seh:call_vectored_handlers calling handler at 00006FFFFB85BA70 code=406d1388 flags=0
59507.471:0190:0308:trace:seh:call_vectored_handlers handler at 00006FFFFB85BA70 returned ffffffff

For context, my audio setup is as follows:

lib32-libpipewire 1:1.0.7-1
lib32-pipewire 1:1.0.7-1
lib32-pipewire-jack 1:1.0.7-1
libpipewire 1:1.0.7-2
libwireplumber 0.5.3-1
pipewire 1:1.0.7-2
pipewire-alsa 1:1.0.7-2
pipewire-audio 1:1.0.7-2
pipewire-jack 1:1.0.7-2
pipewire-pulse 1:1.0.7-2
qemu-audio-pipewire 9.0.0-1
wireplumber 0.5.3-1

Replying to https://github.com/ValveSoftware/Proton/issues/7721#issuecomment-2153538812

I have the same log output during the 10 minute load.

Audio Setup:

lib32-libpipewire                 1:1.0.7-1                        multilib  630.4 kB
lib32-pipewire                    1:1.0.7-1                        multilib  3.9 MB
lib32-pipewire-jack               1:1.0.7-1                        multilib  419.4 kB
libpipewire                       1:1.0.7-2                        extra     1.5 MB
libwireplumber                    0.5.2-2                          extra     1.6 MB
pipewire                          1:1.0.7-2                        extra     2.9 MB
pipewire-audio                    1:1.0.7-2                        extra     4.3 MB
pipewire-jack                     1:1.0.7-2                        extra     634.5 kB
pipewire-session-manager          1:1.0.7-2                        extra     
wireplumber                       0.5.2-2                          extra     984.4 kB

Replying to https://github.com/ValveSoftware/Proton/issues/7721#issuecomment-2153468589

This is very interesting! If I add that same line to my hosts file then I get an instant load - quicker than on my Windows install. I can find and initiate connection to server, but then before I load in I get the 0x00020008 error (client failed to load the anti-cheat module).

Proton log for that run here:
steam-2479810.log

I have tried loading the game with that hosts entry, but then removing it before trying to connect to the server but unfortunately I still get the same error. Proton log for that run added here as well for completeness.
steam-2479810.log

So it looks like the EAC module is loaded during that startup period and doesn't load if that URL is blocked. I am not sure if it is the EAC module load itself that causes the delay or if the failure to load this actually skips some other processes which speeds up the launch. I will try and compare the logs to see if they give any clue.

UPDATE:
Comparing logs doesn't give anything really obvious away. The logs where EAC module fails to load (quick start time) has a lot less of the audio related output mentioned above and highlighted by @Swivelgames.
Those logs also have much fewer of these statements:
20218.379:018c:0294:warn:vkd3d-proton:d3d12_low_latency_device_SetLatencyMarker: PRESENT_START_NV is non-monotonic 70380000 <= 70380000.
I get hundreds of these in my original log with the long startup but very few in the log that doesn't load EAC module and starts quickly. Does anyone know what this warning indicates?

Further information to the previous post. It looks like GZW is using an Epic Online Services version of EAC which loads the library required at launch time. Below is a log from the EAC process when starting the game normally.
anticheatlauncher.log

Compared to a log of starting the game with the URL blocked via hosts entry.
anticheatlauncher.log

The game is launched in both cases, but in the second case the game exe is laucnhed directly rather thanb through the EAC library. This can be confirmed by comparing process trees for the two scenarios. First with EAC enabled, and then disabled:

Edit:
Looks to me like in the process tree for EAC enabled we can see the game binary being launched with an explicit call to the GEProton wine binary, whereas with EAC disabled this isnt the case and game binary launched directly.

Could the EAC process be trying to launch wine inside wine? Or is the non-EAC launch not using GEProton as I selected and is instead running in a wine env within the steam runner rruntime?

Replying to https://github.com/ValveSoftware/Proton/issues/7721#issuecomment-2154459523

The thing is that host file entry worked previously and allowed people to play. Myself included. With a caveat though, if I logged into a distant server, let's say South Africa I would get kicked due to EAC.

@Exist2Resist It did indeed. The problem is that it didn't enable EAC for Linux, it intentionally allowed the circumvention of it. Anti-cheat works on Linux, and it should.

Don't get me started on client-side Anti-Cheat and how utterly flawed the logic is there (as a Software Engineer of 20 years, that's like sanitizing your inputs on a web frontend, and just assuming that it's clean on the backend; it's just stupid :unamused: -- And also kernel-level anti-cheat is a massive privacy concern and potential attack vector for bad actors. But I digress).

At the end of the day, though, the reason Linux support is lacking in the game development community is the false assumption that you either have to (1) disable anti-cheat entirely, or (2) you have to somehow have access to the kernel.

Disabling anti-cheat entirely, rather than improving support for it, doesn't improve our odds of gaining Linux support. If anything, it enables Linux support for early development, only to be locked out of the game entirely once the game launches (something that many Linux gamers have experienced; and something I fear we'll see once Star Citizen gets closer to launch).

tl;dr: Host file entry was only ever going to be a temporary solution, never a permanent one. It only prolonged the inevitable. We need proper improvements implemented into Proton.
:slightly_smiling_face: :+1:

People, including me, are getting banned for playing the game after update 0.3:

https://steamcommunity.com/app/2479810/discussions/0/603031052244505430/

I'm using Proton 10 (beta). Proton Easy Anticheat runtime is installled. I have played 3 days without issue before this happens to me.

EDIT (2025-06-06): Just mentioning that I have been unbanned 10 minutes after my ban appeal explaining I was running Linux and that it was a false positive. I have not been banned again since yet.

I think this might be a ban from there AI anti-cheat system that is also in the game https://www.anybrain.gg/
the reason i say this is all of the other games i have played on linux with EAC dont do this. I have been banned in greyzone now 3 times and lost a great amount of equipment. If there is a way of confirming this via proton debugs i am willing to lag :)

EDIT (2025-06-19): this issue was caused by the usage of AMDVLK or AMDGPU-pro. See vkd3d-proton issue for details.

Patch 0.3.2.0 just came out and there was a massive performance regression. I went from 80-100 FPS to 30-40 FPS. It doesn't matter what graphic settings I use. It's all the same. My specs:

• GPU: AMD Radeon RX 7800 XT.
• OS: Archlinux
• Proton version: GE-Proton-10-4
• Driver: mesa 1:25.1.3-3
• Vulkan: vulkan-radeon and lib32-vulkan-radeon are installed.

I was first playing alright before that patch. I also remember I tried the beta branch yesterday before they applied the patch today and I had the same issue of frame drop. So, the patch clearly made this.

I believe Proton needs to provide a fix at some level. Either this or it's on DXVK side ? I don't know. I'll provide more detail if necessary.

Mangohud shows this in the menu also which is weird:

No FPS. Something's not loaded or something. But in-game FPS counter says:

I actually found this game log here:

GZW.log

It has multiple interesting error messages such as:

LogD3D12RHI: Error: Failed to create pipeline state with combined hash E9BC69E3C1FA8456, error 80070057.

That, to me, seems to be a really good hint.

Since @upsjay pointed out that Anybrain could be related to the ban for scripting issue, I decided to message them about it:

Let's just hope that this can be resolved in the near future.

[Gray Zone Warfare] Atrocious performance with AMD

Issue transferred from https://github.com/ValveSoftware/Proton/issues/8923.
@sim590 posted on 2025-07-22T00:01:51:

Compatibility Report

• Name of the game with compatibility issues: Gray Zone Warfare
• Steam AppID of the game: 2479810

System Information

• GPU: AMD Radeon RX 7800 XT
• Video driver version: 25.3.0_devel.208904.d59c22b6e1a.d41d8cd-1
• Kernel version: 6.15.6-arch1-1
• Link to full system information report as Gist: https://gist.github.com/sim590/d1192081337bd0e00f9b98062ef92f92
• Proton version: GE-Proton9-27

I confirm:

• [ ] that I haven't found an existing compatibility report for this game.
  • No... But this bug report is about specific issue about performance with AMD.
• [x] that I have checked whether there are updates for my system available.

Proton log

steam-2479810.log

Symptoms

Performance is atrocious while Windows users have shown to have around twice the performance using FSR3 with the same graphic card and a comparable CPU. Using FSR3 on Linux doesn't give no where near the same result.

I get around 40-50 FPS with FSR3 running at 1440p resolution. The Windows equivalent runs the same settings with 80-90 FPS.

I also get drastic ghostly frames which makes the game blurry.

• Windows comparison: https://www.youtube.com/watch?v=h48bVmfy81c
• My demo: https://youtu.be/aStOB26y8SU

I am not sure that Proton is responsible. This might be an issue with Mesa or vkd3d-proton. I'm looking for advice to pin point the issue so that I can use my system to its full capacity with this game.

Reproduction

Just play the game and see the bad performance.

After update 0.3.4.0, the game has introduced a game breaking bug where CPU usage goes crazy upon joining a server:

The game is actually half frozen. The whole system's audio is crackling. Everything is going slow, obviously because the CPU is demanded by an unlimited amount by the game.

Then, once the game "stabilizes" after 5 minutes of hell, there are intermittent CPU spikes:

which make the game freeze for a second every time and it's hardly playable because of that.

Before 0.3.4.0, everything was fine. I don't know what changed, but I assume this is not happening on Windows because, since then, they have not done a patch to fix something of the sort, but just memory leaks in 0.3.4.1.

I did check fille integrity. I had 2 corrupted files which Steam fixed, but I don't see any change really.

Same issues as Sim590 with game PopOS cosmic alpha, AMD 5900x/6750xt Latest kernel/Drivers. Game ran perfect before patch. Probably on the dev side of things but still would be nice to know what is actually happening.

Seeing the same with a 5900x and 7800xt on NixOS stable, I did notice that, along with my cpu usage being maxed out, my GPU was barely being utilized. It almost seems like the game might be trying to exclusively use the cpu to process everything?

Something is causing 100% CPU utilization and serious latency/ for about 5min before it shifts to GPU and sorta runs normal untill you try and move anywhere and it spikes again and again as you move thru the game world.

@kisak-valve My mistake, so sorry.
Thank you for the correction. ❤️

Update, After patch 0.3.5 this issue was still active. After discussing with the devs they were willing to look into it, and the EAC issue (starting EAC on game launch) was fixed.

There are still some weird performance issues, even with vkd3d-proton 3.0 with some gzw fix.
But this needs more testing to find where is the problem.

At the moment, trying to connect to servers will get you kicked via EAC, but there is a twist: something about this process also corrupts some files in the game directory, and makes it impossible to connect.

On the GZW Discord there is a Linux users channel, folks have figured out the two files:

Gray Zone Warfare/GZW/Content/SKALLA/PrebuildWorldData/World/cache/0xaf497c273f87b6e4_0x7a22fc105639587d.dat
Gray Zone Warfare/GZW/Content/SKALLA/PrebuildWorldData/World/cache/0xb9af63cee2e43b6c_0x3cb3b3354fb31606.dat

if you:

1. Verify GWZ files in Steam, and then
2. set the above files READ ONLY (400, 444, whatever)

GZW will connect to servers fine. The next time there is a GZW update, Steam will likely set those rw again, your files will get corrupted, and you will have to repeat the process: verify files, chmod a-w those two files.

Surely this info could be useful is sussing out the issue...

@kisak-valve I completely missed that, thank you.

• CPU usage spikes to 100 % across all cores
• GPU usage drops to near idle
• Desktop, audio and input lag system-wide

On Fedora 43 (Intel i7-9700K, RTX2080) I see the hang at 72%. However, I DON'T see any of the systemic instability you do. The KDE desktop remains completely smooth and responsive, and only 2 or 3 of my cores are chugging. Certainly, something Proton is or is not handling is causing GZW to get angry and spin its wheels... but I'm curious about the systemic degradation you experience. I see CachyOS is involved... who knows which out-of-tree kernel patch, bleeding edge upstream package, or goofy set of compiler flags CachyOS is using might explain why your whole computer is freezing up, but it's probably one of them.

I'd also be interested to know if any others with Intel CPUs are having the same issues.

• After several time:

  • Either the game recovers
  • Or crashes

The game just hangs at 72% for me; I kill it with "STOP" button in Steam, re-run, as soon as Gray Zone Warfare is loaded it asks "Join previous session?", I click yes, and I'm in game. So something during the initialization of the multiplayer component of the game is hoarking (I'd wager related to the same bit that's choking up EAC when those two files get corrupted. Wild ass guess.)

Important observations

• The issue only affects Gray Zone Warfare
• Other UE5 titles run fine under Proton on the same system

Highly doubt it has anything to do with UE5. Programming is hard, and trying to predict all of the ways programmers get stuff done to make a game work is even harder (yay Proton.) Hope this gets addressed at some point!

I want to keep this focused on the technical aspects.

I currently use CachyOS, but I am not tied to any specific distribution. I regularly test other distros and keep a dedicated empty 1 TB NVMe drive for that purpose. If there were a concrete technical reason to switch, I would do so.

CachyOS has been stable on this system for over 7 months with daily updates and no system-level issues. At the moment, there is no evidence pointing to a distro-specific problem. I’d also like to note that distro choice alone does not explain the behavior!

Gray Zone Warfare is the only game showing this behavior. Other UE5 titles like STALKER 2, run without issues on the same hardware. I tested multiple Proton versions, various launch parameters, and different kernels on a Ryzen 9 7950X3D with an RTX 5070 Ti, without meaningful changes.

Given that limiting the CPU cores significantly mitigates the issue, this points toward a game-side threading or scheduling problem under Proton rather than a distribution or kernel issue.

I see CachyOS is involved... who knows which out-of-tree kernel patch, bleeding edge upstream package, or goofy set of compiler flags CachyOS is using might explain why your whole computer is freezing up, but it's probably one of them.

@mercster I'm not sure why you're approaching with such hostility, the issue we're having clearly isn't a distro-specific one, as the multiple (in totality, distro-agnostic) reports above should show. @xEnSei's experience is far similar to what I've experienced on NixOS (which uses a mostly mainline kernel with a few nix-related patches, kernel config here if you really want to look at it) than what you're describing. AFAIK, most of the users describing this issue above have commented on their entire system becoming laggy and their entire CPU being maxed out at 100%. (see sim590's comment). If anything, the issue you're describing sounds different from the one we're dealing with.

So something during the initialization of the multiplayer component of the game is hoarking (I'd wager related to the same bit that's choking up EAC when those two files get corrupted.

Those two files getting corrupted has been an issue since the game launched, it's unlikely this is related as this CPU usage issue appeared relatively recently.

Limiting the visible CPU topology significantly improves behavior:

WINE_CPU_TOPOLOGY=12:1,2,3,4,5,6,7,8,9,10,11,12

This does help on my system, after a few minutes the FPS evens out and settle at a pre-issue level, as long as I don't move around too much (after my fps has recovered where I spawned by the pool, moving from there to the front gate of the FOB will cause it to act up again for a few minutes). By no means playable but certainly an improvement.

Gray Zone Warfare is the only game showing this behavior. Other UE5 titles like STALKER 2, run without issues on the same hardware.
...
Given that limiting the CPU cores significantly mitigates the issue, this points toward a game-side threading or scheduling problem under Proton rather than a distribution or kernel issue.

STALKER 2 doesn't include EAC though, maybe an EAC update caused a regression in proton? I know a relatively recent update to W40k: Space Marine 2 started causing similar system-wide effects (linked comment is the start of the conversation, the most recent comment describes similar issues to what we're discussing). SM2 isn't using UE5 though. As far as my personal experience, now that I'm thinking about it, the symptoms seem more and more similar. IIRC, SM2 has CPU usage spikes when loading new areas, as well as when lots of enemies spawn. It also maxes out for a moment right after game launch, which I'm not sure GZW does? There isn't really a startup video/audio that plays when GZW opens, so I'm not sure if I'd notice.

For SM2, bypassing EAC completely fixes the performance issues, I might contact the GZW devs and see if there's any way to load into the game without EAC (since the game doesn't have any sort of offline/modded mode like SM2 has).

Replying to https://github.com/ValveSoftware/Proton/issues/7721#issuecomment-3706896584

I've now tested SM2, and the same problem occurs there too, only slightly worse. As soon as I start a mission and join the server, it's unplayable!

I just read that SM2 doesn't use UE5, so there might be something to your EAC theory.

Additional note: This just occurred to me, and a friend had the same thought. Correct me if I'm completely wrong.

Game (UE5 or other, highly parallel)

• Proton/Wine thread mapping
• EAC (aggressive polling/checks)
• Many logical cores (32T)
  = Thread storm → Scheduler collapses → GPU starves

Additional note: This just occurred to me, and a friend had the same thought. Correct me if I'm completely wrong.

Game (UE5 or other, highly parallel)

* Proton/Wine thread mapping

* EAC (aggressive polling/checks)

* Many logical cores (32T)
  = Thread storm → Scheduler collapses → GPU starves

Sounds plausible to me, although I have no idea what I'm talking about. I suppose a good test to further confirm plausibility is to test limiting WINE_CPU_TOPOLOGY on SM2 to see if it helps there too.

Replying to https://github.com/ValveSoftware/Proton/issues/7721#issuecomment-3707436426
Sounds plausible to me, although I have no idea what I'm talking about. I suppose a good test to further confirm plausibility is to test limiting WINE_CPU_TOPOLOGY on SM2 to see if it helps there too.

Limiting the number of CPU cores via WINE_CPU_TOPOLOGY did not improve the situation and revealed the same problem.

Looking at my proton log, I do see the following error popup quite a few times (with different asset paths), sometimes many a second, other times seconds per one (I can't really correlate that with what was happening on screen at those times though.)

7608.844:0188:0258:warn:seh:OutputDebugStringW L"[2026.01.04-19.05.23:009][402]LogSkalla: Warning: USKALLAReferencesComponent::LoadAsset: Asset '/Game/Audio/AmbientSounds/AmbientSoundVertex_CornField' didn't load using async path. Trying sync\r\n"
7608.844:0188:0258:warn:seh:dispatch_exception L"[2026.01.04-19.05.23:009][402]LogSkalla: Warning: USKALLAReferencesComponent::LoadAsset: Asset '/Game/Audio/AmbientSounds/AmbientSoundVertex_CornField' didn't load using async path. Trying sync\r\n"

I'd have to switch over to windows and figure out how to capture the output for the game to see if it's a normal thing or not. I don't know that much about the specifics, but I assume things falling back to being processed synchronously wouldn't been good for performance? (although obviously something else must be going on, since I don't think it should cause 100% cpu usage on all cores.)

I tried Proton Experimental via Steam today, and GZW ran well with it. I didn't pay much attention to visual errors, or at least I didn't notice any!

I tried Proton Experimental via Steam today, and GZW ran well with it. I didn't pay much attention to visual errors, or at least I didn't notice any!

was that with or without WINE_CPU_TOPOLOGY?

I tried Proton Experimental via Steam today, and GZW ran well with it. I didn't pay much attention to visual errors, or at least I didn't notice any!

was that with or without WINE_CPU_TOPOLOGY?

I didn't need to, I didn't use any startup options.

I tried Proton Experimental via Steam today, and GZW ran well with it. I didn't pay much attention to visual errors, or at least I didn't notice any!

Intel or AMD CPU?

I tried Proton Experimental via Steam today, and GZW ran well with it. I didn't pay much attention to visual errors, or at least I didn't notice any!

Intel or AMD CPU?

AMD Ryzen 9 7950X3D
NVIDIA RTX 5070 Ti 16GB

Well damn, that happened out of nowhere. The game is running completely smooth for me now.

Ryzen 9 5900X
Radeon RX 7800XT

I have really no idea what fixed this, but it seems it is indeed fixed.

The only thing I can come up with is that somehow no one here had tested proton experimental since the December 23rd update. I suppose there could have been a server side update/change for the game or EAC that somehow fixed it. Has anyone confirmed that it is specifically experimental that works correctly?

The only thing I can come up with is that somehow no one here had tested proton experimental since the December 23rd update. I suppose there could have been a server side update/change for the game or EAC that somehow fixed it. Has anyone confirmed that it is specifically experimental that works correctly?

I tested this over Christmas, but I didn't notice any improvement.
(Garuda witch cachy kernel, latest Mesa etc..)
But -

I switched to a new distro in the new year, and only here did I notice a significant performance improvement. (PikaOS, others are the same..)
At that moment, I thought the improvement was the new distro and its modifications.. well..

I'm in the testing phase before I come up with a fix. But suddenly now people are starting to show up who are also feeling the improvement. When I look at the dates, it seems strange.

Small info from GTW discord from one guy:
"So. Launch options as

gamemoderun AMD_VULKAN_ICD=RADV VKD3D_CONFIG=upload_hvm %command% -malloc=system --launcher-skip --intro-skip --skipStartScreen -dx12

Tested on Proton 10.0- 10.3, 9.0-9.4, GE latest, experimental,

Anything earlier than that seems to cause issues with loading in. Not CPU issues but getting to the main screen"

So yes.. looks like proton in the end..

My proton version did not change. It was a fixed version in the settings. It must have been something that updated behind the scenes. Some other folks here thought it was EAC related. However, my proton EAC module didn't update in 2 years according to Steam. Could it be related to a server update on the game devs' side?

It was a fixed version in the settings

What?

Compatibility Report

• Name of the game with compatibility issues:
  Gray Zone Warfare

• Steam AppID of the game:
  2479810

System Information

• GPU:
  NVIDIA GeForce RTX 5070 Ti (ASUS TUF Gaming OC, 16 GB GDDR7)

• Driver/LLVM version:
  NVIDIA 595.58.03

• Kernel version:
  Linux 6.19.11-1-cachyos-bore

• Link to full system information report as Gist:
  https://gist.github.com/xEnSei/1d154ce9fdc546d7975fc564bddc5f08

• Proton version:
  proton-cachyos-10.0-20260330-slr-x86_64_v4
  But it also happens with every other Proton version, such as ProtonGE, Proton Experimental, or Hotfix

I confirm:

• [✓] that I haven't found an existing compatibility report describing this exact issue in sufficient detail
• [✓] that I have checked whether there are updates for my system available

Issue

The game crashes in Starter City after a while

Detailed behavior

• Game launches normally and reaches main menu without issues
• Joining a server without issues
• Fly with chopper to Bravo 2:
  • Run into the City and start fight
• After a while = Hang & Crash to Desktop

Important observations

• The issue only affects Gray Zone Warfare
• Other UE5 titles run fine under Proton on the same system
• Windows does not show this behavior on identical hardware
• The problem started with GZW patch 0.4.0.0

Temporary workaround

Not Found

Reproduction

Start the Game -> Join the Server -> Fly with Chopper to Bravo 2 -> Run into the City and start a Fight -> after a while, it crash

System Information
https://gist.github.com/xEnSei/8cdd84c1704d5c8afd43561ffd310ea2

Steam Runtime Diagnostics
https://gist.github.com/xEnSei/c133f85a137456be1cea5d7ea9842691

steam-2479810-Part1.log

steam-2479810-Part2.log

UEMinidump_to_text.txt

GZW.log

Breadcrumbs_RHIThread_0.txt

CrashContext.runtime-xml.txt <- Delete .txt

UEMinidump.dmp.txt <- Delete .txt

Can't seem to get into the game because of Easy AntiCheat error code 0x0002000A ...

Can't seem to get into the game because of Easy AntiCheat error code 0x0002000A ...

Fully read this bug report. There are workarounds.

Can't seem to get into the game because of Easy AntiCheat error code 0x0002000A ...

https://github.com/ValveSoftware/Proton/issues/7721#issuecomment-3624694181

Estou com problemas graves de crash no Gray Zone Warfare (Steam AppID 1430140) e gostaria de saber se alguém conseguiu resolver ou tem alguma sugestão adicional.

Meu sistema é um Lenovo Legion 5 (i7-10750H, 32GB RAM, RTX 2060 Mobile 6GB), rodando CachyOS (Arch Linux) com KDE Plasma 6 em Wayland. O driver NVIDIA é o 595.71.05. Já testei Proton-CachyOS, Proton Experimental, Proton 9.0 e GE-Proton, com a seguinte opção de inicialização:

PROTON_ENABLE_WAYLAND=0 env DISPLAY=:0 VKD3D_CONFIG=dxr11 %command%

As configurações gráficas do jogo estão reduzidas: XeSS (Qualidade), resolução 3D 59%, VSync desligado, limite de FPS 60, texturas e sombras em médio/baixo.

O problema é que o jogo crasha de forma totalmente imprevisível. Em algumas sessões consigo jogar por até 2 horas sem problemas, mas em outras o jogo não dura nem 1 minuto. O erro que aparece repetidamente nos logs é:

GPU crash detected: Device 0 Removed: DXGI_ERROR_DEVICE_REMOVED
Legacy Aftermath GPU Crash: 0xbad00002

Os crashes acontecem em vários momentos: compilação de shaders na inicialização, tela de equipamento/inventário, dentro de casas e hotéis, andando pela selva, durante combate e até interagindo com menus da interface.

O que já tentei e não resolveu:

• Trocar versões do Proton
• Usar flags do VKD3D (dxr11, no_upload_hvv, apply_hvv_compression)
• Testar XeSS, TSR e DLSS
• Forçar PROTON_ENABLE_WAYLAND=0 e DISPLAY=:0
• Remover permissão de escrita dos arquivos de cache do EAC (chmod 444)
• Limpar compatdata e cache de shaders
• Ativar pré-cache de shaders no Steam
• Reduzir configurações gráficas ao mínimo
• Limitar FPS a 30 e 60

Nada funcionou. O problema parece ser uma combinação entre o motor Unreal Engine 5, o driver NVIDIA com GPUs RTX 2000 Mobile, Proton e Wayland.

Alguém com hardware semelhante conseguiu resolver ou tem alguma dica adicional? Já contatei a NVIDIA e a MADFINGER, mas ainda aguardo retorno. Agradeço desde já.

Gray Zone Warfare - Random crashes (DXGI_ERROR_DEVICE_REMOVED) on RTX 2060 Mobile - Anyone found a fix?

I'm having serious crashing issues with Gray Zone Warfare (Steam AppID 1430140) and would like to know if anyone has managed to solve it or has any additional suggestions.

My system is a Lenovo Legion 5 (i7-10750H, 32GB RAM, RTX 2060 Mobile 6GB), running CachyOS (Arch Linux) with KDE Plasma 6 on Wayland. The NVIDIA driver is 595.71.05. I've tested Proton-CachyOS, Proton Experimental, Proton 9.0, and GE-Proton, with the following launch options:

PROTON_ENABLE_WAYLAND=0 env DISPLAY=:0 VKD3D_CONFIG=dxr11 %command%

In-game graphics are lowered: XeSS (Quality), 3D resolution 59%, VSync off, FPS limit 60, textures and shadows on medium/low.

The problem is that the game crashes unpredictably. In some sessions I can play for up to 2 hours without issues, but in others the game doesn't last even 1 minute. The recurring error in the logs is:

GPU crash detected: Device 0 Removed: DXGI_ERROR_DEVICE_REMOVED
Legacy Aftermath GPU Crash: 0xbad00002

Crashes happen in various situations: shader compilation at startup, equipment/inventory screen, inside houses and hotels, walking through the jungle, during combat, and even when interacting with UI menus.

What I've already tried without success:

• Switching Proton versions
• Using VKD3D flags (dxr11, no_upload_hvv, apply_hvv_compression)
• Testing XeSS, TSR, and DLSS
• Forcing PROTON_ENABLE_WAYLAND=0 and DISPLAY=:0
• Removing write permission from EAC cache files (chmod 444)
• Cleaning compatdata and shader cache
• Enabling Steam shader pre-caching
• Lowering graphics settings to minimum
• Limiting FPS to 30 and 60

Nothing worked. The issue seems to be a combination of Unreal Engine 5, the NVIDIA driver with RTX 2000 Mobile GPUs, Proton, and Wayland.

Has anyone with similar hardware managed to solve this or have any additional tips? I've already contacted NVIDIA and MADFINGER, but I'm still waiting for a reply. Thanks in advance.

Alguém com hardware semelhante conseguiu resolver ou tem alguma dica adicional? Já contatei a NVIDIA e a MADFINGER, mas ainda aguardo retorno. Agradeço desde já.

Il existe actuellement un bug connu affectant le jeu et les cartes NVIDIA sous Linux. Tout le monde subit des plantages. Nous vous conseillons de rejoindre le serveur Discord de Gray Zone Warfare, où une communauté de joueurs Linux échange et partage des informations.

https://discord.gg/grayzonewarfare

Has anyone with similar hardware managed to solve this or have any additional tips? I've already contacted NVIDIA and MADFINGER, but I'm still waiting for a reply. Thanks in advance.

Hah, sorry, just saw English post. There is a known bug with the game and NVIDIA on Linux currently. Everyone is crashing. You should join the Gray Zone Warfare Discord, where there is a community of Linux players who communicate and share notes.

Alguém com hardware semelhante conseguiu resolver ou tem alguma dica adicional? Já contatei a NVIDIA e a MADFINGER, mas ainda aguardo retorno. Agradeço desde já.

Il existe actuellement un bug connu affectant le jeu et les cartes NVIDIA sous Linux. Tout le monde subit des plantages. Nous vous conseillons de rejoindre le serveur Discord de Gray Zone Warfare, où une communauté de joueurs Linux échange et partage des informations.

https://discord.gg/grayzonewarfare

Thank you for your return. I'll check it out there on the disk.
Strong hug.

Thank you for your return. I'll check it out there on the disk. Strong hug.

No need to be snotty, I was trying to help. Not sure why you posted twice anyway, this aint Canada.

EAC Fix

System Information

• GPU: 860M / 5050 Max Q
• Video driver version: MESA 26.1.5 / nVidia 610.43.3
• Kernel version: 7.1.3-ogc5.1.fc44.x86_64
• Proton version: 11-3 also ProtonGE 11-3

Symptoms

Proton gamers are kicked or are required to re-verify.

Reproduction

Version 1

1. Play game
2. Get kicked
3. Can't rejoin

Version 2

1. Play game
2. Successfully extract
3. Close game
4. Start game
5. File verification required

Permanent Solution

Modify Proton to contain a launch script that automatically sets two file to read-only when the game is running.

File locations

1. /Grey Zone Warfare/GZW/Content/SKALLA/PrebuildWorldData/World/cache/0xaf497c273f87b6e4_0x7a22fc105639587d.dat
2. /Grey Zone Warfare/GZW/Content/SKALLA/PrebuildWorldData/World/cache/0xb9af63cee2e43b6c_0x3cb3b3354fb31606.dat"

Temporary solution

Set Launch Arguments to
bash -c 'chmod 444 "./GZW/Content/SKALLA/PrebuildWorldData/World/cache/0xaf497c273f87b6e4_0x7a22fc105639587d.dat" && chmod 444 "./GZW/Content/SKALLA/PrebuildWorldData/World/cache/0xb9af63cee2e43b6c_0x3cb3b3354fb31606.dat" && exec "$@"' -- %command% as discussed in the ProtonDB thread

EAC Fix

System Information

* GPU: 860M / 5050 Max Q

Modify Proton to contain a launch script that automatically sets two file to read-only when the game is running.
....

There’s a wrapper script on the Discord that survives updates and checks the files every time it starts. Just put it in once and you're done!
https://github.com/xEnSei/gzw_autofix

Also, ProtonGE11-XX has a built-in fix!