I can get in game but hitting esc to bring up the menu or opening the social menu crashes the game for me.

Same issue than the initial one. Starts and hangs to a black screen.

• GPU: NVIDIA RTX 4080
• Video driver version: NVIDIA 545.29.06
• Kernel version: 6.7.4-arch1-1
• Proton version: Proton Experimental / GE-Proton8-30

Got the game to launch with GE-Proton7-55. :tada:

Got the to launch with GE-Proton7-55. 🎉

How is it going? Game running well?

Proton 8.0-5 worked just fine on desktop Kubuntu 23.10 here, no crash got into tutorial just fine.

Proton Log:
steam-553850.log

For Steam Deck, GE-Proton7-55 worked (other versions did not) but you must launch it in Desktop Mode.

Has someone played a game "online"?

on my system it works

Running on proton 8.0-5 with -d3d11 and it's aight. 55-60+ frames pretty much all the time in a mission no craashes or weird artifacts (Running on lenovo laptop with arch/hyprland ryzen 75800h and nvidia 3060mobile)
played 1 mission online no issues there

Game is runnin good on GE-Proton7-55. Servers had some hickups early but no issues currently. Multiplayer works.

Can confirm it works with GE-Proton7-55 on Nixos running Hyprland. I could play and finish mission.

Going into the main menu (ESC) crashes instantly for me however.

Edit: The menu crash was present on windows as well and has since been hotfixed.

