I will try master starting from now.

Today, the game crashed again when entering the world while using Experimental. I'll leave the log here in case it comes in handy for you. steam-2246340.log

Just gonna chime in here as a steam forum pointed me to try the dlls from this git... unfortunately doesn't work for me at this point.

I had been able to play the first 5 or 6 hours of the game with mesa fine under proton experimental bleeding edge. Then it started to crash at the same point every time, so I tried out amdvlk and that was able to get through that bit. After a while amdvlk would get super laggy, and also when I tried to start the game it was a 50/50 as to whether it would start or just crash my DE. So went back to mesa - was able to paly for another 8 hours or so, before getting to another point where its started to crash at the same point every time. Tried amdvlk again, no luck. Tried GE proton and experiment (bleeding edge) with the dlls from building this version (as per the user recommendation on steam discussions) ... no luck. Unfortunately I'm now locked out via denuvo's dumb anti tamper for 24 hours... I am wondering if the two hotfixes capcom released somehow made things worse lol

Anyways, thanks for working on this - just thought I'd share my experience in case anything is useful. When the game crashes it takes the whole DE with it and I have to log in again.

DE: Plasma 6.3.2 (X11)
OS: Arch
Kernel: 6.13.5-arch1-1
CPU: Ryzen 9800X3D
GPU: Radeon 6800XT
Driver: Mesa and amdvlk - both most recent versions
Proton versions: Experimental (bleeding edge) and GE 9.25 (both on their own and with the d3d12/d3d12core dlls from this repo)

Tried GE proton and experiment (bleeding edge) with the dlls from building this version

Proton Experimental Bleeding Edge automatically ships latest vkd3d-proton git like 30 minutes after a commit, there is no point in swapping in manually build dlls for this.

Tried GE proton and experiment (bleeding edge) with the dlls from building this version

Proton Experimental Bleeding Edge automatically ships latest vkd3d-proton git like 30 minutes after a commit, there is no point in swapping in manually build dlls for this.

Noted... that's what I get for listening to steam discussions lol. Thanks

Hi ! I also had crashes, especially inside of the forest (instant crash, trapped in crash loop). According to this post, I removed the /WineDetectionEnabled:False instruction (so, unfortunately, I don't have any Ray Tracing enabled anymore) and, indeed, the game is not crashing anymore. So... I suppose that we will have to wait the dxil-spirv issue to be solved

Hi ! I also had crashes, especially inside of the forest (instant crash, trapped in crash loop). According to this post, I removed the /WineDetectionEnabled:False instruction (so, unfortunately, I don't have any Ray Tracing enabled anymore) and, indeed, the game is not crashing anymore. So... I suppose that we will have to wait the dxil-spirv issue to be solved

i removed /WineDetectionEnabled:False , the rt option greyed out again, but is fixed on enabled and is woking. i think you can also edit the config.ini manually

Hi ! I also had crashes, especially inside of the forest (instant crash, trapped in crash loop). According to this post, I removed the /WineDetectionEnabled:False instruction (so, unfortunately, I don't have any Ray Tracing enabled anymore) and, indeed, the game is not crashing anymore. So... I suppose that we will have to wait the dxil-spirv issue to be solved

i removed /WineDetectionEnabled:False , the rt option greyed out again, but is fixed on enabled and is woking. i think you can also edit the config.ini manually

I am not sure that the RT is enabled, even if you find it greyed in "enabled" position inside of the game... I have compared between Linux and Windows, and the lighting does not seem to be the same

Just had two crashes in a row using latest commit, although I can only provide the log from the latest crash.

steam-2246340.log

@doitsujin

I played the entire game from beginning to HR50, had only 1 crash.

I feel maybe you guy's crash is to blame to Capcom for hardware support, not to vkd3d-proton.

And maybe don't ping people if you are not sure the problem.

I played the entire game from beginning to HR50, had only 1 crash.

I feel maybe you guy's crash is to blame to Capcom for hardware support, not to vkd3d-proton.

And maybe don't ping people if you are not sure the problem.

Did you enable Ray Tracing using /WineDetectionEnabled:False launch option ?

maybe don't ping people if you are not sure the problem.

Maybe "it works fine on my machine" isn't the best way to help find the issue.

Maybe speculating it's Capcom's fault is just that, speculation. I can't get logs from Monster Hunter, but I can get logs from vkd3d-proton with a couple of errors I'm running into so that's what I report.

Maybe I'm pinging because I'm testing master with the fixes for Radeon GPUs as they kindly suggested and found out crashes still happen, if the people I ping want me to stop pinging them, they can tell me that themselves and I won't ping them anymore.

[#2366](https://github.com/HansKristian-Work/vkd3d-proton/pull/2366) just merged and it should fix the GPU hangs.

can confirm this fixes the gpu hangs now all that's left is the vertex issues and stutters if that can be fixed.

[#2366](https://github.com/HansKristian-Work/vkd3d-proton/pull/2366) just merged and it should fix the GPU hangs.

I've also played quite a bit using latest commit including this fix and haven't had any crash.

[#2366](https://github.com/HansKristian-Work/vkd3d-proton/pull/2366) just merged and it should fix the GPU hangs.

I'd also like to confirm, played for a couple of hours and no crash.
Finally! Thanks!

Someone should report this on protondb - edit: nvm i just did...

[#2366](https://github.com/HansKristian-Work/vkd3d-proton/pull/2366) just merged and it should fix the GPU hangs.

I'd also like to confirm, played for a couple of hours and no crash. Finally! Thanks!

Someone should report this on protondb - edit: nvm i just did...

Excuse-me, it's the first time I want to use the very last proton version pushed into github... Is chosing "experimental" version on Steam enough or do I need to make another manipulation? Maybe chose the proton experimental app and enable "beta"?

Excuse-me, it's the first time I want to use the very last proton version pushed into github... Is chosing "experimental" version on Steam enough or do I need to make another manipulation? Maybe chose the proton experimental app and enable "beta"?

Yes, the easiest way is choosing the beta participation for Proton Experimental in Steam. To do this, locate Proton Experimental in your library, Right-Click it > Properties > Betas > In the "Beta Participation" option, choose "bleeding-edge - latest untested..."

Excuse-me, it's the first time I want to use the very last proton version pushed into github... Is chosing "experimental" version on Steam enough or do I need to make another manipulation? Maybe chose the proton experimental app and enable "beta"?

Yes, the easiest way is choosing the beta participation for Proton Experimental in Steam. To do this, locate Proton Experimental in your library, Right-Click it > Properties > Betas > In the "Beta Participation" option, choose "bleeding-edge - latest untested..."

Thank you very much! :)

I found "Proton Experimental" in my library, went "Properties", selected "Betas", then "bleeding edge". It updated. Then I selected "Monster Hunter Wilds" in my library, "Properties", "Compatibility", checked the "Use a specific version...", then "Proton Experimental".

Played for about an hour, experienced a couple vertex explosions and ended up freezing in the end (had to kill the process using Steam's "stop" button). What am I missing?

I found "Proton Experimental" in my library, went "Properties", selected "Betas", then "bleeding edge". It updated. Then I selected "Monster Hunter Wilds" in my library, "Properties", "Compatibility", checked the "Use a specific version...", then "Proton Experimental".

Played for about an hour, experienced a couple vertex explosions and ended up freezing in the end (had to kill the process using Steam's "stop" button). What am I missing?

It may be a freeze different than the GPU hang one (that could lead to your whole DE crashing).

Played for about an hour, experienced a couple vertex explosions and ended up freezing in the end (had to kill the process using Steam's "stop" button). What am I missing?

I think it would be advisable that you tried to reproduce this issue with "PROTON_LOG=1 %command%" in launch options and then uploaded the generated log (that should be generated in your home folder) to this thread for the devs to have something to work with (if it's a vkd3d-proton problem of course).

I think it would be advisable that you tried to reproduce this issue with "PROTON_LOG=1 %command%" in launch options and then uploaded the generated log

Here it goes, the log a couple seconds after a substantial (~20 seconds half-freeze):
steam-2246340_.log

In the meantime I noticed that as an in-game workaround it sometimes helps to quickly point the camera straight down once it starts stuttering/freezing: the game unloads a bunch of stuff when you can only see the ground, returns back to normal and at that point it's possible to return the camera to where it was with no freezing. This at least occasionally allows to save the game instead of force quitting. However, sometimes it completely freezes immediately, and then there's nothing I can do.

https://github.com/praydog/REFramework-nightly/releases modders fixed the stutter issues
Fixed major frame pacing issues (micro stuttering) in Monster Hunter Wilds caused by the anti-tamper
This is needed WINEDLLOVERRIDES="dinput8=n,b"

but i got a gpu hang today

Played around 6 hours with the latest commit, no crashes so far where before I had a ton of crashes. The only thing I should mention is that after a while (like 4 hours of gameplay), I started to enter in stutter hell, had to restart the game, and it was not VRAM related.

Maybe it's driver related.
RX 6900 XT, kernel 6.14.0-rc4-1-mainline, gpu driver Mesa 25.1.0-devel

Played around 6 hours with the latest commit, no crashes so far where before I had a ton of crashes. The only thing I should mention is that after a while (like 4 hours of gameplay), I started to enter in stutter hell, had to restart the game, and it was not VRAM related.

something similar happend to me, i did not restart the game and then the desktop environment crashed.
so its still possible for the entire OS to crash (only a restart leads to recovery), but it happens rarely and for another reason and after a long session (4+ hours).

I have a 714mb proton log file from the last crash, i will just paste the last few lines of it:

proton-log-tail.log

Ive actually now had more crashing with all the fixes for Wilds, previously I played without a single crash but both

https://github.com/HansKristian-Work/vkd3d-proton/commit/9645932a1302ea976a14a6e7f1610a63b413b4a8

and

https://github.com/HansKristian-Work/vkd3d-proton/commit/5480e2c1b1b51ce922befeb719679bbb4caf7f24

seem to cause me to freeze in multiplayer while previously i played 60hrs without so much as a hickup

System Info
CPU Vendor: AuthenticAMD
CPU Brand: AMD Ryzen 7 7735HS with Radeon Graphics
Driver: AMD AMD Radeon 680M (radeonsi, rembrandt, LLVM 19.1.7, DRM 3.61, 6.13.5-273-linux-tkg)
Driver Version: 4.6 (Compatibility Profile) Mesa 24.3.4 (git-769e51468b)
dGPU is a RX7700s which is actually the GPU running Wilds.

I always use Proton Experimental Bleeding Edge

Unfortunately Im locked out for 24hrs now so cant disable the changes to verify 100%

Unfortunately Im locked out for 24hrs now so cant disable the changes to verify 100%

I don't know about the multiplayer crashes, but I was banned for 24h yesterday as well by Denuvo (because it seems like when Proton gets updated Denuvo thinks you're login from another device and it bans you when you reach 5 different devices)

However, I reinstalled the game on Steam and it let me play normally.

However, I reinstalled the game on Steam and it let me play normally.

When I first downloaded the game around the release date, it kept freezing with 100% reproducibility on the initial language selection screen under linux (ran fine on windows). I tried verifying the content on steam, deleting the vk shader cache, changing proton versions (including experimental bleeding edge at the time). After trying a bunch of proton versions, Denuvo locked me out for 24 hours.

After 8 or so hours of waiting I got really impatient and out of desperation decided to re-download the game. To my shock, not only it ran without denuvo blocking it, it also didn't freeze on language selection. It does still freeze every now and then during gameplay though.

However, the takeaway 1 is that yes re-downloading might be a workaround for being locked out by denuvo. Takeaway 2 is that there's some sort of a state associated with the game that's not in its shader cache and that state seems to change when the game is re-downloaded. Note there's also a non-zero chance that something changed during those 8 hours of me waiting that I'm not aware of : either the game or proton could have updated in the meantime.

https://github.com/praydog/REFramework-nightly/releases modders fixed the stutter issues Fixed major frame pacing issues (micro stuttering) in Monster Hunter Wilds caused by the anti-tamper This is needed WINEDLLOVERRIDES="dinput8=n,b"

but i got a gpu hang today

Tested this. Nope, still freezes exactly the same way.

https://github.com/praydog/REFramework-nightly/releases modders fixed the stutter issues Fixed major frame pacing issues (micro stuttering) in Monster Hunter Wilds caused by the anti-tamper This is needed WINEDLLOVERRIDES="dinput8=n,b"
but i got a gpu hang today

Tested this. Nope, still freezes exactly the same way.

this was for stutters not gpu hangs

https://github.com/praydog/REFramework-nightly/releases modders fixed the stutter issues Fixed major frame pacing issues (micro stuttering) in Monster Hunter Wilds caused by the anti-tamper This is needed WINEDLLOVERRIDES="dinput8=n,b"
but i got a gpu hang today

Tested this. Nope, still freezes exactly the same way.

this was for stutters not gpu hangs

My gpu doesn't entirely freeze, only the game. I can alt+tab and the DE is fine. And stuttering in my case feels very related to the freezing: sometimes you get a stutter for 1/10th of a second, sometimes you get a stutter for 3 seconds and sometimes it just freezes for good.

as a follow up, running the game with VKD3D_CONFIG=skip_application_workarounds seems to resolve my crashing. Have played for 6hrs without so much as a single issue so at least for me the fixes that might help some others cause the game to stutter and crash

I managed to reproduce the stuttering in a way where it happens every frame consistently, and drops my fps to 1 without completely freezing, while the modding profiler was running:

Note how it says that it's waiting for the gpu for 1000ms+, which implies it's not a denuvo problem, but rather a gpu-related issue. The issue feels related to the way they stream assets, because I can see random geometry disappearing when the stuttering starts. Something related to transfer queue synchronization maybe?

VKD3D_CONFIG=skip_application_workarounds

Tried that, didn't change anything for me :|

Tried that, didn't change anything for me :|

Unless you didnt have issues to begin with it wasnt likely to as I played the game without issue prior to recent changes and the workarounds caused my system to have issues. That simply disables the workarounds, you had issues previously so disabling them wont help.

Some progress here: I no longer perma-freeze after switching to an open source nvidia kernel module. In NixOS the setting is hardware.nvidia.open=true. However, I still get very long occasional stutters (5 seconds easily) and worst of all vertex explosions seem to build up the longer I play, typically reaching levels where it becomes really hard to navigate. This is my palico after an hour of playtime:

Worst of all, some vertex explosions have really terrible fillrate that drops fps to below 1, but at least I can save the game now most of the time and I played about 5 hours after switching to the open source kernel module with no freezes so far.

Some progress here: I no longer perma-freeze after switching to an open source nvidia kernel module. In NixOS the setting is hardware.nvidia.open=true. However, I still get very long occasional stutters (5 seconds easily) and worst of all vertex explosions seem to build up the longer I play, typically reaching levels where it becomes really hard to navigate. This is my palico after an hour of playtime:

Worst of all, some vertex explosions have really terrible fillrate that drops fps to below 1, but at least I can save the game now most of the time and I played about 5 hours after switching to the open source kernel module with no freezes so far.

Pyroveil was meant to fix that but was never properly updated for the main game https://github.com/HansKristian-Work/pyroveil/issues/6 Report the vertex issues here

Apparently there's an option in the settings:

[Render]
AllowMeshShader=False

Some sources claim that it fixes the vertex explosions. It didn't for me.

report vertex issues here if you have nvidia https://forums.developer.nvidia.com/t/monster-hunter-wilds-vertex-explosions-and-performance-issues/327960/1

as of the latest game update the game hard freezes the display and crashes amdgpu. i have reported this to the mesa devs here: https://gitlab.freedesktop.org/mesa/mesa/-/issues/12941

heres the kernel log from the report https://pastebin.com/cwV9C9M0

edit: i have created a issue report here: https://github.com/HansKristian-Work/vkd3d-proton/issues/2430

After Title Update 1 today (in which they updated their Direct Storage version), game crashes on startup using Proton Experimental Bleeding Edge.

People say that manually rolling back Direct Storage solves this crash but I can't test this right now because I got a 24h ban by Denuvo due to me changing between Proton versions 5 times in a row, and unlike my previous 24h ban, re-installing the game doesn't seem to fix it :))))

Although I can provide the logs for the crash using the officially updated Direct Storage version:

steam-2246340.log

It is in fact an issue with direct storage, I knew that the issue was coming as its been known the direct storage update causes the game not to work so i backed up the old files before the update. The other issue recently made related to it mentions its a Dstorage issue

https://github.com/HansKristian-Work/vkd3d-proton/issues/2430

For the past couple months I've been running the game occasionally every now and then (proton-experimental[bleeding edge], NixOS, nvidia open driver module, 4090 laptop gpu) and it was working pretty well. Then the game updated, and I decided to jump off the bleeding edge proton and just unchecked the checkbox in "compatibility" settings to use just the current version of proton. The game rebuilt my shaders and vertex explosions came back.

Unfortunately, after switching back to proton-experimental[bleeding edge] I now have vertex explosions again. I don't know if the issue is caused by rebuilding the shaders, updating the game or somehow failing to switch proton version properly. Maybe it's because I now entered a new biome or something, but it's really strange that the problem was seemingly solved for months and now it came back.

Still no dice after the recent Title Update 2. Crashes within 5 min of gameplay.

Added the following kernel parameters, with amdgpu.dcdebugmask seeming to resolve the amdgpu errors reported in the journal: amdgpu.ppfeaturemask=0xf7fff amdgpu.abmlevel=0 amdgpu.runpm=0 amdgpu.dcdebugmask=0x12

Used LACT to ensure the card is operating within spec.

Using Proton-GE-10-5.

System Information.txt

steam-2246340.log

How is the game behaving for you all with current Proton Experimental? I haven't ran in to any issues after a short test (~45 mins) on my 7900 xtx

I havent had any issues in Wilds for many months on my previous AMD system nor on my current Nvidia system (only the direct storage but that was a blip actually). Ive been running bleeding edge exp since release and while the first week or 2 had some hickups its been pretty well solid for the past several months and the last 2 weeks of my new Nvidia system hasnt seen any issues of note

Still getting crashes about 10-15min into gameplay.

GE-Proton10-12:
journalctl.txt

steam-2246340.log

Proton experimental:
journalctl.txt

steam-2246340.log

I've been using overdrive to limit the maximum clock speeds of the GPU to ensure the card operates within spec. Besides modifying the fan curve, everything else is left at default.

I followed the Arch wiki to arrive at the amdgpu kernel parameter I'm currently using.

I am running EndeavourOS on the latest kernel with no other modifications. There are only a few titles that have been giving me issues, to varying degrees.

System:
  Kernel: 6.16.3-arch1-1 arch: x86_64 bits: 64 compiler: gcc v: 15.2.1
  Desktop: KDE Plasma v: 6.4.4 tk: Qt v: N/A wm: kwin_wayland dm: SDDM
    Distro: EndeavourOS base: Arch Linux

Baldur's Gate 3 and Roadcraft used to also crash quiet frequently, but BG3 has only crashed once in a few months now, and I can't recall when last Roadcraft did.

Running stress tests also does not crash the system.

I have disabled overdrive previously and still experienced crashes. Will disable and report back.

Does it happen anywhere in the game or is it somewhere in particular?

I didn't run into any issues last time I tested on RX 6800, which was with Mesa 25.1.5, 6.15.6-arch1-1, Proton Experimental and Proton GE 10-4, but I haven't gotten that far into the game and I'm wondering if that could be a factor.

I've been testing in the Oil Basin and Iceshard Cliffs. There doesn't seem to be anything in particular that causes the crash, but when they do occur the timing does appear to be relatively consistent.

Since there are quiet a few moving parts (mesa, proton, game updates, etc), it's difficult to track down what exactly helps or hinders. I've been able to play sessions where I don't crash for a few hours or not at all, but recently crashes seem to happen around the 10-15min marks.

I'll try testing in the earlier areas as well.

Crashed within 5min of gameplay in Windward Plains with overdrive disabled.

journalctl.txt

steam-2246340.log

Yeah, I'm also pretty stumped by this one 🫠 Not sure whether the Proton logs would prove more useful.

Aug 26 17:42:33 McTherodin kernel: amdgpu 0000:0b:00.0: amdgpu: psp reg (0x16063) wait timed out, mask: 80000000, read: 0 exp: 80000000
Aug 26 17:42:34 McTherodin kernel: amdgpu 0000:0b:00.0: amdgpu: psp reg (0x16063) wait timed out, mask: 80000000, read: 0 exp: 80000000

Whats going on with the platform security processor there? (usually thats what psp is)

Also i believe amdgpu.dcdebugmask=0x12 is for Panel Self Refresh which i highly doubt you have on a desktop. I also doubt amdgpu.abmlevel=0 does anything as you likely dont have adaptive backlight.

2 of those kernel parameters shouldnt even apply to your platform, amdgpu.runpm=0 might be relevant but did you add this all in because you found warnings or do you actually require `amdgpu.runpm=0'? Its entirely possible to merc your system chasing issues that arent there if all youre chasing is a clean journal.

EDIT: what other kernel cmdline, steam launch options, etc changes have you made? You shouldnt require basically any tweaking on an all AMD platform and most "gaming tweaks" youll find around are likely to cause issues more than anything. Post a more detailed journal as i see youre also using systemd-vconsole which isnt the default for arch based systems (is it for EOS? idr) which means things arent defaults.

possibly relevent kwin issue https://bugs.kde.org/show_bug.cgi?id=491751

due to seeing kwin_scene_opengl: Invalid framebuffer status: "GL_FRAMEBUFFER_INCOMPLETE_ATTACHMENT"

This thread here https://bbs.archlinux.org/viewtopic.php?id=287148

and here https://www.reddit.com/r/Fedora/comments/1ct0tke/amd_gpu_recovery_failed/

suggest it could be related to power delivery to the GPU, possible to confirm its not PSU or power cable related? If you use something like a Seasonic Focus Gold (popular budget PSU along with similar ones in its bracket have similar restrictions) and you use daisy chained cables you WILL have power delivery issues as the manual says you need to seperate ones for GPUs over 200w

Thanks for the response. The kernel parameters were suggested on the EndeavourOS forums as a possible solution to the crashes. Tried them once, but reverted to old settings after getting the same results.

I only have the amdgpu.ppfeaturemask=0xf7fff kernel cmdline. Overclocking is used to ensure the clock speeds remain within spec.

Steam options are just for logging and limiting framerate: DXVK_FRAME_RATE=60 mangohud PROTON_LOG=1 %command%

Been using EndeavourOS for a while now, so can't recall exactly what my options were. I tend to stick to defaults and encrypt my drive.

Only option I disabled in the bios was the resizable BAR. I'm on the latest non-beta bios firmware for my motherboard.

My power supply currently connects to the GPU via daisy-chain, but I've tried different cable configurations with the same results. The cables display no signs of damage, but will do individual cabling when I get a chance.

journalctl_full.txt

@tjvans those options are generally not for desktop systems on almost exclusively apply to laptops as it is exceedingly uncommon for monitors to have PSR or Adaptive Backlight support. You should have ReBar on for AMD GPUs Polaris and Newer (polaris maybe not?) not off as its almost universally detrimental to performance along with the fact you can disable it per game if a game doesnt like it.

Try just for giggles to see if amdgpu.ppfeaturemask=0xffffffff is more stable, generally it isnt but when i had an RX6800 that worked best for me vs any other option.

While your PSU and cable may not show signs of wear anything that doesnt explicitly state you can daisy chain 200w+ GPUs you should assume you cant reliably. I have encountered not only myself but others all around the overclocking, pc building, and general tech enthusiast scene that have run into issues with daisy chain and its always better to have 2 dedicated cables. My old seasonic Focus Gold 750w wouldnt do my RX6800 on a daisy chain stable and that is one of the best budget PSUs around. Generally daisy chain is for 180w and below (i.e 6600XT or less).

overall i dont believe any of your issues stem from VKD3D but are in fact system stability issues. I dont think we should cloud this here too much with troublshooting those issues.

EDIT: looking through that journal i dont see anything of partucular note bseides that it seems the EOS setup is starting to deviate farther from Arch default than i remember. The previous journals SMU issues point towards power possdibly, the kwin issues could be HDR or any number of driver related problems.

Though now that i think about it though, I do have a friend with a 6600xt that for a time had lockups in Wilds but hasnt mentioned it as of recently. Could it be RDNA2 specific? That would IMO point to a driver bug but Ill have to ask them if it still happens and they can get a journal to compare if it does

All good, appreciate the time people take to look into it. 🙏

Still crashing with separate power cables, but I'll keep it as is. 👌

journalctl_full.txt

steam-2246340.log

Think I'll just keep testing with each new update. If it ends up resolving itself, I'll report back.