The 1.3 GB patch allowed me to play a full game in multiplayer on GE-7-55 and Esc didn't crash the game. That said the game crashed after loading back to the ship and now can't be run anymore without hanging on load (I have a feeling it's because I changed windowing to full-screen).

New update now has me stuck in a black screen while booting.

Sadly, not working for me.
Start video is running, then one female Soldier speaks to another and it freezes. Most times even before the soldier starts to speak.
Sometimes opens the nProtect Gameguard FAQ Website by itself, maybe it could not be loaded?!

GPU: NVIDIA RTX 2070 Super
Video driver version: NVIDIA 545.29.06
Kernel version: 6.6.10-76060610-generic
Proton version: Proton Experimental / GE-Proton8-30 / GE-Proton7-55 / Proton 8.0-5

Still working after update using GE-Proton7-55.

Found issues so far:

• Anything newer than GE-Proton7-55 crashes at launch.
• If the game window goes behind an another window, game window goes black and restart is required.
• Borderless fullscreen has tiny margin of white pixels around it.
• If game is launched with window setting set to fullscreen, the game window is black and hangs. Recovery requires editing the game configuration file manually.

/<LIBRARY_DIR>/SteamLibrary/steamapps/compatdata/553850/pfx/drive_c/users/steamuser/AppData/Roaming/Arrowhead/Helldivers2/user_settings.config

fullscreen = false
borderless_fullscreen = true

New update now has me stuck in a black screen while booting.

I fixed it by modifying the config file and dropping the quality settings
/steamapps/compatdata/553850/pfx/drive_c/users/steamuser/AppData/Roaming/Arrowhead/Helldivers2/user_settings.config

I went in and muddled a bunch of numbers until the game booted, then I used the menu to config my settings. Changing "graphics_preset" to 1 or 2 should also work too.

I fixed it by modifier the config file and dropping the quality settings

@LuxLucian Just a tip, if you've fixed it by modifying something then probably also put the location of the file and the modification that you made. Because that's the first thing someone is going to ask about a comment such as yours.

On Steam Deck I was able to just download the game and run it now, didn't have to switch to desktop mode or switch Proton versions at all.

On desktop I still need to use GE-Proton7-55 but it runs fairly well with that. Proton Experimental and Proton 8 run into the blackscreen issue.

ESC menu works as well since the last game update.

GE-Proton8-30 works now!

Seems that something has been updated with the GameGuard configuration server side as no patches have landed to the game nor Proton.

Also all of the issues I mentioned in my earlier comment got fixed with the newer Proton version.

FYI game still hangs on launch with fullscreen even on GE-8-30

GE-Proton8-30 works now!

Seems that something has been updated with the GameGuard configuration server side as no patches have landed to the game nor Proton.

Also all of the issues I mentioned in my earlier comment got fixed with the newer Proton version.

I'm still seeing the white border even with GE 8-30.

Also, as of today the game is consistently crashing my system at random intervals (not just the game process). Hard to track down what might be causing it because all background processes that I can see also freeze/die alongside my keyboard and mouse - only way out is a manual reboot.

It might be the vague AMD issue floating around as I have 7800x3d CPU / 7800xt GPU but difficult to say. I implemented the 'fix' (for windows users at least) listed in some discussions of disabling anti-aliasing and global illuminations which had no impact. Getting the crashes on 8-30 as well as 7-55 despite not having these issues yesterday.

FYI game still hangs on launch with fullscreen even on GE-8-30

Yes, seems it's 50/50 that the game launches or hangs to a black screen with fullscreen enabled.

Was there a proton Hotfix release for this game?

I am currently trying it out with GE-8-30. Unfortunately, I have been met with nothing but crashes during the initial menus. I can't get far along enough without it crashing. The game starts in full-screen mode, so I see the white border. I did notice a proton hotfix that came with the initial game download.

Update Switched to Proton Hotfix in the compatibility drop-down and re-validated the game. The game launched without crashes, but I only played with it after finishing the training zone. I switched back to GE-8-30, and I was able to run around on my deck. I did notice that changing the graphics setting makes it crash, however (e.g., Anti-aliasing), regardless of Proton version.

My system

• Video Card:
  • Driver: AMD AMD Radeon RX 6750 XT (navi22, LLVM 15.0.7, DRM 3.57, 6.7.3-060703-generic)
• OS
  • Ubuntu 23.10 (64 bit)
  • Kernel Name: Linux
  • Kernel Version: 6.7.3-060703-generic

GE-8-31 just released, I'm seeing ~10% more fps but take it with a grain of salt

updated wine to latest bleeding edge, allows helldivers to run

It might be the vague AMD issue floating around as I have 7800x3d CPU / 7800xt GPU but difficult to say. I implemented the 'fix' (for windows users at least) listed in some discussions of disabling anti-aliasing and global illuminations which had no impact. Getting the crashes on 8-30 as well as 7-55 despite not having these issues yesterday.

What helped me reduce the crashes (7900xt GPU) was generally reducing graphics settings. Disabling global illumination is just one of the possible settings but for example while having ultra texture details the crashes were extremely frequent and since I reduced it to medium and lowered a few other settings it did not crash yet, but I still have to test it a bit more.

This seems to point to a bug in amdgpu, and the same issue also happened to me 3 times while playing A Plague Tale Requiem, but a friend of mine was having similar crashes on Windows with the same GPU and reducing graphics settings also helped him.

[drm:amdgpu_job_timedout [amdgpu]] *ERROR* ring gfx_0.0.0 timeout, signaled seq=1751122, emitted seq=1751125
[drm:amdgpu_job_timedout [amdgpu]] *ERROR* Process information: process helldivers2.exe pid 20850 thread vkd3d_queue pid 21005
amdgpu 0000:0d:00.0: amdgpu: GPU reset begin!
amdgpu 0000:0d:00.0: amdgpu: IP block:gfx_v11_0 is hung!
amdgpu 0000:0d:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:169 vmid:0 pasid:0, for process  pid 0 thread  pid 0)
amdgpu 0000:0d:00.0: amdgpu:   in page starting at address 0x0000000000000000 from client 10
amdgpu 0000:0d:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00040B53
amdgpu 0000:0d:00.0: amdgpu:        Faulty UTCL2 client ID: CPC (0x5)
amdgpu 0000:0d:00.0: amdgpu:        MORE_FAULTS: 0x1
amdgpu 0000:0d:00.0: amdgpu:        WALKER_ERROR: 0x1
amdgpu 0000:0d:00.0: amdgpu:        PERMISSION_FAULTS: 0x5
amdgpu 0000:0d:00.0: amdgpu:        MAPPING_ERROR: 0x1
amdgpu 0000:0d:00.0: amdgpu:        RW: 0x1
amdgpu 0000:0d:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:169 vmid:0 pasid:0, for process  pid 0 thread  pid 0)
amdgpu 0000:0d:00.0: amdgpu:   in page starting at address 0x0000000000000000 from client 10
amdgpu 0000:0d:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000000
amdgpu 0000:0d:00.0: amdgpu:        Faulty UTCL2 client ID: CB/DB (0x0)
amdgpu 0000:0d:00.0: amdgpu:        MORE_FAULTS: 0x0
amdgpu 0000:0d:00.0: amdgpu:        WALKER_ERROR: 0x0
amdgpu 0000:0d:00.0: amdgpu:        PERMISSION_FAULTS: 0x0
amdgpu 0000:0d:00.0: amdgpu:        MAPPING_ERROR: 0x0
amdgpu 0000:0d:00.0: amdgpu:        RW: 0x0
amdgpu 0000:0d:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:169 vmid:0 pasid:0, for process  pid 0 thread  pid 0)
amdgpu 0000:0d:00.0: amdgpu:   in page starting at address 0x0000000000000000 from client 10
amdgpu 0000:0d:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000000
amdgpu 0000:0d:00.0: amdgpu:        Faulty UTCL2 client ID: CB/DB (0x0)
amdgpu 0000:0d:00.0: amdgpu:        MORE_FAULTS: 0x0
amdgpu 0000:0d:00.0: amdgpu:        WALKER_ERROR: 0x0
amdgpu 0000:0d:00.0: amdgpu:        PERMISSION_FAULTS: 0x0
amdgpu 0000:0d:00.0: amdgpu:        MAPPING_ERROR: 0x0
amdgpu 0000:0d:00.0: amdgpu:        RW: 0x0
amdgpu 0000:0d:00.0: amdgpu: [gfxhub] page fault (src_id:0 ring:169 vmid:0 pasid:0, for process  pid 0 thread  pid 0)
amdgpu 0000:0d:00.0: amdgpu:   in page starting at address 0x0000000000000000 from client 10
amdgpu 0000:0d:00.0: amdgpu: GCVM_L2_PROTECTION_FAULT_STATUS:0x00000000
amdgpu 0000:0d:00.0: amdgpu:        Faulty UTCL2 client ID: CB/DB (0x0)
amdgpu 0000:0d:00.0: amdgpu:        MORE_FAULTS: 0x0
amdgpu 0000:0d:00.0: amdgpu:        WALKER_ERROR: 0x0
amdgpu 0000:0d:00.0: amdgpu:        PERMISSION_FAULTS: 0x0
amdgpu 0000:0d:00.0: amdgpu:        MAPPING_ERROR: 0x0
amdgpu 0000:0d:00.0: amdgpu:        RW: 0x0
Failed to wait all pipes clean
amdgpu 0000:0d:00.0: amdgpu: soft reset failed, will fallback to full reset!
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
[drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
[drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
[drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
[drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
[drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
[drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
[drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
[drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[drm:mes_v11_0_submit_pkt_and_poll_completion.constprop.0 [amdgpu]] *ERROR* MES failed to response msg=3
[drm:amdgpu_mes_unmap_legacy_queue [amdgpu]] *ERROR* failed to unmap legacy queue
[drm:gfx_v11_0_hw_fini [amdgpu]] *ERROR* failed to halt cp gfx
amdgpu 0000:0d:00.0: amdgpu: MODE1 reset
amdgpu 0000:0d:00.0: amdgpu: GPU mode1 reset
amdgpu 0000:0d:00.0: amdgpu: GPU smu mode1 reset
amdgpu 0000:0d:00.0: amdgpu: GPU reset succeeded, trying to resume
[drm] PCIE GART of 512M enabled (table at 0x00000084FEB00000).
[drm] VRAM is lost due to GPU reset!
[drm] PSP is resuming...
[drm] reserve 0x1300000 from 0x84fc000000 for PSP TMR
amdgpu 0000:0d:00.0: amdgpu: RAP: optional rap ta ucode is not available
amdgpu 0000:0d:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available
amdgpu 0000:0d:00.0: amdgpu: SMU is resuming...
amdgpu 0000:0d:00.0: amdgpu: smu driver if version = 0x0000003d, smu fw if version = 0x0000003f, smu fw program = 0, smu fw version = 0x004e6601 (78.102.1)
amdgpu 0000:0d:00.0: amdgpu: SMU driver if version not matched
amdgpu 0000:0d:00.0: amdgpu: SMU is resumed successfully!

Still getting crashes after 30min-1hr on GE-8-31. AMD CPU/GPU. All graphics set to lowest, resolution reduced, scaling set to performance -- if this was medieval era, picture me at the alter bathed in blood, carcasses spread around me, dragging anything I can find up, red spurts appearing around me as I find another setting to reduce.

edit: joking aside, seems like these issues are on the game and seem cross-platform, only wanted to give a sample that GE-8-31 doesn't magically fix the crashes for AMD

The GCVM_L2_PROTECTION_FAULT errors don't seem to be necessarily local to just Helldivers, you could try some of the fixes mentioned in the convos below. I seem to be having the same problem on my 5800X3D / 6700 XT, booted back to gdm after the driver hard resets, usually after ~2 hrs of playing.

https://bbs.archlinux.org/viewtopic.php?id=284076
https://gitlab.freedesktop.org/drm/amd/-/issues/2496
https://gitlab.freedesktop.org/mesa/mesa/-/issues/8241

Right now servers are down / having issues, not related to Linux / Proton.

@kisak-valve Aaaaah ok. Thanks kisak. I thought per problem. Thanks I know it now for the next time :)

Thanks for answering on sunday :D

hey hey, I just wanted to let you know that it worked for me after I switched to the Nvidia beta drivers in aur and disabled shader caching in Steam. :+1:

Even on Proton GE 8-32 I can't get past the nProtect gameguard download. It tries to download it but can't connect and times out. Anyone have any experience with this? I feel like I am the only one who can't get into the game. On Arch Linux.

for anyone else with AMD 7000 series GPUs experiencing GPU driver crashes (system lockup), I've been following a support thread on steam discussions for updates (and sadly it's been quiet): https://steamcommunity.com/app/553850/discussions/1/4206994023681197128/

An excerpt:

Critical problems for players using the AMD Radeon 7000 series of GPUs

The Problem:
There are all sorts of significant problems players with these GPUs are experiencing, in total making the game nearly unplayable.

Why It Happens:
We aren’t sure at the moment. We had tested with these GPUs previously and hadn’t encountered this in-house, but clearly there is something deep that is wrong.

Frequency:
This is a constant issue for these users.

What We’ve Done / Are Doing:
This one needs some investigation, and our team is looking at it in collaboration with AMD. Please watch this space: we will update when we have more details on this matter.

In my case, using:

• CPU: i7-7700HQ
• RAM: 16GB DDR4
• dGPU: Nvidia GTX 1050TI
• iGPU: Intel HD630

The game freezes constantly after one or two minutes, changing everything to low doesn't help yet, also it doesn't help that this game cannot run in DX11 mode, such a shame.

Using Proton Hotfix BTW.

Throwing my 2 cents into the hat, 5700x CPU, RTX 2070 on 535.133.1 running EndeavourOS, it seemingly gets past the gameguard install, boots, and gets to the start of the dropship/droppod cutscene before freezing on any versions of proton, GE or not.

Currently, the error which stands out is

:err:winstation:map_shared_memory_section failed to open section L"\KernelObjects\__wine_thread_mappings\00000148-input": c0000034

This is has been attempted with both default settings, and a config file shared by a windows user with all settings set to their lowest values, shader pre caching enabled/disabled.

proton log as gist: https://gist.github.com/DanCanGit/81d9becef663ca8f66bbbe00ea2f3b9c

@DanCanGit shame on me, I couldn't even get a similar log out of proton, heh!

After the game locks itself, the gameguard FAQ opens, I don't know why.

My experience with this game so far has been: I spent over 3 hours on Sunday trying several things (proton versions, graphics settings, verifying, etc) to get past the tutorial due to constant crashing. It would lock up anywhere from the encrypted message bit, the cutscene on the dropship, or mid way through the tutorial mission, crash my desktop, and kick me out to GDM.

For reference I'm on Nobara 39, Gnome desktop Wayland session, Ryzen 5 1600AF, Radeon RX 6650 XT. Game is using Proton Hotfix. Borderless window because fullscreen was not working.

I nearly gave up but I decided to try the game on the Xorg session before I quit, and wouldn't you know it, I was able to make it past the tutorial on the first try. Made it onto the ship, dropped on a solo mission, exited the pod... and then it crashed. Okay, so I went back and lowered some settings like turning off Global Illumination, etc. I tried this before on Wayland in the tutorial (I tried the lowest settings) but this time I was able to play 4 or 5 solo missions without crashing.

On Monday I went back to the Wayland session and played around 10 missions on multiplayer. I haven't had any crashes since Sunday.

TL:DR: For some unknown reason, switching to Xorg stopped the constant crashing.

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-1941986377

I've already tried the game using the X11 session, to no avail.
The fact that the crash happened less then it's not happening anymore isn't exactly a fix, since it could mean other underlying issues.

Not sure why, but my primary issue seems to be that on every subsequent launch of the game (any launches after the 1st one), the game locks up on a black screen after the window initializes.
The only solution I've found for it is to delete the proton prefix and re-launch the game, but it's a tedious and incredibly annoying process because it forces me to reconfigure game and graphics settings upon doing so.

Not sure why, but my primary issue seems to be that on every subsequent launch of the game (any launches after the 1st one), the game locks up on a black screen after the window initializes.
The only solution I've found for it is to delete the proton prefix and re-launch the game, but it's a tedious and incredibly annoying process because it forces me to reconfigure game and graphics settings upon doing so.

Sounds like you're setting the window to fullscreen.

I have been doing that because, if I don't, the borderless window leaves a distracting white line along the bottom of my screen.

I have been doing that because, if I don't, the borderless window leaves a distracting white line along the bottom of my screen.

Yeah borderless window doesn't fully stretch but the game currently doesn't launch with fullscreen, as mentioned several times in this issue. It might work with gamescope, not sure anyone tried yet. Or you could set fullscreen while playing and change it back before exiting the game. Or just edit the config file so you don't have to delete the entire prefix.

Set the game to borderless fullscreen before you exit and set it to fullscreen after launch.

That way you can play without border and still have the game launch.

If you messed up you can edit the config file for the game and disable fullscreen in there. No need to recreate the prefix.

No crashes here on the 6900 XT with Wayland either.

Not sure if it's today's update or upgrading to 6.7.4 kernel and 23.3.5-1 mesa but I'm not crashing with GCVM_L2_PROTECTION_FAULT anymore 🥳

@kisak-valve sorry for the direct ping, this log might interest you, that's my error.
steam-553850.log

Not sure if it's today's update or upgrading to 6.7.4 kernel and 23.3.5-1 mesa but I'm not crashing with GCVM_L2_PROTECTION_FAULT anymore 🥳

@zrooda
Today's update certainly didn't fix anything for me. I normally stay away from cutting edge kernel releases, but I'll give 6.7.4 a try tonight and update here if it helps. As of now I'm getting a 100% crash rate (full GPU driver crash) between 1-20 minutes of starting the game.

UPDATE:
I updated to latest 6.7.4 kernel, my mesa was already at the latest for my distro. Managed ~20 minutes before full system crash, so this wasn't the fix for me. Specs:

OS: Pop!_OS 22.04 LTS x86_64
DE: GNOME 42.5
Host: A620I Lightning WiFi
Kernel: 6.7.4-x64v4-xanmod1
CPU: AMD Ryzen 7 7800X3D (16) @ 5.050GHz
GPU: AMD 7800XT
OpenGL version string: 4.6 (Compatibility Profile) Mesa 23.3.2-1pop0~1704238321~22.04~36f1d0e
Proton: GE-Proton8-32

@calvinbull I've refunded the game; However when I tried it on the 10th of February, I was on kernel 6.7.4 and mesa 23.3.5 since the 6th of this month and the game was giving me a full GPU driver crash 1-15 minutes after launching. I'm using a 7900 xtx and 7800x3D, I'd like to give the game another shot one of these days; But I want to see at least the one person with similar hardware report it working!

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-1945057612

I guess the 7k series Radeons have separate issues, the devs are aware of them and working with AMD on a fix as per their Known Issues thread. I'm on 6700 XT.

This is quite possibly the weirdest workaround I've ever found. Game crashes on first handful of rendered (non-cutscene) frames, unless I'm streaming through Discord, specifically. (OBS doesn't work.) I have absolutely no idea what that would indicate, but it's crashed regularly enough that I don't think it's a fluke. (Even crashing moments after closing a call)

OS: Arch Linux
KERNEL: 6.7.4-arch1-1
CPU: Intel Core i7-10700F @ 2.90GHz
GPU: NVIDIA GeForce RTX 2060
GPU DRIVER: NVIDIA 545.29.06
RAM: 16 GB
PROTON: GE-Proton8-32

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-1947479538

Wtf, this worked. But it stutters ofc a lot (Thanks discord Linux software encoding)

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-1947479538

PFFFFFFFFF I'm gonna try this now HAHAHA
EDIT: now = first I'm going to sleep, then, after I do work stuff, I'll try it.

For those utilizing AMD GPUs on Archlinux or one of its derivatives, I found this fix that worked for me on ProtonDB:

You need to start the game via AMDGPU PRO drivers.

Install the proprietary AMD Radeon driver (it consists of multiple packages, see https://wiki.archlinux.org/title/AMDGPU_PRO). Also install amd-vulkan-prefixes (AUR).

Then start the game with vk_pro (use launch options vk_pro %command%).

This is unrelated to the AMD GPU issue since I'm using an NVIDIA card.
However, perhaps this solution will be helpful to others.

I have been playing since just a day or two after launch, and I rarely experience any crashes.
The trick to keeping the game stable on my system has been to ensure that GPU usage stays below 90%.
(I am unsure about the CPU usage)

This mostly means running the game at low graphical settings and a lower resolution, and using mangohud to limit the FPS to 60, resulting in about 40-60% GPU usage.
The only instances in which I've encountered crashes is when GPU usage exceeds 90%, which only happens when I get too confident and increase the graphics settings.
And yes, this also means that anything outside of the game that uses the GPU could crash the game.

Running Proton Experimental on a NVIDIA RTX 2080.
Launch parameters: MANGOHUD_CONFIG=fps_limit=60,no_display mangohud %command%

Not that it helps directly, but the log hints towards an access violation (c0000005) in a thread called winepulse_timer_loop, suggesting some kind of audio related snafu.

Oh, I'd completely missed this comment.
Ok nevermind then, when the game freezes the audio keeps going so that might be it.

By the way: https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-1948465684 is the issue that I have too.
any ideas?

I have tested the game with the newest 6.7.5 kernel and Mesa 24.0.1, unfortunately the GPU driver still crashes 10-15 minutes after the game being open; I have also tested with the AMDGPU-PRO driver set and the game does work, but my performance in all games is significantly worse with the proprietary drivers installed (Anywhere from 40-80% lower FPS). I am going to wait this one out a bit longer.

The game crashes when the GPU hits 100% utilization, both on Windows and Linux. If you monitor the GPU, you'll notice that it hits stupid high utilization relatively easily without really drawing much power, so the GPU overclocks itself to ridiculous degrees. The goal of all the band-aids seems to be to either lower utilization so that it'll never hit 100%, or slow down the GPU to a crawl. I guess AMDGPU-PRO is just so slow, it doesn't manage to overload the GPU.

The game crashes when the GPU hits 100% utilization, both on Windows and Linux. If you monitor the GPU, you'll notice that it hits stupid high utilization relatively easily without really drawing much power, so the GPU overclocks itself to ridiculous degrees. The goal of all the band-aids seems to be to either lower utilization so that it'll never hit 100%, or slow down the GPU to a crawl. I guess AMDGPU-PRO is just so slow, it doesn't manage to overload the GPU.

Do you know a method, on Linux of course, to limit the USAGE of the GPU and not the POWER LIMIT, as the web is full of this crappy "power limit" when I don't even know how many watts my GPU is absorbing since I'm on a laptop?

I have a lot of other games that have 100% GPU usage consistently and have never had a crash like this; The game itself doesn't crash, but it kills my GPU DRIVER forcing the need to completely power-cycle the computer. On both driver crashes my GPU usage was 98% from what mangohud was reporting.

I believe the crash I'm experiencing with my 7900XTX on Linux, May be a different issue; But obviously I don't know anything for certain other than this is the only game that kills my entire GPU driver.

Below are images with journal entries from the GPU driver crash, just in case this helps anyone.

System

OS: Bazzite
KERNEL: 6.7.4-204.fsync.fc39.x86_64
CPU: Intel Core i7-10750H
GPU: NVIDIA GeForce GTX 1660Ti Mobile
GPU DRIVER: NVIDIA 545.29.06
RAM: 32 GB
PROTON: Proton Hotfix
Desktop: Gnome
Session: Wayland

Initial Issue

Encountered intro dropship cutscene performance issues (18fps) and crash before or during the second dialogue line. Tried most of the fixes in this thread, with no luck.

Initial Solution

Manually edited the game's graphics settings file as recommended in some posts here. Used MangoHUD launch option to limit framerate to 30. Reduced settings far enough to escape the cutscene, lower settings further, and complete the tutorial.

Launch option, courtesy of @Hezkore :

MANGOHUD_CONFIG=fps_limit=30,no_display mangohud %command%

Editable settings file courtesy of @WhiteEyeDoll :

/<LIBRARY_DIR>/SteamLibrary/steamapps/compatdata/553850/pfx/drive_c/users/steamuser/AppData/Roaming/Arrowhead/Helldivers2/user_settings.config

fullscreen = false
borderless_fullscreen = true

Issue Identification

Conducted 3 hours of testing and concluded that the game consistently, with no false positives or negatives and 100% reliability, crashes within seconds of the GPU reaching 100% compute usage (NOT VRAM).

Example of GPU usage before, during, and after crash:

Notes

My GTX 1660Ti Mobile cannot maintain 60fps at 1920x1080 and minimum settings, as seen above. I turned on depth of field and anti-aliasing because they seem to dramatically improve visual fidelity with relatively low performance impact. I intend to aim for 48-50fps in order to sync with my variable refresh rate monitor. I will try to report back on the game's stability.

Tentative Solution

Set all graphical options to minimum, windowed, and reduced resolution, limit framerate to 30 (or lower), then minimally increase individual settings until the game is pleasantly playable without reaching 100% GPU usage, and stress test the configuration under extreme in-mission circumstances.

Conducted 3 hours of testing and concluded that the game consistently, with no false positives or negatives and 100% reliability, crashes within seconds of the GPU reaching 100% compute usage (NOT VRAM).

I've got exactly the same problem. I'm trying to find an FPS limit low enough to not crash.

I tried multiple configurations with both Proton, Plasma, Hyprland as well as Waland and X11

System

OS: Bazzite
KERNEL: 6.1.77
CPU: AMS Ryzen 7 5800X
GPU: NVIDIA GeForce RTX 2080Ti
GPU DRIVER: NVIDIA 545.29.06
RAM: 32 GB
PROTON: Proton Experimental / Proton Hotfix / Proton-GE-32
Desktop: Hyprland / Plasma 5
Session: Wayland / X11

Finally found something that works for me. Played 2 hours so far, beating my previous record of 20 min without a crash. Trick was to force dx11 using the 'regular' game parameter. I also capped framerate at 60, unsure if this is required or not. Launch parameters:
DXVK_FRAME_RATE=60 %command% --use-d3d11

@calvinbull Bingo. %command% --use-d3d11

Occasional 100% GPU compute usage without crashing, increased VRAM usage, decreased GPU compute usage. Will test different settings and/or uncapped framerate next. Thanks!

Finally found something that works for me. Played 2 hours so far, beating my previous record of 20 min without a crash. Trick was to force dx11 using the 'regular' game parameter. I also capped framerate at 60, unsure if this is required or not. Launch parameters: DXVK_FRAME_RATE=60 %command% --use-d3d11

Please let me know if forcing dx11 works uncapped, I will definitely pick this game back up if so!

On a 7900 XTX here. While lowering the settings (everything medium, fancy stuff off, fps capped at 25, windowed/borderless windowed) will extend the time before a crash happens, it inevitably happens nonetheless.

Not home atm, but if someone tries the dx11-workaround, please try it with otherwise default or increased settings for your rig just for the sake of stressing the card and seeing if it completely sidesteps the 7000-series crash.

Finally found something that works for me. Played 2 hours so far, beating my previous record of 20 min without a crash. Trick was to force dx11 using the 'regular' game parameter. I also capped framerate at 60, unsure if this is required or not. Launch parameters: DXVK_FRAME_RATE=60 %command% --use-d3d11

Thank you so much, this was able to let me play the game. I tried the "MANGOHUD_CONFIG" fps limit parameter above but it never limited my FPS. I lowered my resolution in the .config file and was able to get pass the intro and then get into the in-game settings menu to change all the graphical settings to allow me to play the game with an acceptable performance.

Not home atm, but if someone tries the dx11-workaround, please try it with otherwise default or increased settings for your rig just for the sake of stressing the card and seeing if it completely sidesteps the 7000-series crash.

Using DX12 crashes for me.
The DX11 workaround works man!

I was able to let the game run with the GPU maxed out and it didn't crash once!

Now, why did the game ran slightly better using DX12, even if I have a Pascal GPU?

I've been experimenting with the --use-d3d11 parameter for a few hours now.
Initially, my impressions were poor; the game ran terribly, with frame rates below 20 FPS and CPU usage hitting 100%.
However, this issue resolved itself after about 10-20 seconds and has not recurred since.

When I tried setting the game to fullscreen, it crashed.
After restarting, I attempted to use borderless fullscreen mode with my native resolution of 5120x1440, but this also caused the game to crash.
After yet another restart, the game successfully launched in fullscreen at 5120x1440 resolution.
I adjusted the game settings to the Ultra preset and ensured it ran at native resolution scaling.
I am also not using any sort of frame limit, allowing the game to push the GPU as far as it can.

I've played for over an hour, completed a couple of missions, and the game is even running right now in the background, without a single crash since those initial ones.
Throughout my gameplay, GPU usage consistently remained at 100%.

TL;DR... It seems to work. ¯\(ツ)/¯

I launched the game with the parameters: mangohud %command% --use-d3d11
Using Proton Experimental on an RTX 2080.

Not home atm, but if someone tries the dx11-workaround, please try it with otherwise default or increased settings for your rig just for the sake of stressing the card and seeing if it completely sidesteps the 7000-series crash.

My 7900XT survived a ~30min mission with maxed out settings without crashing with --use-d3d11

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-1952271087

I've got the exact same behaviour on my 2080Ti, thanks for the tip!

It takes half a minute to stabilize the fps, but then I can use my gpu like it was meant to be used.

Replying to [#7486 (comment)](https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-1952271087)

I've got the exact same behaviour on my 2080Ti, thanks for the tip!

It takes half a minute to stabilize the fps, but then I can use my gpu like it was meant to be used.

@acul009 Since you mentioned this - my 1660Ti had several stutters in the first few minutes where the game stopped for a moment, and I thought it might crash, but it recovered each time and stabilized after that.

Can confirm --use-d3d11 lets me play for hours with no GPU crash on a 7900 XTX!

Confirmed here too. Played all evening yesterday with everything on ultra using only " %command% --use-d3d11 " as launch parameter on a 7900 XTX.

By the way --use-d3d11 made no difference.

By the way --use-d3d11 made no difference.

--use-d3d11 fixes crashing on AMD 7000 series GPUs; that black window is the first server sided check. If the servers are full it could be on that black screen for 20-30 minutes regardless of operating system.

By the way --use-d3d11 made no difference.

--use-d3d11 fixes crashing on AMD 7000 series GPUs; that black window is the first server sided check. If the servers are full it could be on that black screen for 20-30 minutes regardless of operating system.

In that case it would have to be very specific at locking me out. Why did it let me play just once before the game decided it no longer wants me in the server? Every subsequent attempt to get in the game after reinstalling it has been a failure.

Another reason why I don't believe the black screen is caused by the server cap is because this link also opens automatically during the anti-cheat check. Implying that there's some deeper issue here.

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-1954889480

I think I had the same issue you had where the game was just a blank black screen and it would not even load up the intro video.
I did a "Verify Integrity of game files" in the Properties of the game under "Installed Files" and let the process do its thing, it prompted me about the "nProtect registry was going to reset/wipe" or something like that and I just clicked on "Yes", it finished up the process.
I booted up the game after I changed the "user_settings.config" to change the resolution to a lower value than my 4k res monitor, both for the screen and render resolutions, and to also disallow fullscreen, after that I was able to change the graphical settings within the game after I connected into the server.

Another reason why I don't believe the black screen is caused by the server cap is because this link also opens automatically during the anti-cheat check. Implying that there's some deeper issue here.

The developers have already confirmed that there's a "platform handshake" before the intro video starts.
If you're stuck on a black screen, it's server related.
(unless you're having fullscreen issues, in which case you can edit the config file)
Any "fix" for this has been a coincident and placebo, and the real reason was probably that the servers weren't as overloaded once it worked.

The anti-cheat will open a homepage if the game wasn't properly shut down on the previous run.

Apparently, there was a patch today for the "platform handshake", and I'm not certain the patch will fix the issue, but it might at least help somewhat.
From the patch notes:

Improved the way that we handle platform authentication to avoid things like the black screen issue at startup.

The patch changed nothing. This can't be an issue with the server cap because I've tried joining when the playercount was at 100,000. Right now it's at 156,338 which is way below the given limit and my window is still black. Yesterday the playercount was over 400,000 so there's no reason why I should be getting a black screen.

What must I do to convince everyone that there's something wrong? Here's the Proton log I saved while attempting to launch the game when it was nowhere near the cap.
steam-553850.log

@veryrobust

Make sure you do not exit the game will fullscreen enabled or you will get a black screen on next launch.

If you already did it, go to steamapps/compatdata/553850/pfx/drive_c/users/steamuser/AppData/Roaming/Arrowhead/Helldivers2/ and set fullscreen = false in the user_settings.config file.

For me game crashes 90% at first screen (spaceship) and just once i got past that and the screen froze there, but char could move:D

PoP_OS! 22.04 + latest nvidia (4080) + kernel 6.7.5 + experimental proton(BE).

steam-553850.log

For me game crashes 90% at first screen (spaceship) and just once i got past that and the screen froze there, but char could move:D

Add "--use-d3d11" as argument

For me game crashes 90% at first screen (spaceship) and just once i got past that and the screen froze there, but char could move:D

Add "--use-d3d11" as argument

Does not work for me.
steam-553850.log

@spaghetticodez

DXVK_FRAME_RATE=60 %command% --use-d3d11

Adding a frame cap as suggested by calvinbull along with the --use-d3d11 fixed a crash similar to yours for me on fedora 39 with nvidia drivers version 545.29.06, an RTX 2080 Super, and kernel version 6.6.8-200.fc39.x86_64. Went from repeatedly almost immediately crashing within a second of the intro where a character is sitting in a ship, to playing with friends for a few hours without a single crash. So maybe give the frame cap a go as well? Gl!

DXVK_FRAME_RATE=60 %command% --use-d3d11

I get to 2nd screen with it, but result is screen is frozen while character moves:)
steam-553850.log

I believe something major may have been patched within the last 24 hours, and/or that manually editing the game settings file to bypass crashes may have some major risks.

I had originally edited the game's settings file to lower settings and prevent crashes before the DirectX 11 flag was figured out / mentioned. I later noticed frequent lighting bugs (mostly very high brightness), so I deleted the settings file and had the game re-generate it, manually edited the minimum possible amount (windowed state, screen resolution) to stabilize the game with DXVK_FRAME_RATE=60 %command% --use-d3d11, then adjusted settings in-game and played a couple missions. This corrected the lighting issues.

I was able to maintain a mostly consistent 50fps (with adaptive sync) at mostly medium settings, without crashing. Full system details are listed in my initial post here; this performance data is on a laptop GTX 1660Ti.

For anyone still having issues, or having to limit FPS etc., I recommend trying out the Proton Experimental Bleeding Edge beta branch.

For anyone still having issues, or having to limit FPS etc., I recommend trying out the Proton Experimental Bleeding Edge beta branch.

I have tried now everything here, no luck. I once got past the loading into ship while it worked there to be crashed while launching a pod -_-
steam-553850.log

EDIT: Patch 1.000.12 fixed the cinematic bug. First game tested.
E2: Game runs fine now

I'm able to launch the game and play solo just fine. Multiplayer just does not seem to work at all. Don't know what to do, very sad :(

@LukeStonehm could you elaborate on that? as I understand, the game lets you quickmatch and play with friends, neither work? are you getting errors?

I'm able to launch the game and play solo just fine. Multiplayer just does not seem to work at all. Don't know what to do, very sad :(

I had first this issue, the rootk.. (nProtect) does not work well with firewalls etc. Had to disable mine to check the issue. Even OpenSnitch was an issue:/

@LukeStonehm could you elaborate on that? as I understand, the game lets you quickmatch and play with friends, neither work? are you getting errors?

@simifor In-game errors. I'm unable to quickmatch or join friends. It says "establishing uplink to host ship" (or something along those lines), then fails with a "unable to connect" error.

Game runs fine, solo works, but I can tell it's just not connecting to the broader multiplayer features.

I'm runnin POP_OS 22.04 LTS, Nvidia 1080. I've not configured anything regarding a firewall (as hinted by @spaghetticodez), but maybe there's commands to be run to check?

@LukeStonehm pop os comes with ufw, but I don't think it is enabled by default. You can check if it's active by running sudo ufw status there is more firewall software available, but if you didn't go out of your way to install them, they shouldn't be running either.

@simifor Status: inactive for ufw. I've got a fairly stock POP setup. Not sure what to try really tbh. I also tried port-forwarding but it had no effect. I had docker installed, I theorized that perhaps the game was trying to use the network interface that docker creates, so I uninstalled it. No improvement sadly.

I'm open to any suggestions.

I have 4 SSDs in my machine, perhaps I should try a different distro? Maybe something installed has screwed it up? That said, I've been playing other games multiplayer just fine. Remnant 2 being the most recent.

What distro are you using / what do you recommend?

@LukeStonehm
Game seems to have no issues in multiplayer for me using GE-Proton8-32 on Arch Linux. I'm using hyprland and plasma 5, and running the game in gamescope using the arch packaged steam over the flatpak. I also have docker installed, as well as networking for virtual machines, but networkmanager seems to be mapping everything correctly with default configuration. I'm on a 5800x3d with a 6800xt so wayland works really well with the system. I think it's also worth noting Valve's own Steam Deck uses Arch at it's core.

@ebuttonsdude thanks for the info. I'm also running that latest version of GE proton.

Might put arch onto one of my other hdds and give it a try (I do enjoy Plasma). Can you comment on Nvidia support?

@LukeStonehm I've got some friends with Nvidia hardware that are using X11 Plasma which works great for them. The arch wiki has a great install guide on the nvidia drivers, and I think archinstall (the tui installer) can install the drivers as well. I've heard that electron apps like discord can be a bit jittery on wayland with nvidia, but I think games work fine.

• If the game window goes behind an another window, game window goes black and restart is required.

I am seeing behavior which I suspect shares a root cause. In my case I'm running a window manager (AwesomeWM), and the problem presents itself whenever the game window is on a workspace which isn't shown.

I get black screens frequently (but not always). I consistently get disconnected from whatever online lobby I'm connected to. Given how consistently it's related to what the window's doing, it seems likely that some kind of similar issue is at play.

GPU: NVIDIA RTX 3080 Ti
Video driver version: Nvidia 545.29.06
Kernel version: 6.6.13-200.fc39 (Fedora)
Proton Version: Proton Experimental (reproduced with Proton 8.0-5, as well as various recent 8.xx GE versions)

UPDATE: Additional issue - I do not see sample counts when viewing the map. Normally when viewing the map, sample counts appear in the upper-right corner of the screen. These are invisible for me.

I've been struggling with this title a lot. I'm using RX 7900XTX, however combination of the --use-d3d11 (fixed 30 min crash, tested in 3 sessions 8h total) and setting screen to border less window (help with black screen at boot). Unfortunately the picture gets a little blurry and/because of the white frame. Proton version didn't make any difference for me (Tested on Experimental, Hotfix, 9.0-beta, GE). Didn't have to limit FPS, running it at 165 Hz, vsync, 1440p, Ultra settings.

That's on Fedora 39 KDE
Kernel: 6.7.6
Mesa: 23.3.6

On my 6600XT it does not crash when using --use-d3d11
I was not able to get it working without that argument even with Proton Experimental Beta, Proton 9.0 beta and latest GE

Running on Ubuntu 23.10
Flatpak steam with the latest mesa-git
Kernel: 6.5.0-17-lowlatency

I can confirm on a 7800XT it does not crash with --use-d3d11 with around 3 hours of continuous gameplay.

I do get micro stuttering if I leave the framerate unlocked where it hits around 100% GPU usage which does not happen if I don't use the dx11 option (but it will crash regularly then).

Limiting to 60 FPS smooths that out.

Has someone played a game "online"?

Yep.
I noticed as long as:

1. you play it in dx11 mode
2. don't use Full Screen
   Game works just fine.

FULL screen also works, BUT it fails to start next time, unless you change config file later on.

I have multiple issues:

-white pixel border around game on every proton version i tried (proton experimental, proton hotfix, proton GE-8.31)
-game crashes every second or third mission and hardlocks my computer or takes down desktop
-game will crash on a loading screen after a mission and give me gray pixel artifacts (not sure how to call them) - I still get sound but my entire screen gets these gray boxes on them and even quitting the game doesn't work to fix I need to restart the game
-game doesn't work well (Very stuttery) using --use-d3d11
-game freezes without the command --use-d3d11 on every proton version i tried (proton experimental, proton hotfix, proton GE-8.3). dx12 doesn't work for this game.

My stats:
Arch Linux x86_64
Kernel: 6.7.6-arch1-1
DE: Plasma 5.27.10
CPU: Intel i7-10750H (12) @ 2.600GHz
GPU: NVIDIA GeForce RTX 2060 Mobile
Memory: 8904MiB / 23903MiB

@mercifulboss This is a bit of a long shot but the issues you described sound more like overheating and subsequent firmware/hardware failure.

My 10750H semi-randomly overheats without the right CPU frequency/power/temperature management software, and either cripples or crashes games when it does. The graphical artifacts on screen outside of the game sound like GPU overheating and/or failure, which could also happen with a shared heatsink.

If you have an HP Omen 15/16/17 laptop from before 2022, I would bet on overheating being the issue. Auto-cpufreq and TuneD are the only utilities I know of which can prevent it.

Bazzite ships with TuneD, Nvidia drivers, and a bunch of other nice things, if you're open to trying Fedora.

As for the white border: that seems to be a borderless fullscreen issue for everyone. Others have reported that fullscreen will not start properly, so I would recommend playing windowed.

I am not adding anything new to the conversation but I also want to confirm that the game freezes on my 7900 XTX.

I have no intentions to play on DX11 mode, I might as well just wait for a fix.

Anyway, the freeze happens completely randomly, can be after 5 minutes of game time like it could be half an hour. I always do the same test for consistency, did not even try the actual game yet. I boot the game and run the tutorial. The vast majority of freezes happen once you are nearing the completion of the tutorial but I also had a freeze once immediately after having to crawl to avoid being shot by the two automated turrets.

The freeze is not really a freeze, from what I could notice it consists on the video card committing seppuku (the monitors actually notice a video signal disconnect) and after a few seconds coming back to life. Only fatal flow is that all the applications are now frozen despite video image re-appearing on screen, and since it takes no input and no application is running I can't even open a TTY to run the reboot command, the computer is by all means dead obliging you to force reboot it.

Anyone let me know if you would like my game dump logs and system settings. Thank you all!

No

Ok, nevermind then.
But I just wanted to tell you that DX11 is no worse than DX12 except if your CPU is the bottleneck in your PC.
Sure, DX12 enables stuff that DX11 can't do such as... uh... well, it does things, but DX11 works differently in this game.
DX12 seems more stable than DX11 in frame-pacing, but it works unless the DX12 implementation.

Personally I find that targeting DX12 only is stupid, since Vulkan is superior.
Plus, thanks to Nvidia, my GTX1050TI cannot run DX12 efficiently, so having games that doesn't support DX11 (such as Arma: Reforger) pisses me off... because they do not for no apparent reason.

I mean no offense but I am really not interested in a debate of DX11 vs DX12 to Vulkan. I just want to report the issues I had and offer to provide logs and experiments to solve the issue at the root. That is all.

If I can be of use to test things out even better.

I mean no offense but I am really not interested in a debate of DX11 vs DX12 to Vulkan. I just want to report the issues I had and offer to provide logs and experiments to solve the issue at the root. That is all.

If I can be of use to test things out even better.

All right.

Since we're talking about logs, @kisak-valve here's a log of the game functioning for hours, using --use-d3d11.
Can you please tell me what are those weird errors that are spamming the log?
steam-553850.log

If you are talking about the unwind calls it seems to be because you are forcing a non default configuration. Could be because of forcing DX11 instead of DX12 or could just be a harmless proton call. There were some reports for something similar like this on the Arch Linux forums from some years past and it was just that.

I am going to test it without the flag and see if it reproduces the same way

@gabriele2000 I tested it out from beginning of the tutorial mission to freeze and I wouldn't worry too much about your errors, of-course to Kisak the final word.

I have them too and I have been running the game without any launch parameter so I would say we can exclude the issue given by forcing DX11 instead of DX12.

Here is the attached log if you are curious (there are plenty of other errors tho)
steam-553850.log

@Plarpoon Yeah I wasn't worrying about them, though this is one of the few games that produces so many errors.
Your file is more plagued by VKD3D than "seh" (heh, it sounds funny in our language) like mine.

By the way, I couldn't track the issue back when I was trying to run the game without any additional parameter, and my log was the same as yours for about 90% of the content.

I suspect that your issue is something that Helldivers 2 devs has to fix on their side (although it's strange that only the DX12 implementation is broken).

The anticheat could be another cause, but it's highly unlikely, as it never gave a problem for (us) linux users (as far as I know).

when I tried the --use-d3d11 option in windows, the AMD overlay kept detecting dx12 as the api, so vkd3d's presence in the log file is likely due to how the game itself works.

I was not satisfied with forcing directly DX11 on a game so after looking at the logs I experimented a bit changing the WineD3D renderer

For the moment I had good results telling it to use Vulkan as a backend instead of OpenGL as described in-here:
https://github.com/ValveSoftware/Proton?tab=readme-ov-file#runtime-config-options

PROTON_USE_WINED3D=1 %command%

I am marking this as RFC, can anyone kindly help me out testing it on your system as-well and reporting if you experience any freeze? I did not have any.

Please while testing this, for reliability, do not use any other launch parameter.

@Plarpoon that option wouldn't do anything in this case, it disables dxvk which is used for dx9-11 games. If you used mangohud it should show that the game is using vulkan and vkd3d-proton

Then I was just lucky and it did not freeze during testing, sometimes it happens.
Or unlucky in this case as I wanted it to freeze.

Thanks for feedback!
I will gladly take the tip on using mangohud from now on

Will test more in a few hours

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-1968340781

I got another crash with Helldivers 2 on the 550.54.14 drivers and Proton 9. I also managed to nab a screenshot. Mangohud did not show that my computer was overheating. It didn't go above 60C

https://github.com/ValveSoftware/Proton/assets/90151527/0547388e-9ca9-4f75-8c20-301bfffcd9d3

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-1969554990

Most likely not overheating, then (potentially depending on which temperature sensors MangoHUD was reading)... Thanks for checking, and getting that video+screenshot. At this point the issue is beyond my knowledge, but that graphical issue looks pretty recognizable for someone who knows more.

i get a message saying that the my graphics card needs to be able to run direct3d 12_0 after the new update, my card is a 3060, im running Ubuntu and ive tried proton 7,8, the 9 beta, and experimental

i get a message saying that the my graphics card needs to be able to run direct3d 12_0 after the new update, my card is a 3060, im running Ubuntu and ive tried proton 7,8, the 9 beta, and experimental

@breakdowngamesYT can you confirm what your complete launch commands are? If you have any proton/dxvk commands which end in %command% be sure to put the --use-dx11 afterwards.

Placing a dx11 restriction before %command% makes the game think your computer can't run dx12 (if I do this I get an error like yours), placing it after is asking the game to use dx11.

With today's patch 1.000.13 I get the same error as @breakdowngamesYT.

I have the dx11 restriction after %command%

Edit: Rebooting fixed the issue

Then I was just lucky and it did not freeze during testing, sometimes it happens. Or unlucky in this case as I wanted it to freeze.

Thanks for feedback! I will gladly take the tip on using mangohud from now on

Will test more in a few hours

Hey @simifor, I am sorry it took me some extra time but I was full on exams.

Anyway, I have tested it today and despite the copious amount of errors in the log the game actually works perfectly smoothly without DX11 or any other parameter than PROTON_USE_WINED3D=0

I am not excluding just having been lucky again as that is a possibility, but I am genuinely curious now, did you actually test it out last time or did you just reply to me? If so, would you mind testing it so we can exclude it as a fix?

I am also attaching my log but I want to say this, before adding this parameter I couldn't even finish the tutorial mission because the game would just randomly freeze while now I could do that full mission plus my very first actual game (I did not die, it was fun).

steam-553850.log

Thank you so much for time and dedication 🙂

PROTON_USE_WINED3D=0 is the implicit default when you don't set the variable. PROTON_USE_WINED3D=1 would only have an effect in this game if you're also using --use-d3d11 (this doesn't apply to other games) as the WINED3D variable only works when using dxvk, and dxvk is for dx9-11 games. So as this game uses dx12 by default, whether you set that to 0 or 1 should have no effect. Also, when wined3d is in use mangohud will report opengl instead of vulkan.

Regarding stability testing, it's not something I can test in my computer as the game never crashed or hanged for me.

Playing on a 4090, with drivers 535.161.07 on a 5950x with 64 GiB of ram. The game doesn't seem to be able to use my card at 100% (all ultra at 3440x1440), usually hovers between 50~60%, but the FPS sometimes dips way below my v-sync (75 Hz).
I tried disabling v-sync, alas the situation doesn't improve much, looks like this game is somehow CPU bound.
I even reduced the details to low and upscaling to the max, the FPS still dips as when I set ultra - likewise if I set super-sampling the card is getting used more but FPS stays the same.

Tried both proton 9 and hotfix, the results are still the same.

My guess is that or the engine is 'stalled' or wine/proton itself is stalling it.

Launching with gamescope -f -W 1920 -H 1080 -- %command% gets around the black screen issue for me, no need to edit user_settings.config to launch windowed.

When the black screen occurs, attaching gdb to helldivers2.exe would suggest that the game is stuck in an infinite loop. eax is never 0 here so it keeps jumping 2 instructions back.

Card: 3090 Ti
Nvidia driver: 550.54.14
System: Ubuntu 22.04 LTS
RAM: 64GB
Proton version: anything from 6.0 to Hotfix (tried all)

I can't even start the game. I click Play, and the button goes blue. After a brief period, the button then goes back to green.

After today's Proton Experimental patch I can play the game without crashes or any launch paramter.

Fedora 39, KDE, 7900XTX

I really don't understand why, usually it'd be an impossible thing but...
Using my GTX1050TI, I can play the game using DX12 with the same performance of DX11, now I'm wondering HOW.

UPDATE: Nevermind, the game has graphics inconsistencies and sudden low FPS after entering the tutorial, or every mission.
In the ship the performance is the same as DX11 though.

Using a PS4 controller, there seems to be an issue with running. Either I switch between running and walking or just walk. I've reset my in-game controller settings. This is particularly frustrating because you may need to run from a Jumper. The controller is connected via USB.

Launching with gamescope -f -W 1920 -H 1080 -- %command% gets around the black screen issue for me, no need to edit user_settings.config to launch windowed.

For me the game doesn't launch at all when using gamescope with 3440x1440 as a resolution. Sometimes the anti cheat window pops up but that is not reproducible all the time.
Using 1920x1080 seems to work tho.

Fedora 39
7800x3d
7900xtx

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-1975194664

I am also on Fedora 39 (KDE) and played for hours yesterday with these launch settings and no issues.

gamemoderun obs-gamecapture gamescope -W 3840 -H 1080 -b -- %command%

So yeah, I do not really know why.
I also have a RX 7900XTX and a Ryzen 9 7900X3D

the FPS sometimes dips way below my v-sync (75 Hz). I tried disabling v-sync, alas the situation doesn't improve much, looks like this game is somehow CPU bound. I even reduced the details to low and upscaling to the max, the FPS still dips as when I set ultra - likewise if I set super-sampling the card is getting used more but FPS stays the same.

Same problem here, on 3070Ti with 535.154.05 drivers. Game presents very well, but there is a recurring frame pacing issue that makes the max framerate appear choppier than it is. I've tried multiple variations on Proton and toggled between dx11 and dx12 modes, it seems to be an Nvidia-specific hardware issue.

Same problem here, on 3070Ti with 535.154.05 drivers. Game presents very well, but there is a recurring frame pacing issue that makes the max framerate appear choppier than it is. I've tried multiple variations on Proton and toggled between dx11 and dx12 modes, it seems to be an Nvidia-specific hardware issue.

Would be interesting to see if the same issue materialize with drivers 550 series. I'll wait for it to be added to the official drivers on Ubuntu and try (you can find it on the dedicated test ppa now).

I think this issue happens when there are many active moving 'objects' on the screen and my guess is that a sync-api issue where there is some sort of delay somewhere which then bottlenecks sending commands to the GPU (again, my 4090 is utilized at 60% all Ultra and still I get dips of 59 FPS sometimes - disabling v-sync slightly helps of ~3 FPS but doesn't change much - likewise setting everything to low has the same effects, just GPU drawing less power).

Do we know if AMD cards suffer from the same issue?

Is there a mechanism to help out investigating this a bit more? Could we run a Vulkan stub and/or a version of Proton which logs calls without incurring in the anti-cheat penalties?

If you know which launch parameters you want me to use I will gladly test it out for you, I have a full AMD setup

Card: 3090 Ti Nvidia driver: 550.54.14 System: Ubuntu 22.04 LTS RAM: 64GB Proton version: anything from 6.0 to Hotfix (tried all)

I can't even start the game. I click Play, and the button goes blue. After a brief period, the button then goes back to green.

I still can't launch at all. I've tried every command in this thread!

If it helps, my proton log is here:

======================
Proton: 1707501910 hotfix-20240209-1
SteamGameId: 553850
Command: ['[REDACTED]/bin/helldivers2.exe', '--bundle-dir', 'data', '--release']
Options: {'forcelgadd', 'heapzeromemory'}
depot: 0.20240125.75305
pressure-vessel: 0.20240125.0 scout
scripts: 0.20240125.0
sniper: 0.20240125.75305 sniper 0.20240125.75305
Kernel: Linux 6.5.0-21-generic [#21](/issue/ValveSoftware/Proton/21)~22.04.1-Ubuntu SMP PREEMPT_DYNAMIC Fri Feb  9 13:32:52 UTC 2 x86_64
Language: LC_ALL None, LC_MESSAGES None, LC_CTYPE None
Effective WINEDEBUG: +timestamp,+pid,+tid,+seh,+unwind,+threadname,+debugstr,+loaddll,+mscoree
======================

If you know which launch parameters you want me to use I will gladly test it out for you, I have a full AMD setup

Thanks!

1. What videocard do you have?
2. In short, does the game use 100% of your GPU if you disable v-sync?
3. What FPS are you hitting at which resolution/details level?
4. If so, by enabling v-sync, are you able to hit those v-sync FPS constantly?

Would be interesting to see if the same issue materialize with drivers 550 series.

I've been experiencing a different issue that causes stuttering in all games on 545 and above (presumably the explicit-sync issue in XWayland) which makes it hard for me to tell if it's the same issue. I tested on 550 this morning anyways, and the game behaved exactly the same as far as I can tell.

I'm back on 535 for now, and I'll test 550+ again once XWayland ships explicit sync (or Proton gets native Wayland, whichever comes first).

I have a lot of other games that have 100% GPU usage consistently and have never had a crash like this; The game itself doesn't crash, but it kills my GPU DRIVER forcing the need to completely power-cycle the computer. On both driver crashes my GPU usage was 98% from what mangohud was reporting.

You might check this thread:
https://gitlab.freedesktop.org/drm/amd/-/issues/1974

The assumption is that the card is being overdriven, and/or that there is a bottleneck between the CPU and GPU, and power management is causing crashes as the card tries to switch frequencies. Try this in your boot options: amdgpu.ppfeaturemask=0xfff7ffff

I am testing with it right now, will report back.

ed.: didn't help

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-1979982757

I have the same issue with nvidia 2060 mobile on the 550 driver. But it is exactly what you describe (see my photo/video in post above). I hit 100% gpu usage and my entire GPU driver crashes with gray artifacts on the screen, forcing a hard reboot

Setting WINE_DO_NOT_CREATE_DXGI_DEVICE_MANAGER=1 seems to prevent the black screen if launching in fullscreen mode on latest proton_9.0 branch.

Setting WINE_DO_NOT_CREATE_DXGI_DEVICE_MANAGER=1 seems to prevent the black screen if launching in fullscreen mode on latest proton_9.0 branch.

Can confirm on my machine (3070Ti, 535 drivers) that this works well. Better yet, it also seems to fix the frame-pacing issue that I was experiencing in the Borderless mode.

If anyone else with Nvidia graphics is experiencing microstutter, I'd recommend trying this flag on the latest 9.0 update and enabling fullscreen.

I'm afraid even adding this option WINE_DO_NOT_CREATE_DXGI_DEVICE_MANAGER=1 doesn't improve the FPS on my 4090, still low, sometimes around 40s-50s and GPU used at 40%.
I have some suspicion there may be some 'locking'/concurrency suboptimal code which somehow throttles the GPU...

Since today my mouse movement doesn't work outside of menu screens. When I start the game with gamescope it lets me rotate the camera only by about 45 degrees. Anybody had this issue?

Edit: This seems to me like the mouse is being constrained to the monitor bounds

Since today my mouse movement doesn't work outside of menu screens. When I start the game with gamescope it lets me rotate the camera only by about 45 degrees. Anybody had this issue?

Edit: This seems to me like the mouse is being constrained to the monitor bounds

Yeah, happens to me with same Proton Experimental, rebooting helps for some reason

For me it was related to the update to Plasma 6
Running gamescope with --force-grab-cursor fixed it.

Here's my full command: gamescope -f -W 2560 -H 1440 -f -e --force-grab-cursor --display-index 1 -- gamemoderun %command%

This games crashes my amdgpu driver the quickest I've ever seen.
What happens: start the game, proceed through the menu until you're at the ship/play for a few minutes, wait, ???, everything freezes, sound continues, gpu driver resets but never resumes display of screen content, switching between tty is not possible.

journalctl output: https://gist.github.com/zaggynl/da370bbf7edf72283d6a55c4da307aad

systeminfo: https://gist.github.com/zaggynl/2441cf6330d3414352c425f4c8b3763f

proton log: steam-553850.log

Edit: seems stabler after updating distro packages, played one mission without issues
current systeminfo for reference: https://gist.github.com/zaggynl/e66a527d9b24bcb0855c28f9c7f86ea9

switching between tty is not possible.

you have to switch before the driver restarts or your session is likely to lock up. and 9/10 it will not actually recover properly, even if you kill and restart your graphical session there will be memory corruption and things will break/crash more.

This games crashes my amdgpu driver the quickest I've ever seen. What happens: start the game, proceed through the menu until you're at the ship/play for a few minutes, wait, ???, everything freezes, sound continues, gpu driver resets but never resumes display of screen content, switching between tty is not possible.

This is an issue with the game and AMD cards, It is happening on windows as well. There is an active bug thread open on the HD2 discord. Running the game with --use-d3d11 prevents the driver crash

I'm afraid even adding this option WINE_DO_NOT_CREATE_DXGI_DEVICE_MANAGER=1 doesn't improve the FPS on my 4090, still low, sometimes around 40s-50s and GPU used at 40%. I have some suspicion there may be some 'locking'/concurrency suboptimal code which somehow throttles the GPU...

Tried to use the d3d11 renderer --use-d3d11, alas same issue. Looks like the game engine somehow is poor at scheduling GPU commands... or there are sync primitives which are somehow blocking the same.

Performance is worse that expected. MangoHud reports low GPU usage and strangely high CPU usage during missions. According to benchmarks and reviews CPU usage shouldn't be higher than 20-30% for this game. Tried Proton 8.0, Proton 9.0 Beta, GE-9-1 and WINE_DO_NOT_CREATE_DXGI_DEVICE_MANAGER=1 to no avail.

@Rodancoci you seem to be onto something.
I've created a simple python script which will capture CPU usage for all processes on the machine every one second and when interrupted will save down CSV data for both user time and system time for each process.
The content are simply what is reported by the /proc/pid/stat procfs, namely the columns utime and stime; basically is cpu %.

Below the charts for my system, 5950x (16 cores, 32 threads) and I got the following for user time:

and for system time:

It's worth noting that the system time chart is mostly flat while the user time:

• blue is the game (main), red the anti-cheat/protection (some hex chars)
• everything else is flat
• the anti-cheat/protection only really kicks in at the very beginning and stay active for some seconds
• because the game uses an average of 150% CPU for system time, the user+system time chart would have a couple of sections 1600% (my physical cores on a 5950x) and these are the cases when my FPS drops below my v-sync and can't feed my 4090, independently of details and/or resolution

In short, looks like the combination of both this game plus proton/VKD3D and/or proton/DXVK exhaust the available cpu cores and that's when the FPS takes a dive.

Good finding @Rodancoci - I've just confirmed the same.

Also, I don't think the game itself would invoke loads of system calls, my fear is that we end up 'burning' 150% CPU in system time because of wine/wineserver IPC architecture - but again it's just a guess because wineserver is using ~10% CPU system time so this is just a hunch.

Following a chart from MangoHUD - when the cpu_load > 50% (i.e. 16 cores) the FPS struggles to stay about 75 Hz (my V-Sync) and the gpu_load never goes abov 60~70% usage (this is from another run, unrelated to above two charts):

I've trid proton experimental, GE 8.32, and GE 7.55 and no matter what when I'm in the game it doesn't say I'm in my ship and I'm unable to join online lobbies. Occasionally when I open the game I'll get sent to this support page https://gameguardfaq.nprotect.com/eng/con_13.html that provides no information as to what went wrong. This game has a gold status on protondb and it seems I'm the only one with this problem. I don't have this issue on windows. I'm unsure where to begin providing logs or other information. I'm on Debian Bookworm.

If you are sent to that support page, it means that you are triggering the anticheat solution. Make sure that your game is unmodified and that you use the default configuration. @wbehrens-on-gh

I've trid proton experimental, GE 8.32, and GE 7.55 and no matter what when I'm in the game it doesn't say I'm in my ship and I'm unable to join online lobbies. Occasionally when I open the game I'll get sent to this support page https://gameguardfaq.nprotect.com/eng/con_13.html that provides no information as to what went wrong. This game has a gold status on protondb and it seems I'm the only one with this problem. I don't have this issue on windows. I'm unsure where to begin providing logs or other information. I'm on Debian Bookworm.

I do have the same issue, and my setup has not changed. I am almost certain this issue was introduced with a recent Helldivers patch, as the game worked before without any problems.

I validated files, tried different proton versions, all to no avail.

If you are sent to that support page, it means that you are triggering the anticheat solution. Make sure that your game is unmodified and that you use the default configuration. @wbehrens-on-gh

What do you mean with "unmodified", @braiam ?

@wbehrens-on-gh @tillmzw
I too couldn't connect to any friend or online lobby, on both steamdeck and another linux device (running nixos 23.11) until I disabled ipv6 for my network device.

It now runs on Proton 8.0-5 and the --use-d3d11 launch option (although I'm not sure forcing directx11 is necessary anymore, because previously I was able to launch the game without the flag)
I'll have check if disabling the firewall was also part of the job.

@wbehrens-on-gh @tillmzw

I too couldn't connect to any friend or online lobby, on both steamdeck and another linux device (running nixos 23.11) until I disabled ipv6 for my network device.

Huh. That fixed the issue. I used nmcli (RH doc), reconnected my network and it worked. Thanks for the tip!

(btw, I never had to force D11, but that might be an effect of bazzite or AMD hardware)

I haven't had to fiddle with the firewall as of yet. Probably because my router doesn't hand out IPv6 addresses.

Distro: Fedora 39
CPU: AMD 5800X
GPU: AMD 7900 XTX
Proton: Hotfix
Command: gamemoderun MANGOHUD_CONFIG="fps_limit=60" mangohud %command% --use-d3d11

Plays fine. Only the odd vertex from ragdolls stretching.

With out --use-d3d11 game would crash at random times.

With out mangohud limiting the FPS, GPU usage would go to 100%.

It's very weird, I have fully functioning IPv6 connectivity and no issues playing with my wife on a same network or with others. I use in-game 120 FPS limiter to reduce the heat output, 165 Hz loads GPU (7900 XTX) to full load and CPU (5900X) to constant 40-45+% load, so it's getting toasty really fast.

Only the odd vertex from ragdolls stretching.

That happens on Windows as well (looking at what's happening on my Wife's PC), not linux specific

It's still crashing at 30m mark for me without dx11 and still black screen if set to fullscreen instead of borderless window, even with latest proton-experimental based on Proton 9

@wbehrens-on-gh @tillmzw
I too couldn't connect to any friend or online lobby, on both steamdeck and another linux device (running nixos 23.11) until I disabled ipv6 for my network device.

Huh. That fixed the issue. ... Thanks for the tip!

I had a similar issue. I could start solo missions, but could never join my friends.
As an indication for the issue I identified that the steam status in the friend list always stayed at "On Main Menu".

After experimenting with ipv4 vs ipv6 in different combinations. I notice that this issue seems to be DNS related. I don't use the DNS server(s) provided by my provider, as they don't replay properly if I have a typo in a URL in my browser. But after going back to the provider DNS, is just worked. Very odd behaviour, more research is needed...

My game is consistently crashing on latest linux kernel (6.5.0-26-generic). Was not happening on latest 5.15. What can I do to narrow down the issue?

             ...-:::::-...                 pato@qtpi 
          .-MMMMMMMMMMMMMMM-.              --------- 
      .-MMMM`..-:::::::-..`MMMM-.          OS: Linux Mint 21.3 x86_64 
    .:MMMM.:MMMMMMMMMMMMMMM:.MMMM:.        Host: B660M DS3H DDR4 
   -MMM-M---MMMMMMMMMMMMMMMMMMM.MMM-       Kernel: 6.5.0-26-generic 
 `:MMM:MM`  :MMMM:....::-...-MMMM:MMM:`    Uptime: 1 hour, 53 mins 
 :MMM:MMM`  :MM:`  ``    ``  `:MMM:MMM:    Packages: 2351 (dpkg), 8 (flatpak) 
.MMM.MMMM`  :MM.  -MM.  .MM-  `MMMM.MMM.   Shell: bash 5.1.16 
:MMM:MMMM`  :MM.  -MM-  .MM:  `MMMM-MMM:   Resolution: 1920x1080, 1920x1080 
:MMM:MMMM`  :MM.  -MM-  .MM:  `MMMM:MMM:   DE: Cinnamon 6.0.4 
:MMM:MMMM`  :MM.  -MM-  .MM:  `MMMM-MMM:   WM: Mutter (Muffin) 
.MMM.MMMM`  :MM:--:MM:--:MM:  `MMMM.MMM.   WM Theme: Mint-Y-Dark-Purple (Mint-Y 
 :MMM:MMM-  `-MMMMMMMMMMMM-`  -MMM-MMM:    Theme: Mint-Y-Dark-Purple [GTK2/3] 
  :MMM:MMM:`                `:MMM:MMM:     Icons: Mint-Y-Purple [GTK2/3] 
   .MMM.MMMM:--------------:MMMM.MMM.      Terminal: gnome-terminal 
     '-MMMM.-MMMMMMMMMMMMMMM-.MMMM-'       CPU: 12th Gen Intel i5-12400F (12) @ 
       '.-MMMM``--:::::--``MMMM-.'         GPU: AMD ATI Radeon RX 6800/6800 XT  
            '-MMMMMMMMMMMMM-'              Memory: 4685MiB / 31928MiB 
               ``-:::::-``

                                     
Computer Information:
Manufacturer: Gigabyte Technology Co., Ltd.
Model: B660M DS3H DDR4
Form Factor: Desktop
No Touch Input Detected
Processor Information:
CPU Vendor: GenuineIntel
CPU Brand: 12th Gen Intel(R) Core(TM) i5-12400F
CPU Family: 0x6
CPU Model: 0x97
CPU Stepping: 0x2
CPU Type: 0x0
Speed: 4400 MHz
12 logical processors
6 physical processors
Hyper-threading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Unsupported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
AVX2: Supported
AVX512F: Unsupported
AVX512PF: Unsupported
AVX512ER: Unsupported
AVX512CD: Unsupported
AVX512VNNI: Unsupported
SHA: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported
Operating System Version:
Linux Mint 21.3 (64 bit)
Kernel Name: Linux
Kernel Version: 6.5.0-26-generic
X Server Vendor: The X.Org Foundation
X Server Release: 12101004
X Window Manager: Mutter (Muffin)
Steam Runtime Version: steam-runtime_0.20240304.79797
Video Card:
Driver: AMD AMD Radeon RX 6800 (navi21, LLVM 15.0.7, DRM 3.54, 6.5.0-26-generic)
Driver Version: 4.6 (Compatibility Profile) Mesa 23.2.1-1ubuntu3.1~22.04.2
OpenGL Version: 4.6
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 119 Hz
VendorID: 0x1002
DeviceID: 0x73bf
Revision Not Detected
Number of Monitors: 2
Number of Logical Video Cards: 1
Primary Display Resolution: 1920 x 1080
Desktop Resolution: 3840 x 1080
Primary Display Size: 20.91" x 11.77" (23.98" diag), 53.1cm x 29.9cm (60.9cm diag)
Primary VRAM: 16384 MB
Sound card:
Audio device: Realtek ALC897
Memory:
RAM: 31928 Mb
VR Hardware:
VR Headset: None detected
Miscellaneous:
UI Language: English
LANG: en_US.UTF-8
Total Hard Disk Space Available: 233141 MB
Largest Free Hard Disk Block: 188937 MB
Storage:
Number of SSDs: 5
SSD sizes: 2000G,1000G,480G,250G,0B
Number of HDDs: 0
Number of removable drives: 0                                   

I had a similar issue. I could start solo missions, but could never join my friends. As an indication for the issue I identified that the steam status in the friend list always stayed at "On Main Menu".

After experimenting with ipv4 vs ipv6 in different combinations. I notice that this issue seems to be DNS related. I don't use the DNS server(s) provided by my provider, as they don't replay properly if I have a typo in a URL in my browser. But after going back to the provider DNS, is just worked. Very odd behaviour, more research is needed...

I did some more experiments with my DNS settings. I use systemd-resolved as local DNS cache and to add extra DNS servers from Quad9 and OpenNIC, so I don't get redirected on URL typo's in my browser.

This is how my /etc/systemd/resolved.conf looks like if the game runs fine:

[Resolve]
DNS=192.168.0.1 # my router address
Domains=~.
DNSSEC=yes
DNSOverTLS=no
MulticastDNS=no
Cache=yes
ReadEtcHosts=yes

If I put in a different DNS e.g:

-DNS=192.168.0.1 # my router address
+DNS=9.9.9.9 #quad9
+FallbackDNS=192.168.0.1 # my router address

I can start the game, but my status in steam stays at "On Main Menu" and I can't join any of my friends and so can't they.

I have not tried changing the DNS directly in the router yet.

Judging from the known issues in the most recent patch notes this seems to be a game issue and nothing to do with Proton

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-1950729065

I'm also having a similar issue with my RX 7800 XT.

Edit: I also saw on ProtonDB that this is happening to a AMD Radeon RX 6700 XT User.

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2014315668

'%command% --use-d3d11' for launch options allowed me to play the game without issues

'MANGOHUD_CONFIG=fps_only=1 gamescope -W 3440 -H 1440 -F fsr -f --force-grab-cursor --mouse-sensitivity 3 -- mangohud %command% --use-d3d11' for use within Wayland, remove the mangohud bits if you don't want the FPS counter.

@wbehrens-on-gh @tillmzw I too couldn't connect to any friend or online lobby, on both steamdeck and another linux device (running nixos 23.11) until I disabled ipv6 for my network device.

Same here, I can only connect to other lobbys with IPV6 disabled.
That is true for Proton 8.05, Experimental, 9 Beta and Proton GE31

I first thought it might be because of Pihole, but it isn't.

Interestingly, the API of helldivers doesn't have an IPV6 Adress according to Cloudflare and google DNS. I had a look with nslookup

Been playing on a AMD 7840U handheld and have found that using gamescope to launch the game seems to (mostly) resolve the blank screen when launching in full screen mode.

My launch command is

gamescope -W 1280 -H 800 -f -- %command% --use-d3d11

After using gamescope I have seen 3 failed launches, however these where not a blank screen (the game crashed to desktop after the anti cheat pop up)

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2016768156

yeh gamescope doesn't seem to get nprotect working like normal proton does and I'm not 100% sure why. You could try making a bug report on the gamescope repo if you can pull logs for it

Replying to [#7486 (comment)](https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2016768156)

yeh gamescope doesn't seem to get nprotect working like normal proton does and I'm not 100% sure why. You could try making a bug report on the gamescope repo if you can pull logs for it

To be honest using gamescope has gotten the game to be about as stable as my windows setups (in windows the game also seems to just bail out every so often after the nprotect pop-up). And full screen has been working fine with gamescope.

But next time it crashes after the nprotect screen I'll get logs and raise a report.

I am on Debian 12, with an AMD 7800XT, i7 13700K, 128GB of RAM. I have tried various versions of Proton, various graphical settings, modified fan speed settings, and I keep getting a PC crash a few minutes into game that requires hard restart. Linux Kernel is 6.7

I am on Debian 12, with an AMD 7800XT, i7 13700K, 128GB of RAM. I have tried various versions of Proton, various graphical settings, modified fan speed settings, and I keep getting a PC crash a few minutes into game that requires hard restart. Linux Kernel is 6.7

if you aren't already doing so, add --use-d3d11 to your launch options. There is a known crash with Dx12 and AMD GPUs

https://arrowhead.zendesk.com/hc/en-us/articles/12573380356508-Known-issues

Critical problems for players using the AMD Radeon 7000 series of GPUs

The Problem: There are all sorts of significant problems players with these GPUs are experiencing, in total making the game nearly unplayable.

Why It Happens: We aren’t sure at the moment. We had tested with these GPUs previously and hadn’t encountered this in-house, but clearly there is something deep that is wrong.

Frequency: This is a constant issue for these users.

What We’ve Done / Are Doing: This one needs some investigation, and our team is looking at it in collaboration with AMD. Please watch this space: we will update when we have more details on this matter.

What Players Can Do: We need to better understand the problem. Thank you already to players who have sent in more details of their specs so that we can attempt to reproduce. Some AMD-using players have conveyed that they can play the game on the lowest performance settings. We know this is far from ideal, but it may be worth manually ratcheting down the performance in-game and via your GPU settings to see if that helps. Again, we will update here when we have more.

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2023366903

Thank you. From what I can tell, my default is Vulkan, so I am trying GE-Proton 9-2 first, and if that fails I can try DX.

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2023380330

--use-d3d11 does not change what the linux system sees, thats always vulkan. This option changes what version of the DX translation layer is used. Helldivers is a DX only game from what I can find so you cant run native vulkan, its either VKD3D (Dx12) or DXVK (Dx11) --use-d3d11 tells the game to run with Dx11 and it then uses DXVK

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2023380330

Understood, thank you. I will do that now.

For me the crashes seem to come in 3 flavors:

1. The Dx12-crash that happens quite fast after launching the game (circumvented by using --use-d3d11)
2. Generic HD2-crashes where the game just crashes to desktop out of the blue and asking to send bug-reports, but allowing you to interact afterwards. Pretty rare and not related to Proton afaik, happens on Windows too.
3. The 7000-series crashes (I have a Pulse 7900xtx) where you play for about 20 minutes and the driver craps the bed making everything freeze requiring a hard reset. I think I've solved that particular problem now by updating to the latest BIOS (have a x670E Steel Legend, was on version 1.20 now it's on 2.08). I noticed after the update that the fans in my box started revving a lot more when doing demanding stuff, so the cause of the crash is probably heat-related. Have had 4-5 play-sessions after that without a crash. Before it would unavoidably crash within ½ hour, and then behave ok after a reboot if I went straight into the game like it's something it has to get out of it's system.

As your nice concise summary is all problems that are being observed more widely, I'd like to add the other known and reproducible Linux bugs:

1. Starting the game in normal full-screen mode only works the first time and fails every time after that. Circumvented by using borderless windowed full-screen mode, which can be switched to in the config file if the game can't be started.
2. The borderless windowed full-screen mode has a thin (1px?) white border around the screen. If this really bothers you, it can be circumvented by starting the game in borderless, switching in-game to full-screen, then switching back to borderless before quitting. Apparently using gamescope also fixes this.
3. Limiting the framerate is often necessary to prevent crashes.
4. Some crashes result in the output signal from the GPU cutting out. The user session and apps like Discord continue working, and if I remember correctly the game continues (sound can be heard, you don't get disconnected from the current game etc.). I don't know whether these are also actually the "generic HD2 crashes" (i.e. the game being generally buggy on all platforms), or if it's again the amdgpu drivers, or what. I have an RX 570, so this is unrelated to the known problems with the 7000 series.
5. Changing graphics settings in-game (possibly all settings? I can't remember) and saving the configuration causes a massive drop in framerate (to around 5-6 fps for me), it's laggy, and most input is no longer registered, making the game unplayable until restarted.

And some other things that I'm pretty sure I remember being mentioned by other Linux users as well but can't find now, so maybe they're just me:

1. Going to a different ship causes a drop in framerate (40 -> 25-30) that persists until a mission is started, then it's fine again.
2. A weird one -- limiting the framerate (via the in-game option, not launch settings) to 40 fps works well for me and my GPU just about copes. When things are busy the framerate dips, often below 30, but it's tolerable. However, if I deliberately limit the framerate to 30 fps, the framerate drops permanently and is 15-20 in situations where I normally manage 40! Worse, there is significant input lag, making it unplayable.

Other reported things that seem to be game issues not Linux issues:

1. IPv6 prevents connecting.

I recently repurchased the game to try the IPv6 disabling fix. I was still unable to connect to other lobbies. I also tried changing my DNS to google's & cloudflare's, no joy.

If someone would be so kind, is this all that is needed to disable IPv6 on my network device?

1. Changing graphics settings in-game (possibly all settings? I can't remember) and saving the configuration causes a massive drop in framerate (to around 5-6 fps for me), it's laggy, and most input is no longer registered, making the game unplayable until restarted.

Same with mic settings and matchmaking visibility from friends to public.

Me and a friend are trying to play together, both on linux. We cannot join each others games and if one of us joins a windows player, then we both try and connect it kicks whoever connected first.

I've done a load of searching but cannot find any mentions of this issue.

Anybody know what could be causing the issue?

Has anyone managed to tackle the game not running when restarting in full scree mode?

@Emanem yes for me if I launch Helldivers with gamescope with correct resolution parameters, the black screen on boot no longer happens for me. I'm using an 7840U handheld

However I do see some other crashes on launch (basically the anti cheat pop up is shown, then nothing else) this is seen on my windows install as well.

@Emanem if you're using Xorg & not wayland. Another solution is to go into the user_settings.config after you've got your settings the way you want them exit the game.
Go into the user_settings.config under the prefix
$HOME/.steam/steam/steamapps/compatdata/553850/pfx/drive_c/users/steamuser/AppData/Roaming/Arrowhead/Helldivers2 (at least this is the location on Debian)
set fullscreen = false
Set the file to read-only. now every time you open the game it will start in fullscreen-windowed mode.

@Emanem if you're using Xorg & not wayland. Another solution is to go into the user_settings.config after you've got your settings the way you want them exit the game. Go into the user_settings.config under the prefix $HOME/.steam/steam/steamapps/compatdata/553850/pfx/drive_c/users/steamuser/AppData/Roaming/Arrowhead/Helldivers2 (at least this is the location on Debian) set fullscreen = false Set the file to read-only. now every time you open the game it will start in fullscreen-windowed mode.

Thanks, I'm using Xorg (Ubuntu 22.04 + HWE + Nvidia 4090). I have done something similar - i.e. a simple script in my home which overwrites the config when needed (I could overwrite the config at every restart though...).
Just to be clear, I want fullscreen to be true so that the game caps my GPU (via V-Sync on) and sets to my display refresh rate (75 Hz) - I guess I simply can't start it like that but have to change in the game menu at every restart.

is 75hz your native screen fps? The display fps should not change as long as you've edited the configuration in the game menu first including vsync, display res, graphics settings before exiting the game.
The method I've described above should make the game open every time with no script all you have to do to get into fullscreen is alt-enter on the keyboard and everything should be setup the way you left it before setting the file to read-only.
(At least on KDE alt-enter should transition you into fullscreen as long as the window is focused. I'm unsure if it's the same on gnome, if not look online for how to map buttons)
Hope this helps 🙂

is 75hz your native screen fps? The display fps should not change as long as you've edited the configuration in the game menu first including vsync, display res, graphics settings before exiting the game. The method I've described above should make the game open every time with no script all you have to do to get into fullscreen is alt-enter on the keyboard and everything should be setup the way you left it before setting the file to read-only. (At least on KDE alt-enter should transition you into fullscreen as long as the window is focused. I'm unsure if it's the same on gnome, if not look online for how to map buttons) Hope this helps 🙂

Yes - my screen is a 21:9@1440p - 75 Hz.
I didn't know there was a hotkey to switch to full screen (Alt+<enter>) - I could set the config as R/O as you suggest though and just use this, so even when it crashes it won't matter.

Don't know why, but sometimes when flying out of a mission, Helldivers crashes. It has occurred to me fairly frequently. Using DX11 fixes other crashes, but dk what is going on here. There is no app hang, does not require termination. The process just ends.

Crashing on Extraction is a known issue. It's not related to Linux/Proton.

It would seem that the poor performance and high CPU utilization was a game issue unrelated to Proton. After the last couple of patches to the game I've seen improved framerates. Has this been anyone else's experience?

It would seem that the poor performance and high CPU utilization was a game issue unrelated to Proton. After the last couple of patches to the game I've seen improved framerates. Has this been anyone else's experience?

Some of my experience has been better but there are still some situations where the game starts to bog down, but I'm not sure if that is something that would be fixed by running the game natively on windows or if it's just the nature of the engine.

I have been playing at 2560 × 1440p on ultra, and I don't experience being bogged down recently unless I am using Steam Remote play, though in the past I had noticed it once or twice even on lower settings. Killing and restarting processes seemed to remedy. For remote play not using enhanced 1080p and instead using 4k settings on client seems to improve some sluggishness, but I highly doubt that is a Proton issue.

I have been playing at 2560 × 1440p on ultra, and I don't experience being bogged down recently unless I am using Steam Remote play, though in the past I had noticed it once or twice even on lower settings. Killing and restarting processes seemed to remedy. For remote play not using enhanced 1080p and instead using 4k settings on client seems to improve some sluggishness, but I highly doubt that is a Proton issue.

Hi, not sure about this. Played a couple of sessions on 4090 (550.67), 5950x, 64 GiB of Ram.
I've captured the user time:

And system time:

As you can observe HD2 (main) spends a huge amount of CPU time in system calls, likely to the wineserver - and this is slowing down performance big time - at least for me, my GPU only gets used ~50-60% at 1440p 21:9 Ultra and doesn't hit my V-sync cap (75 Hz).

Gist to capture cpu user and system time here.

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2045851327

I something close on my 6800XT, I'll happily sit at 90-100fps on 1440p ultra settings (native render scale)

But the GPU only sits at 70-80% usage.

On the flip side I have tested 780M (7840U) and RX 5500XT, those both make full usage of GPU but at lower than 50fps

Replying to [#7486 (comment)](https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2045851327)

I something close on my 6800XT, I'll happily sit at 90-100fps on 1440p ultra settings (native render scale)

But the GPU only sits at 70-80% usage.

On the flip side I have tested 780M (7840U) and RX 5500XT, those both make full usage of GPU but at lower than 50fps

So you believe this is an Nvidia drivers issue? I'm also on Xorg, could be that?
Anyone else with Nvidia on Xorg has the same behaviour as me - such a high system time from main (i.e. the game itself)?

Replying to [#7486 (comment)](https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2045851327)

I something close on my 6800XT, I'll happily sit at 90-100fps on 1440p ultra settings (native render scale)
But the GPU only sits at 70-80% usage.
On the flip side I have tested 780M (7840U) and RX 5500XT, those both make full usage of GPU but at lower than 50fps

So you believe this is an Nvidia drivers issue? I'm also on Xorg, could be that? Anyone else with Nvidia on Xorg has the same behaviour as me - such a high system time from main (i.e. the game itself)?

I think it's either Proton or the game itself.

I am getting the same limited FPS on my 6800XT (70% GPU usage and wont push past 100fps) and I'm using Wayland

The slower GPUs probably max out on GPU rather than whatever bottleneck we are seeing above.

Wayland is problematic for remote play, so I use Xorg for gaming. Is framerate limited in helldiver settings? I have not measured with 7800XT, but I have enabled framerate limiting so maybe it is enabled?

Wayland is problematic for remote play, so I use Xorg for gaming. Is framerate limited in helldiver settings? I have not measured with 7800XT, but I have enabled framerate limiting so maybe it is enabled?

I'm running with both the frame rate limiting disabled and vsync off, there is definitely something else holding the faster cards back in my setup.

That being said, with the 6800XT the game runs as at a pretty constant 90-100 fps so I don't really notice any slowness (even tho the GPU isn't being fully utilised).

I guess in case of Nvidia cards this is even more pronounced. I tried dumping all the wineserver calls and I was getting loads of interleaved calls from different processes/threads (remember wineserver is single threaded in processing through pipes for every process/thread - and HD2 is heavily multi-threaded) and the main process/threads has loads of unimplemented async calls it seems...

Again could be wrong and all that system time is in Nvidia drivers but all these calls to wineserver may be a proper bottleneck.

This is a simple gist with some syscalls wineserver had to process and can't: https://gist.github.com/Emanem/89e8b4818f5995387232864da66ecf42 (especially around fsync Async thread) - hence I reckon it may fall back to a 'blocking' implementation, thus limiting the frame rate?

This is an example:

02d8: fsync: can't wait on object: Async thread=0x28bfac0
02d8: get_fsync_idx() = NOT_IMPLEMENTED { type=0, shm_idx=00000000 }

My fear is that this will fall back to vanilla sync and slow down the main process/threads.

Minor update - I still have the slowdowns and low performance on my 4090 - but as soon as disabled MangoHud the game seems to be crashing less often.

I'm seeing the issue where the game hangs on a black screen on startup others have reported. Happens consistently every time I launch the game since yesterday. The game was working fine before - not sure what changed. I've tried different version of proton (9.0-1, Hotfix, GE-Proton9-4, GE-Proton7-55), verifying files (one file fails and gets redownloaded), deleting my shader cache and reinstalling the game, but had no luck.

Here is my system information:

• GPU: AMD Radeon RX 7900 XTX
• Video driver version: Mesa 24.0.6
• Kernel version: 6.8.9
• Link to full system information report as Gist:
• Proton version: 9.0-1, GE-Proton9-4, GE-Proton7-55, Hotfix

And the log file. I've truncated it to 2000 lines, since the file is too big to upload here. The logs at the end just repeat over and over.

steam-553850.log

This issue has been reported now by quite a few people on different forums since an update a few days ago.

The game seems completely unplayable now. I have tried GE-Proton9-2, 8-13, 9-4, Standard Proton, Proton Exprimental.

I have tried using d3d11, skipping the intro via joining a non-existant lobby, game mode, non-game mode, disabling steam overlay, verifying files, disabling ESYNC and FSYNC. Nothing works. It is completely borked it seems.

is the anticheat kicking us for mangohud ?

is the anticheat kicking us for mangohud ?

I don't think so, as I can launch the newest build of the game with mangohud launch options. However this latest build does not show mangohud at all ..... It was working fine about 2-3days ago.

This issue has been reported now by quite a few people on different forums since an update a few days ago.

The game seems completely unplayable now. I have tried GE-Proton9-2, 8-13, 9-4, Standard Proton, Proton Exprimental.

I have tried using d3d11, skipping the intro via joining a non-existant lobby, game mode, non-game mode, disabling steam overlay, verifying files, disabling ESYNC and FSYNC. Nothing works. It is completely borked it seems.

I still seems to work as expected for me, bar mangohud not showing anymore

For what it's worth, the game is still working for me, only the mouse speed is very slow in the menu since recently.

Launch options used: MANGOHUD_CONFIG=fps_only=1 gamescope -W 3440 -H 1440 -F fsr -f --force-grab-cursor --mouse-sensitivity 3 --hdr-enabled --hdr-debug-force-output -- mangohud %command% --use-d3d11

Using Proton Experimental.

Steam system info: https://gist.githubusercontent.com/zaggynl/5afb5ef25f01b1fc2081f6bb6d37d883/raw/5cdddc085e27210f8b26de4da2e5be42780a5a4b/gistfile1.txt

For those where it's not working, can you post your Proton log and systeminfo?
More eyes may know and recognize what's going on.

I'm on a 7800XT gpu, game works for me only in dx12 mode now, if I try dx11 it crashes at launch. I can still use mangohud tweaks (so not an issue for anticheat).
MANGOHUD_CONFIG="fps_limit=90,no_display" mangohud %command%

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2094668746

I tried your exact launch options with my resolution without HDR and it wouldn't even launch.

Also tried forcing dx12 with -dx12 launch option (pulled from a forum post because steam's launch option page is out of date) which was no change.

System info:

https://gist.github.com/JustEnoughDucks/beb7045a13947e6e8fcee511fffb5c62

Here is the dump loop that fills my crash log file up to >1GB in 30 seconds:

https://gist.github.com/JustEnoughDucks/0af1a0c5316c044bf6493811011b1d82

Here is the log until the dump loop starts:

https://gist.github.com/JustEnoughDucks/07227dc8680d5de8d371cb6399a11b0e

I'm having the same problem. It starts, seems to get past GameGuard (the anti-cheat) then crashes. Worked about a week
ago when I last played. I have tried with a range of settings, and proton versions, and it has the same results regardless. These logs are when I was using PROTON_LOG=1 %command% --use-d3d11 and GE-Proton9-4 but I had the same result with the default proton, proton experimental, proton 8-5, and with launch options -valkan and no launch commands at all.
steam-553850.log
System info.txt
Helldivers 2 crash on start up (1).webm

@kisak-valve

• CPU: Ryzen 7 5700G
• GPU: Radeon RX 7900 GRE
• Kernel: 6.8.9
• Mesa: 24.0.5

I've noticed it crashes for me now too, when I boot an older kernel 6.8.4 with mesa 24.0.3 it plays fine. On the newer kernel it randomly crashes. I can get to the ship, but I can't play as it'll crash. It crashes for a couple tries and finally logs me out of the desktop and the only way to fix it is rebooting. My system cannot enable rebar as it's PCIe3 only. I haven't noticed any page fault protection errors in dmesg this time. Do you want proton logs from that configuration?

an you check if https://gitlab.freedesktop.org/drm/amd/-/issues/3343 is relevant to your system?

@kisak-valve Can confirm that enabling Above 4G Decoding and Resizable BAR as suggested in https://gitlab.freedesktop.org/drm/amd/-/issues/3343 does fix the issue for me. Looking into pacmans logs, I can see that the kernel was updated from 6.8.8 to 6.8.9 right before the issue started (can pin it down exactly to the reboot after the kernel update). @zaggynl (who doesn't have the issue) appears to be on 6.8.8, so that's matching up as well.

In case anyone else does want to give this a try: Boot in your UEFI and make sure you have Above 4G Decoding and Resizable BAR enabled in your PCIE/GPU settings. In my case I had to enable Above 4G Decoding for the Resizable BAR option to appear. AMD uses the name SAM (Smart Memory Access), so you might find it under this name instead of Resizable BAR in your UEFI.

I was wrong, PCIe3 systems can enable ReBAR. Enabling ReBAR and Above 4G Decoding fixes the issue for me too.

Is the stuttering/intermittent high frame time a known issue being worked on?

Hello @J05HM0N5TER, can you check if https://gitlab.freedesktop.org/drm/amd/-/issues/3343 is relevant to your system? A quick test would be to reboot into an older kernel and see how the game behaves.

I can confirm that enabling ReBAR and Above 4G Decoding in the BIOS resolves the problem for me as well.

Hello @J05HM0N5TER, can you check if https://gitlab.freedesktop.org/drm/amd/-/issues/3343 is relevant to your system? A quick test would be to reboot into an older kernel and see how the game behaves.

I have a B450i, Ryzen 3600X, and an RX 5700XT.

My system does not support resizable BAR though it does support above 4g decoding.

I can confirm that enabling only above 4g decoding and having resizable BAR not supported does not work.

Sadly I don't have the 6.8.8 cached still so it seems I am SoL.

@kisak-valve Using downgrade I was able to move to 6.8.8 (notably no dependency breakages), and can confirm that this bug is the issue. This issue also affects pre 6000 series dGPUs.

This issue also affects Counter-Strike 2. Downgrading to 6.8.8 fixes this also

EDIT: reinstalled the game and it sorted itself. Scan/repair wasn't enough. I am however crashing frequently when joining a friend's lobby, about once every 3 joins.

I'm having the same issue of black screen/crash after GameGuard (sometimes opens the FAQ page as well). My system has both above 4G and reBAR enabled already, and I've tried various kernels.

NixOS 24.05
Linux 6.8.8
Ryzen 5800X3D
NVIDIA 3080 Ti

I'm able to launch the game and play solo just fine. Multiplayer just does not seem to work at all. Don't know what to do, very sad :(

@LukeStonehm, i had the same problem, I enabled ipv6 support in the kernel and it helped.

I have a first-gen ryzen, so enabling rebar wasn't an option. However, the latest amd-staging-drm has fixed the crashing bugs, so anyone still dealing with this can use that (or wait until it's mainlined ig)

After ~30secs in the lobby, Xorg uses up 100% CPU and freezes until killed via SSH.

• Nvidia GTX 1060 6GB
• i7 6700k
• 32 GB RAM
• Ubuntu 22.04.4 LTS / i3wm

After ~30secs in the lobby, Xorg uses up 100% CPU and freezes until killed via SSH.

* Nvidia GTX 1060 6GB

* i7 6700k

* 32 GB RAM

* Ubuntu 22.04.4 LTS / i3wm

Can you share your Steam systeminfo and your Proton log?
systeminfo: Open Steam->Help->System Information, paste into https://gist.github.com/, create and share link here.
Proton log: Set game launch option to PROTON_LOG=1 %command%, upload ~/steam-553850.log and share here.

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2118688862

Well, I cant reproduce this issue anymore - I reinstalled the game, and now am unable to even get to the lobby.
Game freezes (without any noticable CPU/GPU usage) in one of the "first startup settings" menus (sometimes at data consent, sometimes at game settings)

• steam-553850.log
• system info

If playing with a gamepad, cardinal directions make this weird state where it's both walking and trying to run, and ends up doing neither, moving slowly.

Latest patch broke the game for me.

GameGuard loads initially (very slowly), launches to a black screen and then crashes with error 1015.
Everything ran without issues before the patch was applied.

Seems the latest update broke mic input on Linux, tried from two different input sources on two different devices, namely my laptop and my Steam Deck, and asked a friend to test it on their Linux machine, no dice. Kind of a bummer since the stuff patched in is amazing and I'm excited to get back to it, haha.

Seems the latest update broke mic input on Linux, tried from two different input sources on two different devices, namely my laptop and my Steam Deck, and asked a friend to test it on their Linux machine, no dice. Kind of a bummer since the stuff patched in is amazing and I'm excited to get back to it, haha.

Confirmed. Will try to test more and post again

It doesn't create the record device. The only seemly relevant section of the log file is:

189076.090:012c:02d8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\mmdevapi.dll" at 00006FFFF8740000: builtin
189076.095:012c:02d8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\winepulse.drv" at 00006FFFF8720000: builtin
189076.161:012c:02d8:fixme:pulse:pulse_channel_map_to_channel_mask Unhandled channel aux0
189076.161:012c:02d8:fixme:pulse:pulse_channel_map_to_channel_mask Unhandled channel aux1
189076.178:01b0:01cc:fixme:process:NtQueryInformationProcess (0xa4,info_class=61,0x110d5d8,0x00000001,(nil)) Unknown information class
189076.179:01b0:01cc:err:ntdll:NtQueryInformationToken Unhandled token information class 32
189076.185:012c:02d8:fixme:pulse:pulse_channel_map_to_channel_mask Unhandled channel aux0
189076.185:012c:02d8:fixme:pulse:pulse_channel_map_to_channel_mask Unhandled channel aux1
189076.193:01b0:01cc:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\dbghelp.dll" at 00006FFFFEEA0000: builtin
189076.193:01b0:01cc:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\imagehlp.dll" at 00006FFFFEF20000: builtin
189076.193:01b0:01cc:fixme:cryptasn:CryptDecodeObjectEx Unsupported decoder for lpszStructType 1.3.6.1.4.1.311.2.1.4
189076.193:01b0:01cc:fixme:cryptasn:CryptDecodeObjectEx Unsupported decoder for lpszStructType 1.3.6.1.4.1.311.2.1.4
189076.229:01b0:01cc:trace:seh:EnumProcessModulesEx (00000000000000A8, 0000000000725A50, 2048, 000000000110D5D0, 0)
189076.229:01b0:01cc:trace:seh:GetModuleFileNameExA (process=00000000000000A8, module=00006FFFFCAF0000, 000000000110E798, 260)
189076.231:01b0:01cc:trace:seh:GetModuleFileNameExA (process=00000000000000A8, module=00006FFFF9130000, 000000000110E798, 260)
189076.231:01b0:01cc:trace:seh:GetModuleFileNameExA (process=00000000000000A8, module=00006FFFFD340000, 000000000110E798, 260)
189076.232:01b0:01cc:trace:seh:GetModuleFileNameExA (process=00000000000000A8, module=00006FFFFEF80000, 000000000110E798, 260)
189076.234:012c:02d8:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\winealsa.drv" at 00006FFFF8700000: builtin
189076.236:012c:02d8:trace:loaddll:free_modref Unloaded module L"C:\\windows\\system32\\winealsa.drv" : builtin
[...]
189076.344:012c:02e4:warn:threadname:NtSetInformationThread Thread renamed to L"audio_client_main"
[...]
189076.362:012c:02e8:warn:threadname:NtSetInformationThread Thread renamed to L"audio_client_timer"
[...]
189079.463:012c:0318:fixme:combase:RoGetActivationFactory (L"Windows.Media.Devices.MediaDevice", {aa2d9a40-909f-4bba-bf8b-0c0d296f14f0}, 0000000169FD00A0): semi-stub
189079.463:012c:0130:fixme:nls:get_dummy_preferred_ui_language (0x8 0x409 000000000011B1FC 0000000000000000 000000000011B1F8) returning a dummy value (current locale)
189079.463:012c:0130:fixme:nls:get_dummy_preferred_ui_language (0x8 0x409 000000000011B1FC 0000000002253BC0 000000000011B1F8) returning a dummy value (current locale)
189079.464:012c:0320:warn:threadname:NtSetInformationThread Thread renamed to L"wine_threadpool_worker"
189079.464:012c:0318:trace:loaddll:build_module Loaded L"C:\\windows\\system32\\windows.media.devices.dll" at 00006FFFF8630000: builtin
189079.464:012c:0130:fixme:combase:RoGetActivationFactory (L"Windows.Internal.System.Profile.RegionPolicyEvaluator", {00000035-0000-0000-c000-000000000046}, 000000000011B4E0): semi-stub
189079.464:012c:0318:fixme:mmdevapi:media_device_statics_add_DefaultAudioCaptureDeviceChanged iface 00006FFFF86342A8, handler 0000000169FD00C8 token 0000000169FD00B0 stub!
189079.464:012c:0318:fixme:mmdevapi:media_device_statics_add_DefaultAudioRenderDeviceChanged iface 00006FFFF86342A8, handler 0000000169FD00C0 token 0000000169FD00B8 stub!
189079.464:012c:0318:fixme:combase:RoGetActivationFactory (L"Windows.Devices.Enumeration.DeviceAccessInformation", {574bd3d3-5f30-45cd-8a94-724fe5973084}, 0000000169D0FCA8): semi-stub
189079.464:012c:0130:err:combase:RoGetActivationFactory Failed to find library for L"Windows.Internal.System.Profile.RegionPolicyEvaluator"
[...]
189082.940:012c:0130:warn:vkd3d-proton:openvr_instance_extensions: Failed to wait for VR registry key ready.
189082.940:012c:0130:warn:vkd3d-proton:openxr_vulkan_extensions: Failed to get OpenXR extensions size from wineopenxr189082.941:012c:0130:warn:vkd3d-proton:openvr_device_extensions: Failed to wait for VR registry key ready.
189082.941:012c:0130:warn:vkd3d-proton:openxr_vulkan_extensions: Failed to get OpenXR extensions size from wineopenxrLoaded L"C:\\windows\\system32\\XAudio2_7.dll" at 00006FFFF83D0000: native

steam-553850.log

with the most recent game update, my social and options tabs are completely broken, I get either nothing rendering or "please wait democratically" plastered across my screen for the rest of the game session. Proton versions don't seem to make any difference

edit: these issues seem to be affecting windows users as well

On the topic of audio input not working. I tried switching the audio driver wine uses to ALSA directly, but no dice on that either. Just throwing that out there.

Voice chat should hopefully work again with the just updated Proton Experimental ([bleeding-edge] branch). To use that Proton Experimental should be selected as compatibility tool for Helldivers 2 and [bleeding-edge] branch should be selected in Proton Experimental tool properties in Betas tab.

That is supposed to work with Wine pulseaudio driver only. If pulseaudio is not configured on host or alsa driver explicitly selected that won't work, the necessary bits were implemented in winepulse driver only.

Is this change expected to fix this issue elsewhere too @gofman ? I noticed the same thing on Warframe.

I'm running on Linux Mint 21.3, Cinnamon 6.0.4, Kernel 6.5.0-41-generic, no proton, just --use-d3d11 on launch options.
I noticed my mic wasn't working and I think I fixed (more on that later) it. On Volume Control (pulse audio pavucontrol) - Recording I noticed there were two streams. Changing the source for the first stream seems to have fixed the problem.

I mean seems because now I see the sound icon when I speak on open mic, but I haven't asked others yet because since a few days ago, my Social tab doesn't work. I'm waiting democratically for days now and I can't see my friends. And I only play with my friends, so... I can't really test it for now.

Should that fix also work with pipewire? It's still broken for me with the bleeding edge.

Should that fix also work with pipewire? It's still broken for me with the bleeding edge.

It should, yes, with pulse over pipewire, if pipewire-pulse is configured and working. Could you please upload 'pactl list' output and compressed Proton log recorded with launch options PROTON_LOG=+mmdevapi,+pulse %command% launch options, I can take a quick look if anything stands out.

Should that fix also work with pipewire? It's still broken for me with the bleeding edge.

It should, yes, with pulse over pipewire, if pipewire-pulse is configured and working. Could you please upload 'pactl list' output and compressed Proton log recorded with launch options PROTON_LOG=+mmdevapi,+pulse %command% launch options, I can take a quick look if anything stands out.

I think I tried the wrong bleeding edge build. I had chose the bleeding-edge-8.0 before. It does work with "bleeding-edge".

With bleeding-edge and current proton-ge, I can no longer connect to any groups.

@kisak-valve

https://gist.github.com/OneOfOne/7df2a87191d8c8b468ab50f185b824ab

steam-553850.log.gz

this is still an issue as of today's git.

With bleeding-edge and current proton-ge, I can no longer connect to any groups.

@OneOfOne Are you still seeing this failure? We were not able to reproduce which makes it extremely hard to triage. If you are still getting the failure, could you give step-by-step instructions on exactly what type of group you are trying to connect to, how, etc?

As of today's proton_tkg_experimental.bleeding.edge.9.0.110282.20240802 it's still an issue, just trying to join any game gets stuck on "Establishing uplink", it eventually times out and says "couldn't connect to host".

Same with most recent GE.

@OneOfOne Could you get a log with "regular" experimental (not GE) with PROTON_LOG=+steam,+steamclient,+wininet,+winhttp,+winsock,+bcrypt,+secur32,+iphlpapi,+nsi %command%? I suspect you are having some local network issue :/

Microphone issue resurfaced with proton experimental

I tried but couldn't get helldivers 2 to crash, if anyone else is affected by it, I hope they can comment about it. For the time being, I'd ask the reporter to try using a stock kernel and see if the issue still happens.

Last night Nobara updated to 6.11.0-200.fsync.fc40.x86_64, it's the standard one included with the distro. A commenter on reddit provided this which solved the issue : https://github.com/Etaash-mathamsetty/wine-builds/releases/tag/heap-summary

I am using AMD Radeon 7800 XT, in the game the GPU utilisation is 100% but the clock is always around 2100 MHz, but I have overclocked it from 2430 to 2530 MHz, and other games are running at that higher frequency. I am suspecting that it is capped at the "Game Frequency" of 2124 MHz. Has anyone else experienced this?

Anyone able to use mouse outside the menu when using Moonlight/Sunshine for remote gaming?
In menu mouse works, outside it does not, if I exit the menu I have a split second of mouselook movement.
It seems to have broken before, got fixed and now may be broken again?

Related Steam discussion: https://steamcommunity.com/app/553850/discussions/1/7599331177367982219/

Edit:
This seems limited to not working on a secondary monitor, don't think it's a proton issue.

I know this is minor, but in Windowed Fullscreen, there are white 1px borders on the edges of the screen. I'm using PopOS 22.04. Anyone else having this?

Everyone, although on Nobara 40 full screen launches fine for me, except it
launches to the background and I have to alt tab in. I know full screen is
a broken option for many people.

On Tue, Nov 26, 2024, 10:02 Robotman_40 @.***> wrote:

I know this is minor, but in Windowed Fullscreen, there are white 1px
borders on the edges of the screen. I'm using PopOS 22.04. Anyone else
having this?

—
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2501450260,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AFJPHHE5UXOQSJL56TYIPHD2CSSSHAVCNFSM6AAAAABC7M7YQSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBRGQ2TAMRWGA
.
You are receiving this because you were mentioned.Message ID:
@.***>

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2501539504

The windowing issues for this game could certainly be fixed since the game has been out for awhile already.

Has anyone else had a case of the game causing kwin compositor to crash?

Also I noticed that the game doesn’t allow the gpu to go above 60-65 watts (95 watts max, rx 7600s). This even causes other games to run at that power limit after playing Helldivers 2.

Also I noticed that the game doesn’t allow the gpu to go above 60-65 watts (95 watts max, rx 7600s). This even causes other games to run at that power limit after playing Helldivers 2.

FYI, this has always been the case. I have a 4090 (+ Ryzen 9 5950x) and with any version of Proton/Wine I can't use it more than 60% around 40~50 FPS sometimes even if the framerate drops below my v-sync (75 Hz) or even when I remove v-sync cap.

My guess, knowing about the architecture of wine and other synchronization issues may be related to two factors:

• Proton/Wine rely on wineserver to for some API calls and this adds IPC
• The game may use Windows API WaitForMultipleObjects and until this will get implemented in the Linux kernel (and released), Proton/Wine will emulate this call, and we pay a penalty - i.e. engines using this API to synchronize will not be able to fully saturate the GPUs. The great news is that this has been worked on and should come soon - maybe 6.11!

Sounds interesting, though 6.11 is already released so I doubt that it will come to that version. But thank you for the info, hopefully it will resolve the issue.

Sounds interesting, though 6.11 is already released so I doubt that it will come to that version. But thank you for the info, hopefully it will resolve the issue.

I'm hoping once this multiple synchronization API gets embedded in the kernel that many games that depend on this will be able to fully leverage it and we'll be one step closer to fully harness the power of our hardware!

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2509772656

I don't want to sound like I'm basing Nvidia, but I heard DirectX 12 games under Nvidia often face performance penalties, so could that also be why?

The recent 01.002.001 update broke gamescope and is also causing some instability. The game window tends to lock up for me, but the interaction is still there.

Latest proton experimental crashes the game, wtf... to make things worse, ge-proton 9.21 now suffers the same fate
steam-553850.log

Anyone ever experienced this error?

~/.local/share/Steam/steamapps/common/Helldivers 2/bin/helldivers2.exe: 1: MZ����@��8���Y���0�N���: not found
~/.local/share/Steam/steamapps/common/Helldivers 2/bin/helldivers2.exe: 2: Syntax error: word unexpected (expecting ")")

The game played just fine a about a month and a half ago but now Steam fails to even launch the process. 🤔
To me, this reads as if the first line of the Windows EXE is being read as a hashbang line like from a script - but why would Steam launch the game this way?

Edit: Solved using Settings -> Compatibility -> Force the use of a Steam compatibility tool => ON -> Proton 9.0

Works fine with Fedora 41 and KDE, using proton GE 9.21. One trick I found is moving the mouse cursor after the anticheat popup shows up. Otherwise fullscreen is just black.

EDIT: Problem solved. It seems my Moonlander keyboard triggered the anticheat. If you have a similar problem, try to just use an old dumb keyboard.
The funny thing is, when the game was started, I can plug my moonlander back in and everything seems to work.

Since the new update Helldivers 2 is stuck on loading screen.

I tried

• Proton 9.04
• Proton Experimental

sadly it seems that even with PROTON_LOG=1 %command% no log file is written.

chdir "/home/xxx/01_Platte3/SteamLibrary/steamapps/common/Helldivers 2"
ERROR: ld.so: object '/home/xxx/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

ERROR: ld.so: object '/home/xxx/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/xxx/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/home/xxx/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/xxx/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
Game Recording - would start recording game 553850, but recording for this game is disabled
Adding process 7168 for gameID 553850
Adding process 7169 for gameID 553850
Adding process 7170 for gameID 553850
Adding process 7287 for gameID 553850
Adding process 7288 for gameID 553850
Adding process 7289 for gameID 553850
Adding process 7290 for gameID 553850
Adding process 7293 for gameID 553850
Adding process 7295 for gameID 553850
Adding process 7298 for gameID 553850
Adding process 7308 for gameID 553850
Adding process 7321 for gameID 553850
Adding process 7327 for gameID 553850
Adding process 7345 for gameID 553850
Adding process 7362 for gameID 553850
Adding process 7370 for gameID 553850
Adding process 7372 for gameID 553850
Adding process 7396 for gameID 553850
Adding process 7404 for gameID 553850
Adding process 7410 for gameID 553850
Adding process 7496 for gameID 553850
Adding process 7535 for gameID 553850
{       Game Recording - game stopped [gameid=553850]
Removing process 7535 for gameID 553850
Removing process 7496 for gameID 553850
Removing process 7410 for gameID 553850
Removing process 7404 for gameID 553850
Removing process 7396 for gameID 553850
Removing process 7372 for gameID 553850
Removing process 7370 for gameID 553850
Removing process 7362 for gameID 553850
Removing process 7345 for gameID 553850
Removing process 7327 for gameID 553850
Removing process 7321 for gameID 553850
Removing process 7308 for gameID 553850
Removing process 7298 for gameID 553850
Removing process 7295 for gameID 553850
Removing process 7293 for gameID 553850
Removing process 7290 for gameID 553850
Removing process 7289 for gameID 553850
Removing process 7288 for gameID 553850
Removing process 7287 for gameID 553850
Removing process 7170 for gameID 553850
Removing process 7169 for gameID 553850
Removing process 7168 for gameID 553850

steamsysteminfo.txt

Perhaps this info also helps:
Added .txt to the end, so it can be uploaded
user_settings.config.txt

EDIT:
@kisak-valve Was it possible to reproduce the error? In case you need more information, please let me know.

I picked up the game again after the update 01.002.001 dropped, but cannot join friends and nobody can join me.
The in-game error message is: Failed to join game lobby, Timed out.
I can see friends active in the social menu and the mission markers on the planet surface.
But I can neither see any public lobbies on planets nor can I join any via quick play.
This problem does not exist when using Windows 11 on the same machine and network.
Additionally the game doesn't close correctly anymore and has to be stopped via the stop button in steam.

I created a log as mentioned here, because it seems to be a similar issue:

@OneOfOne Could you get a log with "regular" experimental (not GE) with PROTON_LOG=+steam,+steamclient,+wininet,+winhttp,+winsock,+bcrypt,+secur32,+iphlpapi,+nsi %command%? I suspect you are having some local network issue :/

steam-553850.zip

Hello @gabriele2000, I have a hypothesis that VKD3D-Proton is crashing while enumerating you Intel GPU. As a test, can you temporarily disable 64 bit mesa/ANV with the VK_DRIVER_FILES environment variable or temporarily rename the 64 bit mesa/ANV icd file in /usr/share/vulkan/icd.d to something that doesn't end in .json (like intel_icd.x86_64.json.disabled).

There's a potential fix at HansKristian-Work/vkd3d-proton#2262.

I think I'll wait for the fix, but something is off: I'm using the command argument to open the game using the DX11 API.
VKD3D shouldn't even interfere, am I right?

From your last Proton log, it tells us you did have --use-d3d11 as an argument passed to the game. Regardless, I see info:vkd3d-proton:vkd3d_get_vk_version: vkd3d-proton - applicationVersion: 2.14.0. later in the log as the game starts up D3D12, and falls over shortly after with an access violation (c0000005) pointing towards d3d12core.dll (VKD3D-Proton). My understanding is that the crash would be when initially probing for what hardware's around, not what it chooses to render the game with.

Understood.

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2545852055

I found a workaround: Placing steam in a network namespace with the following script (based on https://gist.github.com/dpino/6c0dca1742093346461e11aa8f608a99):

#!/usr/bin/env bash

# source: https://gist.github.com/dpino/6c0dca1742093346461e11aa8f608a99

# set -x

if [[ $EUID -ne 0 ]]; then
    echo "You must be root to run this script (sudo -E ${BASH_SOURCE[0]})"
    exit 1
fi

# Returns all available interfaces, except "lo" and "veth*".
available_interfaces()
{
   local ret=()

   local ifaces=$(ip li sh | cut -d " " -f 2 | tr "\n" " ")
   read -a arr <<< "$ifaces"

   for each in "${arr[@]}"; do
      each=${each::-1}
      if [[ ${each} != "lo" && ${each} != veth* ]]; then
         ret+=( "$each" )
      fi
   done
   echo ${ret[@]}
}

IFACE="$1"
if [[ -z "$IFACE" ]]; then
   ifaces=($(available_interfaces))
   if [[ ${#ifaces[@]} -gt 0 ]]; then
      IFACE=${ifaces[0]}
      echo "Using interface $IFACE"
   else
      echo "Usage: ${BASH_SOURCE[0]} <IFACE>"
      exit 1
   fi
fi

NAMESPACE="steam"
VETH="veth_steam"
VPEER="vpeer_steam"
VETH_ADDR="10.0.0.1"
VPEER_ADDR="10.0.0.2"

trap cleanup EXIT

cleanup()
{
   ip li delete ${VETH} 2>/dev/null
   rm -rf /etc/netns/${NAMESPACE}
}

# add DNS
mkdir -p /etc/netns/${NAMESPACE}/
echo 'nameserver 8.8.8.8' > /etc/netns/${NAMESPACE}/resolv.conf

# Remove namespace if it exists.
ip netns del ${NAMESPACE} &>/dev/null

# Create namespace
ip netns add ${NAMESPACE}

# Create veth link.
ip link add ${VETH} type veth peer name ${VPEER}

# Add peer to NS.
ip link set ${VPEER} netns ${NAMESPACE}

# Setup IP address of ${VETH}.
ip addr add ${VETH_ADDR}/24 dev ${VETH}
ip link set ${VETH} up

# Setup IP ${VPEER}.
ip netns exec ${NAMESPACE} ip addr add ${VPEER_ADDR}/24 dev ${VPEER}
ip netns exec ${NAMESPACE} ip link set ${VPEER} up
ip netns exec ${NAMESPACE} ip link set lo up
ip netns exec ${NAMESPACE} ip route add default via ${VETH_ADDR}

# Enable IP-forwarding.
# echo 1 > /proc/sys/net/ipv4/ip_forward

# Flush forward rules.
# iptables -P FORWARD DROP
# iptables -F FORWARD

# Flush nat rules.
# iptables -t nat -F

# Enable masquerading
iptables -t nat -A POSTROUTING -s ${VPEER_ADDR}/24 -o ${IFACE} -j MASQUERADE

iptables -A FORWARD -i ${IFACE} -o ${VETH} -j ACCEPT
iptables -A FORWARD -o ${IFACE} -i ${VETH} -j ACCEPT

# Get into namespace
ip netns exec ${NAMESPACE} su -p ${SUDO_USER} -c "steam"

Running this script with sudo -E myscript.bash allows me to play the game with others AND fixes the shutdown problem.
I think my problem is related to all the network interfaces I have (ethernet, wifi, docker, tailscale and VM bridge).
But one of my earlier attempts at solving the issue was disabling all those, so I do not know why I need to move the game into a separate namespace to get it working.

Maybe this script will help others or lead to a fix for proton.

Replying to [#7486 (comment)](https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2545852055)

I found a workaround: Placing steam in a network namespace with the following script (based on https://gist.github.com/dpino/6c0dca1742093346461e11aa8f608a99):

I faced the same issue using GE-Proton versions. Using the "steam native ones" that issue disappeared.

I'm facing a crash to desktop after 1 to 5 minutes whenever I start playing on a planet (all fine in the ship).
I placed some Proton logs here: https://gist.github.com/divemorb/61bede39615c5f2224bcc993128c37ab

Inside the logs a missing file is reported to be missing, which indeed is not available (even after verify integrity of game files in Steam): Z:\home\martin\.local\share\Steam\steamapps\common\Helldivers 2\bin\crs-video.exe

I don't think, that's the cause for the crashes, because I can pass (and view) the intro. The crashes happen when no video should be played.

I also tried the following things:

• DRI_PRIME=1002:744c! -> to use my dGPU (not the integrated 7800X3D
• limit my FPS
• play with LACT to increase / lower my power target and frequencies
• tried all different kinds of Proton
• tried different Linux distributions (CachyOS, Nobara, Fedora native, ...)
• different file systems, ext4 and btrfs
• all kinds of different launch options in combination with different Proton versions (reference: protondb working configurations)
• different graphics settings
• adv_force_pstate_peak_gfx11_dgpu=false in /etc/environment
• wayland and x11

My system:

Distro:Nobara Linux 41 (KDE Plasma)
Kernel:6.12.8-201.fsync.fc41.x86_64
RAM:31 GB
GPU Driver:4.6 Mesa 24.3.3
GPU:AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 19.1.5, DRM 3.59, 6.12.8-201.fsync.fc41.x86_64)
CPU:AMD Ryzen 7 7800X3D 8-Core

I hope you can point me to a fix.

thank you

I'm facing a crash to desktop after 1 to 5 minutes whenever I start playing on a planet (all fine in the ship). I placed some Proton logs here: https://gist.github.com/divemorb/61bede39615c5f2224bcc993128c37ab

after a BIOS update and switching off Memory Context Restore and setting RAM to default 5200 MHz, the crashes seem to be gone.
Reference: https://www.reddit.com/r/Helldivers/comments/1b6w655/helldivers_2_constant_crashing_root_cause_fixes/?rdt=51963

I picked up the game again after the update 01.002.001 dropped, but cannot join friends and nobody can join me. The in-game error message is: Failed to join game lobby, Timed out. I can see friends active in the social menu and the mission markers on the planet surface. But I can neither see any public lobbies on planets nor can I join any via quick play. This problem does not exist when using Windows 11 on the same machine and network. Additionally the game doesn't close correctly anymore and has to be stopped via the stop button in steam.

I had the same problem using Flatpak (1.14.10) with (official) Proton 9.0-4 while having two network connections active (WiFi and wired ethernet). When I disconnected WiFi (i.e. only was connected via wire) and restarted HD2 I could again join games.

Thanks to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2569362254 for providing the hint that this is a network-related problem!

(Proton GE 9-22 for Flatpak always exhibits this problem, even with only a single network connection.)

Got the same issue as https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2359463646, I cannot start the game, crashes immediately:

GPU: Intel Arch A770
Video driver version: Mesa 24.3.3
Kernel version: 6.6.71
Proton version: Multiple: 9.0-4 / Experimental / Hotfix
Distro: Manjaro

steam-553850.log

Oddly enough I can actually play this game if I do not update my graphics driver. Works on self-compiled mesa 24.3.0_devel.192487.ec46d2a8f2e.d41d8cd-1, after an update to Manjaro's 24.3.3 I get the issue above.
I do not think this is an issue with graphics drivers tho, looks more like an over-aggressive anticheat, since the game crashes after an unimplemented call to KERNEL32.dll.HeapSummary. I'll experiment with this some more when I find the time since I can reliably reproduce this issue.

Edit: Seems the issue lies with Manjaro's mesa, if I self compile current mesa 25.0.0 I can play the game normally. Weird.

Cannot start the game, GameGuard reports an error code of 122.
According to Arrowhead support, this is the result of an authentication failure, but they provided no means of actually fixing it, as the provided solutions were all Windows-specific.

Distro: Arch Linux
Kernel: 6.13.1-arch1-1
CPU: AMD Ryzen 5 7600X
GPU: AMD Radeon RX 7700 XT
GPU Driver: Mesa 24.3.4-1
Proton Version: Multiple (Experimental, Hotfix, 9.0, 8.0, 7.0)
DE: KDE Plasma 6.2.5

steam-553850.log

Have tried the following so far: reinstalled the game, deleted compatdata/553850, removed all launch options, switched Proton versions, deleted the bin/GameGuard directory, uninstalled and reinstalled GameGuard (ran gguninst.exe and GGSetup.exe through Protontricks), moved Steam Linux Runtimes to same drive as the game, tried using the steam-native-runtime package instead of steam.

gist link @kisak-valve

I run Helldivers2 limited to 60fps, just to get the power consumption and therefore noise levels down. With my current settings this means my 7800xt runs at ~180W (monitored via MangoHud).
As soon as I start CoreCtrl my power consumption drops down to 120W with occasional spikes to 150W, while maintaining constant 60fps and constant frame-times.

I have no profiles defined in CoreCtrl, I just need to start it. And as soon as I stop it, power-consumption goes back up again.
Also I run a stock Fedora 41 with no extra kernel arguments like amdgpu.ppfeaturemask in place.

I wonder if somebody can reproduce this behaviour.

@soerengrunewald I believe what you're experiencing is radv overriding your RDNA3 GPU's performance_level. I experienced this issue as well. You can disable it by setting radv_force_pstate_peak_gfx11_dgpu=false as a game launch option or adding it to your /etc/environment. However, that may or may not lead to GPU driver hangs/timeouts. I mentioned this in ilya-zlobintsev/LACT/issues/452

@billy5155 thanks for the insides. It is indeed radv_force_pstate_peak_gfx11_dgpu. If I set it to false I see the same 60W drop in power-consumption. Also I don't see the GPU resets mentioned in the original [ mesa issues #10584](https://gitlab.freedesktop.org/mesa/mesa/-/issues/10584), at least for now. It also explains why I saw this behaviour only with Helldivers 2.

Something I noticed a few days ago after playing about with some settings, passing WINE_CPU_TOPOLOGY=8 helps a lot with performance in this game. In the ship I gained 40 ish fps (from 120 to 160, obviously not a reliable metric but still a huge gain for just a single setting), and in game, stutters are for the most part gone. Prior to this, the game would become almost unplayable with 500kg bombs going off (often dropping down to 5 fps).

Can anybody else confirm that this helps? (Protondb also shows one other person who has the same experience). I tried this on a ryzen 9 5950x, this could just be a bug with helldivers on higher core count cpu's, or a wine bug related to threading. taskset was tested prior to this, but did not result in any difference.

Can anybody else confirm that this helps?

Resolved the issue for me. Thanks for bringing it to light. For illustration, this is what the issue was like for me before the WINE_CPU_TOPOLOGY fix. Still minor frametime drops but usually only during load screens.

https://github.com/user-attachments/assets/d0a9a404-91de-453e-a5e5-4c0f3ca1f69b

• NixOS 25.05
• AMD Ryzen 9 7950X3D
• XFX Speedster MERC310 AMD Radeon RX 7900XTX

Does anyone have an issue where this game constantly uses 100% of GPU? And when in battle, fps drops to 20 or so.

GPU: RX 7700XT Pulse
Video driver version: Mesa 25.0
Kernel version: 6.14 rc7
Proton version: Proton Experimental / GE-Proton9.26 / Proton 9.0-4 (Changing proton version has no effect)
OS: Ubuntu 24.10

Does anyone have an issue where this game constantly uses 100% of GPU? And when in battle, fps drops to 20 or so.

GPU: RX 7700XT Pulse Video driver version: Mesa 25.0 Kernel version: 6.14 rc7 Proton version: Proton Experimental / GE-Proton9.26 / Proton 9.0-4 (Changing proton version has no effect) OS: Ubuntu 24.10

Yes, I can't damn play.
I'm using a GTX1050TI, on Launch I was getting 30FPS or so, now 15FPS or even 10FPS in action.

Recent update seems to trip nProtect GameGuard when running with gamescope on my system.

CPU: 9950x3D
GPU: RX 7900 XTX
Kernel: 6.14.2
Proton version: Experimental / GE 9.27
OS: Gentoo

Recent update seems to trip nProtect GameGuard when running with gamescope on my system.

Add --backend sdl to your launch options, seems to fix it for me:

LD_PRELOAD="" WINE_CPU_TOPOLOGY=8 gamescope -W 3440 -H 1440 -r 165 -f --backend sdl -- %command% --use-d3d11

Add --backend sdl to your launch options, seems to fix it for me:

LD_PRELOAD="" WINE_CPU_TOPOLOGY=8 gamescope -W 3440 -H 1440 -r 165 -f --backend sdl -- %command% --use-d3d11

Sadly this doesn't work for me, it doesn't even pop up the GameGuard splash screen. Looks like because I'm on wayland instead of x11.

With my 7900 XTX & 5800X I cannot play the game at all now. I've not played in a few months, but tried again today and it crashes every time trying to load a map during the drop sequence. I can load into my ship and join friends but i can't launch a map at all.

With my 7900 XTX & 5800X I cannot play the game at all now. I've not played in a few months, but tried again today and it crashes every time trying to load a map during the drop sequence. I can load into my ship and join friends but i can't launch a map at all.

Can you post your Proton log and system info from steam?
For Proton log, set helldivers 2 in steam launch options to: PROTON_LOG=1 %command%
Log file will be saved to ~/steam-553850.log

I have 7900xtx & 5800x3d and the game is working.

Can you post your Proton log and system info from steam? For Proton log, set helldivers 2 in steam launch options to: PROTON_LOG=1 %command% Log file will be saved to ~/steam-553850.log

I have 7900xtx & 5800x3d and the game is working.

I reinstalled the game whilst I was away, and came back today to get the log. Unsure what's happening but dropped on two separate planets and it seems to be working fine. Makes me wonder if it was something to do with the anti cheat issue I saw mentioned in the past (not steamplay specific, windows users had it too) where the fix was to either reinstall the game or reinstall specifically the anticheat.
I'll keep the logging on and attempt again in the next few days. I did not have my friend (also on linux, no issues) today so my setup was slightly different, and I'll report back if it crops up again.

Also out of curiosity, what framerate do you get? Feel like my XTX isn't performing as well as I expected, but @1440p I get 80-100fps on ultra with no upscaling.

@Turkeysteaks May be related to this?

@StelardActek What's the mesa version?
mesa 25.1 dropped a workaround for Helldivers 2 which force gpu to run at max clock speed.

Also try disable anti-aliasing and see if that help.

Edit 1: Disable Screen-Space Global Illumination too.
These two setting caused crash on amdgpu before, (even on windows machine.). And SSGI have minimum visual difference anyway.

@StelardActek What's the mesa version? mesa 25.1 dropped a workaround for Helldivers 2 which force gpu to run at max clock speed.

@Billli11 Oh my god, that might be it. Is there a way to disable it? The game was fine before mesa 25.1. I've also had issues with other games on this 7900 xtx before which I worked around by slightly underclocking it, but if mesa is forcing it then that might be the problem for me.

Both SSGI and AA were on, have turned them off and will test later, in the meantime.

@StelardActek I just remember disabling async compute to avoid crashing few mouth back. but it'll cost you gpu performance.

Edit 1: And (some how) cause encoding lag with obs using vaapi.

@Billli11 Aha, async compute! I remember turning that on recently, maybe that's the cause of my sudden problems. Thanks!

Edit: Turning off Async Compute seems to have fixed it, knock on wood. The others I left on without issue.

7900xtx. I am facing max usage of gpu. Does not matter what graphic settings are, on low or on ultra - always max frequency on gpu, only watt usage is changing. Does any one else has\had such issue? Is it possible to fix it?

Computer Information:
Manufacturer: Gigabyte Technology Co., Ltd.
Model: X870E AORUS PRO
Form Factor: Desktop
No Touch Input Detected
Processor Information:
CPU Vendor: AuthenticAMD
CPU Brand: AMD Ryzen 7 7700 8-Core Processor
CPU Family: 0x19
CPU Model: 0x61
CPU Stepping: 0x2
CPU Type: 0x0
Speed: 5392 MHz
16 logical processors
8 physical processors
Hyper-threading: Supported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Supported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
AVX2: Supported
AVX512F: Supported
AVX512PF: Unsupported
AVX512ER: Unsupported
AVX512CD: Supported
AVX512VNNI: Supported
SHA: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported
BMI1: Supported
BMI2: Supported
F16C: Supported
FMA: Supported
Operating System Version:
"Arch Linux" (64 bit)
Kernel Name: Linux
Kernel Version: 6.14.6-arch1-1
X Server Vendor: The X.Org Foundation
X Server Release: 12101016
X Window Manager: awesome
Steam Runtime Version: steam-runtime_1.0.20250307.120442
Client Information:
Version: 1745876290
Browser GPU Acceleration Status: Disabled
Browser Canvas: Unavailable
Browser Canvas out-of-process rasterization: Disabled
Browser Direct Rendering Display Compositor: Disabled
Browser Compositing: Disabled
Browser Multiple Raster Threads: Enabled
Browser OpenGL: Disabled
Browser Rasterization: Disabled
Browser Raw Draw: Disabled
Browser Skia Graphite: Disabled
Browser Video Decode: Disabled
Browser Video Encode: Disabled
Browser Vulkan: Disabled
Browser WebGL: Unavailable
Browser WebGL2: Unavailable
Browser WebGPU: Disabled
Browser WebNN: Disabled
Video Card:
Driver: AMD AMD Radeon RX 7900 XTX (radeonsi, navi31, LLVM 19.1.7, DRM 3.61, 6.14.6-arch1-1)
Driver Version: 4.6 (Compatibility Profile) Mesa 25.0.5-arch1.1
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 144 Hz
VendorID: 0x1002
DeviceID: 0x744c
Revision Not Detected
Number of Monitors: 4
Number of Logical Video Cards: 1
Primary Display Resolution: 3440 x 1440
Desktop Resolution: 9200 x 1440
Primary Display Size: 31.38" x 13.15" (34.02" diag), 79.7cm x 33.4cm (86.4cm diag)
Primary VRAM: 24576 MB
Sound card:
Audio device: ATI R6xx HDMI
Memory:
RAM: 31696 Mb

@Ekzilit It's is expected. There are workaround for GFX11(RX 7xxx) to avoid gpu hang.

The workaround will cause 100% gpu usage at all time.

And it will be removed in mesa 25.1

I've had no hanging issues with async computer on or off, at most async compute seems to introduce some random stutters. Maybe there are other factors? like graphics preset? mesa/kernel version, or any kernel parameters that'd affect default amdgpu behavior? I'd appreciate more information from those affected.

I'm currently on mesa git (25.2.0 41a18a27b00), linux 6.14.6, with a rx6600 and 5700X3D

@simifor That is GFX11(RX 7xxx) specific issue.
This is mesa issue when the game is out (before the workaround)

And This is commit that remove the workaround as mesa qa team cannot reproduce hang anymore

Edit 1: Seem like they are testing with preset only and async compute is off by default. May be why they can reproduce the issue?

@Billli11 just to make sure we're on the same page, after the removal of the workaround you're getting gpu hangs when async compute is on? If so, how often do you see this problem

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2898324323

Ok, I got the game to work with Proton 9.0 + no commandline options, but with reduced performance (~15-20 fps, instead of ~50-70)

I haven't been able to reproduce any GPU hangs so far with RX 7600 (same GPU I used to have hangs on before the workarounds). I tried both 25.1.0 and main, medium and high presets, all with async compute enabled. This was on 6.14.6-arch1-1 with Proton Experimental. It's possible it's not the original problem again, unless it takes longer to reproduce now for some reason.

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-2635750996

@r1input did you ever find a solution to this? Experiencing the same issue on my end. What were Arrowhead's proposed Windows fixes?

@bnerickson set kernel.yama.ptrace_scope to 1 in any sysctl conf files you might have, that seemed to be the root of the problem for me

@r1input thanks a million, that did the trick. I had it set to '2' for "increased security", but I guess that goes out the window to satisfy anti-cheat...

Hello @hkcowboy, are you able to test how the game behaves with a newer NVIDIA driver series? Your symptom reads like the NVIDIA 535 series is going to be too old to support going forward and DXVK currently has a note that it needs 550.xx or newer (https://github.com/doitsujin/dxvk/wiki/Driver-support)

Hi @kisak-valve , I wasn't able to get around to it. However, I switched to Proton 9 and few weeks ago the performance went back to what it was (30+ fps)

Compatibility Report

• Name of the game with compatibility issues: HELLDIVERS 2
• Steam AppID of the game: 553850

System Information

• GPU: Radeon RX 7900 XT (GPU the game is rendered on; the system also has an Intel iGPU)
• Video driver version: Mesa 25.1.5 (RADV)
• Kernel version: 6.15.4-tkg-eevdf-gentoo-llvm20-raptorlake
• Link to full system information report: Gist
• Proton version: 10.0-1f

I confirm:

• [x] that I have checked whether there are updates for my system available.

Proton Log: steam-553850.log.gz

Symptoms

The issue I'm having seems to stem from VKD3D-Proton errors after playing the game for an extended period of time, as far as I can tell.

At some point, the proton log spams these messages:

radv/amdgpu: The CS has been cancelled because the context is lost. This context is innocent.
47825.880:0140:02dc:err:vkd3d-proton:d3d12_command_queue_execute: Failed to submit queue(s), vr -4.
47825.880:0140:02e0:err:vkd3d-proton:vkd3d_wait_for_gpu_timeline_semaphore: Failed to wait for Vulkan timeline semaphore, vr -4.
47825.880:0140:02d8:err:vkd3d-proton:vkd3d_wait_for_gpu_timeline_semaphore: Failed to wait for Vulkan timeline semaphore, vr -4.
47825.880:0140:02dc:warn:vkd3d-proton:d3d12_device_mark_as_removed: Device 000000017b880080 is lost (reason 0x887a0005, "VK_ERROR_DEVICE_LOST").
47825.880:0140:02e0:warn:vkd3d-proton:d3d12_device_mark_as_removed: Device 000000017b880080 is lost (reason 0x887a0005, "VK_ERROR_DEVICE_LOST").
47825.880:0140:02d8:warn:vkd3d-proton:d3d12_device_mark_as_removed: Device 000000017b880080 is lost (reason 0x887a0005, "VK_ERROR_DEVICE_LOST").

Reproduction

1. Launch Steam
2. Install the game
3. Launch options I use: mangohud gamemoderun %command%
4. Launch the game
5. Play the game for a few hours(?) - Might not take that long, but not sure
6. Eventually, the game freezes entirely (not even audio in the background continues)

not sure if it's my setup but the white border is gone on borderless window on latest proton experimental, and the game window works as expected now (no running out cursor in-game, but can escape when the menu open) on multi monitors setup. Can anyone else confirm ?

EDIT 29/08/2025 HOTFIX : It's back, lol.

@froz3n Also fixed on my machine.

Hi,

Helldivers 2 stopped working on my Steam Deck today. I tried different Proton versions (current, experimental, hotfix), clearing the prefix directory. I also tried to run it in desktop mode. I verified game files, and installed it again. Nothing worked out. Game just exits after starting to launch.

When I add proton log game hangs with black screen and log just gets bigger and bigger. You can find attached log file.

steam-553850.zip

UPDATE: solution - deleting sharedcache folder, ~/.steam/steam/steamapps/shadercache/553850, fixed the issue

I have a issue where the cursor escapes on latest proton experimental or proton 10 when borderless is enabled, only happens after selecting a menu in the game like armory for example

Cachyos, Kernel 6.18.0, Mesa 25.3.1, KDE Plasma 6.5.3, RX 6700 10GB

My friend is on the same plasma version and doesnt have the problem, i also tried clearing the wine prefix and that didn't fix the issue either

Edit: nvm friend got the issue aswell lol

Screencast_20251209_230300.zip

Gonna report this to kde aswell

@pollux78 you could try setting this protontricks 553850 grabfullscreen=y which prevents the cursor from leaving the window in borderless mode. GE Proton used to ship that protonfix but removed it awhile ago.

Alternatively, with one of those custom proton runners you could try setting PROTON_ENABLE_WAYLAND=1 and/or PROTON_NO_WM_DECORATION=1. The latter is supposed to fix borderless fullscreen issues, mouse clicking through windows

@pollux78 you could try setting this protontricks 553850 grabfullscreen=y which prevents the cursor from leaving the window in borderless mode. GE Proton used to ship that protonfix but removed it awhile ago.

Alternatively, with one of those custom proton runners you could try setting PROTON_ENABLE_WAYLAND=1 and/or PROTON_NO_WM_DECORATION=1. The latter is supposed to fix borderless fullscreen issues, mouse clicking through windows

I will try later but this happens under wine Wayland aswell.

I have a weird framepacing issue, using MESA 25.3.3 and an AMD RX6650XT, with a Ryzen 7 5800X.

Hi, my game doesnt boot after the anticheat window. i tried many solutions. First trying to use dx11, then using different proton versions (Hotfix, sperimental, 10 ecc...) and at last trying to set fullscreen = false into the game config. but nothing seems to work.

here is the log of the game.

steam-553850.zip

And here some specs maybe they can me usefull

Hello, I've been dealing with the game failing to launch specifically on the new "slim" version of the game. The "legacy" non-slim version works fine. It seems to get past the anti-cheat and crashes when the game itself tries to launch. I've tried different proton versions, different graphics drivers, and different kernel versions, but the issue persists.

Proton log: steam-553850.log

System Information

• GPU: AMD Radeon RX 9070 XT (radeonsi, gfx1201, ACO, DRM 3.64, 6.18.6-2-cachyos)
• Video driver version: mesa-git 26.1.0_devel.217483.c5b70dcb48f-1
• Kernel version: 6.18.6-2-cachyos
• Link to full system information report as Gist: Report
• Proton version: Various

Try remove the entire game folder and verified the game.(Which will download the entire game again.)
Some unneeded files may failed to be remove when switching build.

@Billli11 I've already tried common workarounds such as complete reinstalls of the game, clearing out the prefix in compatdata, clearing shader & download cache for both dxvk/vkd3d and the one the game stores in the prefix, and trying to launch with and without --use-d3d11.

Hello @OnlyTegra, your Proton log points towards your video driver install. Please copy the contents of Steam Runtime Diagnostics from Steam (Steam -> Help -> Steam Runtime Diagnostics) and put it in a gist, then include a link to the gist in this issue report. In particular, we want to pay attention to the health of the Vulkan render paths.

@kisak-valve, thank you for your help here is the content of steam runtime diagnostics. Have a good day

https://gist.github.com/OnlyTegra/e0c311365b37e220d2ee131be8dde9f3#file-gistfile1-txt-L84-L97 and https://gist.github.com/OnlyTegra/e0c311365b37e220d2ee131be8dde9f3#file-gistfile1-txt-L370-L383 are the sections to focus on. This tells us your system has no usable Vulkan render path. Check if you have the vulkan-intel and lib32-vulkan-intel system packages, and install them if they're missing.

@kisak-valve thank you, now the game runs. Sadly there are some white artefacts. is there a way to fix that? i saw its a tipical problem in ARC Gpus

That reads like the issue reported at https://gitlab.freedesktop.org/mesa/mesa/-/issues/14580.

Thank you very much. Have a good day

@Kaderenn I have a 9060 XT and the game is launching fine on my end with the game's default branch (which already has slim files) with proton experimental, tried with linux 6.18.5 with mesa 25.3.3 and mesa git 09b92051174 and linux 6.18.6 with the same mesa git. All of them launched the game fine.

Your log is for proton GE, have you tried a clean prefix with proton experimental?

@simifor Yes, I've tried various official and unofficial Proton versions. They all fail the same way. For completeness sake, here's a log from a completely fresh reinstall of the game with no launch options other than PROTON_LOG=1, a blank /etc/environment, and a new prefix on Proton Hotfix.

steam-553850.log

The behavior I'm seeing has degraded as of the latest game update, the game now launches to a black screen where it gets stuck with high CPU usage on all branches. Some fresh logs attached below.

hd2 6.0.1 fresh prefix.log
hd2 6.0.1 legacy.log

@kisak-valve Yes, here's with Proton Experimental and a fresh prefix.
https://gist.github.com/Kaderenn/35281419e961b19b45f0976cd1362f8b

Proton 10.0-4 as well
https://gist.github.com/Kaderenn/65432705297d1c3ea959fc437061f3aa

Here's a fresh log on Proton Experimental with a fresh prefix on the newest version of the game.
https://gist.github.com/Kaderenn/94fc877ff859dfa7f76e00d1b06f2971
May be worth noting that Proton-GE and the CachyOS Proton versions now fail in a different way than the official versions do, failing to even create a window. Here's a log from one of those in case it may help indicate anything.
https://gist.github.com/Kaderenn/9643f318dc22c574c166ab7d06a5ddbf

@Kaderenn You’ll need to open an issue separately on cachyos and ges repos. Their custom patches may be causing those issues.

@Kaderenn have you tried using archlinux's kernel builds rather than cachyos? just to rule out any changes there causing issues. As no one else has reported similar it is likely something in your setup.

@simifor Yes, they fail in the same way. Here's a log.
https://gist.github.com/Kaderenn/94d73f8312b195d194073c6ee5b38fa4
I do agree that it's likely something with the setup but I have no clue what it could be at this point. I have a laptop set up very similarly that has no issues.

Whereas @JaredRichardWilliam experiences gitlab.freedesktop.org/drm/amd/-/issues/4964, with steamdb.info/depot/553851/history/?changeid=M:841529306937876003, I have encountered:

My Environment

Operating System: Fedora Linux 43
KDE Plasma Version: 6.5.5
KDE Frameworks Version: 6.22.0
Qt Version: 6.10.1
Kernel Version: 6.18.9-200.fc43.x86_64 (64-bit)
Graphics Platform: Wayland
Processors: 12 × AMD Ryzen 5 7600X 6-Core Processor
Memory: 32 GiB of RAM (30.4 GiB usable)
Graphics Processor 1: AMD Radeon RX 5700
Graphics Processor 2: AMD Ryzen 5 7600X 6-Core Processor
Manufacturer: ASRock
Product Name: X670E Taichi

I managed to resolve my issue by deleting and reinstalling the Steam Linux Runtime and clearing out the cache folder with installers for dotnet and etc in the common folder then verifying the game.

@mercifulboss, the screenshots that you cite in #issuecomment-1969554990 look a little like what I uploaded to gitlab.freedesktop.org/drm/amd/-/issues/3462, if of use.

Adding data on an active crash: KERNEL32.dll.HeapSummary is still an unimplemented stub in Proton Experimental 10.0-20260210 that aborts the process when called. System: RTX 5090, NVIDIA driver 590.48.01, Ubuntu 24.04, kernel 6.17.

Helldivers 2 calls HeapSummary under heap pressure during high enemy-count missions (Eradicate Terminid). The game runs fine for 60-75 minutes on other mission types, then crashes deterministically when heap pressure peaks. Relaunching into the same in-progress mission crashes within ~1 minute since enemy count is already at maximum.

Journal logs showing 4 consecutive crashes in one session:

Feb 25 22:54:17 wine: Call from 00006FFFFFC0D157 to unimplemented function KERNEL32.dll.HeapSummary, aborting
Feb 25 22:55:22 wine: Call from 00006FFFFFC0D157 to unimplemented function KERNEL32.dll.HeapSummary, aborting
Feb 25 22:56:54 wine: Call from 00006FFFFFC0D157 to unimplemented function KERNEL32.dll.HeapSummary, aborting
Feb 25 22:58:23 wine: Call from 00006FFFFFC0D157 to unimplemented function KERNEL32.dll.HeapSummary, aborting

This was previously reported in #8106 but closed without resolution. A minimal stub returning TRUE in kernelbase.dll resolves it. The proper implementation exists as Wine MR !8237 (https://gitlab.winehq.org/wine/wine/-/merge_requests/8237), pending since June 2025.

@MarcusSell Thank you for the link to the upstream implementation - this has been backported to experimental-10 and should be in experimental-bleeding-edge (you'll need to select this as a beta option in the Proton - Experimental tool properties). Hopefully this helps! :)

Thank you!

Marcus Sell

Compatibility Report

• Name of the game with compatibility issues: HELLDIVERS™ 2
• Steam AppID of the game: 553850

System Information

• GPU: AMD Radeon RX 9070 XT
• Video driver version: Mesa 26.0.1-arch1.1
• Kernel version: 6.19.6-zen1-1-zen
• Link to full system information report as Gist
• Proton version: Experimental/Proton 10.0-4

I confirm:

• [x] that I haven't found an existing compatibility report for this game.
• [x] that I have checked whether there are updates for my system available.

Symptoms

Some assets, mainly trees are invisible at range until player gets closer in which they start to fade in slowly, this is extremely noticeable on jungle-like and swamp biomes. the issue does not occur in Proton 9.0-4.

Reproduction

Play Helldivers 2 with Proton Experimental or Proton 10.0-4 in jungle-like biome, an example of this would be the planet URSICA XI in Borgus sector, Terminids faction.

steam-553850.log

@Tokkichu can you share a video with the issue as well as your graphic settings? I've been trying with a 9070, mesa 26.0.1, proton experimental and linux 6.16.9. One swamp biome map, and then two maps in URSICA XI, this with high graphics preset.

@simifor sure, I've also took screenshots showcasing the difference I get between Proton 9.0-4 and Proton Experimental.

here is a link for the video on youtube: https://www.youtube.com/watch?v=CtPatb89vEY
here are the screenshots with graphics & display settings: https://imgur.com/a/43J5X0P

the command used to launch the game is obs-gamecapture gamemoderun %command% on both Proton versions.

@Tokkichu something I noticed checking for this, is that newer proton versions (some?) flags don't render properly, have you noticed the same?

@simifor I do have the same issue but it seem to be game related as I do also get them in my Windows system with Nvidia card.

Update Report - March 2026 (AMD RDNA2 + CachyOS + Wayland)

System:

• GPU: AMD Radeon RX 6700 XT (RDNA2)
• CPU: AMD Ryzen 7 5700X3D
• Distro: CachyOS x86_64 | Kernel 6.19.9-1-cachyos
• DE: COSMIC 1.0.0 (Wayland)
• RAM: 32GB
• Proton: Proton Experimental
• DXVK: v2.7.1-505-g6f3a758f7982fc5

Status: Playable with tweaks

Working launch options:
RADV_PERFTEST=gpl,aco,nggc,sam PROTON_USE_WINED3D=0
WINE_FULLSCREEN_INTEGER_SCALING=0 DXVK_ASYNC=1 %command%

Performance:

• General gameplay: 100+ FPS stable at 1920x1080
• Heavy combat with many enemies: drops to 45-60 FPS
• Better than Windows on same hardware (40-80 FPS)
• No crashes during gameplay

Issues and workarounds:

1. Cursor not locked to window on Wayland with multiple monitors
   → Fixed with above launch options + Fullscreen (not windowed-fullscreen)
2. FPS instability during large enemy encounters (drops to ~45 FPS)
   → Possible shader compilation stutter, still investigating
3. Game icon shows as generic in COSMIC taskbar
   → Fixed by creating ~/.local/share/applications/steam_app_553850.desktop
   with StartupWMClass=steam_app_553850

before:

after:

1. Discord shows "crs-handler" instead of "Helldivers 2" as activity status
   → crs-handler is an internal Helldivers 2 process that Proton exposes
   and Discord detects it as the active game instead of the actual game
   → Fixed by manually adding Helldivers 2 in Discord:
   Settings → Activity Privacy → Add → search Helldivers 2

Log errors noted:

• Heap zero hack enabled on multiple processes
• Exception 0xc000008e on startup (recovers successfully)
• OpenXR Vulkan extensions unavailable (no VR, no impact)
• NtGdiDdDDIOpenAdapterFromHdc stub (no visible impact)

Crashing while ASync compute is enabled in settings

Helldivers consistently crashes when async compute is enabled. This setting is required for me as it significantly improves how smooth the game feels.

Things that I've tired

1. Protons 10/Experimental/GE
2. Enabling Wayland support in Proton GE
3. Verifying my game files and reinstalling.

Fastfetch results

Sudo Dmesg results

[ 6879.455148] amdgpu 0000:0d:00.0: amdgpu: Dumping IP State
[ 6879.456227] amdgpu 0000:0d:00.0: amdgpu: Dumping IP State Completed
[ 6879.456285] amdgpu 0000:0d:00.0: amdgpu: [drm] AMDGPU device coredump file has been created
[ 6879.456287] amdgpu 0000:0d:00.0: amdgpu: [drm] Check your /sys/class/drm/card1/device/devcoredump/data
[ 6879.456289] amdgpu 0000:0d:00.0: amdgpu: ring gfx_0.0.0 timeout, signaled seq=18451844, emitted seq=18451846
[ 6879.456292] amdgpu 0000:0d:00.0: amdgpu:  Process main pid 18040 thread vkd3d_queue pid 18183
[ 6879.456294] amdgpu 0000:0d:00.0: amdgpu: Starting gfx_0.0.0 ring reset
[ 6879.456341] [drm:gfx_v11_0_bad_op_irq [amdgpu]] *ERROR* Illegal opcode in command stream 
[ 6881.456361] amdgpu 0000:0d:00.0: amdgpu: MES failed to respond to msg=RESET
[ 6881.456367] amdgpu 0000:0d:00.0: amdgpu: failed to reset legacy queue
[ 6881.456370] amdgpu 0000:0d:00.0: amdgpu: reset via MES failed and try pipe reset -110
[ 6881.456372] amdgpu 0000:0d:00.0: amdgpu: The CPFW hasn't support pipe reset yet.
[ 6881.456374] amdgpu 0000:0d:00.0: amdgpu: Ring gfx_0.0.0 reset failed
[ 6881.456376] amdgpu 0000:0d:00.0: amdgpu: GPU reset begin!. Source:  1
[ 6883.662058] amdgpu 0000:0d:00.0: amdgpu: MES failed to respond to msg=REMOVE_QUEUE
[ 6883.662063] amdgpu 0000:0d:00.0: amdgpu: failed to unmap legacy queue
[ 6883.929513] [drm:gfx_v11_0_hw_fini [amdgpu]] *ERROR* failed to halt cp gfx
[ 6884.022093] amdgpu 0000:0d:00.0: amdgpu: MODE1 reset
[ 6884.022098] amdgpu 0000:0d:00.0: amdgpu: GPU mode1 reset
[ 6884.022166] amdgpu 0000:0d:00.0: amdgpu: GPU smu mode1 reset
[ 6884.527195] amdgpu 0000:0d:00.0: amdgpu: GPU reset succeeded, trying to resume
[ 6884.527314] [drm] PCIE GART of 512M enabled (table at 0x0000008000300000).
[ 6884.527365] amdgpu 0000:0d:00.0: amdgpu: VRAM is lost due to GPU reset!
[ 6884.527367] amdgpu 0000:0d:00.0: amdgpu: PSP is resuming...
[ 6884.604787] amdgpu 0000:0d:00.0: amdgpu: reserve 0xa700000 from 0x83e0000000 for PSP TMR
[ 6884.865970] amdgpu 0000:0d:00.0: amdgpu: RAP: optional rap ta ucode is not available
[ 6884.865974] amdgpu 0000:0d:00.0: amdgpu: SECUREDISPLAY: optional securedisplay ta ucode is not available
[ 6884.865978] amdgpu 0000:0d:00.0: amdgpu: SMU is resuming...
[ 6884.865982] amdgpu 0000:0d:00.0: amdgpu: smu driver if version = 0x0000003d, smu fw if version = 0x00000040, smu fw program = 0, smu fw version = 0x00505600 (80.86.0)
[ 6884.865986] amdgpu 0000:0d:00.0: amdgpu: SMU driver if version not matched
[ 6884.957737] amdgpu 0000:0d:00.0: amdgpu: SMU is resumed successfully!
[ 6884.968100] amdgpu 0000:0d:00.0: amdgpu: [drm] DMUB hardware initialized: version=0x07002F00
[ 6885.191413] amdgpu 0000:0d:00.0: amdgpu: ring gfx_0.0.0 uses VM inv eng 0 on hub 0
[ 6885.191418] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.0.0 uses VM inv eng 1 on hub 0
[ 6885.191421] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.1.0 uses VM inv eng 4 on hub 0
[ 6885.191422] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.2.0 uses VM inv eng 6 on hub 0
[ 6885.191424] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.3.0 uses VM inv eng 7 on hub 0
[ 6885.191426] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.0.1 uses VM inv eng 8 on hub 0
[ 6885.191428] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.1.1 uses VM inv eng 9 on hub 0
[ 6885.191429] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.2.1 uses VM inv eng 10 on hub 0
[ 6885.191432] amdgpu 0000:0d:00.0: amdgpu: ring comp_1.3.1 uses VM inv eng 11 on hub 0
[ 6885.191434] amdgpu 0000:0d:00.0: amdgpu: ring sdma0 uses VM inv eng 12 on hub 0
[ 6885.191435] amdgpu 0000:0d:00.0: amdgpu: ring sdma1 uses VM inv eng 13 on hub 0
[ 6885.191437] amdgpu 0000:0d:00.0: amdgpu: ring vcn_unified_0 uses VM inv eng 0 on hub 8
[ 6885.191439] amdgpu 0000:0d:00.0: amdgpu: ring vcn_unified_1 uses VM inv eng 1 on hub 8
[ 6885.191441] amdgpu 0000:0d:00.0: amdgpu: ring jpeg_dec uses VM inv eng 4 on hub 8
[ 6885.191443] amdgpu 0000:0d:00.0: amdgpu: ring mes_kiq_3.1.0 uses VM inv eng 14 on hub 0
[ 6885.193965] amdgpu 0000:0d:00.0: amdgpu: GPU reset(1) succeeded!
[ 6885.193996] amdgpu 0000:0d:00.0: amdgpu: [drm] *ERROR* Failed to initialize parser -125!
[ 6885.207357] amdgpu 0000:0d:00.0: [drm] device wedged, but recovered through reset

@Tokkichu lod issue should be fixed on proton experimental, can you confirm?

@PotatoAndSickle I haven't been able to repro on my card with mesa 26.1.0 git, proton experimental, ultra settings. How often do you get hangs? does it only happen in specific planets? Do you have any sort of overclock or undervolt going?

@simifor Seems to be fixed! I've been using Proton Experimental since it updated and no issues so far.

@Tokkichu do you have async compute enabled?

@PotatoAndSickle not normally, but I just played ~10 minutes with it enabled and I did not face any issues. I'm running the game using gamescope with GE-Proton10-34. my driver version is Mesa 26.0.3-arch1.1 and I also have ntsync enabled in my system.

I suggest updating the drivers to the latest version and also enabling ntsync in your system so GE-Proton can utilize it. if that did not help you should try using gamescope

@Tokkichu do you have async compute enabled?

It only happen for RDNA3 GPU

https://gitlab.freedesktop.org/mesa/mesa/-/work_items/13369

@Billli11 that seems to be what im experiencing what a shame. hope this gets fixed but i dont see any developer action on this yet.

@Billli11 that seems to be what im experiencing what a shame. hope this gets fixed but i dont see any developer action on this yet.

The engine is dead in development since half a decade and they are struggling with simple content patches. The likelihood of them fixing the broken DX12 implementation and support for RDNA3 are very scarce.

Maybe MESA devs can find some workaround, but there is some very heavy lifting on that maybe. You should definitely tone down your hopes that arrowhead will fix it tho.

Newest update is broken on Linux

https://www.reddit.com/r/linux_gaming/comments/1sxwfyk/psa_latest_helldivers_2_update_broke_the_game_on/

@Billli11 doesn't launch for me on Ubuntu 26.04/Proton 10.0-4. I just see the anti-cheat splash and then the process dies.

Doesn't work for me either on Ubuntu 26.04 with the latest proton experimental.

steam-553850.log

I just booted the game under Windows and apparently there's a "GPU Driver Outdated" message popping up.
I suppose it utilized some Windows API to show that pop up as such booting the game is interfered?

Same issue interrestingly together with the crash i also started seen a txt file beeing dropped in the game folder every time i try to start it called NxStorage_2026.04.28_17.34_helldivers2.txt with variation for date and time containing 17:34:27.590 > Unable to query trim descriptor on volume '\\?\Volume{00000000-0000-0000-0000-000000000053}'

@MNarath1 Probably not related to the crashing as It happen before the latest patch.

Also experiencing the crash after 6.2.2 patch, nprotect gameguard splash screen shows, black screen then the crash reporter window.

systeminfo: https://gist.github.com/zaggynl/8433c40593adc780d206839fbe80cd47
proton log: steam-553850.log

On Discord Baskinator sent a message saying:

We are aware of crashes for players using Linux and Steamdeck and we are investigating the cause. We will update you when we have more information on the issue.

This should hopefully work once again in the just updated Proton Experimental bleeding-edge beta branch (experimental-bleeding-edge-11.0-351515-20260428-pee99a7-w9012f3-dbcbc56-v228cc3_ (see https://github.com/ValveSoftware/Proton/wiki/Proton-Versions#proton-bleeding-edge). Or, well, at least, loads for me.

If it still crashes with this Proton version, default Proton log will be helpful. For one, it will show if the right Proton version is used.

UPDATE: If Steam is open, might need to restart Steam to pick the updated Proton Experimental [bleeding-edge] version at once.

Replying to https://github.com/ValveSoftware/Proton/issues/7486#issuecomment-4337159849

Confirming on the bleeding-edge version of Proton Experimental as installed by:
Right click, properties of Proton Experimental in Steam Library->Game Versions & Beta->select "bleeding-edge",
it starts, thanks!

Proton Hotfix and Proton Experimental(Bleeding-Edge) both froze when the SES starts to jump (the time the player clicks on the task).
My launch option is: PROTON_ENABLE_WAYLAND=1 gamemoderun mangohud %command% --useallavailablecores --use-d3d12
The performance on the ship is awesome but I cannot join any game due to this.
Further fix should be applied.

proton-cathyos-11.0-20260429-sir-x86_64 works for me. The freeze problem doesn't reappear till now.
My launch options is PROTON_VKD3D_HEAP=1 PROTON_USE_NTSYNC=1 DXVK_ASYNC=1 PROTON_ENABLE_WAYLAND=1 gamemoderun mangohud %command% --useallavailablecores --use-d3d12

@01Zanon01 Could you confirm if HELLDIVERS 2 is now working with the new Proton - Experimental release from today? There should no longer be anything special in Hotfix - everything should be in this experimental release :)

System: CachyOS Linux, Proton (proton-cachyos-slr build), Ryzen 9 9800X3D, RTX 4090, NVIDIA driver 610.43.02, kernel 7.1.1-2-cachyos

I went through 3 minidumps from 2 sessions, 10 days apart, instead of just the Proton log, and found the same fault signature every time:

• EXCEPTION_ACCESS_VIOLATION (0xC0000005), read access
• Faulting address is exactly 0xFFFFFFFFFFFFFFFF (-1) in all three dumps
• All three crash addresses resolve directly into the game's own modules. None of them touch a graphics, driver, or vkd3d-proton component:
  • helldivers2.exe+0x80B304 (main thread)
  • helldivers2.exe+0xAD752B (thread pool worker 09)
  • game.dll+0x106F1B0 (thread pool worker 03)

For me the process doesn't crash to desktop. It hangs and I have to force-kill it. Right when the hang starts, the crash reporter (crs-handler.exe, which is Crashpad-based) logs this:

[ERROR:crash_report_exception_handler.cc(117)] Process crash detected
[ERROR:file_io_win.cc(241)] SetFilePointerEx: Invalid handle. (6)

I can't say for sure that this file I/O failure is what's actually causing the hang instead of a clean crash. The timing just lines up.

Happy to attach the 3 minidumps plus a fresh PROTON_LOG=1 capture if that'd help.

@eliw00d first you need to check that it happens with upstream proton rather than forks, for example, proton experimental. Other details like your hardware, kernel, and driver version, how long it takes for these issue to happen, graphics settings, what were you doing ingame (whether you were in a mission, in what kind of planet if so, or if you were outside a mission), and of course it's always good to have proton logs.

@eliw00d first you need to check that it happens with upstream proton rather than forks, for example, proton experimental. Other details like your hardware, kernel, and driver version, how long it takes for these issue to happen, graphics settings, what were you doing ingame (whether you were in a mission, in what kind of planet if so, or if you were outside a mission), and of course it's always good to have proton logs.

Sounds good, will do!

> @01Zanon01 Could you confirm if HELLDIVERS 2 is now working with the new Proton - Experimental release from today? There should no longer be anything special in Hotfix - everything should be in this experimental release :)

I can confirm that after switching to the new Proton Experimental release from today, HELLDIVERS 2 now launches and works perfectly on my system without needing the Hotfix anymore.

Thank you for the fix!

My system specs for reference:

• OS: Nobara Linux
• CPU: Intel i5-14400F
• GPU: NVIDIA RTX 4060 Ti 16GB

I have a problem with HELLDIVERS 2 . I have tried launching it with both Proton Experimental (bleeding-edge) and Hotfix. The attached log is below.

My system's specs:

• OS: Arch Linux
• Kernel: 7.1.2-1-cachyos-bore-lto
• CPU: Intel Core i5-12400
• GPU: NVIDIA GeForce RTX 5050 8GB

steam-553850.log

Hi all! I hope I am posting this in the correct place.

The game consistently crashing on every blitz, evacuate high value assets, and eradicate mission on all enemy types. I select the mission, choose drop zone, and select loadout as per usual. I launch the mission only for it to crash as soon as my hellpod leaves the bottom of the ship.

Computer Specs:
OS - Linux Mint 22.2 Cinnamon
Cinnamon Version - 6.4.8
Linux Kernal - 6.17.0-35-generic
CPU - AMD Ryzen 7 9800X3D 8-Core Processor x 8
Memory - 32 GB
GPU - Radeon RX 9070 XT
Current Steam Launch Option - PROTON_LOG=1 gamemoderun %command%

I have had this issue for months and have reported it in the official discord twice. I have also opened a ticket with Arrowhead directly and they stated this was not their issue, but Protons. I have uninstalled the game several times, tried every version of proton available, and any sort of launch option with nothing to show for it. Please help me.

Log:

steam-553850.log

@PMKars complete 3 blitz missions in illuminate planets without any crashing without any extra parameters. rx 9070, ryzen 7800x3d, ultra preset, 2k, with and without async compute.

Are there any amdgpu errors in the kernel log after such a crash happens? you can check with sudo dmesg in your terminal, if yes, I'd first try to update linux kernel and amd driver version (mesa) as they are from last year.

@PMKars I had the exact same issue as you in a full AMD setup. Disabling the "async-compute" in the game settings solved the random crashes issue.

That is a consistent fix, wish you luck, please write here if it resolves your issue as-well. As far as I know it is an AMD specific issue and because we both have a full AMD setup this could be a valuable information for the other users in here. Your feedback is very valuable!

@simifor I tried launching blitz, evacuate high value assets, and eradicate missions once again. I tried around 3 times for each enemy type and I still crash every time. I followed your instructions on looking in the kernal log for anything AMD GPU related, but there was nothing. I have not tried to manually update my MESA drivers yet. My system is completely up to date from what the driver manager and update managers are saying though. Weird.

@Plarpoon I checked and I had already had async-compute disabled. I did try to run some of the missions we've talked about with async-compute on and they still crashed. I am completely stumped.

Is Helldivers 2 supposed to work on Proton 11 now?
As the latest Proton 11 release(Proton 11.0-1) says this: "Fixed a crash in HELLDIVERS 2 happening in high enemy-count missions." but it still crashes on launch?.
Thanks in advance.

@ShadowX117 I just tried to lauch Helldivers 2 on Proton 11.0 and it will not launch at all. It crashes before the game can even launch.

Hi folks - sorry for the confusion. That changelog was originally written before HELLDIVERS 2 updated and broke itself and needed yet another Proton fix. For now it is still only launching with Proton Experimental.

@DriftingSands Is async compute enabled?

Try disable it.

I have a new issue relating to the control center, all text is garbled and indistinguishable. Happens on the other tabs too.
Happens regardless of proton version it seems, tried 10.0.4, hotfix, experimental, GE. Troubleshooting support told me to make a report here as the issue seems to deal with proton and not the game itself.
My computer:
OS: EndeavourOS Linux x86_64
Host: B660M DS3H AX DDR4
Kernel: 7.1.4-arch1-1
Uptime: 8 hours, 28 mins
Packages: 1537 (pacman)
Shell: bash 5.3.15
Resolution: 1920x1080
DE: Plasma 6.7.3
WM: kwin
Theme: Breeze-Dark [GTK2], Breeze [GTK3]
Icons: breeze-dark [GTK2/3]
Terminal: konsole
CPU: 12th Gen Intel i5-12600KF (16) @ 4.900GHz
GPU: AMD ATI Radeon RX 7900 XT/7900 XTX/7900 GRE/7900M
Memory: 11854MiB / 64125MiB

@RichardSantos256 does that rendering issue appear the moment you open the game or does it take a while/are there any other conditions for it to happen? I'm not seeing it on my end. Can you share your display and graphics settings? Particularly resolution scale, dynamic scaling and variable rate shading

@simifor So this is gonna be a little akward. I restarted my computer and just can't seem to replicate the issue anymore. My resolution is 1920x1080p, no upscaling, happened regardless of TAA used, it always happened exclusively on the control center terminal with or without matches played, any time I accessed it the terminal was unreadable.
Used gamescope to try to see if it was a internal resolution issue but it kept happening. I went to cook my dinner and turned my computer off. I came back, restarted, and now its fine.
So uhh regarding this issue, ask folk if they have turned it off and on..
Sorry for bothering you guys.

White pixel border top and left of screen when in borderless window.

Been happening since release. Its a minor issue as fullscreen fixes it. However atleast in my case, my game is very unstable when alt tabbing causing crashing when in menu's

System Infomation
Runtime Infomation

@PotatoAndSickle You can work around it with gamescope or (depend on your desktop environment) start game in windows mode and make it full screen

• Gamescope

  gamescope -h <monitor horizontal resolution> -r <monitor refresh rate> -f -b -- %command%
  

• KDE

  • Right click title bar -> More Action -> Fullscreen

    

  • Custom shortcut

    

• Sway

  In config, set proton windows floating by default

  for_window [class="^steam_app_.*"] floating enable
  

  and set window size equal to output resolution.

@Billli11

i found a easier fix and just decided to use https://github.com/nanomatters/proton-cachyos

hopefully valve fixes it and adds full wayland support soon.