Distro: Ubuntu 18.04
Kernel: 4.15.0-32-generic
GPU: GTX980
Driver: 396.51
CPU: AMD Ryzen 7 2700X
RAM: DDR4 3000MHz 16GB

Launches to black screen after initial install. And will aggressively toggle windowed and full screen if you try to alt-tab out.

setting ScreenMode=Borderless in the config file graphics_option.ini located in the root folder of the installation and the game will work fine (Except for it taking ~10 seconds for the first logo to appear after launching). Didn't do much except load into a existing character and run around for a bit, but didn't notice any issues.

Already clocked a few hours on wine-esync-3.13-x86-64 which had little to no issues.

JonasKnarbakk on 23 Aug 2018

Post from https://github.com/ValveSoftware/Proton/issues/199.
@LP0101 posted on 2018-08-23T01:01:40:

When exiting MH:W, the game closes completely, but the process doesn't quit, leaving your status as "in game" in steam.

~/.s/s/s/c/P/d/l/w/dxvk $ ps -aux | grep -i monster
luca     12753  0.0  0.1  63652 24812 tty2     S+   20:01   0:00 /bin/sh -c '/home/luca/.steam/steam/steamapps/common/Proton 3.7'/proton waitforexitandrun '/home/luca/.steam/steam/steamapps/common/Monster Hunter World/MonsterHunterWorld.exe'
luca     12754  0.0  0.1  91664 31920 tty2     S+   20:01   0:00 /usr/bin/python2.7 /home/luca/.steam/steam/steamapps/common/Proton 3.7/proton waitforexitandrun /home/luca/.steam/steam/steamapps/common/Monster Hunter World/MonsterHunterWorld.exe
luca     12832  153 17.2 7001288 2809540 tty2  Rl+  20:01  89:10 /home/luca/.steam/steam/steamapps/common/Monster Hunter World/MonsterHunterWorld.exe
luca     17022  0.0  0.0  21536  1112 pts/0    S+   20:59   0:00 grep --color=auto -i monster

The game does not quit until I manually kill PID 12832.

On Ubuntu 18.04

kisak-valve on 23 Aug 2018

👍6

I'm experiencing full system lockups on Proton. These completely lock me out of my computer, but audio still works. Can't even change TTY. Only way to recover is either a reboot, or to SSH in from a second PC and kill the Monster Hunter process.

This is not an issue until ~~you alt tab out of the game~~ the game loses focus. Once this happens even once, it will lock up eventually. Doesn't happen if the game never loses focus.

Also, Rumble is broken with Steam Controller. It sometimes get stuck on, and only turns off when pressing the Steam button. On an xbox pad, rumble doesn't work at all.

LP0101 on 23 Aug 2018

👍2

@LP0101 what's your hardware and software stack?

libcg on 23 Aug 2018

@libcg
Hardware:
i7 5820k
16 GB DDR4 RAM
GTX 1080

I'm on Ubuntu 18.04, 396.51.0 nvidia drivers, Kernel 4.15

LP0101 on 23 Aug 2018

I'm also getting freezes, using steam-runtime

$ uname -a
Linux lancelot 4.18.3-arch1-1-ARCH #1 SMP PREEMPT Sat Aug 18 09:22:54 UTC 2018 x86_64 GNU/Linux

nvidia 396.51

Contents of lshw is attached

drgnak on 23 Aug 2018

Also having freezing issues with nvidia.
manjaro
nvidia 1060 6gb
driver 396.51
ive tried different kernels as well and all of them freeze randomly.

roadh0use on 23 Aug 2018

Anyone tried with 396.54 drivers?

libcg on 23 Aug 2018

reporting back that running the 4.14.65 kernel now and it has seemingly fixed the freezing issue on nvidia.

roadh0use on 23 Aug 2018

I updated to 4.18.4 kernel and nvidia drivers 396.54. Not sure which is of these is the cause, but freezing it much more frequent now, game is practically unplayable. Will downgrade kernel and try again.

Edit: No luck downgrading kernel, looks like the issue is related to the 396.54 drivers

LP0101 on 24 Aug 2018

@LP0101 does enabling vsync help?

libcg on 24 Aug 2018

@libcg I didn't play enough to draw any concrete conclusions, but I think that worked. Vsync & capping FPS at 60 certainly made it more stable, I'll update if it ends up crashing at any point tonight.

LP0101 on 24 Aug 2018

@libcg I believe enabling vsync may have helped me as well. I've been able to get two hours of playtime without crashing so far. Will update if it ends up doing so.

EDIT: Spoke too soon; crashed shortly after I posted that.

drgnak on 24 Aug 2018

@drgnak still, 2 hours is an improvement. Before I turned on vsync, I wouldn't last more than 20 minutes (on 369.54)

LP0101 on 24 Aug 2018

Game won't launch for me on Ubuntu. Black screen for about 10 seconds then it closes. Worked perfectly fine on Manjaro. Attaching a log. Another user on Reddit with the same GPU series (R9 390) on the same driver stack had the same issue and solved it by switching from the radeon kernel driver to amdgpu. I've been on amdgpu the whole time so I'm stumped.

Ryzen 1700
AMD R9 390X 8GB
16GB RAM
Ubuntu 18.04.1 LTS

steam-582010.log

TyMiles2012 on 24 Aug 2018

Can't get the game running on Arch. Some sort of network error. It wants to take me to a link, but disappears before I can even read it. I only have a single NIC set up, so I have no idea what is going on.

CPU: i7-6700K
GPU: GTX 1080
Driver: 396.54-1
RAM: 32GB DDR4-2400
Distro: Arch
Kernel: 4.18.4-arch1-1-ARCH

lshw.txt

Eragon5779 on 24 Aug 2018

Also getting a network error, but the popup box is just black and crashes.

Hardware info, but the crash log is 60MB and difficult to upload anywhere (or even analyse).

xeals on 24 Aug 2018

Game worked flawlessly for me, out of the box. I get slight FPS drops (from 30 to 25), as compared to windows, where they're less frequent, but it's barely noticeable. Note that I play on the lowest possible settings due to my hardware, same as on Windows. Here's my system specs:

Distro: Antergos (Arch Linux)
Kernel: 4.18.3-arch1-1-ARCH
GPU: Nvidia GTX 860M
Driver: nvidia 396.51-5
CPU: i7-4710HQ
RAM: 16GB 1333Mhz

A minor issue, is that using KDE, I cannot easily minimize the game from fullscreen mode. Attempting to do so causes system freezes for a short while. Similar to what @JonasKnarbakk mentioned, but definitely not getting a full system when focus is lost in my case (as @LP0101 reported).

setzer22 on 24 Aug 2018

Distro: Ubuntu 18.04
Kernel: 4.15.0-32-generic
GPU: GTX980
Driver: 396.51
CPU: AMD Ryzen 7 2700X
RAM: DDR4 3000MHz 16GB

Launches to black screen after initial install. And will aggressively toggle windowed and full screen if you try to alt-tab out.

setting ScreenMode=Borderless in the config file graphics_option.ini located in the root folder of the installation and the game will work fine (Except for it taking ~10 seconds for the first logo to appear after launching). Didn't do much except load into a existing character and run around for a bit, but didn't notice any issues.

Already clocked a few hours on wine-esync-3.13-x86-64 which had little to no issues

I had a similar experience with needing borderless mode to get it working properly

Distro: Arch 4.18.4
GPU: GTX970
Driver: 396.54
CPU: i7 3770k
RAM: DDR3 16GB

Controller support working, no issues playing game or with performance after the change to borderless

Skylead on 24 Aug 2018

you should really try the .54 drivers which fixes resource leaks.

cjwijtmans on 24 Aug 2018

On attempting to load the game, I run into E_FAIL: IDX11Device->CreateShaderResourceView(pres->getHandle(), &srvDesc, &mpView) and a black screen

Nvidia 396.54-1.fc28.x86_64
Proton 3.7

About half the time afterwards, it will exit, otherwise the process will linger until kill -9'd

Xaenalt on 24 Aug 2018

👍2

Anyone running this on Vega 64? How's the performance?

LP0101 on 25 Aug 2018

I was able to fix the crash on first boot by messing with the graphics_setting.ini file. I set most of the variables to low and it finally loaded. I'll try to bisect which setting caused it

Xaenalt on 25 Aug 2018

Found it, setting VolumeRenderingQuality to Highest was the culprit, I can set the other settings as high as possible with no E_FAIL. Setting VolumeRenderingQuality to anything under Highest worked for me

Xaenalt on 25 Aug 2018

👍2

@Xaenalt can you test if the error happens with Nvidia 396.51.02 (i.e. the Vulkan beta)? There's a known issue with the stable Nvidia driver failing to create buffer views in some cases, which might cause this issue.

doitsujin on 25 Aug 2018

The game is on a black screen when you run it, for a but. But once you get ingame it plays the same as on Windows for me. I did a few quests Online and it went without problems.

My Specs:
omputer Information:
Manufacturer: Unknown
Model: Unknown
Form Factor: Desktop
No Touch Input Detected

Processor Information:
CPU Vendor: AuthenticAMD
CPU Brand: AMD FX(tm)-8350 Eight-Core Processor
CPU Family: 0x15
CPU Model: 0x2
CPU Stepping: 0x0
CPU Type: 0x0
Speed: 4000 Mhz
8 logical processors
8 physical processors
HyperThreading: Unsupported
FCMOV: Supported
SSE2: Supported
SSE3: Supported
SSSE3: Supported
SSE4a: Supported
SSE41: Supported
SSE42: Supported
AES: Supported
AVX: Supported
CMPXCHG16B: Supported
LAHF/SAHF: Supported
PrefetchW: Unsupported

Operating System Version:
Linux Mint 19 Tara (64 bit)
Kernel Name: Linux
Kernel Version: 4.15.0-33-generic
X Server Vendor: The X.Org Foundation
X Server Release: 11906000
X Window Manager: Mutter (Muffin)
Steam Runtime Version: steam-runtime-beta-release_2018-06-14

Video Card:
Driver: NVIDIA Corporation GeForce GTX 1050 Ti/PCIe/SSE2
Driver Version: 4.6.0 NVIDIA 396.54
OpenGL Version: 4.6
Desktop Color Depth: 24 bits per pixel
Monitor Refresh Rate: 60 Hz
VendorID: 0x10de
DeviceID: 0x1c82
Revision Not Detected
Number of Monitors: 1
Number of Logical Video Cards: 1
Primary Display Resolution: 1920 x 1080
Desktop Resolution: 1920 x 1080
Primary Display Size: 20.08" x 11.42" (23.07" diag)
51.0cm x 29.0cm (58.6cm diag)
Primary Bus: PCI Express 16x
Primary VRAM: 4096 MB
Supported MSAA Modes: 2x 4x 8x 16x

Sound card:
Audio device: Realtek ALC889

Memory:
RAM: 7994 Mb

Miscellaneous:
UI Language: English
LANG: sk_SK.UTF-8
Total Hard Disk Space Available: 505611 Mb
Largest Free Hard Disk Block: 191015 Mb
VR Headset: None detected

Recent Failure Reports:

only minor issue could be alt+tab dosnt work.

Zero86Sk on 25 Aug 2018

When attempting to use a third party xbox controller, I did encounter a fair number of issues. It seems the mapping in config.ini starts at 0, whereas the input mappings from xboxdrv start at 1. This resulted in some very odd gameplay for a bit until I changed it

Controller:        Rock Candy Gamepad Wired Controller
Vendor/Product:    0e6f:011f
USB Path:          001:009
Controller Type:   Xbox360

I was able to get the triggers set up finally:
xboxdrv --silent --trigger-as-button --detach-kernel-driver

[JOYPAD]
A=0
B=1
X=2
Y=3
LEFT=POV
RIGHT=POV
UP=POV
DOWN=POV
START=9
BACK=8
LT=6
LB=4
RT=7
RB=5
LSTICK_PUSH=11
LSTICK_VERT=Y
LSTICK_HORZ=X
RSTICK_PUSH=12
RSTICK_VERT=RX
RSTICK_HORZ=Z

Xaenalt on 25 Aug 2018

Game working smoothly for me, Performance not as great as with Windows (might be that i did not notice it in Windows due to GSYNC), but very playable.

However, after beating Xeno, the Save Game Corruption happens and I can't load this save file anymore, due to missing Codecs so the cinematic can't be played and the game crashes to Desktop.

Xatulu on 25 Aug 2018

@doitsujin You wouldn't happen to have an rpm repo that contains it handy would you? If not, let me see what I can do. if nothing else, I'll update when that driver makes it mainstream

Also, can confirm that alt-tabbing out of the game does cause a crash and/or host lockup at some points. Think that one's Nvidia-related too?

Xaenalt on 27 Aug 2018

It worked for me with the latest Nvidia drivers and Linux kernel, I spent yesterday's afternoon playing without much issue.
Hardware includes an AMD Ryzen 7 2700X paired with an NVIDIA 1700 Ti, on Ubuntu Budgie 18.04.
On the software side, apart from the prerequisites of using latest drivers (396 on Nvidia) and kernel (4.18.5), I activated the beta version of Proton (3.7.4).

Note that the game did work with outdated kernel and drivers on the main Proton version (3.7), but the Xinput issues outlined below prevented me from playing, and there were some graphic artifacts in the main menu, so this should be discouraged.

Issues:

Performance loss (expected because of the DirectX-Vulkan translation, not an issue with the shown hardware with some conservative graphics options)
V-Sync issues (lower performance with it activated, pronounced screen tearing with it disabled. Graphical issues mostly, not that noticeable after a while)
Small freezes/hiccups (not common, but they are there; might be a game issue though. I had only 2 or 3 in the entire play session of roughly 4 hours)
Xinput issues
- Initially, could not play the game because something was sending random direction inputs, rendering menu navigation impossible.
- Don't know what solved this, but keeping the latest driver/kernel update and after an OS update/restart, the issue disappeared.
- Could be related to the Steam Controller? Though I could play perfectly with the controller afterwards.
Complete game freeze after long playing sessions. Maybe once every hour and a half or so, I had this happen twice.
- The OS itself worked fine, so I could just kill the game with "kill -9". Still, this can be a deal breaker for some.

In my case the game is playable, but there are still some rough edges to keep track of.

Kaylebor on 27 Aug 2018

Can anyone confirm if the complete game/OS freezes happen on AMD as well, or if it's only an Nvidia-related issue?

LP0101 on 27 Aug 2018

Distro: Ubuntu 18.04
Kernel: 4.15.0-33-generic
GPU: GTX1080 Ti
Driver: 396.54

Game works perfectly fine except for the same OS lockups as @LP0101 and @Kaylebor mention. Seem to happen completely at random, sometimes the game will only run for 20 minutes, sometimes for multiple hours.

EDIT: Tried updating kernel to 4.18, Proton to 3.7-4 beta and using V-Sync on/off with windowed and borderless windowed. Still getting OS lock-ups.

bentrevett on 27 Aug 2018

It seems like playing in Windowed Mode with V-Sync on fixes the lockup issues. I was able to play for over 4 hours without a lockup, which is longer than I've ever managed in borderless window.

Driver version: 396.54
Kernel Version: 4.18.5-041805-generic

LP0101 on 27 Aug 2018

Unfortunately, I still experienced lockups with both Windowed & Borderless Windowed + V-Sync after approximately 1-2 hours of being in game, sometimes less. For what it's worth, in both instances, I made sure to intentionally lose window focus as per @LP0101's earlier post. As of yet, I haven't tried playing for any length of time without losing window focus to see if the game doesn't lockup.

Distro: KDE Neon (Ubuntu 16.04)
Kernel: 4.15.0-33-generic
GPU: GTX 1070
Driver: 396.54
CPU: Intel 6700K
RAM: 16GB DDR4 @ 3000MHz
Proton Version: 3.7-4 Beta

suika-ibuki on 28 Aug 2018

Could you please attach nvidia-bug-report.log.gz next time you experience a lockup?

damienleone on 29 Aug 2018

Certainly, here you go, @damienleone.

nvidia-bug-report.log.gz

suika-ibuki on 29 Aug 2018

Playing any video in-game results in a page fault due to missing function implementation;

wine: Call from 0x7b44abbc to unimplemented function mfplat.dll.MFCreateMFByteStreamOnStream, aborting

This function has yet to be implemented upstream.

Log: steam-582010.log

Replication steps: When in-game, press start, go to Info->Player Guide->View Tutorials->Hunter Equipment and press Play Movie.

Note: This does not happen to scenes in-game, they are not pre-rendered video files, thus does not crash the game.

fureloka on 31 Aug 2018

👍4

The forever running process when exiting out, is caused by an exception;

wine: Unhandled exception 0x40000015 in thread 53 at address 0x1428f3032 (thread 0053)

which then ends up with a forever ending wait;

err:ntdll:RtlpWaitForCriticalSection section 0x14484a320 "?" wait timed out in thread 0053, blocked by 002d, retrying (60 sec)

Log: steam-582010.log

fureloka on 31 Aug 2018

@fureloka I cannot replicate the issue you mention with playing in-game videos. To confirm this, I just opened the gallery and watched a couple of scenes. Please note that I have not completed the game so I cannot verify wether all scenes work, but I've been able to play all the way to HR14 watching the videos just fine.

setzer22 on 31 Aug 2018

@setzer22 @fureloka Based on my experiences, it plays just fine - at least until you beat the final boss. The video file trying to get played after leads to game crashes. Probably due to codecs missing (this also happens on Windows in Certain Regions where the Codecs are missing).

Also, what crashes my game is playing Preview Videos of Weapons/Tools in the Inventory.

Other In Game Videos were working perfectly fine.

Xatulu on 31 Aug 2018

@setzer22 @Xatulu Apparently I wasn't specific enough, I'm not talking about the in-game rendered scenes, these are rendered in real time with the engine, thus plays fine. Capcom wouldn't have the time to make pre-rendered video for those, due to the amount of style combinations.

What I'm referring to are the pre-rendered video files that are played in-game, mostly tutorials and previews which @Xatulu mentioned.

When in-game, press start, go to Info->Player Guide->View Tutorials->Hunter Equipment and press Play Movie.

If it doesn't crash there, you have a magical version of Proton. This will also crash with the latest version of Wine, as MFCreateMFByteStreamOnStream is unimplemented.

fureloka on 31 Aug 2018

👍2

Has anyone gotten a chance to test the latest proton beta? Has it done anything about the crashes?

LP0101 on 31 Aug 2018

Crashes, full system hangs, and game persisting after window exit still occur on 3.7-5 Beta
Nvidia 396.54-1.fc28.x86_64
Kernel 4.17.19-200.fc28.x86_64

There may be some fixes in the Nvidia beta driver, but I can't find a good beta rpm to install to check

Xaenalt on 31 Aug 2018

Monster Hunter World - all surfaces have specular highlighting

Issue transferred from https://github.com/ValveSoftware/Proton/issues/1092.
@shadywack posted on 2018-08-31T19:51:15:

Issue: specular highlighting on all surfaces
Steps to reproduce: launch game and observe surfaces
Observations: it depends on the texture and what the game engine calls for, in some cases its subtle, but it depends on the material to make it more obvious. In a rainy environment it actually looks cool, but I don't think it's what the renderer intends. I'd take a screenshot but it's obvious in motion. Wood should not have a specular highlight on its surface.
System: Ryzen 7 1800X on a Vega64 using the RADV/Mesa 18.3 driver (from the Padoka PPA listed in the quickstart guide) Ubuntu 18.04, Steam beta client running Proton 3.7-5

On a personal note: Thanks for all your hard work! This is some awesome coding to see, and probably the best thing I've ever seen Valve do. If there's a fix for this issue great, but if not, it's really not the end of the world. I can play this game natively at 4k in Windows but on Proton there's a pretty substantive hit to drop the fps down to 20-ish on my hardware. It runs buttery smooth at 60fps at 1440p however and I absolutely love it. Many thanks.

kisak-valve on 31 Aug 2018

Monster Hunter World - Crash on Credits Cutscene - Missing Windows Media Codecs

Issue transferred from https://github.com/ValveSoftware/Proton/issues/1125.
@Estard posted on 2018-09-01T10:28:18:

After defeating the final boss in MH: World the game tries to load a cutscene where, according to this reddit post:
https://www.reddit.com/r/MonsterHunter/comments/99cqi4/xeno_save_corruption_bug_does_not_exist_proof/
it needs certain codecs contained in the Windows Media Feature Pack in order to play said cutscene.
I suppose that is the reason why the game also crashes at that point when playing it with Proton.
It would be well appreciated if a workaround could be implemented for this and other games that require it.

Tested on Proton 3-7-5 and winestaging 3.14 (64 bit) esync + dxvk

kisak-valve on 1 Sep 2018

@doitsujin Can confirm that VolumeRenderingQuality can be set to Highest on Nvidia 396.54.02

Testing if the crash is reproducible with that driver

Xaenalt on 1 Sep 2018

Can confirm the game still crashes accompanied with a system lockup on Nvidia 396.54.02

Xaenalt on 1 Sep 2018

What a letdown.
I was hoping newest nvidia driver would fix the lock up.
has anyone narrowed down what causes the freezing?
I get a full system lockup that can only be fixed by power cycle
I have tried almost every kernel manjaro has listed.
the latest lts kernel gives the least amount of lockups but it still happens

roadh0use on 1 Sep 2018

I'm not sure what debug logs to provide, if someone can post a what to do and what logs are needed, I'll gladly provide them. I'd imagine something like perf record?

Xaenalt on 1 Sep 2018

Has anyone tried replacing the proton-provided DXVK binaries with the newly-released 0.71 binaries, see if that fixes anything?

LP0101 on 2 Sep 2018

I am about to try 0.71 using Lutris with wine 3.15-esync. If that goes well i am going to try it in proton with replacing the DXVK. this will be on the 4.18.5-3 Kernel on a GTX 980 using the 396.54 Driver. I will report back with how things go.

lordkitsuna on 2 Sep 2018

Seems to be working, played for a little over an hour and no lockup. Have not tried with proton yet but will later and report back

lordkitsuna on 3 Sep 2018

Hummmm It seems I cannot set my game to work under 4k.

Manjaro Linux
Gnome 3.28.3
Manjaro Linux 17.1.12
NVIDIA 396.54
GeForce GTX 1070
AMD Ryzen 1700x
Linux 4.14.66-1
RAM: DDR4 2133MHz 32GB

Resolution: 3840 x 2160
Gnome UI Scaling - 200%

Step to reproduce - Set the game to full screen/boardless and 4k resolution in in-game setting, and set the graphic setting to medium. Exit options, click on start game, error prompt
E_FAIL: IDX11Device->CreateShaderResourceView(pres->getHandle(),&srvDes,&mpView)

Anything under 4k works just fine :D Amazed by it

ICEFIR on 3 Sep 2018

@ICEFIR See
https://github.com/ValveSoftware/Proton/issues/175#issuecomment-415886153
and
https://github.com/ValveSoftware/Proton/issues/175#issuecomment-415942845

Xaenalt on 4 Sep 2018

Can confirm dxvk 0.71 still experiences the hang. I replaced the Proton 3.7-5 beta's dxvk library with one from master, same system hang as before

Xaenalt on 4 Sep 2018

@Xaenalt It's not the same problem - I've read that thread before
Here I am not able to run the game under 4k resolution - game crash after I click on start game in the main menu. The save slot screen was not able to load. Anything under 4k works just fine tho.
His problem was the game was not able to load - which I have experienced before, and fixed by setting VolumeRenderingQuality to low

ICEFIR on 4 Sep 2018

Can I throw out a theory
First I have to ask
Is there any sort of caching going on with this game?
the reason I ask is this
I have installed multiple distros and kernels and they have one thing in common
after a fresh install, monster hunter world runs perfect without freezing for hours and hours
it's only after let's say 12 hours of play the freezing becomes common like every 45 minutes
I've tried Ubuntu, manjaro, fedora, mint, and opensuse
and all of these distros meet the same fate.
if there is no sort of caching then disregard this
But it's what I've kinda narrowed it down to

roadh0use on 4 Sep 2018

@ICEFIR: In that case, to help debug it, you can cd to "$steamdir/steamapps/common/Proton 3.7 Beta". Once there, mv user_settings.sample.py user_settings.py that will enable debugging for the game. It will generate a log file in $HOME called steam-$steam_game_id.log. Can you upload the log from that, and the MonsterHunterWorld_d3d11.log and MonsterHunterWorld_dxgi.log from "$steamdir/steamapps/common/Monster Hunter World" I'm not sure if extra debug arguments are needed there, but that's the defaults as far as I can tell

Xaenalt on 4 Sep 2018

I still don't have a root cause for the hang. The hang seems caused by a NULL pointer dereference from the GPU in what seems to be a texture fetch operation. Since the only information I have about the address is that it's 0 and given that the hang is very intermittent, it makes debugging difficult. I'll keep looking. In the meantime, any extra information about how to reproduce the hang reliably would be helpful.

damienleone on 5 Sep 2018

@roadh0use NVIDIA driver do own shader caching. Can you try remove shader cache ($XDG_CACHE_HOME/.nv/*) instead of fresh OS install?

lieff on 5 Sep 2018

@lieff I will test later and report back.

roadh0use on 5 Sep 2018

@Xaenalt I will try that and report back once I get home :) Thx~

ICEFIR on 5 Sep 2018

@lieff I just got around to looking for the location of the shader cache. Should I delete everything in the .nv folder?
or the subfolder that has steamapp_shader_cache0.bin and steamapp_shader_cache0.toc?
there is another folder in the .nv folder. Since it's cache I dont see why deleting it will be a problem but I just want confirmation before I go deleting things.

roadh0use on 5 Sep 2018

Decided to wait a bit for this to evolve and I'm having really good performance on this game out of the box! The only issue I'm having is that I can't alt-tab, and if I play in borderless or windowed, I get like, 5fps plus the game will open on the wrong display if I do that. If I can get the same near native performance in borderless while opening on the correct display in that mode, I'll be a happy camper. If I try to alt-tab in fullscreen mode, I still have no control over the mouse outside the game, so I would have to quit the game to interact with Discord, Spotify, etc. on my other monitor. Borderless does function as intended, but the framerate plummets to unplayable slideshow rates. My save is also past the end game WMP bug, as I've played it on Windows. I hadn't played for longer than 2 hours, but I've never had freezes. Don't have the free time to play for many hours straight to replicate the issues above, but so far, no crashes. Nvidia exclusive issue, maybe? I also noticed that if I change settings that would require a game restart, I would have to kill the process, then start the game again.

Proton 3.7-5 Beta
Manjaro Gnome Stable
Ryzen 1700
AMD R9 390X
16GB RAM
Kernel Version: 4.18.5-1-MANJARO
MESA 18.1.7
LLVM 6.0.1

As I said, this is out of the box stuff. Maybe sometime I'll use protontricks to use winecfg and try a virtualized desktop and fullscreen that way, who knows.

EDIT: So I turned on Steam's FPS counter. The framerate issue with borderless and windowed seems to be an issue with Gnome's compositor, as it still reports close to the same framerate. I'll consider that a non-issue then as that would be off topic.

EDIT:. Yeah, it was a compositor issue. Using Manjaro XFCE now and I can play on borderless no issues! :)

TyMiles2012 on 5 Sep 2018

@roadh0use steamapp_shader_cache is pre-installed with game, so it cannot be source after 12 hours. .nv folder in home directory - generated and updated in run-time, try to fully delete this directory.

lieff on 5 Sep 2018

Finally I've begun to get the hangs that people were talking about, though it didn't make the whole system freeze, it just made it reeeeeeeeeally sluggish. Anyways, nothing useful in the Proton or DXVK logs, no shocker there. Checking journalctl, the kernel reported a GPU error;

kernel: NVRM: GPU at PCI:0000:01:00: GPU-e3934bd0-774d-bae8-8fa0-ce38440e3fde
kernel: NVRM: Xid (PCI:0000:01:00): 31, Ch 00000023, engmask 00000111, intr 10000000

According to Nvidia, Xid 31 is a GPU memory page fault, which points to driver error or application error. It wouldn't surprise me if it were the driver, as I've yet to see any AMD reports of a "frozen" system.

GPU: GTX 970
Driver: 396.54

Edit: Forgot to mention that so far all my hangs (3 so far) have happened during fights with large monsters, probably just coincidence.

fureloka on 6 Sep 2018

@fureloka I had the same thing happen to me tonight. Managed to get a sluggish terminal open for pkill

Fight was versus double tempered Bazelgeuse

Gtx 970
396.54

Skylead on 6 Sep 2018

Just beat xeno'jiiva and can confirm that the last cutscene does cause a crash. It didn't corrupt my save thankfully, but I crash on load now. In looking into it, some codecs might be portable from windows, but it requires some messing with the dlls. Is there a good way to modify them similar to winecfg for Proton? Additionally, is there a good way to do the usual wineprefix operations with Proton? Also do the games run in their own wineprefix? ~/.local/share/Steam/steamapps/compatdata/582010/pfx seems to be a wineprefix, and has the ID for MHW in the path, but the game doesn't seem to reside there

Xaenalt on 6 Sep 2018

Having regular crashes with mine, not so much of the freezing although that has happened a couple times. Game performance is excellent then suddenly poof it's gone.

Fedora 28 - 4.17.19-200.fc28.x85_64 ( also tested with 4.18.5-300.fc29.x86_64 )
AMD FX-8350 ( 8 Core ) / 16GB RAM
NVidia GeForce GTX 1050 Ti ( 396.54.1 )
Proton 3.7-5 ( Beta )
DXVK 0.71

Tried running in windowed/borderless, changing the framerate, disabling Steam overlay, turning off 'Shader Pre-Caching' and even put a dummy file in place of the '.nv' folder but it'll still crash after about 10-15 minutes. Really a shame as it runs so well up until that moment.

It seems like despite the issues most others seem to be getting slightly more stability out of play than I have so any insight or advice would be greatly appreciated.

steam-582010.log
MonsterHunterWorld_d3d11.log
MonsterHunterWorld_dxgi.log

There are 12 errors in the log about './Steam/ubuntu12_32/gameoverlayrenderer.so' being the wrong ELF class ( not sure why a 32-bit is even being used ) and one for 'jack_error_callback' though I'm definitely using PulseAudio... if any additional logs might help let me know!

HMSS013 on 6 Sep 2018

@Xaenalt It's actually not a save corruption bug. People thought it was because of the fact that it crashes on start post crash as someone eventually discovered. It's only because of the missing codecs. The bug also happens on N/KN versions of Windows. Maybe try installing the optional Media Packs for N/KN onto the game's Proton prefix. Those add the required codecs.

I'm not entirely sure how to run external programs on the proton prefixes, though I know where the prefixes are located. They're created per-game via appid.

EDIT: The media packs are *.msu files. No way to install them through at least regular/staged Wine, so it likely won't work via Proton. msiexec won't work.

TyMiles2012 on 6 Sep 2018

@damienleone Regrettably, I haven't really been able to find any particular sets of circumstances that lead to the hang, either. As per @fureloka's post, I _feel_ like a good number of my hangs have occurred upon hitting a monster with a lot of effects and whatnot filling the screen, but I've just as well had a number of hangs that occurred whilst running around a level, not in any heavy action. In fact, the hang that occurred with the bug log that I uploaded actually occurred in the hub world (Astera) shortly after having finished a quest, so whatever is causing the hang doesn't necessarily seem linked to any effects that would occur in combat. It may also be worth noting that this hang occurred after several segmented 1-2 hour sessions that resulted in no crash.

If I recall correctly, I was panning the camera at the time of that crash--I'd have to dig it up, but I recall a post on the /r/Linux_Gaming subreddit that stated they believe the hangs might be caused during periods of motion blur. This may potentially explain the generalized nature of the hangs, as well as why they may occur more frequently in combat (since there's heavy panning of the camera during). If I get the opportunity to, I'll try to test this later.

suika-ibuki on 6 Sep 2018

Well, it seems like you can use $WINEPREFIX with $STEAM/steamapps/compdata/$GAME_ID/pfx and do installs, overrides, winetricks, etc.

As for getting the codecs installed, this seems to be the culprit:

0030:fixme:wusa:load_assemblies_from_cab Cabinet uses proprietary msdelta file compression which is not (yet) supported.
0030:fixme:wusa:load_assemblies_from_cab Installation of msu file will most likely fail.

I'm out of ideas on that front though

Xaenalt on 6 Sep 2018

Running on Proton 3.7.5-beta I am having an issue where OS notifications (and presumably other things) cause my game to switch to what looks like software rendering while the notification is active. I can still run around in game, I just can't see what's going on for a few seconds. After the notification leaves, the game runs fine again.

Another issue is that input seems to be delayed by as much as 1/8th of a second. I am using an xbox one controller plugged in via usb (I have an older controller that doesn't have BT)

Fedora 28
Kernel 4.17.19
i7-6700K
GTX 1070
Driver 396.54

karai17 on 7 Sep 2018

Alright sorry it took so long. to get back.
Deleted the contents of .nv after i noticed consistent freezing about every hour again
Been playing all day since then and havent had a freeze issue. Im not sure if this is the culprit or it's just coincidental......

roadh0use on 7 Sep 2018

Hi @Xaenalt Sry for late reply - was extremely busy over the last several days :P
In regards to 4k resolution problems, here's all the log :D

Steam Log file has been zipped since it is too large
steam-582010.zip
MonsterHunterWorld_dxgi.log

MonsterHunterWorld_d3d11.log

ICEFIR on 8 Sep 2018

Oh also there is another minor issue
The last time when I tried to play with my friend, i got disconnected when i attempted to get potions/ration etc from that blue supply chest.
Tried twice, all resulted in disconnection.
Everything else works flawlessly, though, somehow.....

Not sure what kind of magical net code capcom used for that chest, but apprently its different than everything else...

Have done any extensive testing for this though. I was in a camp that i have not unlocked yet. Are there any similar issues happening?

ICEFIR on 8 Sep 2018

As mentioned before most people seem to be able to run MHW fine except for a freeze of the game/OS. I'm experience a system wide freeze at random moments which require me to reboot my pc in order to get it to respond again.

Looking at the log I can see it being spammed with:

5664.319:001d:0023:err:hid_report:process_hid_report Device reports coming in too fast, last report not read yet!

Ocassionally also having:

5552.906:0008:0092:trace:module:LdrGetDllHandle L"steam_api64.dll" -> 0x3b400000 (load path L"Z:\\home\\jonathan\\.steam\\steamapps\\common\\Monster Hunter World;C:\\Program Files (x86)\\Steam;C:\\windows\\system32;C:\\windows\\system;C:\\windows;.;C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem")
5552.906:0008:0092:trace:module:LdrGetDllHandle L"oo2core_5_win64.dll" -> 0x470000 (load path L"Z:\\home\\jonathan\\.steam\\steamapps\\common\\Monster Hunter World;C:\\Program Files (x86)\\Steam;C:\\windows\\system32;C:\\windows\\system;C:\\windows;.;C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem")
5552.907:0008:0092:trace:module:LdrGetDllHandle L"amd_ags_x64.dll" -> 0x180000000 (load path L"Z:\\home\\jonathan\\.steam\\steamapps\\common\\Monster Hunter World;C:\\Program Files (x86)\\Steam;C:\\windows\\system32;C:\\windows\\system;C:\\windows;.;C:\\windows\\system32;C:\\windows;C:\\windows\\system32\\wbem")
5552.908:0008:0092:trace:module:LdrAddRefDll (L"MonsterHunterWorld.exe") ldr.LoadCount: -1
5552.909:0008:0092:trace:module:LdrAddRefDll (L"MonsterHunterWorld.exe") ldr.LoadCount: -1

jonathansty on 8 Sep 2018

Ok, finally worked around the cinematic issue by getting a friend to boot it and bypass the cutscene on their Windows system. Booting it on my own hw goes against my religious beliefs

Anyway, was able to reproduce the crash with the debug logs enabled. Hopefully they help, let me know if I need more debug flags, I just used the default ones

mhw-crash.tar.gz

Xaenalt on 8 Sep 2018

@xaenalt
just to clarify
You can beat xeno, get the crash, bring the save to a windows pc, do the cut scene, and then transfer the save back to the Linux pc.
Am I correct?

roadh0use on 8 Sep 2018

@roadh0use
Yep, I had them log in on my account, and the save synced successfully, they played the cutscene, and I logged back in on my account and it synced the save post-cutscene back. It didn't work just transferring SAVE1000 to their box though. I suspect there's some metadata somewhere that prevents that from just working

I'm still in the process of trying to recompile proton on Fedora, I saw in the release notes for wine-staging 3.15 that they added some better windows media support, so maybe there's a chance that it'll help fix that issue

Xaenalt on 8 Sep 2018

Another crash log
mhw-crash-2.tar.gz

Xaenalt on 8 Sep 2018

Can confirm the crash still occurs post-deletion of the .nv directory

Xaenalt on 8 Sep 2018

@Xaenalt
same. i thought it was fixing the crash but it was just coincidence

roadh0use on 9 Sep 2018

Out of curiosity, for those experiencing the system lockup that accompanies the crash, you guys using KDE? If so, try disabling the compositor and seeing if the crash locks up the system

Xaenalt on 11 Sep 2018

@Xaenalt I use GNOME.

karai17 on 11 Sep 2018

Ah darn, I just had a regular old crash when trying with the compositor disabled, so I was hopeful that might cut the full system lockup

Xaenalt on 11 Sep 2018

@Xaenalt
im using cinnamon
on a side note
i havent given up on my shadercache idea
under ~/.steam/steam/steamapps/ there is a shadercache folder.
again it might be a placebo but so far, deleting the contents of this folder after every play session has (seemingly) curved the crashing.
was hoping if someone else could try this as well and see if it is a possible fix, or a placebo

roadh0use on 11 Sep 2018

New Nvidia drivers have been released, has anyone been able to test with them?

LP0101 on 11 Sep 2018

@LP0101
Current newest Linux driver still is 396.54, 399.24 has not been released for Linux yet I think?

ICEFIR on 12 Sep 2018

A patch was released, 396.54.05 I believe.

karai17 on 12 Sep 2018

I'll update and test tonight

Xaenalt on 12 Sep 2018

So I played the game for about a 2-3 hours today, doing various sort of missions and things in general. I did not experience the same system lockups I was having before anymore.
Things I have done were:

update gpu driver
update kernel

See below info for more:

Processor Information:
    CPU Brand:          Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz

Operating System Version:
    Pop!_OS 18.04 LTS (64 bit)
    Kernel Name:  Linux
    Kernel Version:  4.18.7-041807-generic
    X Server Vendor:  The X.Org Foundation
    X Server Release:  11906000
    X Window Manager:  Mutter(Budgie)
    Steam Runtime Version:  steam-runtime-beta-release_2018-06-14

Video Card:
    Driver:  NVIDIA Corporation GeForce GTX 1080/PCIe/SSE2
    Driver Version:  4.6.0 NVIDIA 396.54

Only thing I noticed was that MonsterHunterWorld.exe would stay running in the background after exiting it.
Not sure if this helps a lot.

jonathansty on 13 Sep 2018

I'm still only getting about ~20 minutes of gameplay before the MH abruptly closes. No freezing, the game just closes out to the desktop and I'm not finding anything in any of the logs to indicate why.

Fedora 28 - 4.18.5-300.fc28.x86_64 ( Cinnamon )
AMD FX-8350 / 16GB RAM
NVidia GeForce GTX 1050 Ti ( 396.54.1 )
Proton 3.7-6 Beta

I've done a clean install but the problem persists, any help would be greatly appreciated.

HMSS013 on 13 Sep 2018

396.45.1

Please update to 396.54.

doitsujin on 13 Sep 2018

Please update to 396.54.

@doitsujin
I will absolutely do that now, but please note on my earlier post that this issue was still present using 396.54.1

HMSS013 on 13 Sep 2018

@roadh0use

So I've been testing deleting the shadercache folder every time I play and it looks like it fixed the crashing for me too. I haven't been able to have a really long play session yet to fully confirm this, but it used to be that if I played in borderless fullscreen the game would crash about 5 minutes after starting a hunt, but now I've gotten through three hunts without any crashing. So it does seem like the crashing might have something to do with the shadercache. The only side effect that I have is occasional stuttering when it rebuilds the cache, I might try disabling it in steam to see if that helps.

ecru332 on 13 Sep 2018

Maybe it's just me, but feels like lockup is much more common now in 3.7-6 than it was before.

Skylead on 14 Sep 2018

I'm also getting lockups after running the game for some time. dmesg shows these lines when it happens:

[18082.187238] NVRM: GPU at PCI:0000:01:00: GPU-31cce69c-7592-a02b-a7f1-537eb763536f
[18082.187242] NVRM: Xid (PCI:0000:01:00): 31, Ch 0000002b, engmask 00000111, intr 10000000

As @fureloka said, maybe a driver bug?

System:

Processor Information:
    CPU Brand:         Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz

Operating System Version:
    Ubuntu 16.04.5 LTS (64 bit)
    Kernel Name:  Linux
    Kernel Version:  4.15.0-34-generic
    X Server Vendor:  The X.Org Foundation
    X Server Release:  11906000
    X Window Manager:  Compiz
    Steam Runtime Version:  steam-runtime-beta-release_2018-06-14

Video Card:
    Driver:  NVIDIA Corporation GeForce GTX 970/PCIe/SSE2
    Driver Version:  4.6.0 NVIDIA 396.54

Memory:
    RAM:  7869 Mb

dseguin on 15 Sep 2018

So I've had more time to play now and from what I can see, with Proton 3.7-6 and Nvidia 396.54, I can get about an hour of gameplay without crashing if I disable the shader cache in steam.

I'm running Arch with a 1080ti and driver version 396.54-4. If I run in windowed mode there are no problems, if I run in borderless then I get a crash after about 5-10 minutes. If I disable the shader cache then I can run in borderless and get about an hour before the crash. So it looks like it might be a driver bug which is improved but not fully solved by stopping Steam from pre-caching shaders.

ecru332 on 17 Sep 2018

@ecru332
Same thing man.
Deleting the shader cache and disabling it in steam does result in longer play between freezes, but doesn't alleviate the problem like I was hoping.
so it looks to be only an nvidia problem because I don't see any amd posting in here. Kinda sucks

roadh0use on 18 Sep 2018

Interestingly, I only had one account of freezing when I tried the game the first time and was alt-tabbing a lot. I tried playing again wihtout alt-tabbing and I played for well over an hour without any real issue. I'm on nvidia.

karai17 on 18 Sep 2018

I've noticed that the specular reflections? aren't rendered properly in Proton 3.7-6.
Proton 3.7-6 Incorrect Rendering - https://youtu.be/WPXIl5cOhls
Windows Correct Rendering - https://youtu.be/7QctglngEk4
It could be because I'm using "beta" Southern Island support for AMDgpu, but I don't know how to isolate wether it's a driver, wine, or DXVK issue.

Other than the missing codec softlocked saves Monster Hunter World runs very well for me. No crashes / hangs other than the game not exiting correctly sometimes.

OS: "Arch Linux" (64 bit)
Kernel: 4.18.5-arch1-1-ARCH
CPU: Intel(R) Core(TM) i7-4770K CPU @ 3.50GHz
GPU: X.Org AMD Radeon HD 7900 Series (TAHITI, DRM 3.26.0, 4.18.5-arch1-1-ARCH, LLVM 6.0.1) Specifically an R9 280 aka rebranded 7950
GPU Driver: 3.1 Mesa 18.1.7 (AMDgpu driver forced on instead of Radeon)
RAM: 15914 Mb @ 2400MHz

Confetti-Camouflage on 18 Sep 2018

@Confetti-Camouflage Could it be the same driver bug as this?

https://github.com/doitsujin/dxvk/issues/652

ryao on 20 Sep 2018

@ryao I think that is an issue with MSAA and MHW doesn't even use it, idk if this texture bug is also an issue for nvidia users

EDIT: Nvidia GPUs don't have this texture bug
EDIT2: Disabling Z-Prepass in-games change the behaviour of the bug a little bit, some objects are normal when close to the camera

BlazeKl on 21 Sep 2018

Distro: Mint 19 Cinnamon
Kernel: 4.15.0-34-generic
GPU: [AMD/ATI] Tonga PRO [Radeon R9 285/380]
CPU: Intel i3-6100
RAM: 8GB

I am experiencing the black window and closing itself. I have gone into the graphics_option_preset.ini and changed 4 instances of each of these settings:

ScreenMode=Borderless
Resolution=1680x1050 (my monitor size)

I'm not sure what else I can do or change this.

czarsquid on 24 Sep 2018

There is an issue with videos causing the game to hang. In particular there is a cutscene after killing Xeno'jiiva (aka "???") in the final campaign mission which prevents completion of the game. The same issue also occurs when trying to view videos in tutorials. Fortunately, I was able to overcome the issue using DLL files from Windows 7, following the same steps as in the Proton issue thread for Shadows: Awakening.

The files are

mf.dll
mferror.dll
mfplat.dll
mfreadwrite.dll
msmpeg2adec.dll
msmpeg2vdec.dll
sqmapi.dll

Since I'm using a 64 bit wineprefix, I obtained both the 64-bit and 32-bit versions of each file (in system32 and syswow64 respectively). For the registry files, I obtained a Windows 7 + IE10 evaluation virtual machine.

For some reason, wine regedit wmf.reg did not import the registry changes so I had to open up wine regedit and do it from the GUI.

time=1d490ce3aaf5900

"api-ms-win-crt-conio-l1-1-0"="native,builtin"
"api-ms-win-crt-heap-l1-1-0"="native,builtin"
"api-ms-win-crt-locale-l1-1-0"="native,builtin"
"api-ms-win-crt-math-l1-1-0"="native,builtin"
"api-ms-win-crt-runtime-l1-1-0"="native,builtin"
"api-ms-win-crt-stdio-l1-1-0"="native,builtin"
"api-ms-win-crt-time-l1-1-0"="native,builtin"
"atl100"="native,builtin"
"atl110"="native,builtin"
"atl120"="native,builtin"
"atl140"="native,builtin"
"concrt140"="native,builtin"
"mf"="native,builtin"
"mfplat"="native,builtin"
"msvcp100"="native,builtin"
"msvcp110"="native,builtin"
"msvcp120"="native,builtin"
"msvcp140"="native,builtin"
"msvcr100"="native,builtin"
"msvcr110"="native,builtin"
"msvcr120"="native,builtin"
"msvcr140"="native,builtin"
"ucrtbase"="native,builtin"
"vcomp100"="native,builtin"
"vcomp110"="native,builtin"
"vcomp120"="native,builtin"
"vcomp140"="native,builtin"
"vcruntime140"="native,builtin"

And this is the new log.
steam-582010.log

blastermaster77 on 15 Dec 2018

9821.747:0026:0027:warn:module:load_builtin_dll failed to load .so lib for builtin L"Z:\\home\\blastermaster\\.steam\\steam\\steamapps\\common\\Monster Hunter World\\steam_api64.dll": /home/blastermaster/.steam/steam/steamapps/compatdata/582010/pfx/dosdevices/z:/home/blastermaster/.steam/steam/steamapps/common/Monster Hunter World/steam_api64.dll: invalid ELF header
9822.864:0026:0027:warn:module:load_builtin_dll failed to load .so lib for builtin L"C:\\windows\\system32\\MFReadWrite.dll": /home/blastermaster/.steam/steam/steamapps/compatdata/582010/pfx/dosdevices/c:/windows/system32/mfreadwrite.dll: invalid ELF header
9822.944:0026:0027:warn:module:load_builtin_dll failed to load .so lib for builtin L"Z:\\home\\blastermaster\\.steam\\steam\\steamapps\\common\\Monster Hunter World\\amd_ags_x64.dll": /home/blastermaster/.steam/steam/steamapps/compatdata/582010/pfx/dosdevices/z:/home/blastermaster/.steam/steam/steamapps/common/Monster Hunter World/amd_ags_x64.dll: invalid ELF header
9823.030:0026:0027:warn:module:load_builtin_dll failed to load .so lib for builtin L"Z:\\home\\blastermaster\\.steam\\steam\\steamapps\\common\\Monster Hunter World\\oo2core_5_win64.dll": /home/blastermaster/.steam/steam/steamapps/compatdata/582010/pfx/dosdevices/z:/home/blastermaster/.steam/steam/steamapps/common/Monster Hunter World/oo2core_5_win64.dll: invalid ELF header
9829.780:0026:0030:warn:module:load_builtin_dll failed to load .so lib for builtin L"C:\\windows\\system32\\openvr_api_dxvk.dll": /home/blastermaster/.steam/steam/steamapps/compatdata/582010/pfx/dosdevices/c:/windows/system32/openvr_api_dxvk.dll: invalid ELF header

Looks like new wine starts to implement mfreadwrite.dll and you need to set dll override for it as well.

lieff on 15 Dec 2018

9821.747:0026:0027:warn:module:load_builtin_dll failed to load .so lib for builtin L"Z:\\home\\blastermaster\\.steam\\steam\\steamapps\\common\\Monster Hunter World\\steam_api64.dll": /home/blastermaster/.steam/steam/steamapps/compatdata/582010/pfx/dosdevices/z:/home/blastermaster/.steam/steam/steamapps/common/Monster Hunter World/steam_api64.dll: invalid ELF header
9822.864:0026:0027:warn:module:load_builtin_dll failed to load .so lib for builtin L"C:\\windows\\system32\\MFReadWrite.dll": /home/blastermaster/.steam/steam/steamapps/compatdata/582010/pfx/dosdevices/c:/windows/system32/mfreadwrite.dll: invalid ELF header
9822.944:0026:0027:warn:module:load_builtin_dll failed to load .so lib for builtin L"Z:\\home\\blastermaster\\.steam\\steam\\steamapps\\common\\Monster Hunter World\\amd_ags_x64.dll": /home/blastermaster/.steam/steam/steamapps/compatdata/582010/pfx/dosdevices/z:/home/blastermaster/.steam/steam/steamapps/common/Monster Hunter World/amd_ags_x64.dll: invalid ELF header
9823.030:0026:0027:warn:module:load_builtin_dll failed to load .so lib for builtin L"Z:\\home\\blastermaster\\.steam\\steam\\steamapps\\common\\Monster Hunter World\\oo2core_5_win64.dll": /home/blastermaster/.steam/steam/steamapps/compatdata/582010/pfx/dosdevices/z:/home/blastermaster/.steam/steam/steamapps/common/Monster Hunter World/oo2core_5_win64.dll: invalid ELF header
9829.780:0026:0030:warn:module:load_builtin_dll failed to load .so lib for builtin L"C:\\windows\\system32\\openvr_api_dxvk.dll": /home/blastermaster/.steam/steam/steamapps/compatdata/582010/pfx/dosdevices/c:/windows/system32/openvr_api_dxvk.dll: invalid ELF header

Looks like new wine starts to implement mfreadwrite.dll and you need to set dll override for it as well.

New Log after override mfreadwrite.dll on user.reg

steam-582010.log

blastermaster77 on 15 Dec 2018

Now I do not see obvious errors, but still same crash in mfplat. Probably game uses other format than H264 and may be needs more registry keys transfer (or even additional files).

lieff on 15 Dec 2018

Now I do not see obvious errors, but still same crash in mfplat. Probably game uses other format than H264 and may be needs more registry keys transfer (or even additional files).

Ok thanks for the help will keep on trying.

blastermaster77 on 15 Dec 2018

Ubuntu 18.04
Nvidia 1080 GTX (415)
64 GiB RAM
1440p
Proton 3.16-5

The game runs _ok-ish_ in terms of performance (around 35 FPS in 21:9@1440p - everything _maxed out_). The main issues I've faced are:

~~Can't seem to be able to setup my pad (PS3 wireless, PS3 wired USB, XBOX emulated) - and the game is super hard to play without controller, especially Bow and other weapons which require to focus/zoom~~
The game crashes when playing movies - not an issue up until the final boss (I know people have reported workarounds, I think the best would be to just skip the movies themselves with a stub implementation)
~~Performance could be improved (it's all maxed out, not sure though what is the performance on Windows)~~

I have ~1000 hours on PS4, this is more an experiment, but I'd really love switching to the PC/Linux combo...

Edit

I've asked about performance on Windows and doesn't seem that different... plus at high settings it runs around 50 FPS. Not being able to use the pad is driving me nuts...

Edit 2

We really need to fix the movies, and this would be platinum... I've managed to enable the pads, followed the same tutorial as Windows and it worked. This game is much better on PC than PS4...

Emanem on 16 Dec 2018

Ubuntu 18.04
Nvidia 1080 GTX (415)
64 GiB RAM
1440p
Proton 3.16-5

The game runs _ok-ish_ in terms of performance (around 35 FPS in 21:9@1440p - everything _maxed out_). The main issues I've faced are:
* Can't seem to be able to setup my pad (PS3 wireless, PS3 wired USB, XBOX emulated) - and the game is super hard to play without controller, especially Bow and other weapons which require to focus/zoom

* The game crashes when playing movies - not an issue up until the final boss (I know people have reported workarounds, I think the best would be to just skip the movies themselves with a stub implementation)

* Performance could be improved (it's all maxed out, not sure though what is the performance on Windows)
I have ~1000 hours on PS4, this is more an experiment, but I'd really love switching to the PC/Linux combo...

Edit

I've asked about performance on Windows and doesn't seem that different... plus at high settings it runs around 50 FPS. Not being able to use the pad is driving me nuts...

Edit 2

We really need to fix the movies, and this would be platinum... I've managed to enable the pads, followed the same tutorial as Windows and it worked. This game is much better on PC than PS4...

About the controller problem, do this and tell me if it fixes the problem. I use the steam controller,dual shock 4, wiiupro controller and generic xbox360 controller without a problem, on ubuntu 18.04 http://steamcommunity.com/app/353370/discussions/0/490123197956024380/

blastermaster77 on 16 Dec 2018

Just postin a video so you can see the problem https://t.co/rKisdtS8LC

blastermaster77 on 17 Dec 2018

@Plagman @blastermaster77 @lieff @buscher The only real issue for this not being _platinum_ is that the movies can't be skipped (or ideally played back).

I've had a look at the default implementation of this API and it seems to return E_NOTIMPL. I would think that looking at the API docs on MSDN the guys at CAPCOM may have only implemented checking for the 3 values _S_OK_, _MF_E_INVALIDSTREAMNUMBER_ and/or _MF_E_NO_MORE_TYPES_.
I was wondering, perhaps if we were to patch this wine implementation call returning _MF_E_INVALIDSTREAMNUMBER_ and setting
*type = NULL;
perhaps the CAPCOM crowd would have maybe written some code to deal with an explicit failure?
This is the only hope, unless we can repackage the required binaries or @Plagman reaches out to CAPCOM and asks them to manage _E_NOTIMPL_ correctly? :+1:

Hopefully we manage to sort this, then we'll be done!

Edit

After a ~2 hours sessions, the game soft-crashes (i.e. the screen doesn't refresh but the music and process are still alive - thank god I just kill the _pid_ and restart it) approximately every ~20 minutes, which is annoying.
Should I capture the logs? Would it be useful?
_dmesg_ logs are:

[ 1831.482496] NVRM: Xid (PCI:0000:01:00): 31, Ch 0000002b, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_T1_5 faulted @ 0x0_00000000. Fault is of type FAULT_PDE ACCESS_TYPE_READ
[ 3610.304080] snd_hda_intel 0000:00:1f.3: Unstable LPIB (65536 >= 32768); disabling LPIB delay counting
[ 4340.252228] NVRM: Xid (PCI:0000:01:00): 31, Ch 0000002b, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_T1_7 faulted @ 0x0_00000000. Fault is of type FAULT_PDE ACCESS_TYPE_READ
[ 5497.137813] perf: interrupt took too long (2508 > 2500), lowering kernel.perf_event_max_sample_rate to 79500
[ 5931.131236] NVRM: Xid (PCI:0000:01:00): 31, Ch 0000002b, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_T1_9 faulted @ 0x0_00000000. Fault is of type FAULT_PDE ACCESS_TYPE_READ
[ 6644.139978] NVRM: Xid (PCI:0000:01:00): 31, Ch 0000002b, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_T1_4 faulted @ 0x0_00000000. Fault is of type FAULT_PDE ACCESS_TYPE_READ

Same as @buscher @Likutar .
Has anyone found a solution for this yet? Or is it a Nvidia driver issue? Shall I revert back to 410?

Emanem on 17 Dec 2018

👍1

@Emanem I also have the freezing issue on a GTX 1070 with driver 415.23 and Proton 3.16-5

So far this problem has been there for every driver version and every Proton version

It can happen after 2 hours of gameplay and even as short as 10 minutes, but I seemed to be random (no matter if the computer just booted or if it's the third time you launch the game)

nyanloutre on 18 Dec 2018

@nyanloutre just to confirm, it does crash the rendering threads only, but main process is up (as audio is working) and also the system is fine - am I correct?

And yes, it can happen after 10 mins but also after 2 hours... this is the most disappointing bit, because the game doesn't save often.
Again, seems to be an Nvidia driver issue to me.

Emanem on 18 Dec 2018

For the record, I opened https://github.com/doitsujin/dxvk/issues/816 to investigate the freeze, but no fix/workaround known yet.

buscher on 18 Dec 2018

@Emanem yes the audio is still playing when it crashes and I can alt tab in a terminal to kill it

nyanloutre on 18 Dec 2018

Seems like by disabling _motion blur_ the odds of it happening decrease (still happens, but rarely).
I'll test more and let you know.

Emanem on 20 Dec 2018

So I'm going to chime my 255 hours of playing only on linux here, and what I could gather from all problems I noticed in game.

Crashes

I noticed 4 different kinds of crashes, likely caused by the same source.

1. Full system crash.

The rarest by far and only happened 2 or 3 times, at maximum, this means even the audio is gone, it always happens after another kind of crash, so it is probably the system failing to recover from another crash that triggers this one.

2. Non recoverable game crash

The annoying crash, and the one that seems to be most frequent in this thread. The game can crash anytime, in any screen (even during a loading screen), it has the "audio keeps playing" symptom, however it isn't only a render crash, since the game state gets frozen, the audio only loops whatever was playing, this includes sound effects.

2.1 Before the 415+ Nvidia drivers

Before the 415 drivers, it became almost impossible to send any input to the system after a crash, the closest I could ever get was trying to change to a tty, but if I managed to get a black screen it would never load the login prompt.

2.2 Nvidia 415.18.04 Vulkan-beta driver

Game was unplayable, I hardly managed to get 10 min without a crash, however there were occasions that _only the game crashed_ and I could alt tab then kill it

2.3 Current drivers (415.22.01)

Game is playable, still have all known crashes, but sometimes can be alt-tabbed and killed

3. Recoverable crashes

The most common in my case, the game will crash, but after 1 or 5 minutes it will resume as if nothing happened, except for the network timing out.

At the beginning it was infrequent (around mid October) however it became more common as time passed with kernel, proton, and Nvidia drivers updates.

Behaves the same as a non recoverable game crash, audio looping, and system being non responsive until it just resumes.

4. Window manager crashes

Noticed with 415+ the game will crash, and bring the compositor with it, using cinnamon, only the desktop is visible, including icons, but no taskbar, the browser I usually have on the second display also disappears and the wallpaper is shown. Sometimes I can just change to a tty and kill the MH process however I still need to kill the window manager and start a new session, sometimes I managed to restart the WM with no adverse effects

General details regarding crashes

I suspect the crashes might have some CPU influence, the game audio remains looping, however the game state is frozen, as seen when a recovery happens, if I have a video being streamed, on You Tube for exemple, the audio will continue playing as normal, until whatever was buffered ends then it just stops and resumes after a small pause, usually at the same time the game recovers from the crash or the computer resumes responding to mouse and/or keyboard inputs, note that the video audio always resumes whether or not I'm able to resume control to the PC.

I've been using the Vulkan-beta branch for a long time and on the update from 396.54.09 to 415.18.04 the game was crashing constantly, after an update to the 415.22.01 drivers it seems to have the frequency of the 396 crashes, maybe a little less, but with the ocasional unrecoverable game crash that I can just alt-tab away, that didn't happen on 396.

Frequently when a unrecoverable crash happens there is a frame, or two, update on both displays and every time a full system crash happened was in this scenario, if a frame update happens and the game didn't recover I just hard reset, I never managed to get out off one. Note that the frame update isn't a necessary condition for a unrecoverable crash.

When running nvidia-smi on the other display it occasionally shows 100% GPU usage when a crash happens, that is the only situation I ever saw 100% GPU usage being reported.

Video Codecs

Playing any in-game video will crash the game, unless you install the adequate codecs, they must be taken from a windows 7 64-bits install, with the registry from that same machine.

Wine lacks the codecs to play those files (the ones inside the system32 folder look like stubs from their size), either someone implements an equivalent dll to the windows version, or makes a workaround to use a linux version of the codec (if it exists at all) needless to say you can't just share those without angering Microsoft.

Performance

Some people say it is "pretty good" but I can't agree, using the same settings on both linux and windows I've seen a difference of 30 FPS (98 on windows to 68 on linux).

Likutar on 20 Dec 2018

👍3

it seams that proton 3.16-6 fixed the video issues! can someone else confirm?

blastermaster77 on 22 Dec 2018

it does seem like things are running much better, but now my game gets stuck loading indefinitely on Rotten Vale...

it doesn't freeze, but the loading bar goes 95% of the way and just stays there.

HMSS013 on 22 Dec 2018

I was hopeful, but no, I just got frozen, should be noted that now only the render is crashing, the game eventually resumes and I even managed to abort a mission.

At this point I have no ideia on what could be causing the issue, likely wine had some part, since now the crash is pretty different.

Likutar on 22 Dec 2018

well for some reason i was able to see the video cutsceen after the final boss with proton 3.16-6. I tryied the video tutorials and still crashes, at least I can keep playing now.

blastermaster77 on 22 Dec 2018

well for some reason i was able to see the video cutsceen after the final boss with proton 3.16-6. I tryied the video tutorials and still crashes, at least I can keep playing now.

can confirm that the problem still exist, when I go to the gallery to watch the video sequence it does still crash, I think something weird happend that let the video play oh well.

blastermaster77 on 22 Dec 2018

Eventually reached _Xeno_ (the end of the basic game) and then decided to use Windows 10 to _watch_ the movie and then import back the save.

I feel dirty :(

Hopefully these Media Feature Pack interfaces will be properly implemented by the _wine_ bunch!

edit

Removed direct link

Emanem on 25 Dec 2018

Warning for above: That's a direct link to a file download.

WesCook on 25 Dec 2018

Alienware 15R4
Distro: Manjaro
Kernel: 4.19.0.3-MANJARO
GPU: Nvidia GTX 1070 (Mobile)
Driver: Nvidia 415 (I believe)
CPU: i7 8750H
RAM: 16GB

There is currently a Windows bug that is causing crashes with Monster Hunter World as well on Nvidia Cards. (ERR12 "graphics device crashed") The supposed fix to this is to set Nvidia Control Panel - 3D Settings - Global - Power Management to Maximum Performance.

I'm curious if this is the same issue that is happening on GNU/Linux machines. I wonder if you set your Power-Mizer to the maximum performance mode if it will solve this.

Try at your own risk

The command (for me) is nvidia-settings -a [gpu:0]/GPUPowerMizerMode=1 > /dev/null

I may not have time to test it for a little bit, but I'll post results.

robbierobs on 1 Jan 2019

Alienware 15R4
Distro: Manjaro
Kernel: 4.19.0.3-MANJARO
GPU: Nvidia GTX 1070 (Mobile)
Driver: Nvidia 415 (I believe)
CPU: i7 8750H
RAM: 16GB

There is currently a Windows bug that is causing crashes with Monster Hunter World as well on Nvidia Cards. (ERR12 "graphics device crashed") The supposed fix to this is to set Nvidia Control Panel - 3D Settings - Global - Power Management to Maximum Performance.

I'm curious if this is the same issue that is happening on GNU/Linux machines. I wonder if you set your Power-Mizer to the maximum performance mode if it will solve this.

Try at your own risk

The command (for me) is nvidia-settings -a [gpu:0]/GPUPowerMizerMode=1 > /dev/null

I may not have time to test it for a little bit, but I'll post results.

I tested it for about 3 hours with Power mizer set to maximum and it did not crash will continue to test to see if it is a definitive fix.

blastermaster77 on 2 Jan 2019

👍2

@robbierobs I can confirm that using PoweMizer on performance works! I have played the game for hours and it does not freeze. If I disable it, it does freeze. thanks.

blastermaster77 on 3 Jan 2019

👍1

@robbierobs I can confirm that using PoweMizer on performance works! I have played the game for hours and it does not freeze. If I disable it, it does freeze. thanks.

Perfect! I'm glad to see that it is working!

Next, we will have to see if the cut-scenes are still causing crashes. I'm nowhere close to beating the game, can anyone confirm if this solves the crash at the end of the game? I would assume that the cut-scenes invoke a power saving and that's what causing it to crash.

robbierobs on 3 Jan 2019

@robbierobs Unfortunately it doesn't seem to have fixed it for me. I ran the command and I tried setting it through the gui. I had one full system lock up and one game crash, both after around 15 minutes of play. It could be that I'm on a the 4.20 kernel though. Once I have some time I'll switch to 4.19 and give it another test.

ecru332 on 3 Jan 2019

@ecru332 can you post system specs and are you getting confirmation that you are set in maximum performance? (Sitting at the desktop with no windows open, no browser, the GUI should show max and not be changing)

robbierobs on 3 Jan 2019

@robbierobs I'm away from my computer right now so I can't get super detailed, but here are the specs that I can remember:

Custom Built Desktop
Distro: Manjaro Linux
Kernel: 4.20.0
GPU: GTX 1080ti
Driver: Nvidia 415.25
CPU: i7-4790k
Motherboard: Gigabyte Z97X-Gaming 3
RAM: 32GB

I'm pretty sure that it was at max performance, the chart showed stage 3 and my frequency was at 1923Mhz when I looked at it. It could have been lying though, Nvidia stuff can be kind of finicky...

I'll double check the frequency when I get back to my computer.

ecru332 on 3 Jan 2019

@ecru332 for me max level is 4. Let me know what you find.

robbierobs on 3 Jan 2019

I tested for a couple of hours and had one crash. Seems better than usual though!

Edit

I tested with setting 1, level is at 4.
1080 GTX with 415.25

Emanem on 3 Jan 2019

After 13 hours of gameplay i finally got a freeze but it does help a lot.

On Thu, Jan 3, 2019, 6:26 PM Emanem <[email protected] wrote:

I tested for a couple of hours and had one crash. Seems better than usual
though!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/175#issuecomment-451297424,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AI4Dvk6Ir7RkRa44TR_opqJg1OeWtYQ3ks5u_oOxgaJpZM4WIe20
.

blastermaster77 on 3 Jan 2019

@robbierobs I think there was some confusion on the performance level from me. The chart has level 0-3 so I said 3, but it is sitting in the fourth level. Unless there should be a 4 somewhere which, if there is, then I'm extra confused.

ecru332 on 4 Jan 2019

@ecru332 that's all good, as long as it's max level. We are still crashing with the power at Max.

@blastermaster77 @emanem. Thanks for the updates. The search continues.

robbierobs on 4 Jan 2019

My problem may have come from the kernel because I made it longer than normal when I switched back to 4.19. So it seems like maybe setting the power level to max and being on kernel 4.19 makes it significantly more stable. As long as I can get through a hunt and save before a crash I'm happy with it for now.

Edit:

Never mind, I had a crash this morning after about 5 minutes.

ecru332 on 4 Jan 2019

I just beat the game, sort of...

Killed last boss, and then it crashed. Now I can't even play the game on my save file, because it crashes every time I try to load it, due to it trying to play a cutscene that Wine doesn't have codecs for.

I'm on 3.16-6, doesn't work even though apparently it did for @blastermaster77 , is there anything else you did?

z0z0z on 5 Jan 2019

@z0z0z Follow the instructions in this earlier post to get videos to play.
You'll need a 64-bit windows 7 with the media update to get the files you need.
Or you can boot up the save on a windows machine, watch the cutscene, and then bring the save back.

Confetti-Camouflage on 5 Jan 2019

@Confetti-Camouflage

Yeah I just installed Steam and MHW on a Windows laptop, watched the cutscene at 5 FPS, then it worked on my regular PC.

Didn't even need to manually transfer save files at all, it automatically worked because of Steam cloud.

z0z0z on 6 Jan 2019

With regards to cutscenes that do not work, are they different from the opening one? When starting a new character?

I haven't tried with Proton yet, but everything worked with plain Wine (Vanilla and/or Staging) for me, after a 'winetricks dxvk' (Wine is usually from git master, 4.0-rcs at this time, and I'm waiting for 4.0 to be released before I'll file AppDB test data). The opening cutscene did run at very low FPS values, even de-syncing the A/V, but I believe I had the graphics settings set to maximum at the time... need to re-test it with my current, playable settings).

By everything I don't mean that I've played far from the beginning, in part due to a strange issue with my keyboard suddenly being lost to the game at times. Never seen this one before. Mouse control is still fine at the time, and the keyboard otherwise works. The game just doesn't respond to any keys I press, and I have to terminate it.

Also using nvidia hardware (GTX 960), with usually the latest proprietary drivers, but haven't seen any actual crashes yet.

Lesser issues I noticed with plain Wine:

When first launching the game, there's just a black screen and it may remain that way for as long as at least around 8 minutes when I timed it once. Changing the resolution seems to reset this (some kind of shader building?). It's fine after the first start though.
The 'Volume Rendering Quality' setting seems to have a huge impact on perfromance, and may cause FPS value to be around <1 (while otherwise I may have around 15 to 80, depending on the other settings and in-game location/view).

Chiitoo on 6 Jan 2019

👍1

@z0z0z Follow the instructions in this earlier post to get videos to play.
You'll need a 64-bit windows 7 with the media update to get the files you need.

Sadly this doesn't seem to be enough to make the tutorial videos play (the ones you can see that displays how different weapons work).
Instant crash-to-desktop even with this fix.

fosspill on 7 Jan 2019

Sadly this doesn't seem to be enough to make the tutorial videos play (the ones you can see that displays how different weapons work).

Had forgotten about these things being a thing (never tried them yet). They indeed lead to a crash for me, too, using plain Wine (4.0-rc4-10-g40c5184a90a6).

Chiitoo on 7 Jan 2019

Sadly this doesn't seem to be enough to make the tutorial videos play (the ones you can see that displays how different weapons work).
Instant crash-to-desktop even with this fix.

@fosspill Applying and registering the dlls does fix the tutorial videos. Double check that you followed the instructions exactly?

Confetti-Camouflage on 9 Jan 2019

I have a problem with running MHW through proton. So I can launch the game through it, get pass the logos, loading screens, and load into the town. The game will play fine for a bit but will eventually crash where everything gets frozen in place. At this point I will have to force close the game by killing the wine process. However, upon doing so, I can no longer get past the logos as the screen will be black when I relaunch the game. Essentially, I can not play with MHW with Proton after this happens and must wait for this problem to somehow resolves itself, which it does if I wait for some days...I feel like there are files that needs to be removed to allow Wine to load the game after the logos. Is this true if so what might they be? How do I get beyond this?

I'm using steam proton 3.16-6, Fedora 29, Nvidia driver 415.25

Fatmice on 18 Jan 2019

I have a problem with running MHW through proton. So I can launch the game through it, get pass the logos, loading screens, and load into the town. The game will play fine for a bit but will eventually crash where everything gets frozen in place. At this point I will have to force close the game by killing the wine process. However, upon doing so, I can no longer get past the logos as the screen will be black when I relaunch the game. Essentially, I can not play with MHW with Proton after this happens and must wait for this problem to somehow resolves itself, which it does if I wait for some days...I feel like there are files that needs to be removed to allow Wine to load the game after the logos. Is this true if so what might they be? How do I get beyond this?

I'm using steam proton 3.16-6, Fedora 29, Nvidia driver 415.25

@Fatmice there's 2 things to consider:

Nvidia drivers do unfortunately crash - hence save often and when the game crashes you can then restart from there. I have to say with the latest (415.27) seems slightly more stable (half the crashes)
The game uses a particular version of Microsoft library to play movies (again, not in-game scenes, but movies such as the ones in weapons tutorial) and this library is not implemented in _wine_. As long as you don't watch movies (again like the weapons tutorials) you'll be fine. The only issue you'll have is when you defeat the final monster, then the game will force you to play a movie cutscene and as of now you won't never advance. The solution to this is:
- load the game in windows, save it and move again on Linux
- download the required libraries to play these movies (note these can't be included with _wine_/_proton_ by default because of licensing issues), set them up and allow play movies and carry on

Hope this helps!

Ps. I have almost 130+ hours, it is definitely working fine and playable.

Emanem on 20 Jan 2019

@Emanem I'm not having issues with the in-game movies... I'm having issues with _relaunching the game after it crashes_. It will not get past the Capcom logo after it has crashed as there is nothing but a black screen...I feel like there are some files left over in the wine prefix that needs to be removed to get beyond this? I don't know if Fedora 29 posted 415.27 yet...

Fatmice on 21 Jan 2019

By everything I don't mean that I've played far from the beginning, in part due to a strange issue with my keyboard suddenly being lost to the game at times. Never seen this one before. Mouse control is still fine at the time, and the keyboard otherwise works. The game just doesn't respond to any keys I press, and I have to terminate it.

This is my major pain point right now. Every hour or so the keyboard just stops working. This makes me kill -9 the process and reload the game. Given the auto-save nature this also means quite a bit of lost progress every time. I can avoid the videos crashing; I kind of need the keyboard to actually play.

greydmiyu on 25 Jan 2019

@Emanem I'm not having issues with the in-game movies... I'm having issues with _relaunching the game after it crashes_. It will not get past the Capcom logo after it has crashed as there is nothing but a black screen...I feel like there are some files left over in the wine prefix that needs to be removed to get beyond this? I don't know if Fedora 29 posted 415.27 yet...

@Fatmice FYI, the non-free rpmfusion repo has 415.27 driver already.

ljn917 on 25 Jan 2019

Updated to 415.27, no change, still black screen after the Capcom Logo upon relaunching game once MHW crashed.

Fatmice on 25 Jan 2019

@Fatmice It is loading save file after the Capcom logo. I guess, unfortunately, your save file might be corrupted during the crash. You can try to backup first and then remove the original save file.

ljn917 on 26 Jan 2019

@ljn917 no unlikely because I can transfer that file to my windows machine and it will load up fine.

Fatmice on 26 Jan 2019

@Plagman Out of curiosity, do you know if someone at Nvidia is looking into this drivers issue?

Emanem on 29 Jan 2019

👀1

A possible fix for the game:
https://github.com/doitsujin/dxvk/issues/728#issuecomment-459839962

Ahmed-E-86 on 1 Feb 2019

👍1

@ahmed-elsayed2017 tried that fix but game still crashes when I try to play tutorial videos (only videos tested). Looks like it's trying to use the mfplat file but something goes wrong when it does.
mfplat.dll v12.0.7601.23471 64-bit with MD5: 2188de5fa5c741fb2b81eb9f37d26ba7
steam-582010.log

fgblomqvist on 5 Feb 2019

Some games needs MF + WMP installed to be able to play the videos. WMP is a problematic component, because it can be only be installed in 32bit prefix only. It is an old issue that wine developers ignore like what they are doing now with WMF problem, and they are working on DX9/DX10/DX11/DX12 to Vulkan for their official Wine right now, and fixing a combination of old and new bugs to increase the number of working games on Wine/Proton, so don't expect any fix for other issues any time soon!

Ahmed-E-86 on 5 Feb 2019

@ahmed-elsayed2017 ah I see. Bummer. Thanks for the detailed explanation though!

fgblomqvist on 5 Feb 2019

currently broken for me, can't seem to work out why.
steam.txt using 3.16-6 beta right now

prototype99 on 5 Feb 2019

A patch is coming to Winetricks to add the files needed for some games needs Media Foundation native dlls. It could be better than the manual fix.

https://github.com/Winetricks/winetricks/issues/1132

Ahmed-E-86 on 5 Feb 2019

👍2

@ahmed-elsayed2017 I believe the proton team is working on a fix for it as well.

fgblomqvist on 5 Feb 2019

👍1

A possible fix for the game:
doitsujin/dxvk#728 (comment)

Did this fix the freeze problem at least ? :D
PS: the variable rnd freeze throughout the game is what I'm talking about
PSS: > @fgblomqvist I believe the proton team is working on a fix for it as well.
i rly hope so :(

Lelo91 on 6 Feb 2019

@Lelo91 I haven't gotten a single freeze/crash since I bought a new computer with much more powerful hardware (e.g. the game is no longer putting a 100% load on my GPU). Quite odd, but yeah idk.

fgblomqvist on 6 Feb 2019

@fgblomqvist

hmm i got a relatively new system too and while the game runs it runs just fine, very confused about this bug only thing that makes it a little better is the everywhere mentioned powermizer option

PS: besides i did fresh install ubuntu 18.04 a few days ago in desperate ambition to get rid of the freezes and choose the nvidia probrietary driver 410.93 instead of the updatecenter ones, made some improvements on the time scaling til a freeze occurs, but if i get a freeze i'm no longer able to just tab out in any way and kill the gameprocess, hardresets hurt my fingers every time
PSS:
CPU: AMD Athlon 200GE
GPU: Nividia 1060 3GB
RAM: 8GB
MB: Asus Prime 450m-k

Lelo91 on 6 Feb 2019

@Lelo91 I haven't gotten a single freeze/crash since I bought a new computer with much more powerful hardware (e.g. the game is no longer putting a 100% load on my GPU). Quite odd, but yeah idk.

I've had this game for running for several hours at a time with an RX580 on Arch, no problems or crashes.

I tried with my RX460 with 2GB of VRAM and it would let you load into the game, and then as soon as you move the camera it would crash and freeze Xorg.

Maybe people here with crashes are running out of VRAM? Or less powerful hardware just crashes it.

z0z0z on 7 Feb 2019

@z0z0z I was running it on a GTX 1060 Ti at 40-50 fps and then I upgraded to an RTX 2080 Ti where I run it maxed out at ~70-80 fps. I think either the VRAM thing could be an issue, or the game simply gets unstable for some reason when it can't render at at least a certain speed (wouldn't surprise me since it's a console port after all). Even though it ran at 40-50 it def. dropped below 30 at times.

fgblomqvist on 7 Feb 2019

I had several crashes with Geforce 1070 (laptop). I think all of them were
in arena quests.

On Wed, Feb 6, 2019, 18:18 z0z0z notifications@github.com wrote:

@Lelo91 https://github.com/Lelo91 I haven't gotten a single
freeze/crash since I bought a new computer with much more powerful hardware
(e.g. the game is no longer putting a 100% load on my GPU). Quite odd, but
yeah idk.

I've had this game for running for several hours at a time with an RX580
on Arch, no problems or crashes.

I tried with my RX460 with 2GB of VRAM and it would let you load into the
game, and then as soon as you move the camera it would crash and freeze
Xorg.

Maybe people here with crashes are running out of VRAM? Or less powerful
hardware just crashes it.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/175#issuecomment-461227416,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABY5ni1KbNpzzTc0JSYqw6Ys5f4EysbZks5vK2LegaJpZM4WIe20
.

ljn917 on 7 Feb 2019

@fgblomqvist I've played the game at the framerates you describe on Windows without any crashes. I think if the instability is framerate dependent, then it is likely a result of an underlying problem in the Proton stack (ed: or in LInux drivers or such).

InvalidInterrupt on 7 Feb 2019

👍1

Maybe people here with crashes are running out of VRAM?

That's one of my guesses, too. I started to get them freezes as well, while writing a test report (Vanilla Wine) for the Wine AppDB. [1]

I have a GTX 960 with only around 2 GiB of memory, which tends to be at 99-100% used at all times, if using a 1080p resolution (with graphics settings set to as low as possible for the most part).

I set the resolution to 900p, and it seemed to make things better, for a time, starting at around 85%, but it seems to eventually climb up regardless (leaks?).

How much is the game using from cards with more memory?

https://appdb.winehq.org/objectManager.php?sClass=version&iId=37601&iTestingId=104892

Chiitoo on 7 Feb 2019

@z0z0z @Chiitoo I tested on my laptop for the possibility of out-of-memory. It used about 3.5 GB on my Geforce 1070 (laptop version, 8GB VRAM). The crash did not cause spike in VRAM.

If you only have 2GB VRAM, it is likely that it will be out of VRAM, but in other cases (VRAM > 4GB), I think the sporadic crashes were not related to VRAM usage.

ljn917 on 8 Feb 2019

@ljn917,

Just to be sure, you mean the 'hang with music still playing' situation?

Thanks!

Chiitoo on 9 Feb 2019

Yes

On Sat, Feb 9, 2019, 08:02 Chiitoo notifications@github.com wrote:

@ljn917 https://github.com/ljn917,

Just to be sure, you mean the 'hang with music still playing' situation?

Thanks!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/175#issuecomment-462042797,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABY5noigVg_bzVi-AkMxbIsy5GgfxDVjks5vLsbkgaJpZM4WIe20
.

ljn917 on 9 Feb 2019

i found a "possible fix" for windows machines, but don't have one myself to test, maybe someone with some expertise and the right stuff at hand wants to look insight of the fix, it claims to fix freezes and stuttering on MH:W, here a facebook link:
deleted the link because i did not test it and many declared it as virus/spyware

EDIT: since installing win10 i got no freezes anymore without testing the fix all are so wary about, so didn't test it, not sure if its because of win10 or maybe a the new nvidia driver which fixxed it now for me on win10

Lelo91 on 9 Feb 2019

👎4

That post looks suspicious AF

Xaenalt on 9 Feb 2019

That post looks suspicious AF

I'm actually taking the risk myself, installing win10 and test it, will let you know if its worth looking into

Lelo91 on 9 Feb 2019

That post looks suspicious AF

I'm actually taking the risk myself, installing win10 and test it, will let you know if its worth looking into

That is clearly a virus/spyware and whatnot...

Emanem on 10 Feb 2019

Another note, since I got back into it and started testing again, when it occurs, I was able to take a look at top, Xorg was spinning at 100%, while the game was at a normal 80ish%

Xaenalt on 13 Feb 2019

AHA Gotcha!

Feb 12 20:50:11 graviton.localdomain kernel: NVRM: Xid (PCI:0000:01:00): 31, Ch 0000009b, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_T1_8 faulted @ 0x0_00000000. Fault is of type FAULT_PDE ACCESS_TYPE_READ

That showed up in the journal right as the game went into full lockup mode

According to Nvidia's manual, that's a GPU memory page fault, either a driver bug or user app error

Any ideas how to track it down further?

Xaenalt on 13 Feb 2019

Ok, found cuda-memcheck, going to see if I can get it to run under that and maybe we'll finally find the freeze bug!

Xaenalt on 13 Feb 2019

Hmmm, trying to attach cuda-gdb to it seems to cause it to crash, but I'm no gdb expert, anyone had any luck attaching debuggers to it?

Xaenalt on 13 Feb 2019

Not sure if you are aware of this
https://github.com/doitsujin/dxvk/issues/816

Most games have very strong antidebugging measures... I am thinking of
adding windows_print_stacktrace() in dxvk to print the stack trace.

On Tue, Feb 12, 2019, 21:46 Sean Pryor notifications@github.com wrote:

Hmmm, trying to attach cuda-gdb to it seems to cause it to crash, but I'm
no gdb expert, anyone had any luck attaching debuggers to it?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/175#issuecomment-463033810,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABY5npo47lv25JfnwojOk8cJjysqXNLRks5vM3x-gaJpZM4WIe20
.

ljn917 on 13 Feb 2019

Ah, so someone else already found the root error message

Yeah, I figured, through my first attempt at gdb, the game did run while attached, but transitions seemed to kill it

I'll see if some of the stuff in that other thread can help

Xaenalt on 13 Feb 2019

Managed to get cuda-gdb attached to it, fingers crossed!

To get cuda-gdb attached, you'll need to do the following:

Start MHW and get into the game proper. The early menu screens will crash if you attach early
ps aux | grep MonsterHunterWorld.exe # Note the PID of the actual executable
cuda-gdb
# The rest of these inside the cuda-gdb shell
handle SIGUSR1 nostop noprint
handle SIGQUIT nostop noprint
set cuda api_failures stop
attach <mhw pid from above>
continue

At this point the game will run, and hopefully will give us a nice backtrace when the null pointer deref occurs

Xaenalt on 14 Feb 2019

Any ideas how to track it down further?

Just had the crash w/music playing that locks X problem. Had to SSH in via my phone to kill MHW. However, searching for NVRM I saw a dump indicating that Steam was the one that died. My Firefox session was still up, but Steam had indeed died. Maybe some interaction with Steam is causing it?

greydmiyu on 15 Feb 2019

Hmmm, that would explain why gdb wasn't catching the crash from MHW's process

Xaenalt on 15 Feb 2019

MHW has many threads. I think the render thread is not the main thread.

On Fri, Feb 15, 2019, 10:19 Sean Pryor notifications@github.com wrote:

Hmmm, that would explain why gdb wasn't catching the crash from MHW's
process

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/175#issuecomment-464087135,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABY5nrpluD2wfHy4RCEIFjCkxb_-xHVBks5vNtACgaJpZM4WIe20
.

ljn917 on 15 Feb 2019

My fear is that the issue would be that DXVK is referring to a valid _handle_, but the the underlying memory get deallocated by the driver without _reassigning_ the resource itself (i.e. not a DXVK bug, but simply a bug in the drivers).

After all doesn't happen on AMD and is relatively common on Nvidia.

Emanem on 16 Feb 2019

I'm having the full system lockups on my machine with an AMD card:
GPU: RX590
Drivers: 18.3.3 (RADV)
CPU: i7 6700k
linux Dist: Manjaro(Arch) - 4.19 Kernel

Weird thing is i have to power off the pc using the power button. Neither SSH or the reset button seem to work. This only happens to me consistently during the Vaal Hazak fight. That, coupled with the fact that turning Volume rendering down made the game last longer before crashing, makes me think that this error is related to particle rendering somehow (since this specific monster uses an absurd amount of particle effects)

xantyleonhart on 6 Mar 2019

Hmmm, to help diagnose it, can you do two steps:
Go into the Steam directory (~/.local/share/Steam on my system) go to steamapps/common and then to the directory for the version of Proton that you're using. Then mv user_settings.py.sample to user_settings.py

In there, set two values (they can be the same run or different)
DXVK_SHADER_DUMP_PATH=/some/path (make sure /some/path exists, a lot of files will get dumped here). Setting this may affect framerate slightly, but should still be playable

The second requires the LunarG sdk, you can find instructions here https://vulkan.lunarg.com/doc/sdk/1.1.101.0/linux/getting_started.html on how to install it

Once you have that set up, make sure that you source the rc file before starting MHW. I created a launcher icon and in the .desktop file source the script before launching. It does require that to be the thing that launches Steam, and doesn't seem to persist, but it does the job for single runs of debugging with the following option

VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_api_dump this will produce a massive amount of output in /tmp/dumps/$(whoami)_stdout.log, I ended up having to mount a spare disk at /tmp/dumps (and I'd suggest putting it on persistent storage if you end up rebooting anyway). Additionally, it will absolutely destroy your framerate, but it should gather all the possible debugging info.

Uploading both of those should assist in the debugging process

Xaenalt on 6 Mar 2019

Hmmm, to help diagnose it, can you do two steps:
Go into the Steam directory (~/.local/share/Steam on my system) go to steamapps/common and then to the directory for the version of Proton that you're using. Then mv user_settings.py.sample to user_settings.py

In there, set two values (they can be the same run or different)
DXVK_SHADER_DUMP_PATH=/some/path (make sure /some/path exists, a lot of files will get dumped here). Setting this may affect framerate slightly, but should still be playable

The second requires the LunarG sdk, you can find instructions here https://vulkan.lunarg.com/doc/sdk/1.1.101.0/linux/getting_started.html on how to install it

Once you have that set up, make sure that you source the rc file before starting MHW. I created a launcher icon and in the .desktop file source the script before launching. It does require that to be the thing that launches Steam, and doesn't seem to persist, but it does the job for single runs of debugging with the following option

VK_INSTANCE_LAYERS=VK_LAYER_LUNARG_api_dump this will produce a massive amount of output in /tmp/dumps/$(whoami)_stdout.log, I ended up having to mount a spare disk at /tmp/dumps (and I'd suggest putting it on persistent storage if you end up rebooting anyway). Additionally, it will absolutely destroy your framerate, but it should gather all the possible debugging info.

Uploading both of those should assist in the debugging process

I think i've finally solved it. When my system crashed it did crash completely, nothing would work, not even ctrl+alt+del or ctrl+alt+f1, not even ssh in (i would get a host unreachable message). So i thought that maybe the problem was CPU-related, since a GPU crash wouldn't kill it to such an extent. (one thing is to have all graphical output dead, and a very different thing is to have everything dead, including the reset button). So i ended up adding the PROTON_NO_ESYNC=1 option for the game, as well as increasing the open file limit on my OS (just in case):
https://www.reddit.com/r/SteamPlay/comments/9kqisk/tip_for_those_using_proton_no_esync1/
I managed to do the entire fight without a single crash, so i think this might have indeed fixed it, or at least made it more stable.

xantyleonhart on 6 Mar 2019

So I tried the media foundation fix for the first time. Like this just to ensure people I'm doing it right

winetricks mf
export WINEPREFIX='/home/user/STEAM/steamapps/compatdata/582010/pfx'
Uncommented lines 129-137 in installcab.py
Placed "python2" before lines 3-8 of install-mf-64.sh
Ran install-mf-64.sh, output seemed correct
Placed mfplat.dll (md5sum 2188de5fa5c741fb2b81eb9f37d26ba7) inside directory with MonsterHunterWorld.exe

Basically, it don't work. The ending cutscene "Denouement" from the gallery crashes in the loading screen still.

The weapon tutorial cutscenes don't always crash now however, and they show graphical corruption where the video is supposed to play. Pic related.

Here is a log of me running the game and immediately trying to play the Denouement cutscene from the gallery. I have only included the bottom of the log as there is 250,000 lines of dinput8 nonsense spam otherwise.

https://gist.github.com/z0z0z/e110687cc79dfcc5a172916762dc9659

z0z0z on 13 Mar 2019

I have found a method that works. I can now play the weapon tutorial movies and the final cutscene.

I am not sure where I found this workaround, but it was from a zip file called "WMF_workaround.zip" I downloaded at some point. It included DLLs so I don't think I can post here anyway.

Basically you need these dlls from system32 from Windows 7. This is their md5sum and filename

20ecac7791dcba69121631cb627e5a96  mf.dll
c6b15f0d5ab0bd0aefc0223f14deb3f9  mferror.dll
54b5dcd55b223bc5df50b82e1e9e86b1  mfplat.dll
e8706a051bffc9da9e9b935aaa432aac  mfreadwrite.dll
35e81aa554e60d395572e780ef3b60cb  msmpeg2adec.dll
e793d5bc2d58797235741eba61dc56b8  msmpeg2vdec.dll
27b9e163740a226b65e4b9e186117911  sqmapi.dll

And these files from syswow64.

fdba1dec4f9be4274a00b9b850c63484  mf.dll
92050e12bd24f365a8b8eddf912a3b1e  mferror.dll
40b82688907a7dba4db3b5adde3eab3b  mfplat.dll
bfebb6f76a0988a38260870c61a6d1b7  mfreadwrite.dll
2829ea1cda353987b5552db955f3b736  msmpeg2adec.dll
3de43bfdaf3f8979699650202aa18b12  msmpeg2vdec.dll
ce292c4c10b8db6070f262ea2733f0dc  sqmapi.dll

You put these in the corresponding system32 and syswow64 folders in the MHW Wine prefix located in steamapps/compatdata/582010/pfx/drive_c/windows

Then you also need these 2 registry files, "mf.reg" and "wmf.reg".

https://gist.github.com/z0z0z/7d535c810cc08dae5bafa68030b96212
https://gist.github.com/z0z0z/d2a937110847bd488716f91dfb6d9dd1

Run the following steps all in the same terminal instance, so the WINEPREFIX environment variable stays set:

export WINEPREFIX="/home/user/my_steam_dir/steamapps/compatdata/582010/pfx"
winecfg

Set all the DLLs to native in winecfg.

Run (obviously in the same directory you downloaded mf.reg and wmf.reg)

wine start regedit.exe mf.reg
wine start regedit.exe wmf.reg
wine64 start regedit.exe mf.reg
wine64 start regedit.exe wmf.reg
wine64 regsvr32 msmpeg2vdec.dll
wine64 regsvr32 msmpeg2adec.dll
wine regsvr32 msmpeg2vdec.dll
wine regsvr32 msmpeg2adec.dll

z0z0z on 13 Mar 2019

👍1

I have found a method that works. I can now play the weapon tutorial movies and the final cutscene.

...

This should be made into a _legit_ script of some sorts which downloads the correct DLLs from a Microsoft site.
Awesome work @z0z0z btw!

Emanem on 15 Mar 2019

I think winetricks people tried that, but they did not find the dlls in any
packages on microsoft website.

On Fri, Mar 15, 2019, 13:55 Emanem notifications@github.com wrote:

I have found a method that works. I can now play the weapon tutorial
movies and the final cutscene.

...

This should be made into a script of some sorts which downloads the
correct DLLs from a Microsoft site.
Awesome work, btw!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/175#issuecomment-473384782,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABY5nujuRcanCPsndS8K6kTQK8woF2Lqks5vW953gaJpZM4WIe20
.

ljn917 on 15 Mar 2019

@z0z0z I tried your fix using the .dlls from my current Win10 install and this was my output:

[administrator@CM-Sandy ~]$ wine start regedit.exe mf.reg
0009:fixme:exec:SHELL_execute flags ignored: 0x00000100
[administrator@CM-Sandy ~]$ wine start regedit.exe wmf.reg
002d:fixme:exec:SHELL_execute flags ignored: 0x00000100
[administrator@CM-Sandy ~]$ wine64 start regedit.exe mf.reg
0031:fixme:exec:SHELL_execute flags ignored: 0x00000100
[administrator@CM-Sandy ~]$ wine64 start regedit.exe wmf.reg
0035:fixme:exec:SHELL_execute flags ignored: 0x00000100
[administrator@CM-Sandy ~]$ wine64 regsvr32 msmpeg2vdec.dll
regsvr32: Failed to load DLL 'msmpeg2vdec.dll'
[administrator@CM-Sandy ~]$ wine64 regsvr32 msmpeg2adec.dll
regsvr32: Failed to load DLL 'msmpeg2adec.dll'
[administrator@CM-Sandy ~]$ wine regsvr32 msmpeg2vdec.dll
regsvr32: Failed to load DLL 'msmpeg2vdec.dll'
[administrator@CM-Sandy ~]$ wine regsvr32 msmpeg2adec.dll
regsvr32: Failed to load DLL 'msmpeg2adec.dll'

As expected, the game still crashes immediately when loading my post Xeno save. Do the Win7 .dlls need to be used or did I do something wrong along the way?

Nyshan on 20 Mar 2019

@Nyshan

As expected, the game still crashes immediately when loading my post Xeno save. Do the Win7 .dlls need to be used or did I do something wrong along the way?

I've heard it needs to be specifically Win7 DLLS. Maybe check protondb or something.

Make sure you're setting them to native winecfg.

z0z0z on 20 Mar 2019

Win10 dlls have issues with wine, win7 dlls needed.

lieff on 20 Mar 2019

Using Win7 .dlls changed my output to the below, game still crashes on load:
I checked the MD5SUMS as well before I moved everything and everything matched what you listed.

administrator@linux-hd8q:~/util/mhw_fix> wine start regedit.exe mf.reg
0009:fixme:exec:SHELL_execute flags ignored: 0x00000100
administrator@linux-hd8q:~/util/mhw_fix> wine start regedit.exe wmf.reg
002f:fixme:exec:SHELL_execute flags ignored: 0x00000100
administrator@linux-hd8q:~/util/mhw_fix> wine64 start regedit.exe mf.reg
0033:fixme:exec:SHELL_execute flags ignored: 0x00000100
administrator@linux-hd8q:~/util/mhw_fix> wine64 start regedit.exe wmf.reg
0037:fixme:exec:SHELL_execute flags ignored: 0x00000100
administrator@linux-hd8q:~/util/mhw_fix> wine64 regsvr32 msmpeg2vdec.dll
003b:fixme:ntdll:EtwEventRegister ({f404b94e-27e0-4384-bfe8-1d8d390b0aa3}, 0x7ff385dce74, 0x7ff3861f800, 0x7ff3861f118) stub.
003b:fixme:ntdll:EtwEventRegister ({bc97b970-d001-482f-8745-b8d7d5759f99}, 0x7ff385dce74, 0x7ff3861f7d0, 0x7ff3861f110) stub.
003b:fixme:ntdll:EtwRegisterTraceGuidsW (0x7ff7277d18c, 0x7ff7279a1b0, {e2821408-c59d-418f-ad3f-aa4e792aeb79}, 1, 0x23f5a0, (null), (null), 0x7ff7279a1b8): stub
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {e2821408-c59d-418f-ad3f-aa4e792aeb79}
003b:fixme:ntdll:EtwRegisterTraceGuidsW (0x7ff56de1b6c, 0x261d00, {ae5cf422-786a-476a-ac96-753b05877c99}, 59, 0x261db0, (null), (null), 0x261da8): stub
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {924fef1b-8c47-47c4-b2a2-0f798e5197f9}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {8bfbc8d5-e916-40fb-bb35-7a2d4af2e67c}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {0df035c2-4ce4-4c90-91ec-be88a75256a0}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {e69ebe53-f68f-44af-8413-3208e0650cb1}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {9618aaa3-f1b7-4547-8d7d-ecd33a9f5f21}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {6e425425-2cf1-4a56-a342-f9b0be19f959}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {af12b205-0cb3-468a-b974-939c7a9fccb5}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {58d1dcb8-3d39-454b-9d0c-86f13ef40598}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {418b0044-3a99-42e9-bc6b-27aa981c9fcd}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {7a870f24-2d49-4a63-b490-bc3d334c467f}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {6f3f585b-24fe-42c4-9297-a68099d88b78}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {92dbd4ed-8ede-4b81-8f21-08854d1d73a3}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {489cebd7-2ea1-4b7f-a691-fa3832d91653}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {cff7ab7d-bc30-4f86-a8ea-012d68acf443}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {5c42bb3c-1ac3-4a29-b444-a34201cb8c80}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {01c7f2d5-d540-425a-b2d9-de5009328b61}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {cc524410-c384-4bd1-97a6-41ff7675cce6}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {148e90b2-99d4-4c69-acdc-b50376efd9c0}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {11c5ebdd-b374-490a-95d1-0d1bd1fcf62c}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {fcc7ed1d-bfdc-4167-b260-7467400298b3}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {7b704605-fd3c-4c41-93e1-28e24d9d4da2}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {78b20843-da14-425c-9ce9-299cc07c4a74}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {0be12c7b-5a32-4ad1-8b5f-383478d611bf}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {2e06ed10-e950-4caf-9ce8-b3b5bd71e4d0}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {7d931f4b-b3ae-43f3-a09f-cae4ac366dc2}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {67fd805b-8c72-40eb-b338-d1946238196a}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {d8eab3c0-b199-4ddf-9989-7f207e1ef682}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {60c0a470-f195-4c82-b860-6c22fd910bab}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {462ed505-628b-4750-aa0b-8980666c0749}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {f5c049ef-a79d-4eda-a8b9-9098995f1305}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {4edccdc3-acd3-4e58-a8ce-1274f6a5c14b}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {77edd950-3d3b-472a-8375-68f69a3eb708}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {72fc760d-103c-491a-84b0-eb5b979324e2}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {fd85abae-6318-4816-a599-a29827770f56}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {ffbb6354-03a7-4f32-97db-8cb234c03715}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {f485b25e-afd5-4b28-aec8-71c3b44797ff}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {1f1a717a-06e3-48a8-956e-c5bc1e88e043}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {e81ec494-478f-4901-982f-0e402d01e3ec}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {9be3da12-30e5-48d3-ab65-267387448ce4}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {de846c56-3b73-4021-8fd3-bb17a0642d1f}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {ad2dd759-97cd-4a76-945f-f6108b5aaca1}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {827e8d25-fe4e-46f6-b263-ccf41ddca4fd}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {08a2ce94-b603-43e8-9de4-ed09705fe07a}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {c6d167a4-9536-4f66-9c30-b8544a0f9a7f}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {6bed20f7-831f-43d6-9e84-d431893a161f}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {3dfb2b0c-1d54-494c-a508-93c092bc2dd5}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {dcb2aeed-8d4e-4eff-bbdf-52e9f85a964a}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {31f96aab-89fa-4909-93b8-a3ec8252a84b}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {a04cf2a8-40c0-4def-8640-bd0fb7834c58}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {41fbed6a-4396-441b-88ba-79ba9e4f2d9e}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {8d15d110-141f-47f2-958b-e3f197e8eae7}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {3933bc04-15a2-40b0-a6ee-8559928780e2}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {7719a441-b86d-421a-9642-63689a7bf81f}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {7008c05c-33a9-4fec-b010-b7369bc71f73}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {2bd6889f-0a1d-4612-a1f9-6f0c6f01467c}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {62ebe05c-39ef-4170-9c84-aaa3b3d0d8e1}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {6a764b22-a86d-4ca0-9ef8-b2b26d3df464}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {c0785df3-6630-4097-9771-1a22cb7ac173}
003b:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {ed28be9f-fcd9-4cb8-a2ed-b87eccccf7b2}
003b:fixme:reg:RegDisableReflectionKey 0x8c: stub
regsvr32: Successfully registered DLL 'msmpeg2vdec.dll'
003b:fixme:ntdll:EtwUnregisterTraceGuids deadbeef: stub
003b:fixme:ntdll:EtwUnregisterTraceGuids deadbeef: stub
003b:fixme:ntdll:EtwEventUnregister (deadbeef) stub.
003b:fixme:ntdll:EtwEventUnregister (deadbeef) stub.
administrator@linux-hd8q:~/util/mhw_fix> wine64 regsvr32 msmpeg2adec.dll
003d:fixme:ntdll:EtwEventRegister ({f404b94e-27e0-4384-bfe8-1d8d390b0aa3}, 0x7ff385dce74, 0x7ff3861f800, 0x7ff3861f118) stub.
003d:fixme:ntdll:EtwEventRegister ({bc97b970-d001-482f-8745-b8d7d5759f99}, 0x7ff385dce74, 0x7ff3861f7d0, 0x7ff3861f110) stub.
003d:fixme:reg:RegDisableReflectionKey 0x8c: stub
regsvr32: Successfully registered DLL 'msmpeg2adec.dll'
003d:fixme:ntdll:EtwEventUnregister (deadbeef) stub.
003d:fixme:ntdll:EtwEventUnregister (deadbeef) stub.
administrator@linux-hd8q:~/util/mhw_fix> wine regsvr32 msmpeg2vdec.dll
003f:fixme:ntdll:EtwEventRegister ({f404b94e-27e0-4384-bfe8-1d8d390b0aa3}, 0xfdd4df9, 0xfdfdbd0, 0xfdfdbc8) stub.
003f:fixme:ntdll:EtwEventRegister ({bc97b970-d001-482f-8745-b8d7d5759f99}, 0xfdd4df9, 0xfdfdcb0, 0xfdfdca8) stub.
003f:fixme:ntdll:EtwRegisterTraceGuidsW (0x6c116b14, 0x6c13d178, {e2821408-c59d-418f-ad3f-aa4e792aeb79}, 1, 0x33fa70, (null), (null), 0x6c13d180): stub
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {e2821408-c59d-418f-ad3f-aa4e792aeb79}
003f:fixme:ntdll:EtwRegisterTraceGuidsW (0x2772aab0, 0x3614a0, {ae5cf422-786a-476a-ac96-753b05877c99}, 59, 0x361550, (null), (null), 0x361548): stub
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {924fef1b-8c47-47c4-b2a2-0f798e5197f9}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {8bfbc8d5-e916-40fb-bb35-7a2d4af2e67c}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {0df035c2-4ce4-4c90-91ec-be88a75256a0}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {e69ebe53-f68f-44af-8413-3208e0650cb1}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {9618aaa3-f1b7-4547-8d7d-ecd33a9f5f21}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {6e425425-2cf1-4a56-a342-f9b0be19f959}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {af12b205-0cb3-468a-b974-939c7a9fccb5}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {58d1dcb8-3d39-454b-9d0c-86f13ef40598}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {418b0044-3a99-42e9-bc6b-27aa981c9fcd}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {7a870f24-2d49-4a63-b490-bc3d334c467f}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {6f3f585b-24fe-42c4-9297-a68099d88b78}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {92dbd4ed-8ede-4b81-8f21-08854d1d73a3}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {489cebd7-2ea1-4b7f-a691-fa3832d91653}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {cff7ab7d-bc30-4f86-a8ea-012d68acf443}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {5c42bb3c-1ac3-4a29-b444-a34201cb8c80}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {01c7f2d5-d540-425a-b2d9-de5009328b61}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {cc524410-c384-4bd1-97a6-41ff7675cce6}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {148e90b2-99d4-4c69-acdc-b50376efd9c0}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {11c5ebdd-b374-490a-95d1-0d1bd1fcf62c}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {fcc7ed1d-bfdc-4167-b260-7467400298b3}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {7b704605-fd3c-4c41-93e1-28e24d9d4da2}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {78b20843-da14-425c-9ce9-299cc07c4a74}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {0be12c7b-5a32-4ad1-8b5f-383478d611bf}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {2e06ed10-e950-4caf-9ce8-b3b5bd71e4d0}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {7d931f4b-b3ae-43f3-a09f-cae4ac366dc2}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {67fd805b-8c72-40eb-b338-d1946238196a}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {d8eab3c0-b199-4ddf-9989-7f207e1ef682}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {60c0a470-f195-4c82-b860-6c22fd910bab}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {462ed505-628b-4750-aa0b-8980666c0749}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {f5c049ef-a79d-4eda-a8b9-9098995f1305}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {4edccdc3-acd3-4e58-a8ce-1274f6a5c14b}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {77edd950-3d3b-472a-8375-68f69a3eb708}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {72fc760d-103c-491a-84b0-eb5b979324e2}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {fd85abae-6318-4816-a599-a29827770f56}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {ffbb6354-03a7-4f32-97db-8cb234c03715}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {f485b25e-afd5-4b28-aec8-71c3b44797ff}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {1f1a717a-06e3-48a8-956e-c5bc1e88e043}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {e81ec494-478f-4901-982f-0e402d01e3ec}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {9be3da12-30e5-48d3-ab65-267387448ce4}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {de846c56-3b73-4021-8fd3-bb17a0642d1f}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {ad2dd759-97cd-4a76-945f-f6108b5aaca1}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {827e8d25-fe4e-46f6-b263-ccf41ddca4fd}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {08a2ce94-b603-43e8-9de4-ed09705fe07a}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {c6d167a4-9536-4f66-9c30-b8544a0f9a7f}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {6bed20f7-831f-43d6-9e84-d431893a161f}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {3dfb2b0c-1d54-494c-a508-93c092bc2dd5}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {dcb2aeed-8d4e-4eff-bbdf-52e9f85a964a}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {31f96aab-89fa-4909-93b8-a3ec8252a84b}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {a04cf2a8-40c0-4def-8640-bd0fb7834c58}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {41fbed6a-4396-441b-88ba-79ba9e4f2d9e}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {8d15d110-141f-47f2-958b-e3f197e8eae7}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {3933bc04-15a2-40b0-a6ee-8559928780e2}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {7719a441-b86d-421a-9642-63689a7bf81f}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {7008c05c-33a9-4fec-b010-b7369bc71f73}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {2bd6889f-0a1d-4612-a1f9-6f0c6f01467c}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {62ebe05c-39ef-4170-9c84-aaa3b3d0d8e1}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {6a764b22-a86d-4ca0-9ef8-b2b26d3df464}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {c0785df3-6630-4097-9771-1a22cb7ac173}
003f:fixme:ntdll:EtwRegisterTraceGuidsW   register trace class {ed28be9f-fcd9-4cb8-a2ed-b87eccccf7b2}
003f:fixme:reg:RegDisableReflectionKey 0x8c: stub
regsvr32: Successfully registered DLL 'msmpeg2vdec.dll'
003f:fixme:ntdll:EtwUnregisterTraceGuids deadbeef: stub
003f:fixme:ntdll:EtwUnregisterTraceGuids deadbeef: stub
003f:fixme:ntdll:EtwEventUnregister (deadbeef) stub.
003f:fixme:ntdll:EtwEventUnregister (deadbeef) stub.
administrator@linux-hd8q:~/util/mhw_fix> wine regsvr32 msmpeg2adec.dll
0041:fixme:ntdll:EtwEventRegister ({f404b94e-27e0-4384-bfe8-1d8d390b0aa3}, 0xfdd4df9, 0xfdfdbd0, 0xfdfdbc8) stub.
0041:fixme:ntdll:EtwEventRegister ({bc97b970-d001-482f-8745-b8d7d5759f99}, 0xfdd4df9, 0xfdfdcb0, 0xfdfdca8) stub.
0041:fixme:reg:RegDisableReflectionKey 0x94: stub
regsvr32: Successfully registered DLL 'msmpeg2adec.dll'
0041:fixme:ntdll:EtwEventUnregister (deadbeef) stub.
0041:fixme:ntdll:EtwEventUnregister (deadbeef) stub.
administrator@linux-hd8q:~/util/mhw_fix>

Nyshan on 21 Mar 2019

@z0z0z What version of Proton are you using; I've still been unable to get the fix to work with win7 .dlls.
Edit: I wasn't able to get it working on 3.7-8 but it did finally work on 3.16-4.
Edit2: I can no longer load my save using proton 3.7-8.
Edit3: I can load my save again on 3.7-8 but I had to run all of the steps listed in @z0z0z 's fix each time I changed the Proton version MHW was using.

Nyshan on 22 Mar 2019

👍1

still same freezing issue with latest proton v4.2
steam-582010.log

system spec:

inxi -bxxx
System:    Host: linux Kernel: 5.0.3-1-default x86_64 bits: 64 compiler: gcc v: 8.3.1 Desktop: KDE Plasma 5.15.3 tk: Qt 5.12.2 
           wm: kwin_x11 dm: SDDM Distro: openSUSE Tumbleweed 20190324 
Machine:   Type: Desktop Mobo: ASUSTeK model: Z170 PRO GAMING v: Rev X.0x serial: <root required> UEFI: American Megatrends 
           v: 3805 date: 05/16/2018 
Battery:   Device-1: sony_controller_battery_90:fb:a6:df:fa:93 model: N/A serial: N/A charge: N/A status: Full 
CPU:       Quad Core: Intel Core i5-6600K type: MCP arch: Skylake-S speed: 4392 MHz min/max: 800/4400 MHz 
Graphics:  Device-1: NVIDIA GM204 [GeForce GTX 970] vendor: eVga.com. driver: nvidia v: 418.49.04 bus ID: 01:00.0 
           chip ID: 10de:13c2 
           Display: x11 server: X.Org 1.20.4 driver: nvidia compositor: kwin_x11 resolution: 1920x1080~60Hz, 1920x1080~60Hz 
           OpenGL: renderer: GeForce GTX 970/PCIe/SSE2 v: 4.6.0 NVIDIA 418.49.04 direct render: Yes 
Network:   Device-1: Intel Ethernet I219-V vendor: ASUSTeK driver: e1000e v: 3.2.6-k port: f000 bus ID: 00:1f.6 
           chip ID: 8086:15b8 
Drives:    Local Storage: total: 34.34 TiB used: 33.26 TiB (96.9%) 
Info:      Processes: 381 Uptime: N/A Memory: 15.60 GiB used: 4.71 GiB (30.2%) Init: systemd v: 241 runlevel: 5 
           target: graphical.target Compilers: gcc: 8.3.1 alt: 8 Shell: bash v: 5.0.2 running in: yakuake inxi: 3.0.32

ahjolinna on 27 Mar 2019

Fossilize ERROR: Failed to record graphics pipeline: pNext in VkPipelineRasterizationCreateInfo not supported.
Fossilize ERROR: Failed to record graphics pipeline: pNext in VkPipelineRasterizationCreateInfo not supported.

There's more than 1000 lines trying to call VkPipelineRasterizationCreateInfo is that a vulkan method that isn't fully supported yet getting called?

cj360 on 31 Mar 2019

I got this error after the with the new highres texture pack (installed & enabled):
Screenshot_20190405_001347
I was using the latest proton v4.2(-2)

the log: steam-582010.log

before this error it did run just suprisingly fine...a solid 30fps, even when it shouldn't be able run on my gpu (GTX970)...well according to the requirement at least, the new AA option was way more demanding than the highres textures

ahjolinna on 4 Apr 2019

What i need to play thins game without any crashes?
Proton 4.2-2
Do i need install MFPlat? Do i need ffmpeg?

XakepSDK on 5 Apr 2019

@XakepSDK
You need an MFplat workaround, which can't be posted here because it includes dll files from Windows 7.

Check protondb for links.

z0z0z on 5 Apr 2019

@z0z0z
Thank you!
@kisak-valve
This info should be in first post.

XakepSDK on 5 Apr 2019

Did anyone see "wine: Unhandled page fault on write access to 0x00000000 at address 0x7f8fdaf1fef3 (thread 003e)" (line 25940 in the log)? I accepted a quest, and then the game crashed and terminated.

Distro: Fedora 29
Kernel: 5.0.6-200.fc29.x86_64
GPU: GTX 1070 (laptop)
Driver: nvidia 418.56
CPU: Intel(R) Core(TM) i7-8750H CPU @ 2.20GHz
RAM: 32GB
Proton: 4.2-2 (dxvk commit fd9a938)

steam-582010.zip
SystemInfo.txt

ljn917 on 13 Apr 2019

MHW works beautifully for me (besides video, but I've already completed the main game so it isn't a big deal), but it has a major issue. Anytime I hit enter in a text field the game loses my keyboard. I can no longer do anything with the keyboard EXCEPT typing, but controllers still work so I can still finish the mission or exit out of the game. This happens with the Steam runtime, native libraries, and Linux Steam Integration.

Distro: Arch Linux (with testing repos enabled)
Kernel: 5.0.8.arch1-1
GPU: GTX 1060 6gb
Driver: nvidia 418.56-8
CPU: AMD Ryzen 5 1600X
RAM: 16 GB
Proton: 4.2-3

CalebQ42 on 22 Apr 2019

MHW works beautifully for me (besides video, but I've already completed the main game so it isn't a big deal), but it has a major issue. Anytime I hit enter in a text field the game loses my keyboard. I can no longer do anything with the keyboard EXCEPT typing, but controllers still work so I can still finish the mission or exit out of the game. This happens with the Steam runtime, native libraries, and Linux Steam Integration.

Distro: Arch Linux (with testing repos enabled)
Kernel: 5.0.8.arch1-1
GPU: GTX 1060 6gb
Driver: nvidia 418.56-8
CPU: AMD Ryzen 5 1600X
RAM: 16 GB
Proton: 4.2-3

Yes, I noticed that too. But it seems to be a new bug. Easily reproduce able if you want to name a item set or something like that.
You could test it with older proton versions to see if this was introduced via a Proton (wine) update or is a new MHW bug itself.

buscher on 22 Apr 2019

But it seems to be a new bug.

It isn't. One of the first mentions of it is back in October. I've had it since at least the 3.16 series.

greydmiyu on 23 Apr 2019

MHW works beautifully for me (besides video, but I've already completed the main game so it isn't a big deal), but it has a major issue. Anytime I hit enter in a text field the game loses my keyboard. I can no longer do anything with the keyboard EXCEPT typing, but controllers still work so I can still finish the mission or exit out of the game. This happens with the Steam runtime, native libraries, and Linux Steam Integration.
Distro: Arch Linux (with testing repos enabled)
Kernel: 5.0.8.arch1-1
GPU: GTX 1060 6gb
Driver: nvidia 418.56-8
CPU: AMD Ryzen 5 1600X
RAM: 16 GB
Proton: 4.2-3

Yes, I noticed that too. But it seems to be a new bug. Easily reproduce able if you want to name a item set or something like that.
You could test it with older proton versions to see if this was introduced via a Proton (wine) update or is a new MHW bug itself.

I can recall having this bug since the game came out, so it's definitely not a new bug. Lead me to purchasing a controller specifically to avoid this problem.
The bug doesn't seem to occur 100% of the time since after some accidental openings of the chat it still worked.
Text and Chat seem to work just fine on native Windows so I would guess it's not the games direct fault.

Tested on almost every version of proton and title update of Monster Hunter

Estard on 11 May 2019

I was having this issue and found that it was an issue with my steam launch options. I had killall compton && %command%; compton -b --config ~/.config/compton.blur.conf & set to kill compton and restart it on exit, however it seemed to cause system locks with some games and others the processes would linger until a full reboot.

It's probably a different reason to everyone here but it migh help some. This was on

Distro: Manjaro i3
Kernel: 4.19.42-1-MANJARO
GPU: RX480 8GB
Driver: 4.5 (Core Profile) Mesa 19.0.4
CPU: i5 6600k
RAM: 16 GB
Proton: 4.2-4

Riiskyy on 23 May 2019

This sript works like a charm with MHW and dauntless, but is it legal? <Link removed by moderator>

blastermaster77 on 3 Jun 2019

👍1

Hello @blastermaster77, no, it is not.

kisak-valve on 3 Jun 2019

Ok good to know, hope there is a fix for it thanks for the reply

On Mon, Jun 3, 2019, 1:06 PM kisak-valve notifications@github.com wrote:

Hello @blastermaster77 https://github.com/blastermaster77, no, it is
not.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/175?email_source=notifications&email_token=ACHAHPURT424F3GLPVT3AR3PYVFRBA5CNFSM4FRB5W2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW2BXEY#issuecomment-498342803,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACHAHPQF2Y2PHAVNEIGJ5M3PYVFRBANCNFSM4FRB5W2A
.

blastermaster77 on 3 Jun 2019

The newly released proton (4.2-8) has a regression that cuases MHW to crash within 1-2 seconds of loading into the game (but the main menu works fine). I have a nvidia GPU but I can confirm this issue occurs on AMD GPUs as well. Downgrading to Proton 4.2-7 fixes the issue.

Distro: Arch (i3-gaps)
Kernel: 5.1.15-arch1-1-ARCH
GPU: GTX1070
Driver: 430.26
CPU: i5-6600k
RAM: 32GB
Proton: 4.2-8

ConnorJC3 on 26 Jun 2019

Hello @ConnorJC3, please add PROTON_LOG=1 %command% to the game's launch options, reproduce the crash, and drag and drop the generated $HOME/steam-$APPID.log into the comment box.

kisak-valve on 26 Jun 2019

@ConnorJC3 I'm not having this issue with Proton 4.2-8. Worth noting, I have done the Windows 7 media foundation DLLs workaround to get the cinematics working.

OpenSUSE Tumbleweed, KDE, Kernel 5.1.7-1-default
AMD Fury X using Mesa 19.0.5

meowmeowfuzzyface on 27 Jun 2019

Hello @ConnorJC3, please add PROTON_LOG=1 %command% to the game's launch options, reproduce the crash, and drag and drop the generated $HOME/steam-$APPID.log into the comment box.

I'm having the same issue.

Distro: Arch
DE: XFCE
Kernel: 5.1.15-arch1-1-ARCH
GPU: Nvidia 1060 (6gb version)
Driver: 430.26-7
CPU: i5-3550
RAM: 16GB
Proton: 4.2-8
MHW Launch Options: PROTON_NO_ESYNC=1 PROTON_LOG=1 %command%
Log file: steam-582010.log

Same issue happens. Menus work, up-to-and-including the character selection screen. Once the save is loaded, about 0.5s to 1s the game freezes for a moment, then quits to the desktop.

The only thing of note to change, as far as packages go, was harfbuzz and mesa, which changed like so:

mesa (19.1.0-3 -> 19.1.1-1)
lib32-mesa (19.1.0-2 -> 19.1.1-1)

ndegruchy on 27 Jun 2019

Interestingly, I can no longer reproduce the issue on either proton 4.2-7 or 4.2-8? @ndegruchy try completely clearing your proton install directory and validating files.

ConnorJC3 on 27 Jun 2019

👍1

Interestingly, I can no longer reproduce the issue on either proton 4.2-7 or 4.2-8? @ndegruchy try completely clearing your proton install directory and validating files.

After I posted above, I was able to play for a bit using 3.16-4. I'll try your suggestion next.

For consistency, here's the log:
steam-582010.log

ndegruchy on 27 Jun 2019

Test with a freshly installed Proton 4.2-8 (thanks, @ConnorJC3). It works! I wasn't able to play test as much, but it does work for significantly longer than before.

New log, for consistency: steam-582010.log

ndegruchy on 27 Jun 2019

And now, after 2 quests, I'm back to crashing with 100% consistency upon loading into the lobby area: steam-582010.log

ConnorJC3 on 27 Jun 2019

Been messing around with launching MHW on the latest proton. Not only have I not made it past loading into the tradeyard, steam either quits while the game is running, or MHW crashing also crashes steam all together.
steam-582010.log

DigitalDevilSummoner on 27 Jun 2019

I installed the game and it crashes on load.

Proton: 4.2-9 (freshly installed)
Distro: Ubuntu 18.04.2 LTS
Kernel: 047.15.0-52-generic
CPU: AMD Ryzen 5 2600
GPU: ATI Radeon HD5570
GPU-Drivers: Radeon 4.15.0-52-generic
RAM: 16 GB

Daybreakerflint on 28 Jun 2019

And here the log.
steam-582010.log

I installed the game and it crashes on load.

Proton: 4.2-9 (freshly installed)
Distro: Ubuntu 18.04.2 LTS
Kernel: 047.15.0-52-generic
CPU: AMD Ryzen 5 2600
GPU: ATI Radeon HD5570
GPU-Drivers: Radeon 4.15.0-52-generic
RAM: 16 GB

Daybreakerflint on 28 Jun 2019

Hello @Daybreakerflint, an ATi Radeon HD 5570 is a Terascale 2 generation video card. All Terascale cards do not support Vulkan, which is used by DXVK in Proton to translate DirectX 11 to Vulkan.

Your video card is unsupported, but you may have some luck by adding PROTON_USE_WINED3D=1 %command% to the game's launch options in order to tell Proton to use the DirectX 11 to OpenGL render path.

kisak-valve on 28 Jun 2019

Latest update (4.2-9) may have fixed this? Don't want to call it for sure yet, but several hours of gameplay in and no crashes yet.

ConnorJC3 on 28 Jun 2019

Hello @kisak-valve
Well it did something... the game started up but then crashed short after. I only saw a black screen. Even with the command it doesn't do what it should. I'll need a new graphics card anyway soon. Thanks for your help! It runs on my laptop at least. ;)

Daybreakerflint on 29 Jun 2019

After some some more extensive testing. It seems like it’s performing as well as can be expected. I had one freeze that I had to swap to a VT to kill, but other than that, it works.

I’ve noticed, however, the compositor in XFCE and Compton back off much more extensively than KDE/Plasma. I see a noticeable drop in frames inside KDE, where Xfce or Compton are just fine, even on slightly higher settings. Not sure if this is a proton issue or a Kwin issue, though.

Nathan DeGruchy
http://degruchy.org

On Jun 29, 2019, at 16:21, Daybreakerflint <[email protected]notifications@github.com> wrote:

Hello @kisak-valvehttps://github.com/kisak-valve
Well it did something... the game started up but then crashed short after. I only saw a black screen. Even with the command it doesn't do what it should. I'll need a new graphics card anyway soon. Thanks for your help! It runs on my laptop at least. ;)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHubhttps://github.com/ValveSoftware/Proton/issues/175?email_source=notifications&email_token=AMOXOEKLNXZDNQ5PTUMRC6LP4674FA5CNFSM4FRB5W2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODY37RQI#issuecomment-506984641, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AMOXOEPH437U2YZGOKZ7R7DP4674FANCNFSM4FRB5W2A.

ndegruchy on 1 Jul 2019

Fedora 30 x64
Ryzen 2700 @ 4ghz
AMD r9 580x with Mesa 19.08
KDE Plasma 5.15.5
Game settings: 1440p, 30 fps cap, mixed Medium/High, Z-Prepass off

Proton 4.2-9

Alright just got the game, and tried it out. Good performance, but horrible input lag unless I cap it at 30 fps. I have a 144hz monitor, so this is killer. Both 60fps and no limit are unplayable, even tho I get 55fps average.

My keyboard will also randomly stop working. I can session switch, and the mouse input continues to work fine. This is regardless of the fps cap.

Any tips?

DeathTBO on 5 Jul 2019

Fedora 30 x64
Ryzen 2700 @ 4ghz
AMD r9 580x with Mesa 19.08
KDE Plasma 5.15.5
Game settings: 1440p, 30 fps cap, mixed Medium/High, Z-Prepass off

Proton 4.2-9

Alright just got the game, and tried it out. Good performance, but horrible input lag unless I cap it at 30 fps. I have a 144hz monitor, so this is killer. Both 60fps and no limit are unplayable, even tho I get 55fps average.

My keyboard will also randomly stop working. I can session switch, and the mouse input continues to work fine. This is regardless of the fps cap.

Any tips?

Running XWindows or Wayland with the game running in an XWayland session? Since you're on AMD, it's plausible that KDE is running in Wayland mode...

ndegruchy on 5 Jul 2019

Running XWindows or Wayland with the game running in an XWayland session? Since you're on AMD, it's plausible that KDE is running in Wayland mode...

I am not using Wayland.

DeathTBO on 5 Jul 2019

Was doing the xenojiva hunt and the game crashed after the results screen where a cutscene should have played, I presume this was an mfplat issue. Later on, I tried to launch the game again, where it now consistently crashes after the load data screen.
https://gist.github.com/DigitalDevilSummoner/d7a227765539daee04f9fd1d98d2be93
steam-582010.log

DigitalDevilSummoner on 9 Jul 2019

Yeah. I got that one, too. It was solved by installing the MFPlat dlls.

Nathan DeGruchy
http://degruchy.org

On Jul 9, 2019, at 00:27, DigitalDevilSummoner <[email protected]notifications@github.com> wrote:

Was doing the xenojiva hunt and the game crashed after the results screen where a cutscene should have played, I presume this was an mfplat issue. Later on, I tried to launch the game again, where it now consistently crashes after the load data screen.
https://gist.github.com/DigitalDevilSummoner/d7a227765539daee04f9fd1d98d2be93
steam-582010.loghttps://github.com/ValveSoftware/Proton/files/3371179/steam-582010.log

ndegruchy on 9 Jul 2019

Yeah. I got that one, too. It was solved by installing the MFPlat dlls. Nathan DeGruchy http://degruchy.org On Jul 9, 2019, at 00:27, DigitalDevilSummoner <[email protected]notifications@github.com> wrote: Was doing the xenojiva hunt and the game crashed after the results screen where a cutscene should have played, I presume this was an mfplat issue. Later on, I tried to launch the game again, where it now consistently crashes after the load data screen. https://gist.github.com/DigitalDevilSummoner/d7a227765539daee04f9fd1d98d2be93 steam-582010.loghttps://github.com/ValveSoftware/Proton/files/3371179/steam-582010.log

Have you been able to get past the save screen? Iv'e installed the mfplat stuff, but I still haven't been able to get to the tradeyard. Does this have something to do with the game crashing right after the xenojiva fight?

DigitalDevilSummoner on 9 Jul 2019

Yes. The MFPlat fixed the crashing on the xeno cutscene for me. Make sure you’re installing the right bitness for MHW, which is 64-bit

Nathan DeGruchy
http://degruchy.org

On Jul 9, 2019, at 07:18, DigitalDevilSummoner <[email protected]notifications@github.com> wrote:

Yeah. I got that one, too. It was solved by installing the MFPlat dlls. Nathan DeGruchy http://degruchy.org On Jul 9, 2019, at 00:27, DigitalDevilSummoner <[email protected]notifications@github.commailto:[email protected]> wrote: Was doing the xenojiva hunt and the game crashed after the results screen where a cutscene should have played, I presume this was an mfplat issue. Later on, I tried to launch the game again, where it now consistently crashes after the load data screen. https://gist.github.com/DigitalDevilSummoner/d7a227765539daee04f9fd1d98d2be93 steam-582010.loghttps://github.com/ValveSoftware/Proton/files/3371179/steam-582010.log

Have you been able to get past the save screen? Iv'e installed the mfplat stuff, but I still haven't been able to get to the tradeyard. Does this have something to do with the game crashing right after the xenojiva fight?

ndegruchy on 9 Jul 2019

I've run into a regression with the latest proton that appears to affect this games controller handling:

With Proton 4.2.9, the game launches and runs fine but doesn't respond to any controller input from either the Steam Controller or a wired 360 pad, like the input didn't register at all, all input hints remained using kb+mouse icons, characters/menus didn't respond, etc. 360 pad works fine in other native linux games, eg Rocket League. Even attempting to enable desktop controller as suggested in this thread did nothing until I realised I needed to apply these udev rules. With both these enabled, running the game would sometimes crash instantly and sometimes start fine. But any controller input would cause it to instantly crash to desktop. So I had been resigned to playing without a controller.

Later I decided to try using the old Proton version 3.16-9. And to my surprise, both the Steam Controller and 360 pad work absolutely fine, I've even disabled the 360 controller's desktop integration and it still works.

I've also applied the MFPlat fix as well FWIW

Is this a known issue or would proton logs be helpful?

sbearcsiro on 10 Jul 2019

So I've installed all the needed mfplat stuff, but I can't get into the game because it crashes at the match making screen, and thus I can't verify if anything worked. iv'e tried this with 4.2-9 and 3.16-9. Before the first crash, I had just finished the xenojiva quest and was at the results screen, could that be the reason for the crash? Has anyone else had this issue?

DigitalDevilSummoner on 10 Jul 2019

@DigitalDevilSummoner After beating Xeno'Jiva the game auto saves, when you load that save it tries to play the ending cutscene and crashes.

This is expected, it is what is what happens normally by default for everyone on Linux, unless you have an mfplat workaround installed correctly.

z0z0z on 10 Jul 2019

@z0z0z Good to know! I did install the mfplat workaround using this video (it was the RE2 fix, but that wasn't the right one). If I did mess something up though (which I probably did) how would I go about fixing it? (if I can at all) Thanks for the answer/sorry for wasting your time.

DigitalDevilSummoner on 10 Jul 2019

@DigitalDevilSummoner The mf workaround used for Resident Evil 2 doesn't work for MHW.

Try checking protondb, but please don't link stuff here that's against the rules.

z0z0z on 10 Jul 2019

@z0z0z Thank You! I didn't know there was a different fix for this. Sorry for the link as well.

DigitalDevilSummoner on 10 Jul 2019

Hello @DigitalDevilSummoner, there isn't a general ban on sharing links on the issue tracker, but we can't condone the redistribution of copyrighted material unless its license permits it, which includes the Media Foundation libraries from Windows.

kisak-valve on 10 Jul 2019

@z0z0z It worked! thanks for the assist!

DigitalDevilSummoner on 10 Jul 2019

@sbearcsiro What exactly were your steps to get your controllers to work with the MF fix on 3.16-9? For me, they worked alright on Proton 4.2-9 without the MF fix, but no matter which Proton version I applied the MF fix to (4.2-9, 3.16-9, 3.7-8), pressing any controller button crashed the game immediately.

Aironfaar on 11 Jul 2019

@Aironfaar you're right, controller input always crashes MHW with the MF fix applied.

I had just assumed the MF fix would remain after downgrading proton version but it turns out it didn't. Reapplying the fix to 3.16-9 brought back the "crash on any controller input" behaviour.

Additionally, attempting to run MHW with PROTON_LOG=1 and the MF fix applied causes the game to instantly crash, even without a controller plugged in.

sbearcsiro on 13 Jul 2019

@sbearcsiro Yeah, changing the Proton version seems to build an entirely new wine bottle upon the game's next launch, removing any manually applied fix in the process.
Doesn't help at all that logging makes the game crash. I'm not at home for a few days so I can't test this myself, but are you able to fetch a log with the following launch options instead?
WINEDEBUG="+timestamp,+pid,+tid,+seh,+debugstr,+module" %command%

Aironfaar on 18 Jul 2019

Well the input stopped working a couple times this week. I think it has something to do with the "tab" key. It happened once when I was switching between the steam overlay, and the other was when looking at my skills (tab opens the menu).

Still have to play with that 30 fps cap otherwise I get horrible input lag. I saw a Reddit thread where a linux/proton user also had to play with the 30 fps cap.

DeathTBO on 26 Jul 2019

There's an install-script that fixes the missing media foundation without the need to do it manually. Worked perfectly for me. Can anyone confirm?

<Link removed by moderator>

zink-chimaera on 28 Jul 2019

Hello @zink-chimaera, the link you posted is legally problematic and has been removed.

kisak-valve on 28 Jul 2019

Monster Hunter World doesn't launch

Issue transferred from https://github.com/ValveSoftware/Proton/issues/2920.
@abnazhor posted on 2019-07-28T22:32:32:

Compatibility Report

Name of the game with compatibility issues: Monster Hunter World
Steam AppID of the game: 582010

System Information

GPU: NVIDIA GeForce RTX 2060
Driver/LLVM version: NVIDIA 430.34
Kernel version: 5.2.2-122
Link to full system information report as Gist: https://gist.github.com/abnazhor/fa0b22d2105cb46a0c4cf3432ce45995
Proton version: 4.2-9

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.

(Log generates 5,000,000 lines so I couldn't copy everything.)
<Log omitted, please see #2920. Short version is CPU access violation (c0000005)>

Symptoms

Game doesn't start. This has been happening since I change my cpu to an AMD Ryzen 5 3600.

Reproduction

Try to start the game while using a Ryzen 3000 series cpu.

kisak-valve on 29 Jul 2019

Reproducing this with a Ryzen 3700x and a GTX 1060 6GB
Applying the workaround suggested on #2927 fixes the issue

Monster Hunter World doesn't launch

Issue transferred from #2920.
@abnazhor posted on 2019-07-28T22:32:32:

Compatibility Report
* Name of the game with compatibility issues: Monster Hunter World

* Steam AppID of the game: 582010
System Information
* GPU: NVIDIA GeForce RTX 2060

* Driver/LLVM version: NVIDIA 430.34

* Kernel version: 5.2.2-122

* Link to full system information report as [Gist](https://gist.github.com/): https://gist.github.com/abnazhor/fa0b22d2105cb46a0c4cf3432ce45995

* Proton version: 4.2-9
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.
(Log generates 5,000,000 lines so I couldn't copy everything.)
<Log omitted, please see #2920. Short version is CPU access violation (c0000005)>

Symptoms

Game doesn't start. This has been happening since I change my cpu to an AMD Ryzen 5 3600.

Reproduction

Try to start the game while using a Ryzen 3000 series cpu.

Dl0tt on 30 Jul 2019

Alright, got something concrete about the input not working at all.

After opening then closing the chat, the input will completely stop working. The mouse still works fine, and I can save/quit the game using it. Sending a message has no impact on this. I was partially right about the "tab" key, opening the menu and hitting tab opens the chat.

Would still love some help with the >30fps input lag. Moving to Proton 4.11-1 did not affect it.

DeathTBO on 2 Aug 2019

After opening then closing the chat, the input will completely stop working.

This is one of the downsides of having one issue per game, long-standing, known issues are lost in the conversation.

This was well defined back in April with the initial report from what looks like October.

Any time you enter text input you run the risk of losing your keyboard input. It's been a while since I played MHW on Linux (moved to PS4 to play with a friend who only has PS4, don't judge me) but I think it isn't just activating a text input field. I think it is specifically activating it, then hitting escape to get out of it. I know I have several named gear sets on my PC profile which means I was able to enter the text input field, enter text, hit enter, and have keyboard input continue to be recognized as I would then have to hit ESC to get into the menu, move over to the save game option, and save the game for the name to take.

greydmiyu on 2 Aug 2019

Any time you enter text input

Wow yes. Come to think of it, I couldn't control my character at all after creating him.

GitHub is really meant for individual projects. Having an issue tracker where you can post multiple issues per game would be nice.

DeathTBO on 3 Aug 2019

Can people affected by the NVIDIA hang issue re-test with the newest Vulkan beta driver?

https://developer.nvidia.com/vulkan-beta-4185218-linux

Plagman on 8 Aug 2019

Can people affected by the NVIDIA hang issue re-test with the newest Vulkan beta driver?

https://developer.nvidia.com/vulkan-beta-4185218-linux

Since I moved to RTX 2080 Ti I never had the freeze bug (using only mainline drivers).

Emanem on 10 Aug 2019

After opening then closing the chat, the input will completely stop working. The mouse still works fine, and I can save/quit the game using it. Sending a message has no impact on this. I was partially right about the "tab" key, opening the menu and hitting tab opens the chat.

This problem is very cumbersome since it potentially means losing a lot of progress, if your not as lucky to be able to save & quit. Has anybody come up with a fix / workaround yet?

Chilzi on 21 Aug 2019

This problem is very cumbersome since it potentially means losing a lot of progress, if your not as lucky to be able to save & quit. Has anybody come up with a fix / workaround yet?

Don't chat, save before doing anything with gear/item sets (IE, naming them). Once I knew the exact problem (Text input boxes) and was mindful of it I could play the game as long as I wanted. Or until the Nvidia hard lock reared its ugly head.

greydmiyu on 22 Aug 2019

Hi, I have weird light based artefacts haven´t found anything to that specific problem in the web.

System Information

Distro: Ubuntu 18.04
CPU: Ryzen 7 3700X
GPU: AMD Radeon™ RX 5700 XT
Driver/LLVM version: Radeon Pro Driver for Ubuntu 18.04.3 Revision Number 19.30
Kernel version: 5.0.0-25-generic
Proton version: 4.11-2
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.

BelphegorPrime on 25 Aug 2019

@BelphegorPrime This is probably specific to the AMDGPU-Pro driver you're using.

Most people on Linux with AMD cards use mesa, and that's generally recommended to use.

z0z0z on 25 Aug 2019

👀1

@z0z0z Thanks for the help but it was a giant pain to install mesa 19.2 to get the rx 5700xt "running", so I decided for me to stay with the pro driver until the free drivers are up to a good stable level.

BelphegorPrime on 29 Aug 2019

I feel really dumb right now, maybe someone here can help me out.I felt like playing some Monster Hunter World after some time again. Opened up Steam, clicked "Play" using newest Proton-Version (4.11-3). Nothing really happend. Just said it was running but then it would just fail to start. Not even a black screen nothing. My System:

OS: Arch Linux Kernel 5.2.11
CPU: Ryzen 3700x
Graphics Card: Radeon RX 480 8GB
Drivers: mesa (19.1.6-1), mesa-git, mesa-aco-git, LLVM 8 Vulkan drivers are installed I checked specifically.

Things I did try:

Reinstall the game
Verify Game Files
Reinstall Steam
different graphics drivers
all proton-versions available in steam being (3.7-8, 3.16-9, 4.2-9, 4.11-3)
different OS POP_OS (19.04 all updated)

All these things didn't really helped me out. I grabbed a Proton-log: (it is rather big being over 50MB so I uploaded i https://cloud.mhtube.de/s/LHCzsELDFHZFeQR

Maybe someone here has an idea?

stefan240 on 7 Sep 2019

@stefan240 FYI it works perfect for me on Ubuntu 18.04.3 with Nvidia (drivers 430).
From the logs it feels like it's not able to initialize some DLL and goes into an infinite loop of function calling, ending up in stack overflow:

14.095:002f:0030:trace:seh:execute_cfa_instructions 7bc87c03: DW_CFA_restore %r15
914.095:002f:0030:trace:seh:execute_cfa_instructions 7bc87c03: DW_CFA_advance_loc 1
914.095:002f:0030:trace:seh:execute_cfa_instructions 7bc87c04: DW_CFA_restore %rbp
914.095:002f:0030:trace:seh:execute_cfa_instructions 7bc87c04: DW_CFA_def_cfa %rsp, 8
914.095:002f:0030:trace:seh:execute_cfa_instructions 7bc87c04: DW_CFA_advance_loc 4
914.095:002f:0030:trace:seh:execute_cfa_instructions 7bc87c08: DW_CFA_restore_state
914.095:002f:0030:err:seh:setup_exception stack overflow 1552 bytes in thread 0030 eip 00007ffdf65fb5cd esp 0000000000131000 stack 0x130000-0x131000-0x230000

Can you try to remove Proton _plus_ clear the wine/proton profile for _MH:W_ and reinstall?
Furthermore, can you confirm your 32 and 64 bit Vulkan apps work (with other external programs)?

Emanem on 7 Sep 2019

@Emanem As I stated above the issue persists even on a freshly installed and updated PopOS. But a user on reddit gave me a tip. But yeah I cleaned steam and proton fully then reinstalled all of it, still not really helping.
On ProtonDB you can read more on the Issue in regrads to Linux, a Ryzen 3000-CPU and Monster Hunter World:
"Zen 2 cpu owners need to disable UMIP to have the game launch until an official fixed is pushed out; add "clearcpuid=514" to kernel boot options. Also, needs mfplat fix to stop tutorial videos from crashing. Near parity performance with Windows using the newest versions of mesa and ACO shader compiler."

well adding that option to my arch install as kernel boot option does help. The game boots into black screen and throws an error:
E_INVALIDARG: IDX11Device->CreateBuffer(&bdesc.pinitvalues?& data : NULL&pbuffer)

Vulkan seems to work fine since other Proton games (I tested Project Cars briefly) seem to work.

stefan240 on 7 Sep 2019

solved the problem? I don’t know how, but I managed to run it. your situation. start and reset. you can try transferring the monster hunter to another folder on another media in my case it was on a different drive not on ssd. before that I put the last mesa then LLVM I don’t know, but put IMHO on, I just banged my head on the table and prayed. I'm sorry, but I really killed on this day to say exactly in what order everything happened to say I can’t

alexchexz on 10 Sep 2019

I'm getting crazy mouse problems. It's not just the acceleration, but the cursor seems to be jumping around a lot.

Here's a video to illustrate the issue.

I play many other games on Proton and Wine including Doom, The Witcher 3, and Starcraft II, and the mouse works perfectly in all of them.

Specs:

Arch Linux with linux-amd-staging-drm-next-git-5.3.841339.865b4ca43816 kernel
CPU: AMD Ryzen 9 3900X 12-Core
GPU: AMD Radeon RX 5700 XT
Mesa version: 19.3.0_devel.115313.f812cbfd884-1 with LLVM 10.0.0_r326744.bfb5b0cb86c-1
Window manager: i3
Proton: 4.11-4

I previously tried the sway window manager on Wayland but the game failed to start.

I have applied clearcpuid=514 kernel option as well as installed z0z0z/mf-install.

The problem happens regardless of whether I use fullscreen mode or borderless window mode, and regardess of screen resolution. I have no other mice or input devices plugged into the computer.

Any ideas what could be causing this strange mouse issue?

dllu on 14 Sep 2019

@dllu
This only happens to me if the frame rate is greater than 30fps. Have you tried the 30fps frame limit in the options? It sucks to be capped, especially with a nice rig like that.

I'm using a 1440p/144hz monitor.

I also get input lag every time the fps deviates from that 30fps cap.

DeathTBO on 14 Sep 2019

I tried it with the 30 fps cap but the mouse cursor issue persists. I verified the framerate was 30 Hz with dxvk HUD enabled in Proton's user_settings.py. I also tried changing the MouseBaseSpeed to 0.000000 in config.ini but the game automatically changed it back to 2.000000.

EDIT: was able to work around mouse issues by enabling "Emulate a virtual desktop" in winecfg. This also allows the game to run in Wayland, which has no mouse issues. Mouse issues still persist in xorg with i3 window manager though. In i3, I already set focus_follows_mouse no and focus_on_window_activation no. Also, framerate sucks --- about DXVK HUD says 35 fps at 4k at medium settings, but the game feels way worse than that. Feels like 15 fps. I will investigate further...

dllu on 15 Sep 2019

So I did a system update. I then launched the game testing the new Proton version (4.11-5). I am also on the Steam beta.

Kernel: 5.2.15-200
KDE Plasma 5.15.5
Mesa 19.1.6

I changed the fps cap to 60fps and no limit, and it worked just fine today! No input lag from sub 30fps or >30fps. My eyes are very happy. I also tested the chatbox, and that did not disable input at all.

I'm attributing this to the proton version.

DeathTBO on 20 Sep 2019

On my system the game suffered performance regression with proton 4.11-7

GPU: RX 480 8gb
Driver/LLVM version: mesa 19.2.1
Kernel version: 4.19
Link to full system information report :https://gist.github.com/Utopanic/edfcf6a24846d1777e79d3aa6f67c914
Proton version: 4.11-7

Utopanic on 11 Oct 2019

There is a regression in terms of preformance in Monster hunter world with proton 4.11-7 with 4.11-6 was way better now the frame rate drops and there are stutters.

blastermaster77 on 14 Oct 2019

There is a regression in terms of preformance in Monster hunter world with proton 4.11-7 with 4.11-6 was way better now the frame rate drops and there are stutters.

Had the same problem, it just vanished after a day. Are you on Manjaro?

Utopanic on 15 Oct 2019

I've got a new issue since the most recent updates: the game process doesn't exit and keeps using 1 or 2 cores in the background.

Has anyone else experienced the same?

Emanem on 17 Oct 2019

@Emanem I've started playing this game with 4.11-4, so I don't know if it's related to most recent proton or not. I'm on arch linux and it happens to me at random :thinking:

FrogTheFrog on 17 Oct 2019

@Emanem
@FrogTheFrog
I've had that happen maybe once or twice.

Could be unrelated because this happens even if there is no background process. I noticed that my screen will turn off after 10-20 minutes of inactivity after having played MHW. Really strange because that goes against my computer settings: I don't have a screensaver or have it set to turn off after inactivity.

DeathTBO on 18 Oct 2019

@Emanem I've started playing this game with 4.11-4, so I don't know if it's related to most recent proton or not. I'm on arch linux and it happens to me at random thinking

It's definitely more recent. I would guess is an update of the game's DRM?
But again, just a guess... I tried _ptrace_ the process and it kept waiting and trying to read from _pipes_ (I would suspect main wineserver instance).

Emanem on 19 Oct 2019

The game locks up when fighting the bat/balloon monster (HR6 quest). I'm using the default graphics settings, with exception to borderless fullscreen and vsync off, and have made no special changes to the game. I also updated the nvidia drivers and kernel to arch's latest versions. The lockup seems to be vulkan related, Path of Exile used to exhibit the same behavior for a while. Only the rendering stalls heavily, rendering windows such as urxvt and steam will eventually complete but will take a while. Sound keeps playing as if everything is normal. Input is delayed as well.

GoLD-ReaVeR on 20 Oct 2019

An update: I've updated to the nvidia beta drivers and haven't had a single lockup thus far. It will take me a while before I can get more playing time in one session than I have now, but I reckon this is fixed by nvidia.

EDIT: as per request of kisak I'm adding this to inform that the driver version I'm currently using is nvidia 440.26 . So far still no issues, even while streaming.

GoLD-ReaVeR on 23 Oct 2019

And another update: the game seems to be locking up with the latest proton release, 4.11-8. The lockups are random, the game is killable but it's definitely a step back. The lockup seems to happen after 5 hours of play or so and after that happens much more frequently. GPU temperature seems to be normal and the rest of the system keeps functioning as normal.

GoLD-ReaVeR on 10 Nov 2019

Works perfect (apart the MF libraries).

The only drawback is that 30% of the time the game doesn't close on exit and requires a kill -9 <pid>.

Emanem on 20 Dec 2019

Performance is about ~40% less than on Windows (Intel iGPU playing on 540p low)

Everything looks fine otherwise.

xzn on 23 Dec 2019

Game received an update today and it now crashes in 15 minutes of play on 4.11-11.
This is with nvidia beta 440.44 which were installed to fix a different crashing issue. The game is unplayable now as I can't get through a single hunt anymore.

GoLD-ReaVeR on 24 Dec 2019

Game received an update today and it now crashes in 15 minutes of play on 4.11-11.
This is with nvidia beta 440.44 which were installed to fix a different crashing issue. The game is unplayable now as I can't get through a single hunt anymore.

I updated to new patch and it works fine for me, what gpu do you have and cpu? I dont have issues whatsoever. Give more info on your specs, happy hunting

blastermaster77 on 25 Dec 2019

GTX 1080 Ti and Ryzen 2700X. What seems to have resolved the crashing issue for me entirely is setting "DXVK_STATE_CACHE=0 %command%" as my launch option. I do have occasional stutters, but it's miles better than crashing out of the game completely.

GoLD-ReaVeR on 25 Dec 2019

well nice to hear that worked for you

On Wed, Dec 25, 2019 at 1:24 AM GoLD-ReaVeR notifications@github.com
wrote:

GTX 1080 Ti and Ryzen 2700X. What seems to have resolved the crashing
issue for me entirely is setting "DXVK_STATE_CACHE=0 %command%" as my
launch option. I do have occasional stutters, but it's miles better than
crashing out of the game completely.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/175?email_source=notifications&email_token=ACHAHPVYDN7JRTO3WBCQXS3Q2LU7BA5CNFSM4FRB5W2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHT5GXI#issuecomment-568841053,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACHAHPRFM3B46BDBX3PREJDQ2LU7BANCNFSM4FRB5W2A
.

blastermaster77 on 25 Dec 2019

Game is starting to crash more frequently again, it's as if the environment value is being ignored. I'm at a loss now.

GoLD-ReaVeR on 1 Jan 2020

Game has been working flawless for me until today's update with the expansion.

AMD Ryzen 1700
RX 5700 XT
16 GB RAM
5.4.8-zen1-1-zen

Now it's unplayable..., Have tested the NO_FSYNC, going to regular Linux instead of zen, Xorg and Wayland and nothing, running another game like RE2 (Some power hungry game) runs perfectly...

EDIT: Looks like they added the DirectX12 support with the update. Could it be that?

Captura de pantalla de 2020-01-09 19-01-28

Can someone else confirm it's not just me?

alosarjos on 9 Jan 2020

👀5 👍1

Did you try using the mf-install script? Maybe it's trying to play video and failing.

GoLD-ReaVeR on 9 Jan 2020

Did you try using the mf-install script? Maybe it's trying to play video and failing.

Already installed and checked it was working fine. But no it's just slow as hell...

alosarjos on 9 Jan 2020

Can someone else confirm it's not just me?

I am getting 1/2 FPS on Pop OS with the update
AMD Ryzen 1800x
AMD Vega 64
16GB RAM

zeeshan595 on 9 Jan 2020

👍1

Also having issues after today's update

Distro: Arch 5.4.8-arch1-1
GPU: GTX 1060 6GB
Driver: 440.44
CPU: R7 3700x
RAM: DDR4 32GB

Dl0tt on 9 Jan 2020

Have you tried to play in D3D11 mode instead of D3D12?

I'll try soon and report after the hefty 80 GiB of download...

Emanem on 9 Jan 2020

Have you tried to play in D3D11 mode instead of D3D12?

I'll try soon and report after the hefty 80 GiB of download...

I couldn't find any command to "Force D3D11" on the Proton Docs but the capture shows like I'm already using D3D11 if I'm right

alosarjos on 9 Jan 2020

Have you tried to play in D3D11 mode instead of D3D12?
I'll try soon and report after the hefty 80 GiB of download...

I couldn't find any command to "Force D3D11" on the Proton Docs but the capture shows like I'm already using D3D11 if I'm right

Yeah noted that... :(
I'll report my experience soon-ish I hope...

Emanem on 9 Jan 2020

Also having significant framerate issues after latest update (Iceborne) - went from 60 fps to around 10.

Distro: Arch 5.4.7-arch1-1
GPU: RX 470 4 GB
CPU: i3 6100
RAM: DDR4 16 GB

jadball on 9 Jan 2020

Can confirm I now get 1.8 FPS on the starting menu, when I used to get 200+.
I haven't even tried to start the game. Using DX11, DX12 is disabled with Proton (just checked in the menu).
I would guess a slow codepath on DXVK?

@doitsujin you may want to look into this one (or someone at Valve) - it's happening on different kernels, drivers and hardware, seems like a (common) DXVK codepath triggering the slowness...
Let us know if we can help in any way investigating this!

EDIT: could also be some other form of syscalls, but the audio thread and the game itself seem to be running ok?

EDIT 2: looks like it's a wine/syscall issue as reported below...

Distro: Ubuntu 18.04.3
GPU: RTX 2080 Ti
CPU: i7-8700K
RAM: 64 GiB 3200 MHz
MHW Menu

Emanem on 9 Jan 2020

It seems to be a game/wine issues since on Windows DXVK performs similar to native D3D11, the current release of the game is very buggy and even on Windows the game has a big performance hit compared to the previous version.

Some windows users have reported the same low FPS issue tho.

Game on Windows 10 using DXVK:
Screenshot_3

BlazeKl on 9 Jan 2020

This is really bad! The game went from perfect to unplayable. DX12 is disabled by default. It also says it can only be enabled on Windows 10 (I think Proton shows Win7 by default).

I at 10fps on the intro menus (privacy policy, conflicting keybinds), and 1fps on the main menu (3d rendered menu). I painstakingly lowered every setting to the lowest and reduced the resolution to 720p.

Upon relaunching with the newly lowered settings I had similar framerate but it did feel a little faster. GPU usage was little to nothing, and a single core would occasionally peg at 100% while sitting at a 60-70% average with 4 others hitting ~20-40%.

Distro: Fedora 31 5.4.7-200
CPU: Ryzen 2700 @ 4ghz
GPU: RX 580 Mesa 19.2.8
RAM: 16gb 3200mhz 14 cas (probably not necessary :P)

I wonder if setting the proton wineprefix to Win10 and enabling DX12 would make any difference. Wine already has DX12 to Vulkan right?

Edit: When quitting the game, the process stays alive and active in the background. This happened months ago but was fixed with a Proton release. Looks like it's back.

DeathTBO on 9 Jan 2020

Tried enabling D3D12 with a custom Proton build but it always defaulted to D3D11, I can't test this anymore since Denuvo blocked my game because of too many prefix reconfigurations

BlazeKl on 9 Jan 2020

This is not really a proton/wine issue. The wineserver is overloaded by exception handling:
https://gist.github.com/GoLD-ReaVeR/e9109cebad3b766d07973dfeb053dbfb

Someone at capcom is being an idiot. The exception seems to be an attempt to communicate with the OS, or it's being used as a cross function goto statement. Either way, this is not something wine should be having to for see.

GoLD-ReaVeR on 9 Jan 2020

To clarify, the MHW forums are littered with people having performance issues, and I don't think all of them are proton users. So this may get resolved eventually by capcom.

GoLD-ReaVeR on 9 Jan 2020

I hope they patch this soon. I changed my proton version to see if that helped, but it somehow deleted all of the game files. After I had downloaded the update.

Koonboi on 9 Jan 2020

Just want to say I have the same < 5 FPS problem.

Distro: Manjaro Linux Xfce (Up-to-date)
CPU: Intel Core i7-4770K
GPU: GTX 1080 Ti
RAM: 32 GB DDR3

E3FxGaming on 10 Jan 2020

I've been working on this for the last 3 hours.

Distro: Linux Mint 19.2
CPU: Intel Core i7-4770K
GPU: Radeon RX 580
RAM: 16 GB

Before today, I was able to run Monster Hunter without issue by forcing Proton 4.2-9. However, now Proton 4.2-9 crashes with this error: "ERR14: Graphics API not implemented."

Screenshot from 2020-01-09 16-39-36

According to this post here, that error indicates DirectX isn't working properly and you should update your drivers. I updated my Mesa drivers this morning, but it had no effect.

A little research uncovered this Reddit thread, which claims that the new expansion also brought along DX12 support which probably explains why Proton 4.2-9 no longer works, since Direct3D 12 support was added in Proton 4.11-8. This change seems to have been made to the base game, uninstalling Iceborne had no effect on this compatibility issue.

Unfortunately, switching to Proton 4.11-11 is yielding significant performance degradation. I suspect the issue is that the newest version of Proton is incorrectly allocating or detecting VRAM. When I look under display options it reports that I only have 0.5 GB where it should report 8 GB:

Screenshot from 2020-01-09 16-51-26

Note: I am 100% confident that this VRAM reporting issue existed with Proton 4.11-11 before the updates to Monster Hunter today. The reason I was using Proton 4.2-9 was because it was correctly recording and using my VRAM.

Proton 4.11-9 supposedly "Fix[ed] reporting too little GPU memory for certain GPUs." so my current plan is to download the source and compile Proton 4.11-9 and see if that works. Hopefully that process is relatively painless. I'll report back once I've tried that. Hope this helps.

MrMulciber on 10 Jan 2020

😕1

It's not Proton 4.11-11 that is degrading performance. Wineserver is maxed out, which means that 4.11-9 is likely to have the same problem and 4.2-9 isn't safe either. I've also tried setting the windows version to 10, but DX12 isn't becoming available nor is there an improvement on performance. I'll try 4.2-9 myself to verify whether it helps performance or not.

GoLD-ReaVeR on 10 Jan 2020

👍2

With 4.2-9 I get the error that was mentioned, but wineserver load is at 79% instead of 100% and the exception address changed:

304739.481:0028:0030:trace:seh:NtRaiseException code=406d1388 flags=0 addr=0x7b44c04c ip=7b44c04c tid=0030

Hmm, this would imply that either wine or DXVK is raising these exceptions.

Though the framerate only drops to 2fps after the logos have been displayed.

GoLD-ReaVeR on 10 Jan 2020

Ok, doing the fools errant of installing dxvk through winetricks, prevents DX11 from initializing with 4.11-11. Wineserver is stuck at 79% as well, which would suggest DXVK is responsible for 20% of wineserver CPU usage, OR, the render thread is responsible for 20% of wineserver usage. The remaining 80% is triggered elsewhere. I tried fiddling with the settings but nothing would alleviate this slowdown at all.

GoLD-ReaVeR on 10 Jan 2020

I'm curious if anyone else's VRAM is also being limited in the same way mine is when you use Proton 4.11-11. If you go into Options->Display upon successfully loading the game, is your VRAM being misreported as far less than it actually is?

MrMulciber on 10 Jan 2020

I'm curious if anyone else's VRAM is also being limited in the same way mine is when you use Proton 4.11-11. If you go into Options->Display upon successfully loading the game, is your VRAM being misreported as far less than it actually is?

My VRAM is displayed normally. Im on 4.11-11 on a 1660 Ti with 6gb of VRAM.

DigitalDevilSummoner on 10 Jan 2020

How's your performance @DigitalDevilSummoner?

MrMulciber on 10 Jan 2020

How's your performance @DigitalDevilSummoner?

Bad just like the other reports here

DigitalDevilSummoner on 10 Jan 2020

I am getting the same massive performance degradation that everyone else is getting. Between 1 and 3 FPS in the main menu and likewise when I finally get into the game using Proton 4.11-11. It just gives me ERR14 API not implemented when I try Proton 4.2-9. Haven't checked the VRAM usage yet, it's painful to go through the menu at 1-3 fps.

Running Manjaro on kernel 5.4.6 with an RX 5700 XT and running the mesa 19.3.1-1 drivers.

Vorthas on 10 Jan 2020

I tried 4.11-11 debug build (opt in beta) to have a d3d12.dll, but that didn't help either. The game also didn't recognize the system as being able of using d3d12 either. Guess there's nothing that can be done at the moment. Lots of windows users are having this issue too, so hopefully CAPCOM will remove this retarded bit of code.

GoLD-ReaVeR on 10 Jan 2020

So, I managed to fix my VRAM problem with a fresh install. You may have to use winecfg to change the Windows version for Proton 4.11-11 to 10 first.

However, even after getting the VRAM reported correctly, I am still getting performance issues like everyone else.

MrMulciber on 10 Jan 2020

Same here, 0.5~2fps on main menu, after struggling trying to lower my graphical settings I noticed d3d12 is disabled by default and cannot be enabled, so I guess that's not related to d3d12.

Distro: Arch running 5.4.7-16linux-tkg-pds-zen2
CPU: AMD 3700X
GPU: Nvidia GTX 1050Ti using nvidia-dkms 440.44.0
RAM: 16 GB
DXVK: v1.5-16-g3b180e3bb
Vulkan: 1.1.119

sugayaa on 10 Jan 2020

Also experiencing the 1 FPS issue here as well. I opened a case with Capcom to see if I can provide them any debug info since it seems to be on their end

Xaenalt on 10 Jan 2020

@vitoor-s

This issue most likely related with DX 12, I found that some Windows users are reporting that enabling DX 12 helps a lot, some of them made the game become playable by enabling DX 12 which was unplayable.

Especially, I found a Windows 7 user who was unable to play the game like us because of the heavy CPU utilization, but that player successfully made the game playable by upgrading the system to Windows 10 and with DX 12 enabled.

You may want to have a look on this Reddit thread: The Link

So, here are some clues that could help. I'll try it later with Windows 10 wine environment and VKD3D.

BUT, there is one more thing need to be noticed: MHWI currently requires a beefy PC to run at 60 FPS even for Windows users. We Linux users will need an even more powerful PC to get this game work. :disappointed:

Capcom must do something or the MHWI DLC will be overwhelmed by negative reviews.

Update:

I failed :roll_eyes: I can confirm that d3d12.dll has been loaded from proton's log file, but that's about it, seems the game is not using it in rendering.

Mr-indescribable on 10 Jan 2020

I tried using the proton 4.11-11 debug opt in, but DX12 is still not recognized as usable by MHW. Furthermore, a huge portion of the slowdown reports are DX12 users or at least have DX12 installed.

Maybe there's something extra I would need to do to actually get DX12, but I fiddled with just about everything I could. I don't know why the exception is raised and fiddling with options in the application doesn't do a thing to alleviate this problem. All I can tell is that this performance drop happens after the game mentions autosave is enabled.

GoLD-ReaVeR on 10 Jan 2020

Well, now my game won't even launch. Can someone check if this is just an issue on my side?

zeeshan595 on 10 Jan 2020

@zeeshan595 You have hit your 5/day Denuvo activation limit and you will have to wait 24h, after which the issue will resolve itself.

Note that using custom/multiple Proton versions can apparently cause your Wine prefix to become volatile, which forces a new Denuvo reactivation on every game relaunch attempt.

Saancreed on 10 Jan 2020

👍2

@zeeshan595 You have hit your 5/day Denuvo activation limit and you will have to wait 24h, after which the issue will resolve itself.

Note that using custom/multiple Proton versions can apparently cause your Wine prefix to become volatile, which forces a new Denuvo reactivation on every game relaunch attempt.

Thanks for the clarification. But this is a really silly design. They could just store my motherboard's UUID or something

zeeshan595 on 10 Jan 2020

Hi,

I have been able to work around this issue by downgrading MH to 5080591846956782264.
You can folllow this guide to do the downgrade: https://steamcommunity.com/sharedfiles/filedetails/?id=1086279994

The depotid is 582011.

I went from <1 FPS on low settings to ~45FPS on Highest. The game size also went down from about 50GiB to about 20GiB.

torvitas on 10 Jan 2020

👍1

@torvitas can you play online?
So you are basically playing before Iceborne was launched?

sugayaa on 10 Jan 2020

@torvitas can you play online?

Can't tell for sure, I can use the quest board though and it suggest to start an online session. I doubt it'll work since I am on an old version but I am not sure.

So you are basically playing before Iceborne was launched?

exactly

torvitas on 10 Jan 2020

7910381936908271401 is a little bit newer but also works. I just joined a random guys online session - seems to work. Although I just found one open session.

torvitas on 10 Jan 2020

@GoLD-ReaVeR Is there a way to trace back which API call is being forwarded to _wineserver_ all the time?

I'm wondering if we should temporarily patch invoking such API form the MHW process so that the effect would be basically a no-op?
Just experimenting of course... And yes, CAPCOM messed up big time.

Emanem on 10 Jan 2020

I'm not good with debuggers but as the gist I gave earlier indicated, something is calling NtRaiseException with an MS_VC_EXCEPTION. According to google this exception is used to set threadnames. So that is where I would be looking.

However, it can also be, and this is something I can't rule out, that someone was using this exception as a means of a cross function goto.

Anyway, if you can prevent NtRaiseException from interfacing the wineserver, the problem will probably be gone. Thinking about it, if you would make a ntdll that checks if the raiseexception is calling for a threadname change; and if the name is already the same just continues as if successful, you will probably help the windows users too.

GoLD-ReaVeR on 10 Jan 2020

OH DUH.
@Emanem
Yes what I said would totally work. Make a ntdll that ignores all MS_VC_EXCEPTIONs.

GoLD-ReaVeR on 11 Jan 2020

OH DUH.
@Emanem
Yes what I said would totally work. Make a ntdll that ignores all MS_VC_EXCEPTIONs.

That's what I had in mind :)

Basically a nice

switch(rec->ExceptionCode)
case MS_VC_EXCEPTION:
   return STATUS_SUCCESS;
default:
   break;

Emanem on 11 Jan 2020

SpecialK seems to have released something already, I'm going to test that.

GoLD-ReaVeR on 11 Jan 2020

Nope, didn't work.

EDIT: for clarification: https://steamcommunity.com/groups/SpecialK_Mods/discussions/0/3570700856110421443/?tscn=1578697020#c1747893804389966558

He aims to fix a lot of things wrong with games and provides a dxgi.dll that seeks to fix problems in the game. He said he fixed debugger code, but the exceptions are still being thrown.

GoLD-ReaVeR on 11 Jan 2020

😕2

I have built a _ntdll.dll.so_ with above snippet and the game doesn't fully start (i.e. black screen, just before the _CAPCOM_ logo).

Looks like this API is used to invoke some other code (as _goto_) or as form of anti-hack/DRM...
Let's investigate more...

Emanem on 11 Jan 2020

Well in both cases its a goto. I'll just ask for a crack on the MHW steam forums and see how fast capcom starts to respond. ( :D ) If its actually denuvo doing this, that would just be hilarious and sad at the same time.

GoLD-ReaVeR on 11 Jan 2020

Checked the new version MHW with Protons 4.2-9, 4.11-11, 4.21-GE-2 + DXVK 1.5.1 and everywhere see maximum 2 FPS.

steam-582010-4.11-11.log

Screenshot from 2020-01-11 12-09-57

CPU: AMD 3950X
GPU: Radeon VII
Mesa/LLVM: 20.0.0 (b5c9688)/10.0.0 (gitfc3367d)

NTMan on 11 Jan 2020

Looks like we found the culprit?

https://fearlessrevolution.com/viewtopic.php?p=117527#p117527

Now... Is this something completely on their end, or does Proton/Wine/DXVK require some work?

Found in this post. Showing the performance difference

https://steamcommunity.com/app/582010/discussions/0/1737760710130372658/

alosarjos on 11 Jan 2020

It still shows the exceptions and the wineserver is still at 100%. Though there may be something else that communicates with the wineserver... But I think merely undoes the damage of the scanner and doesn't stop the scanning entirely. So while that may help windows users, it doesn't do anything for us.

GoLD-ReaVeR on 11 Jan 2020

Can confirm the CRC bypass does nothing, I've been taking perf records of the data, and there's one function that's got an extreme amount of overhead at 0x00000001605b0532

Two perf reports, one with no CRC bypass:
https://drive.google.com/open?id=1JECOHULxCNVYblDK6w37GECj-uwSWksX
and one with CRC bypass:
https://drive.google.com/open?id=1OUrRbLqLKGg5-UY_aaJ4DSyJ-nW154Sp

Xaenalt on 11 Jan 2020

Well, not "nothing", it does drop the CPU usage significantly, but it doesn't address the low FPS issue

Xaenalt on 11 Jan 2020

Well, got myself banned from the MHW forums for a day. Is there a way to contact GabeN?

GoLD-ReaVeR on 11 Jan 2020

🎉1

I get 2FPS with Proton 4.11-11
It's honestly amazing.

StylinGreymon on 12 Jan 2020

Well, got myself banned from the MHW forums for a day. Is there a way to contact GabeN?

If you are being serious -> https://www.valvesoftware.com/en/contact?recipient=Gabe+Newell

Also, any way I can help? Im new to proper troubleshooting but Im willing to learn. I want to play this one pretty bad ahah

RavyuS on 12 Jan 2020

😄3

I guess we should start at the source, which is the wineserver being at 100%. perf top is giving me:
54.20% [kernel] [k] toggle_bp_slot.constprop.0
27.45% [kernel] [k] __reserve_bp_slot
7.95% [kernel] [k] smp_call_function_single

Maybe we can throttle the amount of these calls coming through somehow? It's like there's no stopping the continuous breakpoint spam.

GoLD-ReaVeR on 12 Jan 2020

So the problem seems to be ptrace being spammed at the wineserver end, which is in fact one process inspecting another; which sounds like the new anti tamper protection. Maybe someone can sort the ptrace calls to the end of the queue so the rest of the application(s) can function as normal?

GoLD-ReaVeR on 12 Jan 2020

I was going to mention this earlier, but Assassins Creed had a new obfuscation/tamper system. It was basically a virtual machine which would interpret incoming calls and then redirect them to the program. The program itself I think is scrambled to prevent reverse engineering or something. This was amplified by Denuvo, which also obfuscates by rerouting.

It might not be related, but using this exception flagging as a goto might by similar to the virtual system.

Do we know what anti-tamper/anti-cheat systems are present in MHW? I saw someone mention Denuvo (activation limit), but are there any other systems? Could it be the worst homebrew in history?

DeathTBO on 12 Jan 2020

I believe wholeheartedly that denuvo fucked up and is sending full exe scans "for CAPCOM's sake". And CAPCOM just took the weekend off because "whatever". Two things Valve should never allow on steam. It's also retarded that the proton devs now have a new hole to plug in case this ends up becoming common practice in the future. I mean the wineserver is ancient and is very prone to performance issues, but this forcing their hands... ugh.

I'm also very interested why the trainer that was mentioned earlier, that was supposed to undo the damage, has no effect on the proton version of the game.

GoLD-ReaVeR on 12 Jan 2020

So is there a way around this now or do we have to wait for them to fix this?

Mera1506 on 12 Jan 2020

I'm also very interested why the trainer that was mentioned earlier, that was supposed to undo the damage, has no effect on the proton version of the game.

It does have an effect. It doubles my FPS from 5 to 10 in the main menu and significantly reduces the CPU load of the main exe (from 180% to 110%). The wineserver stays at >80% though, with or without the bypass.

In addition to low FPS I'm also experiencing extreme input lag. It feels like the cursor is capped at some (slow) speed and I have to wait multiple seconds for it to catch up to the actual mouse movement. This does not affect the cursor outside of the game at all, even when it's running. Is this due to the wineserver overload, or is it yet another issue?

Wuestengecko on 12 Jan 2020

For me the fps goes to 4 I guess, but the wineserver is still stuck doing ptraces.

GoLD-ReaVeR on 13 Jan 2020

In addition to low FPS I'm also experiencing extreme input lag. It feels like the cursor is capped at some (slow) speed and I have to wait multiple seconds for it to catch up to the actual mouse movement. This does not affect the cursor outside of the game at all, even when it's running. Is this due to the wineserver overload, or is it yet another issue?

Experiencing the same issue. I don't think it's an issue with wineserver overloading CPU cos alt-tabbing out of the game results in the normal mouse behavior as you said.

RavyuS on 13 Jan 2020

wineserver isn't overloading the cpu, wineserver is overloading on the CPU, causing one core to be dedicated to wineserver and wineserver not being able to answer to requests fast enough.

GoLD-ReaVeR on 13 Jan 2020

I'm getting more and more scared that this thing is here to stay and that whatever solution CAPCUM will put forth will still hamper wineserver performance making the game unplayable. I'm at a loss quite frankly, if stuff like this keeps happening I don't know which games to buy anymore.

If there's any proton devs out there watching this, I'm willing to think with you on a solution to this problem. I can't really help out code wise because I'm too unfamiliar with the server structure. I think that allowing thread-unsafe ptraces from the ntdll will mitigate most of this bullshit with the performance. Another option could be increasing the number of wineserver threads. But the heavy calls made to the kernel must be mitigated for this to work.

If there's anything you want me (or anyone else here for that matter), to do, then please say something.

GoLD-ReaVeR on 13 Jan 2020

Relax, Windows users are getting crushed by the same performance problems. Granted it may not be as severe but losing 60 fps is totally unacceptable. One guy went from 150 to 70, another from 60 to 15. They also acknowledged the problem on their official Twitter: https://twitter.com/monsterhunter/status/1215703124427624448

DeathTBO on 13 Jan 2020

That tweet was from before the weekend, we're now after the weekend. Do note what I said: whatever solution they are chasing, is probably still going to shaft us the proton users. It wouldn't take this long for them to give us a status update or even supply a fix if all they did was remove the offending piece of code.

GoLD-ReaVeR on 13 Jan 2020

Today I found this with some "method" to disable Denuvo which seems to be the culprit

https://www.dsogaming.com/news/monster-hunter-worlds-pc-performance-issues-may-be-caused-by-its-anti-cheat-workaround-discovered/

Tried it, but still nothing. I'm worried that:

A. We are going to need a fix in our end to handle this new protection system

B. Maybe all new games coming with Denuvo are going to behave like this until a fix is done.

To me it seems like maybe the best place to post this error would be on the WineHQ. Maybe some of you guys with more technical background can provide there more info on your findings?

alosarjos on 13 Jan 2020

Not really anything new, but I launched it with Wine-Staging 5 + DXVK and it too ran awful. Possibly worse because the intro stuff had more fps on Proton.

They might not give a quick follow up if the problem runs too deep, which it appears to be. Imagine huge chunks of code needing to be redone. So many users are also doing that stupid "iT WeRKs fOR mE" online. Do they just like to dilute real problems?

DeathTBO on 13 Jan 2020

Under the newest GE proton, the bypass seems to better the performance on my end, though it's still far away from what it once was. It was borderline playable with all settings turned down, cutscenes still lag and their audio desyncs.
With the bypass, the wineserver never went over 15% CPU usage and the MHW executable itself never over 70%... So it never fully utlilized my CPU, too.

Ran it with the following command (note: SteamLibrary is a link to an other harddrive)
WINEPREFIX='/home/<USER>/SteamLibrary/steamapps/compatdata/582010/pfx' WINEESYNC=1 /home/<USER>/.steam/steam/compatibilitytools.d/Proton-4.21-GE-2/dist/bin/wine Downloads/MHWResetCRC.exe

Steam System Information: https://pastebin.com/xR6pRRet

A whole other problem though is the game getting stuck in a black screen after taking a photo with that new camera mode.

LizardWithHat on 13 Jan 2020

Hello

I'm getting an "ERR14 : Graphics API not implemented" after the update.
Which according to this steam thread https://steamcommunity.com/app/582010/discussions/3/1745594817430288153/?ctp=14 means my driver is out of date (it's not) or there some direct X shenanigans but from reading this thread it seams that Denuvo broke the game.
I hate DRM. I'll probably request a refund if they don't fix this somehow.

AnimatedFreak on 13 Jan 2020

👍1

Under the newest GE proton, the bypass seems to better the performance on my end, though it's still far away from what it once was. It was borderline playable with all settings turned down, cutscenes still lag and their audio desyncs.
With the bypass, the wineserver never went over 15% CPU usage and the MHW executable itself never over 70%... So it never fully utlilized my CPU, too.

Ran it with the following command (note: SteamLibrary is a link to an other harddrive)
WINEPREFIX='/home/<USER>/SteamLibrary/steamapps/compatdata/582010/pfx' WINEESYNC=1 /home/<USER>/.steam/steam/compatibilitytools.d/Proton-4.21-GE-2/dist/bin/wine Downloads/MHWResetCRC.exe

Steam System Information: https://pastebin.com/xR6pRRet

A whole other problem though is the game getting stuck in a black screen after taking a photo with that new camera mode.

I tried running that version of proton and it crashes at start up, apparently I also triggered my denuvo limit in the process. Is there anything special I need know about to run with that version?

The error is out of my log, but a page fault was being raised, looks to be a null pointer exception.

GoLD-ReaVeR on 14 Jan 2020

Well Proton-GE seems to be pretty much the same. I didn't notice any significant reduction in CPU spikes. Also using the alt+enter -> close game didn't help either. I changed the prefix to Windows 10 but that too made no difference.

Has anyone tried using VKD3D (DX12 to VK)? https://github.com/d3d12/vkd3d

DeathTBO on 14 Jan 2020

@DeathTBO vkd3d is integrated with stock proton by default, but for some reason the game wont let you enable DX12 even with vkd3d and a windows 10 prefix

Hengecobdig on 14 Jan 2020

@Lightwolf219 have you tried enabling DX12 in steam\steamapps\common\Monster Hunter Worldgraphics_option.ini? It's possible that this may just be an option if you're using SpecialK (if so, disregard) but I've not been able to get to a machine to check.

tosirius on 14 Jan 2020

@Lightwolf219 I must have missed VKD3D being included. I don't ever use DX12 :P

@tosirius I just attempted to. There is both an option graphics_option.ini and config.ini. After flipping both of them to "on" the in-game menu was still grayed out, but was set to on. I also have Win10 set as the windows version for the prefix. I saw no difference in performance, and I don't think it was actually being enabled.

DeathTBO on 14 Jan 2020

@DeathTBO if you have DXVK_HUD enabled you'll actually see dxvk is still being used despite being forced in the inis, I assume however they're checking for DX12 support fails so it just falls back to DX11

Hengecobdig on 14 Jan 2020

That's correct, the logs confirm that the DX12 implementation doesn't expose the features requested by the game.

GoLD-ReaVeR on 14 Jan 2020

I tried running that version of proton and it crashes at start up, apparently I also triggered my denuvo limit in the process. Is there anything special I need know about to run with that version?

I can't remember doing anything special;

Changed the pretended windows version to win10 when attempting to get VKD3D to run, which didn't work.
Renamed/deleted config.ini and graphics_option.ini to reset them, then setting everything to low and borderless windowed. LOD level to -1 and Z-Prepass off
had the media framework workaround installed from the pre-dlc version
Turned off xfwm's desktop compositor

LizardWithHat on 14 Jan 2020

Hello @LizardWithHat, the link you posted is legally problematic and has been removed.

kisak-valve on 14 Jan 2020

Before the Iceborne update I would get 30+ FPS, now I'm getting 1~3 FPS, so the game is totally unplayable. It seems that this is a issue with Capcom, but because the game is working fine for some people, maybe there's a workaround in Proton to make us play the game too? Hopefully...

shigutso on 14 Jan 2020

My system specs:

https://pastebin.com/Ckts3fhE

shigutso on 14 Jan 2020

There's a new tweet at MonsterHunter's page, they are talking about some easy fixes, a troubleshooting guide and they are gathering info about people that still have issues. How should we adress it?
Should we just wait for a fix?

sugayaa on 14 Jan 2020

Hello @LizardWithHat, the link you posted is legally problematic and has been removed.

Hey @kisak-valve, sorry about that.

Currently, lots of people have the same problems on windows that we have. I saw some discussions about the CRC Bypass not working for everyone on windows, and even DX12 is not a solution for everyone. All we can do for now is wait for a fix from them, IMO.

LizardWithHat on 14 Jan 2020

OK a friend if mine suggested the following:
Think I found it, just go to the monster hunter files, in the DLL folder just delete winpixeventruntime

Since I have no clue what it does I figured I'd ask the folks who do.

Mera1506 on 14 Jan 2020

I didn't update MH:W. I got the non-IB copy to run with a few tweaks to the appmanifest file, and forcing offline mode. I know that helps nobody here, but if anyone wants to pull comparisons between the versions, call me up. If I can help, I will.

larchea on 14 Jan 2020

@Mera1506 It did not change anything sadly.

przmkg on 14 Jan 2020

@Mera1506 It did not change anything sadly.

Too bad..... At this point I'm going to be greatful if it can fun on a stable 30fps similar to mhgu on switch.

Mera1506 on 14 Jan 2020

I figured out the issue. The game is getting and setting the debug registers on the current thread, requiring a server call, which is very slow. Stubbing this functionality out fixes performance.

Guy1524 on 14 Jan 2020

👍5 ❤2

@Guy1524 Did you test it locally with a fix of yours ?

przmkg on 14 Jan 2020

@przmkg Yes, and the performance is fixed, don't use this in your regular wine builds as it may break other apps.
mkw_hack.diff.txt

Guy1524 on 14 Jan 2020

🎉12 👍4

I can confirm it works.
Screenshot_20200114_215406

Tk-Glitch on 14 Jan 2020

🎉4 🚀2

Does anyone have a compiled Proton version with the fix by any chance ?

przmkg on 14 Jan 2020

For what it's worth, I wouldn't be suprised if this issue is also what's causing people trouble on Windows. Getting and setting the debug registers requires a context switch, which is nowhere near as expensive as a global lock waiting for ptrace to set the registers, but still might be the culprit for the smaller issues there.

Guy1524 on 14 Jan 2020

👍8

Dude! This is amazing!!!!! Ok, now how can we get this delivered to non-tech people?

alosarjos on 14 Jan 2020

Yeah, was just about to ask how I would get this to work.

DigitalDevilSummoner on 14 Jan 2020

I would love to know how to make it work too.

abnazhor on 14 Jan 2020

I'm trying to build a custom version of proton with this fix. I don't promise anything but I'll try. If it works, I'll put it in a repo so everyone can use it.

przmkg on 14 Jan 2020

👍3 ❤1

@Guy1524 @przmkg You're awesome!

Utopanic on 14 Jan 2020

Amazing, the Linux community once again saves the world... Well Monster Hunter World :P

All this debug stuff sounds like it wasn't supposed to be included. Did they accidentally publish a development build of the game?

DeathTBO on 14 Jan 2020

😄2

That was the initial assumption but we can't really say. It's possible.

Tk-Glitch on 14 Jan 2020

@DeathTBO It seems more likely to be copy protection. They're probably trying to continuously remove hardware breakpoints, but I didn't check.

Guy1524 on 14 Jan 2020

There you go, took me 2 hours to compile everything. I've tested it and the performance is back on track.
Link is here
https://github.com/przmkg/proton-ge-custom/releases/tag/5.0-rc3-GE-1-MHW

przmkg on 15 Jan 2020

❤15

Is it possible that this specific fix will cause bans?

Utopanic on 15 Jan 2020

@Tk-Glitch I have compiled proton-tkg with your patch enabled, and performance has somewhat (not completely) improved - 5 fps up to 30, when it was 60.

jadball on 15 Jan 2020

@przmkg Nice, I'm back to 40 FPS with this.

@Utopanic If I understand this correctly, it seems that this tweak prevents the Wine server from changing the debug mode on threads. So, unlike the CRC hacking, we're removing the ability to cheat in the first place. I would hope this doesn't result in bans, but who knows how exactly Capcom implemented their anti-cheat.

MrMulciber on 15 Jan 2020

@MrMulciber In Italy we say: "Chi non risica non rosica"

Utopanic on 15 Jan 2020

@jadball Make sure your settings are correct (for me the framecap was enabled in settings by default after I re-clean-installed the game). That being said it's heavier than it was and thus runs slower than before the patch with supposedly similar settings. I would definitely wait for Capcom on that front.

Screenshot_20200115_010242

Edit: Also I remember reading (and afterwards seeing it myself) that they have frogged the config migration, so removing the graphics_option.ini file in the gamedir or switching all settings to low then ramping back up to the desired values fixed similar issues.

Tk-Glitch on 15 Jan 2020

It works! I have to put on a 30fps cap otherwise I get huge stuttering. I'm struggling to get to 60fps on the same settings (at least I think they're the same). Anti cheat for a coop game hopefully isn't too intrusive. I would figure it's mainly server side state checking.

DeathTBO on 15 Jan 2020

There you go, took me 2 hours to compile everything. I've tested it and the performance is back on track.
Link is here
https://github.com/przmkg/proton-ge-custom/releases/tag/5.0-rc3-GE-1-MHW

Worked perfectly for me the stutters did appear at the start but after playing they go away so i am guessing it is a caching issue. Thanks again for compiling that proton version!

zeeshan595 on 15 Jan 2020

There you go, took me 2 hours to compile everything. I've tested it and the performance is back on track.
Link is here
https://github.com/przmkg/proton-ge-custom/releases/tag/5.0-rc3-GE-1-MHW

Working for me, as above with some initial stutterings after loading a map.

I did notice that system performance when alt tabbed out of game is laggier than it was pre-expansion but we are playable!

System specs: 3900x, 1080 ti on Manjaro Gnome

Skylead on 15 Jan 2020

There you go, took me 2 hours to compile everything. I've tested it and the performance is back on track.
Link is here
https://github.com/przmkg/proton-ge-custom/releases/tag/5.0-rc3-GE-1-MHW

do I have to make the compatibilitytools folder, or should it already exist? Thanks in advance dude.

DigitalDevilSummoner on 15 Jan 2020

@DigitalDevilSummoner You'll have to create it if it doesn't exist. It's not supposed to be there by default unless you have installed custom proton or other steam-related tool before.

Tk-Glitch on 15 Jan 2020

@Tk-Glitch Thanks!

DigitalDevilSummoner on 15 Jan 2020

There you go, took me 2 hours to compile everything. I've tested it and the performance is back on track.
Link is here
https://github.com/przmkg/proton-ge-custom/releases/tag/5.0-rc3-GE-1-MHW

Thank you (and @Tk-Glitch and @Guy1524 )! I can somewhat play now, though I think my slow CPU is giving into the CPU overheads this update added.

i5 4460, RX 570, Ubuntu 18.04 5.4

RavyuS on 15 Jan 2020

im getting another 80gb download, is this supposed to happen?

DigitalDevilSummoner on 15 Jan 2020

Thanks so much, trying this after work......

Mera1506 on 15 Jan 2020

wow, thanks so much for figuring this out!
game seems to be working harder than it was pre-Iceborne, but I'm back up to around my previous performance.

StylinGreymon on 15 Jan 2020

@przmkg thank you soooo much, it's working amazingly!!

distengine on 15 Jan 2020

@DigitalDevilSummoner the title update for Iceborne should be an additional 10-15GB, bringing the entire install to 40gb. You might be downloading high-res textures, which is why the size ends up that big.

RavyuS on 15 Jan 2020

After taking a capture with the in-game camera added in Iceborne, the screen goes black and the game softlocks. I can still open the communication menu by holding Select, but besides that nothing can be done.

jclc on 15 Jan 2020

👍1

@Guy1524 Please pay attention to other games that have problems with low FPS:
[1] [Agents of Mayhem](https://github.com/ValveSoftware/Proton/issues/1466)
[2] [The Evil Within 2](https://github.com/ValveSoftware/Proton/issues/2070) - here is low PFS when the game showing start splash screens.
Patch which help solve issue with low FPS in MHW did not solve issues in these games.

NTMan on 15 Jan 2020

Thanks @Guy1524, @Tk-Glitch, @przmkg, game launches like a charm now!

sugayaa on 15 Jan 2020

🚀1

@Guy1524 thanks for finding and fixing that! Now lets hope denuvo doesn't fuck things up again for me :D

GoLD-ReaVeR on 15 Jan 2020

The solution posted worked for me.
I ended up getting extremely bad stuttering however on my first fight with shrieking legiana. I noticed 1 thread is maxing out at 100% all the time. I am hoping this is the bug that is affecting everyone and will get fixed. not sure it's something that can be fixed here.

maverck on 15 Jan 2020

Capcom has announced they will release a fix soon for lost savedata bug and to reduce CPU usage. Maybe this + this patch will get things done. Now I am wondering if this "fix" is something that should go upstream wine or not and in case not, what the upstream solution should be

alosarjos on 15 Jan 2020

The patch seems to work. Though with the precompiled build I had to completely reset the config because I got a black screen at the start of the game. I'm thinking this is related to the HD Texture pack bug that is torturing windows users as well. The mouse cursor seems to lag as well; kinda like it was doing in 4.11-9, is that patch not in the GE build?

Also, @Guy1524, out of sheer curiosity: how did you find that? I don't recall these two functions showing up in perf top and the tracing didn't show these functions getting spammed. Are the operations THAT slow or is there simply a lack of logging?

GoLD-ReaVeR on 15 Jan 2020

So, yesterday it worked just fine, but today it keeps crashing, any suggestions? I'm on Linux mint and I run on a rx 480 wit mesa drivers

Utopanic on 15 Jan 2020

@alosarjos I thought about that as well, and I'm not sure if there is a good solution upstream, as

AFAIK the only way to set debug registers on Linux is using ptrace. It may be possible to make a worker thread in wineserver to do the stuff with pthread freeing it up for other requests, but the requests themselves would still be very slow, so it wouldn't fix the issue.

The only way I can see this being fixed is Linux adding the debug registers to the ucontext_t structure, so we can do the same thing as Windows.

@GoLD-ReaVeR I wrote a wine patch that logs wineserver requests and their timing in microseconds in a binary format. I then parse the file offline at given timing to see how wineserver is dealing with requests at that time. A typical output during the time of the slowdown showed something like this: https://paste.ubuntu.com/p/mNmf4T9b7X/
As you can see, the wineserver is struggling to keep up with all the requests, and it is being spammed with (get/set)threadcontext requests, which are very expensive.

Guy1524 on 15 Jan 2020

@Guy1524 I understand that recompiling ntdll.dll with your patch should do the trick, right?

Also, I understand you've removed setting the thread data in _NtSetContextThread_ but then you sort of restore them from the current thread in _NtGetContextThread_?

Thanks again for the patch, I'll test it too!

Edit: It's working, seems to be same performance as pre-patch.
Awesome investigative work!

MHW_Iceborne

Emanem on 15 Jan 2020

@Emanem All I did is remove the functionality for getting and setting debug registers.

Guy1524 on 16 Jan 2020

Has anyone else gotten an issue where your whole computer freezes during the cutscene with the First Wyverian in the Hoarfrost Reach? I got to that section and then my entire machine just stops responding to anything. I had to do a hard reboot. I wasn't sure if this was an issue with the patch or not. I'll attempt it again tomorrow after work to see if it's consistent or a one-time thing. That kind of freeze scares me.

I also have the same black screen issue with the in-game camera that @jclc mentioned.

Vorthas on 16 Jan 2020

Has anyone else gotten an issue where your whole computer freezes during the cutscene with the First Wyverian in the Hoarfrost Reach? I got to that section and then my entire machine just stops responding to anything. I had to do a hard reboot. I wasn't sure if this was an issue with the patch or not. I'll attempt it again tomorrow after work to see if it's consistent or a one-time thing. That kind of freeze scares me.

I also have the same black screen issue with the in-game camera that @jclc mentioned.

Not sure about the first issue, but the surveyor set bug is known and happens on windows as well. it doesn't seem to be a graphical issue afaik.

DigitalDevilSummoner on 16 Jan 2020

The savedata and CPU usage usage "update" just landed. The game still runs at 1 fps without the custom wine build.

It seems it also didn't help windows players as well...

Dl0tt on 17 Jan 2020

The savedata and CPU usage usage "update" just landed. The game still runs at 1 fps without the custom wine build.

It seems it also didn't help windows players as well...

Called it :D

GoLD-ReaVeR on 17 Jan 2020

I'm seeing improved performance from the patch, running with the custom wine build. Previously I was getting ~45-50fps in most of the game, and now i'm up to around ~60-70fps, which is enough that it looks much smoother. I wouldn't be surprised if we see more performance patches over time, personally.

Also, for people having issues with cutscenes (I personally crashed after defeating Xeno'jiiva for the first time, and freaked out - luckily the game autosaves after you beat it) - MHW requires the Media Foundation workaround for wine, much like many other games. Although most of the rest of the cutscenes worked just fine, weirdly.

waycooler on 17 Jan 2020

I can't load quests anymore without the graphics card freezing my system.

GoLD-ReaVeR on 17 Jan 2020

OK it worked OK before the update, but now during the hunt suddenly my graphics card crashed.
OK guessing it was because of both gsync and V sync active.... Turned of vsync and it looks to run alright again.

Mera1506 on 17 Jan 2020

My performance went back to pre-custom wine build (10fps-ish) with the new update while still running said custom wine build... Only plus is input lag is gone so it feels smoother. Why capcom...

i5 4430, RX 570, Ubuntu 18.04 on 5.4

RavyuS on 17 Jan 2020

The only sad thing now is the inability to use the surveyor said, after snapping a picture it remains stuck on a black screen. Any idea what it causing that?

Mera1506 on 17 Jan 2020

@Mera1506 Since this is also happening on windows I'd say Capcom did a poor job, just like with the whole Iceborne release.

Tk-Glitch on 17 Jan 2020

I am having an issue when I click play in steam it pops up the startup dialog and then that closes and the game never starts. The play button becomes clickable and I can do it all over again. Doing this many times never seems to get it to start.

If I restart steam a couple times I can get the game to finally launch. Has anyone seen an issue similarly to this?

ProtonLover432 on 17 Jan 2020

@ProtonLover432 Can you generate a log on a run where this happens and upload it here?

Guy1524 on 17 Jan 2020

@Guy1524 I'd love to do that but I'm not sure how to generate it or where to look for the output. Is there a guide outlining what to do? This is my first time really having an issue with anything so I haven't had to troubleshoot much.

ProtonLover432 on 17 Jan 2020

Hello @ProtonLover432, please add PROTON_LOG=1 %command% to the game's launch options and drag and drop the generated $HOME/steam-$APPID.log into the comment box.

kisak-valve on 17 Jan 2020

@Mera1506 Since this is also happening on windows I'd say Capcom did a poor job, just like with the whole Iceborne release.

On windows too wtf Capcom. Lol, I just hope they fix it at some point already glad the game is playable now.

Mera1506 on 17 Jan 2020

I'm using https://github.com/przmkg/proton-ge-custom/releases/tag/5.0-rc3-GE-1-MHW and I can finally play MHW again on Linux. Thanks a lot!

shigutso on 18 Jan 2020

I don't know what happened, but I can play quests again. Didn't install anything new in terms of proton, so I don't know what happened. SteamDB also says the gamedevs didn't update. Maybe it was just a patching thing.

GoLD-ReaVeR on 18 Jan 2020

I crash to desktop every few minutes, now
can't even finish a quest

StylinGreymon on 18 Jan 2020

I crashed almost immediately after changing loadouts. Turned off V-Sync and have not crashed since, in around 4-5 hours of play. If you are still crashing with V-Sync off, say so and I'll write out the rest of my settings so we can narrow down the cause/fix.

fuzxi on 18 Jan 2020

Mine crashed with V sync, not without.... Not yet at least.

Mera1506 on 18 Jan 2020

Written a patch for ntdll.dll a bit more generic which applies the _workaround_ from @Guy1524 only when MH:W is running.
Feel free to review and comment!

mhw_iceborne_ntdll.txt

Emanem on 18 Jan 2020

I don't think it's just iceborn, you should probably just name the flag DENUVO2020 or something like that as someone reported other games in this thread having similar fps issues.

GoLD-ReaVeR on 18 Jan 2020

I'm not sure about that, Denuvo can be related but it could be just a bad use of it by Capcom. For now I would keep the Iceborne tag

alosarjos on 18 Jan 2020

👍1

Or, we could also name it after what it does which is STUB_DEBUG_REGS.

GoLD-ReaVeR on 18 Jan 2020

I might have just now experienced the same issue as @ProtonLover432, where it shows the "Starting..." dialog but instantly closes. Here's the (very short) steam-582010.log:

======================
Proton: 1579111914 5.0-rc3-GE-1-7-gc08532c
SteamGameId: 582010
Command: ['/home/wuestengecko/.local/share/Steam/steamapps/common/Monster Hunter World/MonsterHunterWorld.exe']
Options: set()
======================
ERROR: ld.so: object '/home/wuestengecko/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/wuestengecko/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/home/wuestengecko/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
0037:err:esync:esync_init Failed to open esync shared memory file; make sure no stale wineserver instances are running without WINEESYNC.

I freshly booted up the machine, started Steam and tried to start the game. I have no idea where such a stale wineserver might have come from. I also checked that I'm not running low on memory or /tmp space.

However, unlike @ProtonLover432, for me this only happened once and after clicking on Start again it launches normally.

Arch Linux
linux-ck 5.4.12
nvidia-dkms 440.44-12
% cat .local/share/Steam/compatibilitytools.d/mhwhack/version 1579111914 5.0-rc3-GE-1-7-gc08532c

Wuestengecko on 18 Jan 2020

@Guy1524 sorry for the delay, and @kisak-valve thanks for the help.
The log I got was pretty much the same as @Wuestengecko
```======================
Proton: 1579042588 5.0-rc3-GE-1-7-gc08532c
SteamGameId: 582010
Command: ['/home/username/storage/games/steam/steamapps/common/Monster Hunter World/MonsterHunterWorld.exe']

Options: set()

ERROR: ld.so: object '/home/username/.steam/debian-installation/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/username/.steam/debian-installation/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
ERROR: ld.so: object '/home/username/.steam/debian-installation/ubuntu12_64/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS64): ignored.
2708.786:0032:0033:err:esync:esync_init Failed to open esync shared memory file; make sure no stale wineserver instances are running without WINEESYNC.
```

I'm running:

OS: Pop!_OS 19.10
Kernel: 5.3.0-7625-generic
Nvidia Driver Version: 440.44

ProtonLover432 on 18 Jan 2020

That seems like a problem with GloriousEggroll's build. You might want to try applying the patch to proton 4.11 or using proton-tkg.

Guy1524 on 18 Jan 2020

I havent made an rc3 release, so that's a self compiled build he's using.
I have an rc5 build thats working perfectly fine with MHW which i have not released.
My build uses staging's esync, and tkg's fsync and proton patches. Whatever his issue is is in regards to another wine instance running, and not related to any of those patches, since the esync patches are those of default wine-staging.

With that being said if WINEESYNC=0 is specified, the game will likely run.

GloriousEggroll on 18 Jan 2020

5.0-rc3-GE-1-MHW is a fork from GloriousEggroll's build with a modified version of wine implementing Guy1524's workaround. It's linked earlier by przmkg.

@ProtonLover432 I'd say follow GloriousEggroll's suggestion regarding stale wineservers, as that's what the error suggests as well and matches the way Wuestengecko fixed things (reboot likely shutdown the old wineservers).

The one issue when running with the workaround from @Guy1524 appears to be with vsync, others have reported it crashes after a couple minutes with vsync on. I haven't tested with it on, but I can confirm it runs fine with it off.

EDIT: Tested with vsync on for about 20 minutes with no issue. Might be a combination of things causing the crash

onesol on 18 Jan 2020

Yeah I am using the version that @onesol linked.
So for WINEESYNC=0 I'm guessing that is a launch option?
If so, is it just WINEESYNC=0 or do I need to do WINEESYNC=0 %command%?
I see the %command% for other things but not sure if its always required or not.

ProtonLover432 on 19 Jan 2020

matches the way Wuestengecko fixed things (reboot likely shutdown the old wineservers)

It seems I wasn't clear when describing my situation. I cold-booted my machine, started Steam, and then had the issue. It happened immediately after booting up, and wasn't fixed by rebooting. There's nothing that could have started such a wineserver. And more strangely, even if there was something, it would have gotten WINEESYNC=1 from my ~/.pam_environment.

Then, after the failed attempt to start (and without rebooting), I clicked Start again and it worked.

This behavior is also consistent on my machine: after rebooting, it fails once (with the same log message), and then works every time until I reboot again. I have no idea what might cause this.

@ProtonLover432, yes that is meant to be used like the Proton launch options, so you need to specify %command%. However, as I understand, Proton sets esync via its own environment variable called PROTON_NO_ESYNC (with inversed meaning, i.e. 1 = esync off). With that in mind, the full launch options line should look like this:

PROTON_LOG=1 PROTON_NO_ESYNC=1 %command%

Wuestengecko on 19 Jan 2020

Follow-up to the "esync problem". A look into my journal revealed this:

Process 6471 (wineserver) of user 1000 dumped core.

Stack trace of thread 6471:
#0  0x00007fabbdeae248 n/a (/home/wuestengecko/.local/share/Steam/ubuntu12_64/gameoverlayrenderer.so + 0xd248)

So, it is in fact not related to esync at all, it's the wineserver crashing (seemingly due to Steam's overlay). Unfortunately it doesn't appear as consistent as I initially thought, which makes it really hard to test for the issue. @ProtonLover432, you might want to try disabling the Steam in-game overlay.

Full journal output of that Steam instance: steam-journal.log

Wuestengecko on 19 Jan 2020

@Wuestengecko Can you please give the mhw build I have pushed here a try to see if there's any change in behavior?

Tk-Glitch on 19 Jan 2020

@Tk-Glitch 10 out of 10 launch attempts (with reboot after every 3rd) were successful. I'd say that build fixes it for me. Thanks!

Wuestengecko on 19 Jan 2020

👍1

@Tk-Glitch I seem to be having problems with joining friend's sessions with your recent build (proton_tkg_5.0rc6.r1.g9dc9c57b.mhw) - I receive error code 50385-MW1. Any ideas?

egguchan on 19 Jan 2020

@egguchan If you're not missing some wine dependency, I would insist for a bit. Capcom has quite a few connectivity issues since Iceborne, so it will eventually fix itself. I just played for two hours straight in a friend's session.

Tk-Glitch on 19 Jan 2020

👍1

@egguchan If you're not missing some wine dependency, I would insist for a bit. Capcom has quite a few connectivity issues since Iceborne, so it will eventually fix itself. I just played for two hours straight in a friend's session.

@Tk-Glitch Thanks, they had no problems joining my session so assume it was a temp networking hiccup.

egguchan on 19 Jan 2020

🎉1

anyone else having an issue where their camera is constantly spinning or their character is constantly walking?
I thought I had a stick drift issue, but it only happens in MHW since the IB update.

when I unplug the controller, the camera immediately starts spinning and won't stop until I plug it back in.

testing shows me that when my controller isn't plugged in, MHW detects a constant upward tilt to the camera, along with constant walking toward the left, and I can't for the life of me tell where the input is coming from, as it happens even if I unplug my keyboard and mouse.

System:
Manjaro
5.4:12-1-MANJARO
Ryzen 3900x
Nvidia RTX 2080ti
I'm using proton-tkg 5.0rc6.r1.g9dc9c57b, but it occurs no matter what version of Proton I use.

no idea whose bug this is, really.

any help would be wonderful.

LOG

StylinGreymon on 20 Jan 2020

anyone else having an issue where their camera is constantly spinning or their character is constantly walking?
I thought I had a stick drift issue, but it only happens in MHW since the IB update.

when I unplug the controller, the camera immediately starts spinning and won't stop until I plug it back in.

testing shows me that when my controller isn't plugged in, MHW detects a constant upward tilt to the camera, along with constant walking toward the left, and I can't for the life of me tell where the input is coming from, as it happens even if I unplug my keyboard and mouse.

System:
Manjaro
5.4:12-1-MANJARO
Ryzen 3900x
Nvidia RTX 2080ti
I'm using proton-tkg 5.0rc6.r1.g9dc9c57b, but it occurs no matter what version of Proton I use.

no idea whose bug this is, really.

any help would be wonderful.

I have the same issue. I only have a single PS4 controller connected, and while the game is running, jstest-gtk shows me that an additional xbox360 controller is connected. This controller seems to make these constant inputs.

This controller must be emulated by steam or something. Trying to configure it didn't change anything.

The problem didn't happen before the iceborne update / the patched proton version.

heikomat on 20 Jan 2020

anyone else having an issue where their camera is constantly spinning or their character is constantly walking?
I thought I had a stick drift issue, but it only happens in MHW since the IB update.
when I unplug the controller, the camera immediately starts spinning and won't stop until I plug it back in.
testing shows me that when my controller isn't plugged in, MHW detects a constant upward tilt to the camera, along with constant walking toward the left, and I can't for the life of me tell where the input is coming from, as it happens even if I unplug my keyboard and mouse.
System:
Manjaro
5.4:12-1-MANJARO
Ryzen 3900x
Nvidia RTX 2080ti
I'm using proton-tkg 5.0rc6.r1.g9dc9c57b, but it occurs no matter what version of Proton I use.
no idea whose bug this is, really.
any help would be wonderful.

I have the same issue. I only have a single PS4 controller connected, and while the game is running, jstest-gtk shows me that an additional xbox360 controller is connected. This controller seems to make these constant inputs.

This controller must be emulated by steam or something. Trying to configure it didn't change anything.

The problem didn't happen before the iceborne update / the patched proton version.

Try turning off the controller supports in the settings, as well as going into the properties for MHW and turning those controller settings to "forced off"

DigitalDevilSummoner on 20 Jan 2020

@DigitalDevilSummoner
Setting the controller settings for mhw in steam to "force off" made my PS4 controller work better (inputs worked) but didn't fix the mentioned issue

heikomat on 20 Jan 2020

@heikomat did you turn off the controller support in steam settings? Make sure all of those options are turned off too.

DigitalDevilSummoner on 20 Jan 2020

@DigitalDevilSummoner will test that when i can, could take a day or two though. But thanks for the input! :)

heikomat on 20 Jan 2020

5.0-rc3-GE-1-MHW is a fork from GloriousEggroll's build with a modified version of wine implementing Guy1524's workaround. It's linked earlier by przmkg.

@ProtonLover432 I'd say follow GloriousEggroll's suggestion regarding stale wineservers, as that's what the error suggests as well and matches the way Wuestengecko fixed things (reboot likely shutdown the old wineservers).

The one issue when running with the workaround from @Guy1524 appears to be with vsync, others have reported it crashes after a couple minutes with vsync on. I haven't tested with it on, but I can confirm it runs fine with it off.

EDIT: Tested with vsync on for about 20 minutes with no issue. Might be a combination of things causing the crash

I got trouble, i'm using proton-ge-5rc-mhw but when game startup, the game appears but in black screen and after that the game exit unexpectedly.

rahadian on 20 Jan 2020

👍1

5.0-rc3-GE-1-MHW is a fork from GloriousEggroll's build with a modified version of wine implementing Guy1524's workaround. It's linked earlier by przmkg.
@ProtonLover432 I'd say follow GloriousEggroll's suggestion regarding stale wineservers, as that's what the error suggests as well and matches the way Wuestengecko fixed things (reboot likely shutdown the old wineservers).
The one issue when running with the workaround from @Guy1524 appears to be with vsync, others have reported it crashes after a couple minutes with vsync on. I haven't tested with it on, but I can confirm it runs fine with it off.
EDIT: Tested with vsync on for about 20 minutes with no issue. Might be a combination of things causing the crash

I got trouble, i'm using proton-ge-5rc-mhw but when game startup, the game appears but in black screen and after that the game exit unexpectedly.

Following this thread I have the exact error, game launches but mostly it crashes with a blackscreen in a few seconds, sometimes after character loading. Here's the log
steam-582010.log

Workarounds used: foundation media (didn't even know how to apply it), using proton-ge-5rc-mhw, overlay disabled (guess that's why it throws error at the beginning), esync disabled using PROTON_LOG=1 PROTON_NO_ESYNC=1 %command%

Specs:
Ram: 15,5
Intel® Core™ i7-8750H CPU @ 2.20GHz × 12
graphics GeForce GTX 1050/PCIe/SSE2
Gnome 3.32.1 (Ubuntu 19.04)
64 bits
disk of 1TB

tetricoaullante on 20 Jan 2020

I found a fix for the photo tool.
A friend of mine told me that under windows the game creates a directory named "_TempPhoto" in the root of the harddrive the game is installed to and doesn't delete it. Our root filesystem (i mean "/") gets mounted as Z: and the game doesn't have the permissions to create folders/files there.
So to fix it:

Create a folder in your root directory named "_TempPhoto" (sudo mkdir /_TempPhoto)
Give it appropriate permissions (I only tested it with full permissions, sudo chmod 777 /_TempPhoto)

Taking photos works as expected, and you can see the photos getting written in that directory.
Just remember to put that directories permissions back to something more secure after a play session.
The game also doesn't clean up after itself, pictures remain in that temp directory. They do get copied somewhere as they are copied back after deleting the files and starting up the game again, but I don't know where. fdupes couldn't find anything.

LizardWithHat on 22 Jan 2020

👍6 🎉2

I found a fix for the photo tool.

Good find! I can confirm that both symlinking /tmp (which has 1777) and using a directory with restrictive permissions (700 and chowned to myself) work fine too. It appears that everything that's required is read/write access for the game process.

(Who even needs %TEMP% anyways ...)

Wuestengecko on 22 Jan 2020

Awesome that fix the photo thingy, now i can complete de achivement thanks.
Did chown /_Temphotos and chmod 700

On Wed, Jan 22, 2020, 2:16 PM Wuestengecko notifications@github.com wrote:

I found a fix for the photo tool.

Good find! I can confirm that both symlinking /tmp (which has 1777) and
using a directory with restrictive permissions (700 and chowned to
myself) work fine too. It appears that everything that's required is
read/write access for the game process.

(Who even needs %TEMP% anyways ...)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/175?email_source=notifications&email_token=ACHAHPXKXN3KWWR7PM4RES3Q7CEP3A5CNFSM4FRB5W2KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEJUSNZQ#issuecomment-577316582,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACHAHPXKJBRD26FUEOSRAN3Q7CEP3ANCNFSM4FRB5W2A
.

blastermaster77 on 23 Jan 2020

I found a fix for the photo tool.
A friend of mine told me that under windows the game creates a directory named "_TempPhoto" in the root of the harddrive the game is installed to and doesn't delete it. Our root filesystem (i mean "/") gets mounted as Z: and the game doesn't have the permissions to create folders/files there.
So to fix it:

Create a folder in your root directory named "_TempPhoto" (sudo mkdir /_TempPhoto)

Give it appropriate permissions (I only tested it with full permissions, sudo chmod 777 /_TempPhoto)

Taking photos works as expected, and you can see the photos getting written in that directory.
Just remember to put that directories permissions back to something more secure after a play session.
The game also doesn't clean up after itself, pictures remain in that temp directory. They do get copied somewhere as they are copied back after deleting the files and starting up the game again, but I don't know where. fdupes couldn't find anything.

I got a few questions what does chown do and how do you do it?

Also root folder and home folder are on different drives. Root in on the bootdrive and the home folder is on a second drive and steam is installed on the home folders. Do I still have to install this file in the root folder?

Mera1506 on 23 Jan 2020

Just thought I would comment and say that Emanem's version of the patch worked for me in getting practically the same performance as before the patch, and to try to give back thought I would share a custom build I did of Proton 4.11-9 with the patch and the dx12 patches that were needed to get iceborne working. It's specifically this version as I have an issue with the input changes that were added in Proton 4.11-10 which caused it so that I couldn't use my mouse at all in other applications within my window manager after starting up Monster Hunter World, and this version has been serving me well for a while before Iceborne dropped. Though it does have the latest proton stuff outside of wine, only wine is 4.11-9, so it has the latest dxvk and faudio and the like. Hopefully this is useful to someone, just thought I would share:
https://drive.google.com/open?id=1LAAtj2g4xcQrlboy6WH3L-PjsxcWZoMj

JDGBOLT on 23 Jan 2020

Sadly it doesn't seem to work for me. / and /home are on two different drives for me and steam is in the home folder. I tried making the Temp Photo directory in both / and /home, but neither works, am I missing something?

Mera1506 on 23 Jan 2020

@JDGBOLT where did you find Emanem's patch?

Also, why is it so difficult to navigate through issue threads? I have to load from the top to reach some of the more recent messages that aren't recent enough to be loaded already. Very frustrating

RavyuS on 24 Jan 2020

https://github.com/ValveSoftware/Proton/issues/175#issuecomment-575883674
This was based on work from Guy1524 but made more general to only affect monster hunter world.
Patches against dlls/ntdll/signal_x86_64.c in the wine directory.

JDGBOLT on 24 Jan 2020

@JDGBOLT ohh I see. Missed out on that comment!

RavyuS on 24 Jan 2020

@Mera1506
The fact that they are on different hard drives shouldn't matter.
I did like the following:
Make sure you are logged in as the user who launches Steam, or Lutris, idk
$ mkdir /tmp/MonsterHunterPhotos
$ sudo ln -s /tmp/MonsterHunterPhotos/ /_TempPhoto

sugayaa on 24 Jan 2020

Sadly that did not work either. Followed that exactly and it didn't work sadly. Neither did creating the _TempPhoto directory directly in /. Could this be Pop OS specific?

Mera1506 on 24 Jan 2020

Regarding that patch proposed to remove x64 DebugRegister activity. It does not go far enough if this is in fact causing a performance problem for you with WINE.

All Denuvo and a number of other roll-your-own anti-debug strategies involve this technique calling SetThreadContext (…) periodically on protected threads with the DRs manipulated. It is their stupid strategy to remove utility-assigned breakpoints, utterly pointless since this is so easy to spot. 🤷‍♂

You are either going to want this workaround as a full-fledged feature for the benefit of all Denuvo games, or inefficiencies in WINE need to be addressed. Anti-debug is only ramping up and appearing in games it has no practical application in.

Andon13 on 24 Jan 2020

I still have trouble to get a monster hunter working on the custom proton or normal proton with media fix. if I want to join an online session and then a loading screen is appearing in the middle of this process. the game is crashing.

Any idea how to fix this?

donutloop on 25 Jan 2020

@StylinGreymon @DigitalDevilSummoner i fixed the constant camera spinning (at least for me)
first, i turned all controller settings steam offered me off. That improved the controller situation (as in, start would now bring up the start menu etc), but didn't fix the spinning.

What did fix the spinning was setting the windows version in winecfg back to windows 7.
When people suggested that DX12 might improve framerate, i manually set the windows environment to windows 10, and forgot about it.

Setting that back to Windows 7 fixed it.

heikomat on 26 Jan 2020

New patch brakes the game, :( it doesn't load. Using proton version: 5.0-rc3-GE-1-MHW, log here. (Note: everything was working with the custom proton runtime just fine)

Distro: Pop OS! 19.10
CPU: Ryzen 9 3900x
GPU: Nvidia rtx 2070 super

cjgratacos on 27 Jan 2020

Are you using mods? SpecialK's dll? You may want to fiddle around with that. I'm using SpecialK's dll without mods and the latest patch seems to be working over here (though network is still complete ass).

GoLD-ReaVeR on 27 Jan 2020

@GoLD-ReaVeR how'd you get SpecialK working?
it's always stopped MHW from loading, for me.

StylinGreymon on 27 Jan 2020

He updated his dll a few times after the patch, make sure you're using the latest. Other than that I got nothing special going on besides that 5.0-rc3-GE-1-MHW-fix version.

GoLD-ReaVeR on 27 Jan 2020

Are you using mods? SpecialK's dll? You may want to fiddle around with that. I'm using SpecialK's dll without mods and the latest patch seems to be working over here (though network is still complete ass).

@GoLD-ReaVeR Nop no mods, only some dlcs ( iceborne, deluxe kit and enhance textures)

I redownloaded the full game from a clean slate. Still got the same issue. Now I am wondering where I screwed up.

Are any of you using dlcs besides the iceborne one, also any other configuration on the launcher?

cjgratacos on 27 Jan 2020

I have the same issue on Ubuntu 19.10. Launching the game with the custom proton-ge makes it crash at start. It launches fine with the proton 4.11-12 but still with the 3 fps bug

Edit : The game launches fine with the 4.11-9-mhw linked by @JDGBOLT, but I have weird camera issue with this one, it feels like it's shaking as I move the mouse and ends up giving a feeling of a non smooth game

tuxrinku on 27 Jan 2020

@GoLD-ReaVeR How did you get Special K's mod working?
Apparently it requires vcredist2019, which I installed with protontricks, but the game still won't load (hangs on a black screen).
Care to share your .ini?

egguchan on 27 Jan 2020

New patch brakes the game, :( it doesn't load. Using proton version: 5.0-rc3-GE-1-MHW, log here. (Note: everything was working with the custom proton runtime just fine)

Distro: Pop OS! 19.10
CPU: Ryzen 9 3900x
GPU: Nvidia rtx 2070 super

Running Pop OS 18.04 and it's a gamble if it will load or not.

Mera1506 on 28 Jan 2020

👍1

@GoLD-ReaVeR How did you get Special K's mod working?
Apparently it requires vcredist2019, which I installed with protontricks, but the game still won't load (hangs on a black screen).
Care to share your .ini?

I didn't change anything in specialK's uni, I did move the old MHW config away and replaced it with what IB puts in there. I then went into the menus to reconfig everything as it was etc. in game.

GoLD-ReaVeR on 28 Jan 2020

I use this fix but when I try to set MHW to launch with it in steam, I have to do a 40Gb update (I already downloaded Iceborne) and when I do it, the compatibility tool disappear from the available tools. I relaunch steam and I have to do the update again if I select the tool. Any idea on why it's happening ? I managed to play on this compatibility tool before the update for the appreciation festival so I don't really understand.

cvignal on 28 Jan 2020

👍2

Im wondering if my problem is related or not, but for me it works great with the fix here https://github.com/przmkg/proton-ge-custom/releases/tag/5.0-rc3-GE-1-MHW However im having a problem where I will sometimes hard crash and have to force reboot my computer. Im running 4.19.(98?) Manjaro, and using a i7-8700k, alongside a gtx 1070, im not seeing any issues with cpu usage when running the game however. Unsure if I can get logs due to the hard crash

Zyean on 29 Jan 2020

@Zyean Sounds like the long standing issue with MHW+DXVK on Pascal. You might want to give the 440.43.02 vulkan dev driver a try if you're not already using that. It contains bugfixes missing from 440.44 and doesn't have the stability issues 440.48.02 has.

Tk-Glitch on 30 Jan 2020

PSA

Please note with the most recent patch, setting the cpu governor to _performance_ is mandatory to avoid micro stutterings (at least on Intel).

Emanem on 30 Jan 2020

I haven't noticed a difference between the two governors, but I have noticed my CPU usage has gone way down since the patch.
I still can't play any higher than 30fps without crashing though.

StylinGreymon on 31 Jan 2020

@Tk-Glitch I wasnt able to find that version of mhwd. But i tried the suggestion from @Emanem and disabling my compositor while in game, and messing with a few bios settings, seems to have reduced the frequency of the full freezes a lot, they happen once or twice but I can play basically all night without it happening, did you have the package location for 440.43.02?

Zyean on 31 Jan 2020

As I understand you're running Manjaro, you can use my nvidia-all installer for that:
https://github.com/Tk-Glitch/PKGBUILDS/tree/master/nvidia-all

If you're not familiar with makepg:

git clone https://github.com/Tk-Glitch/PKGBUILDS.git
cd PKGBUILDS/nvidia-all
makepkg -si

I encourage checking the readme ;)

Tk-Glitch on 31 Jan 2020

I'm getting so many startup crashes that I'm giving up on playing for now... before January 27th patch it was working fine with the custom Proton GE builds.

I can get the game to open with the official Proton version, but then I get the 3 FPS bug.

Now I don't know if the February 6th patch will fix any of these of if will be worse.

Anybody got a workaround for the constant crashes on startup?

Kubuntu 19.10 x86_64
nvidia driver 440.48.02
GeForce GTX 1050 Ti
16GB RAM
Intel Core i5-8300H CPU @ 2.30GHz
5.0-rc3-GE-1-MHW and Proton-5.0-GE-1

shigutso on 1 Feb 2020

If all people with issues are on Ubuntu/Debian/PopOS, that would look like something has regressed in the distro. Also for people using nvidia, 440.48.02 has stability issues, so you might want to rollback to 440.43.02 (or even 440.44) until the next release.

Tk-Glitch on 1 Feb 2020

Where do you get 440.48.02? I don't see nvidia offering it at all.

I currently have issues with the game freezing when chromium is open and playing video. It causes both the game and chromium to repeatedly freeze until either is killed. There is no CPU spiking, my disk seems to be under heavy load but I don't see how that should be interfering with chromium. This started happening in particular after the last patch (26-01-2020). If someone has any ideas on how to circumvent this, that would be nice. I tried disabling G-sync, and while it seemed to alleviate the issue at first, it's now back to the freezing thing.

GoLD-ReaVeR on 1 Feb 2020

Where do you get 440.48.02? I don't see nvidia offering it at all.

I don't know about other distros, but in the Ubuntu PPA is available for Ubuntu 18.04
https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa/+packages?field.name_filter=&field.status_filter=published&field.series_filter=bionic

CSahajdacny on 1 Feb 2020

@GoLD-ReaVeR https://developer.nvidia.com/vulkan-driver

Tk-Glitch on 1 Feb 2020

But I can open other games with no issues and with official Proton MHW always opens, but with the <10FPS bug, so I'm guessing it could be something related to the workaround being used in Proton-GE... but I don't know how to debug that. I'll try to take a look.

shigutso on 2 Feb 2020

Some more feedback:

The game now runs at same levels pre _Iceborne_
Requires a patched _ntdll.dll_ - need to try GE Proton, using mine for the time being
The game has issues with _G-Sync_ (or _FreeSync_), it happens also on Windows
_Alt-Tab_ sometimes results in FPS decrease - try avoiding it
Running other programs in background and _Alt-Tab_ to those has high chances to trigger the performance bug
Setting the CPU governor to _performance_ is almost a must have now - since the latest patch if you don't do it, you'll experience micro stuttering
The Media Foundation is indeed required, otherwise you won't be able to 'finish' the game.

Everything else is quite good - one can actually game with it.

Emanem on 3 Feb 2020

Well, this will vary quite a bit depending on your hardware and software config. My experience is different:

The game doesn't run at same levels as pre Iceborne here. Perf is lower by ~5-7% at same settings (max), depending on scene. However some effects such as ambient occlusion are not the same as before and the new highest setting is much heavier than it was.
The patch is indeed still required. I'm using my own proton-tkg builds here myself.
No issue with Freesync on my 5700XT. I don't have a VRR capable Geforce to test.
I'm alt-tabbing hundreds of time a play session and never saw a perf decrease by doing so.
I'm always having a high amount of apps running in the background, notably a 100+ tabs Firefox session, and alt-tabbing to it or other apps never triggered the issue (as said above).
Changing CPU governor is not needed as long as the one in use is sane for the desired performance level and CPU. The (usually kept default on distro-provided kernels) Intel_pstate driver that will get used on Sandy-Bridge and newer CPUs has been suffering from a huge perf regression lately (since 5.3 I think?) so disabling it or using it in passive mode to act as a wrapper is recommended on Intel CPUs (and the more cores you have, the more you're affected).
mfplat is indeed still required for a few cutscenes.

I have about 150 hours played since IB release at this point 🐸

Edit: For the ones interested, I just released 5.1 based builds, with one dedicated to MHW: https://github.com/Tk-Glitch/PKGBUILDS/releases/tag/5.1.r2.gd53a1b4a

Tk-Glitch on 3 Feb 2020

Hello @Emanem, a workaround you linked is legally problematic and has been removed.

kisak-valve on 3 Feb 2020

Well, this will vary quite a bit depending on your hardware and software config. My experience is different:

The game doesn't run at same levels as pre _Iceborne_ here. Perf is lower by ~5-7% at same settings (max), depending on scene. However some effects such as ambient occlusion are not the same as before and the new highest setting is much heavier than it was.

The patch is indeed still required. I'm using my own proton-tkg builds here myself.

No issue with Freesync on my 5700XT. I don't have a VRR capable Geforce to test.

I'm alt-tabbing hundreds of time a play session and never saw a perf decrease by doing so.

I'm always having a high amount of apps running in the background, notably a 100+ tabs Firefox session, and alt-tabbing to it or other apps never triggered the issue (as said above).

Changing CPU governor is not needed as long as the one in use is sane for the desired performance level and CPU. The (usually kept default on distro-provided kernels) Intel_pstate driver that will get used on Sandy-Bridge and newer CPUs has been suffering from a huge perf regression lately (since 5.3 I think?) so disabling it or using it in passive mode to act as a wrapper is recommended on Intel CPUs (and the more cores you have, the more you're affected).

mfplat is indeed still required for a few cutscenes.

I have about 150 hours played since IB release at this point 🐸

Edit: For the ones interested, I just released 5.1 based builds, with one dedicated to MHW: https://github.com/Tk-Glitch/PKGBUILDS/releases/tag/5.1.r2.gd53a1b4a

Are you using mouse and keyboard? I'm using GloriousEggroll's latest release combined with nvidia's vulkan beta driver and I have good performance thus far. But the mouse won't work properly when I have my browser open. Other inputs are malfunctioning as well. I have no indication of processes hanging or anything similar, wineserver is below 5% and MHW's CPU usage is all over the place as it always is. I have nvidia's indicators enabled and it sometimes says vsync is on for 1-2 frames for some weird reason. Framerate is 60fps (I capped it at that) with some drops to 50fps, but nothing concerning. Having to close my browser is the last pending issue I have with the iceborne release (to my knowledge) and when that is fixed I can FINALLY enjoy the game as I could pre-IB release.

GoLD-ReaVeR on 3 Feb 2020

@GoLD-ReaVeR I'm using m+kb and my inputs are fine. However that behavior sounds familiar. I have had similar issues on Nvidia when some kind of hardware accelerated content was playing in the browser. Disabling hw accel worked. No such issue with the AMD+RADV/ACO combo at least. That being said, the input handling has clearly changed since the (IB-release) update, and not in a good way. 180° turns are funky (but the issue is also present on windows), and some mouse interactions aren't working anymore when running the game through xwayland (when it used to work before).

Tk-Glitch on 3 Feb 2020

Using Tk-Glitch's recent build fixes the issue of the app crashing when I hit play.
However now when I start the game it sits at a black screen for a couple seconds then eventually closes.
This is the log for that: steam-582010.log

I have done a number of tests and it seems like if I keep trying to run it, every 4th or 5th run the screen stays black for much longer before closing.

If I click my mouse in the game window while its loading(on that 4th or 5th run that stays open longer) then it will load the game and drop me in the main menu.

The other times where it would normally close quickly doesn't start if I'm clicking in the game window.

Does this make sense to anyone, it sounds superstitious to me, but it happens consistently enough I think clicking in the game window is doing something.

ProtonLover432 on 3 Feb 2020

Well maybe I am being superstitions I did more testing and it would sometime start without me clicking into the active window it did still seem to be every 4 or 5 tries though

ProtonLover432 on 3 Feb 2020

@Tk-Glitch Well this is a little embarrassing, when I was using your script (great script btw!) I realized I was using 418.113 as my drivers (oopsie!) That would explain all the crashes I had

Zyean on 4 Feb 2020

@ProtonLover432 Have you tried switching modes? From borderless FS to FS, or windowed? I remember that some people hit that issue with some DEs even before IB release. You can get there by editing graphics_option.ini in the game's dir.
Also if you have mods (especially ones that injects themselves in the game's memory), try without them. That initial black screen is when the DRM kicks in btw.

@Zyean Happy you find it useful! 418.113 should indeed miss quite a few important fixes so that sounds reasonable 😄

Tk-Glitch on 4 Feb 2020

I'm getting some random framedrops using Proton-5.0-GE-1. In the new area, I'm going from 60 to 35 for like 2 seconds, then jumps back to 60 etc. I don't have this issue in any other game, and never encountered it either before the Iceborne release. My cpu governor is set to Performance. Anyone else having this issue ?

Edit: I have the same framedrops using @Tk-Glitch build. I'll check with some different nvidia drivers

tuxrinku on 4 Feb 2020

@GoLD-ReaVeR I'm using m+kb and my inputs are fine. However that behavior sounds familiar. I have had similar issues on Nvidia when some kind of hardware accelerated content was playing in the browser. Disabling hw accel worked. No such issue with the AMD+RADV/ACO combo at least. That being said, the input handling has clearly changed since the (IB-release) update, and not in a good way. 180° turns are funky (but the issue is also present on windows), and some mouse interactions aren't working anymore when running the game through xwayland (when it used to work before).

I suspected HW acceleration in browser as well, but I've disabled that already. Do you have any patches GE doesn't by any chance?

GoLD-ReaVeR on 4 Feb 2020

@ProtonLover432 have you tried removing ~/.steam/root/userdata/582010? Had the same issue as you yesterday and today after removing that directory the game launches again.

edit- As Gold below pointed out it is the save data directory, I had mine backed up on windows & steam cloud.

cj360 on 4 Feb 2020

Eh that's the save data. Please back that up before removing!

GoLD-ReaVeR on 4 Feb 2020

I actually have a similar issue as @shigutso

It will load the black screen and then crash on startup a bunch of times and eventually it will load

However when loading into the game after hitting 'start game' it seems there's a 50/50 chance it will crash there too going back to the beginning of crash on startup

This happened before I updated drivers if anyone is following the paper trail I left behind

@Tk-Glitch Is this something you have an issue with as well? You mentioned it was running perfect for you (minus a small performance dip) I assume you're on 440.43.02 as you mentioned?

Zyean on 5 Feb 2020

@GoLD-ReaVeR

I suspected HW acceleration in browser as well, but I've disabled that already. Do you have any patches GE doesn't by any chance?

That's extremely likely and probably true the other way around as well as I don't feel like some of the patches GE enables by default should be in for a "generalist" build. I might be a bit too conservationist here regarding those "releases" but my build system is ultimately made for customization and experimentation, so one can craft a very unique and unsafe build with it if need be.

For the people who has issues getting the game to run, or performance issues, are you using a fsync patched kernel? I have noticed that some people seem to have specifically more issues running the game lately when they hit the esync path. Fsync doesn't seem to exhibit the same issue, and will also give a performance boost. Considering the game is still doing retarded stuff maybe esync hits a bottleneck here. Disabling it altogether isn't desired considering the heavy CPU requirements of the game, so it might be worth trying a fsync patched kernel if you're not already using one.

Specifically for the ones who can't get ingame or only very inconsistently, is it any better when using PROTON_NO_ESYNC=1 %command% as launch option for the game (from the game properties menu)? If that fixes it, you definitely should consider trying a fsync patched kernel to get back the performance lost by disabling esync (+a bit more) and get enhanced stability.

@Zyean

Is this something you have an issue with as well? You mentioned it was running perfect for you (minus a small performance dip) I assume you're on 440.43.02 as you mentioned?

I'm playing the game with an AMD GPU currently (RX5700XT), and have been since IB release. I saw and received a good amount of users feedback regarding 440.48.02 issues, all fixed by rolling back to 440.43.02, so I'm simply sharing that with you guys. My Nvidia GPU will be installed in a different machine soon-ish so I'll be able to give a more personal experience. Nvidia might have a new driver out fixing the 440.48.02 problems by then.. Who knows 🐸

Tk-Glitch on 5 Feb 2020

Hello, haven't been following this thread very closely so sorry if I'm out of the loop but I thought I should post this.
I stared a thread a couple of weeks ago on the steam discussion board for this game with instructions to help Linux users run it again directly linked to this thread.
https://steamcommunity.com/app/582010/discussions/3/1735509281937243358/
I did post a link to this github thread but I'm sure a lot of people on there hasn't read this entire thread to find more information.
It has a few people posting so if anyone wants to join in and help those on there that would be really good for the community. If someone wants me to update the OP with better instructions just post those instructions in the steam thread and I'll get around to it. Many people don't bother reading pass the OP after all.

AnimatedFreak on 5 Feb 2020

Using no esync seems to reduce the issue I'm having weirdly enough, even though I'm running an fsync kernel (zen kernel). Furthermore, removing the framerate limit (from 60fps to no limit) increases the effect and crashes the game. The game isn't bottlenecking any piece of hardware at 60fps and the GPU hits a mere 70% before the game crashes. Definitely some weird stuff going on. The mouse behavior kinda feels like you're hitting the edges of a window without the cursor resetting to the center. Keys don't press or depress properly. And other games, such as code vein, don't have this issue at all.

GoLD-ReaVeR on 5 Feb 2020

For the people who has issues getting the game to run, or performance issues, are you using a fsync patched kernel? I have noticed that some people seem to have specifically more issues running the game lately when they hit the esync path. Fsync doesn't seem to exhibit the same issue, and will also give a performance boost. Considering the game is still doing retarded stuff maybe esync hits a bottleneck here. Disabling it altogether isn't desired considering the heavy CPU requirements of the game, so it might be worth trying a fsync patched kernel if you're not already using one.

Any idea on how to install fsync on ubuntu 19.10 ?

tuxrinku on 5 Feb 2020

@tuxrinku Since Valve doesn't provide a PPA for 19.10 afaik, your best bet is to try an alternative kernel such as Xanmod or Liquorix.

Tk-Glitch on 5 Feb 2020

@Tk-Glitch Merci ! I'm gonna try that and let you know if it fixes the framedrops issue.

Edit: Okay I installed the xanmod kernel with fsync (fsync: up and running in the game log). The framedrops issue is still here but seems to appear less often. Tho the game still launches 1 out of 10 times and still regularly crashes right after loading the character. Even with PROTON_NO_ESYNC=1 set.

tuxrinku on 5 Feb 2020

🚀1

I discovered that the cpu usage during the game "peaks" randomly for like 2 seconds and that's what causing me those fps drop. It mostly happens in the new area, tho I noticed it also in the old areas but less frequently. fsync makes the drop less significant, but still here and annoying.

tuxrinku on 6 Feb 2020

@tuxrinku @GoLD-ReaVeR
Regarding the random hitches, I think and sure hope I was actually able to reproduce it so my fix will also work for you guys. The fix seems to be to set dxgi.maxFrameLatency = 1 for DXVK. There are a couple ways to do so, but the most straightforward is to create a dxvk.conf file in the same dir as the game exe, and put dxgi.maxFrameLatency = 1 in there. If you enable proton logs, you should see the option being applied when DXVK initializes.

Other potentially interesting things:

The HD textures DLC seems to be borked since IB and currently requires 11GB+ VRAM to work stably on Windows. DXVK using more memory makes it a no go for most hardware (2080Ti included) if you want a stable game at all times.
The highest LOD bias option seems to be pretty badly optimized when it comes to loading new data between zones. Using a lower value or the "variable" option makes data streaming in quite a bit smoother.
The game became much more sensitive to overclocking since the IB update, especially regarding system RAM and GPU, so if you have those overclocked, it might be worth trying slightly lower clocks.

@GoLD-ReaVeR

removing the framerate limit (from 60fps to no limit) increases the effect and crashes the game

That one is really weird. I'm playing with framerate uncapped and it's been smooth sailing. I'm curious to see if I can reproduce that with my Nvidia GPU. It could actually be unique to Nvidia tbh, from the similar reports I saw on Windows.

Tk-Glitch on 6 Feb 2020

@Tk-Glitch Thanks for the tip. Sadly I can't try it as the game now always crashes after loading the character. No idea if it's related to the latest 11.50.00 update but I've been trying to run it for the last 30 minutes.
steam-582010.log

EDIT: I finally managed to get ingame (I still feel like the odds of getting through that loading screen are even worse now), and can confirm setting dxgi.maxFrameLatency = 1 helped. I still have fps drops here and there, but nothing compared to how it was before.

tuxrinku on 6 Feb 2020

no matter what I do, I still can't play at more than 30fps without crashing every 40 minutes.

StylinGreymon on 6 Feb 2020

@Tk-Glitch I haven't tested turning off the framerate limit, but the setting has no effect on my input issues when the browser is open. I miss the sweet luxury of playing the game with my browser open :'( There is no overload anywhere, at some point input just doesn't respond. This happens far more frequently in hunts compared to the hubs.

GoLD-ReaVeR on 10 Feb 2020

Can confirm playing with fsync enabled kernel & proton without the hd texture pack the game sits at the capped 60fps 90% of the time. No idea why the game recently refused to launch and deleting local save data fixed it though.

cj360 on 11 Feb 2020

For anyone still having issues, try using the newest version of GloriousEggroll's custom proton, it fixed 99% of issues for me, consistently launches at start, only occasionally crashes at character select

https://github.com/GloriousEggroll/proton-ge-custom/releases

Zyean on 12 Feb 2020

Even with GE proton build game crashes halfway during loading screen after hitting new game.
Edit:
After trying literally everything from this thread and reports on protondb only lead i have is that crash is of a segfault variety and nothing that i tried in the past 3 hours helps. Crash happens at about 55% mark on loading screen right after selecting new game menu entry after fresh install / fresh savefile.
Arch. nvidia latest. proton eg latest. mf-install. 1050ti.
Edit2: strace shows that segfault occurs right after this group of calls

I guess it somehow relates to this fsync thing everyone is talking about?

Nhlest on 12 Feb 2020

@Flutterlice I have the same issue (crashing during first loading screen after character select). I got it working sometimes after opening another game before that uses a bunch of my RAM (my case I opened CS:GO, played for 30 minutes, then tried MHW). I don't know why it worked, though. And when it goes past the first loading screen, the game never crashes, I can play for hours and hours without any crashes.

@ everybody, how much RAM do you have in your setup? Maybe this is a memory leak RAM related issue...

I have 16GB RAM DDR4.

shigutso on 12 Feb 2020

24GB ram, does your game crash before loading screen appears or right in the middle of progress bar?
Also after way too much experimentation i think i got my account locked for 24 hours because of DENUVO

Nhlest on 12 Feb 2020

Yes, usually right in the middle of progress bar.

I ran the game with PROTON_LOG=1 but there's no relevant info that could lead to the root cause, but maybe that helps someone:
https://paste.ubuntu.com/p/mxPZq6jnSc/

shigutso on 12 Feb 2020

@shigutso I don't know what magic is this, but your tip to launch CS:GO before monster hunter actually helped, thank you. I had 0% success rate to launch the game before but now with this hacky workaround i am getting 9 out of 10 launches done.
Edit: After some experimentation i found a 100% reliable way to get past this first loading screen. Segfault disappears if i throttle cpu right before i click start game button to the minimum allowed frequency (800 Mhz in my case). Why and how it helps - i can't even imagine but after this little trick game is 100% playable without any even minor problems (i can unthrottle cpu after loading finishes)

Nhlest on 13 Feb 2020

I have 16GB of RAM and seem to have the same problem after character select as well. The loading bar will move a bit, freeze and then crash.

@Flutterlice How are you throttling your cpu to try and get past the initial character select loading screen?

ProtonLover432 on 13 Feb 2020

sudo cpupower frequency-set -u 2700Mhz
for example

Nhlest on 13 Feb 2020

So Before you start with game with steam you are doing:
sudo cpupower frequency-set -u 800Mhz
start game
select character
then you set it back to normal:
sudo cpupower frequency-set -u 2700Mhz
Is that the process?

ProtonLover432 on 13 Feb 2020

I start the game at full cpu power to speed up initial loading, then when i am in menu - i throttle cpu to 800Mhz and click play. After that game loads normaly and i put cpu on full power again.
Edit: After some restarts under different conditions it turned out that i was too quick to find a conclusion. I am still getting occasional crashes on the first loading screen here and there without obvious connections to my cpu clock speed.

Nhlest on 13 Feb 2020

I'm trying to enable more in-depth logging so as to determine what causes me to crash at fps higher than 30.
PROTON_LOG=1 doesn't give me any answers I can interpret, so are there other logs I should be looking at?

StylinGreymon on 13 Feb 2020

Updated specific MH:W only patch for dlls/ntdll/signal_x86_64.c latest proton/wine.
Works beautifully as of now - enjoy.

signal_x86_64.patch.txt

Emanem on 15 Feb 2020

@Tk-Glitch I got an update for ya on my situation. Apparently the browser video player and the game are not playing nice with eachother. If I have a twitch video stream open I get input issues and actual frame hangs while if I move to a tab such as this issue list the problem is gone. I have 2 monitors of which one is gsync and the other isn't. I tried disabling gsync using nvidia-settings but the monitor itself still indicates gsync is enabled. I'll try to investigate that a little more; this could be related to the problem that was reported on the MHW forums with gsync users in windows.

If anyone has any ideas on this problem, I'd love to hear them.

GoLD-ReaVeR on 15 Feb 2020

I finally managed to disable GSync and it made no difference whatsoever.

GoLD-ReaVeR on 17 Feb 2020

new 2GB patch from Capcom today.
CTD within 10 minutes of playing at 60fps.

StylinGreymon on 20 Feb 2020

@GoLD-ReaVeR That seems indeed very nvidia-y. I used to have a triple monitor setup with Nvidia GPUs and that was pretty much the norm when the GPU was nearing or at 100% utilization. That was without Gsync so probably unrelated. I have tried almost every configuration possible and the only partial fix was to use chromium (after the game was ran and the compositor disabled), but it would randomly stop working, and frametimes weren't anywhere near as good anyway. I have never experienced such a thing on my radeons.

On my end I have played for 3 hours straight today and the game has been idling for 2 hours more while I was away. No crash, no perf issue, framerate unlocked and averaging 80 @ 1440p..

While it looked like a Debian-based distro issue at first, it might not tell the whole story. Is anyone having issues not using a Nvidia GPU? And, if so, on what distro?

Tk-Glitch on 22 Feb 2020

Are you using the mouse? Because that seems to be the only thing affected by the framerate increase in terms of stuttering. I just tried increasing in menu and the mouse became really choppy while keyboard responded just fine. I see no CPU difference in htop (so no wineserver overload).

With the latest patch I've also been getting this mysterious behavior when I have twitch hidden and having a tab over containing a still image. The game also seems to be becoming more crash prone again; though I haven't entirely verified that with nvidia's latest vulkan update. The game seems to recognize the renderer has crashed and even draws a popup for that, after which trying to close the game though the WM shows the next pop up asking if I want to exit without saving, clicking "Yes" however doesn't close the game. It stays in zombie much like it would do if you tried to exit the game normally. If you want any more info from me, just let me know.

GoLD-ReaVeR on 23 Feb 2020

Yeah I'm using mouse+keyboard for the game. Mouse input isn't awesomely smooth and the best compromise I found was with my mouse set to 125Hz. 500Hz was pretty skippy. Wine has had issues with high pollrate mice for years anyway so nothing too unusual here. If you're using the force composition pipeline option, you may want to try without it as it tends to be playful with frametimes when GPU load is high.

Regarding the stability problem, have you checked your journal/dmesg for a potential XID from the Nvidia driver when the renderer dies? I am aware of a supposedly Pascal-specific crash Nvidia guys were trying to repro better on the base game as their trace triggered the crash only after ~8 hours, so not very practical.

If the issue is indeed nvidia-specific (which I assume it is, considering I have no stability issue with the game on both Intel+Navi and Zen2+Polaris systems) and trackable/reproducible with an apitrace it would likely be of great help for Nvidia.

Tk-Glitch on 24 Feb 2020

This is in my dmesg:

[17856.122461] NVRM: GPU at PCI:0000:09:00: GPU-21589442-001b-4b23-9b0e-073213285a8d
[17856.122464] NVRM: GPU Board Serial Number:
[17856.122468] NVRM: Xid (PCI:0000:09:00): 31, pid=2563, Ch 0000002b, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_T1_4 faulted @ 0x364d_00002000. Fault is of type FAULT_PDE ACCESS_TYPE_READ

GoLD-ReaVeR on 24 Feb 2020

Thanks. I'll pass it along.

Tk-Glitch on 24 Feb 2020

Some feedback - When I was on my 1080 GTX the game was crashing randomly - since I moved to 2080 Ti RTX it's much more stable.
Now, not totally sure about of my 1080 GTX with more recent drivers, unfortunately don't have another PC to test it.

Emanem on 24 Feb 2020

@Tk-Glitch about the mouse thing, I recall one of the changes between MHW base and MHW IB being that they switched mouse input to raw. Is there a patch available that skips wineserver calls for these kinds of inputs? Or is this already native behavior?

GoLD-ReaVeR on 24 Feb 2020

@GoLD-ReaVeR Proton and wine-staging have support (and patching it out makes things worse), but there's room for improvements for sure.

Tk-Glitch on 24 Feb 2020

Support for it? Do I need to enable it somehow?

GoLD-ReaVeR on 24 Feb 2020

No it'll get used OOTB when a game tries to use rawinput, sorry if I was unclear.

Tk-Glitch on 24 Feb 2020

Is there a way to verify it does this?

GoLD-ReaVeR on 24 Feb 2020

Is there anything in this log that might explain why my system locks up completely when I play at ≥60fps?
steam-582010.log

StylinGreymon on 25 Feb 2020

@GoLD-ReaVeR WINEDEBUG="+rawinput" should do

Tk-Glitch on 25 Feb 2020

The latest update of Proton fixes everything ! The only small issue I have with official proton builds is that some few numbers keys (not the ones in numpad) doesn't work in-game. Maybe it has to do something with the keyboard using a french layout.

tuxrinku on 11 Mar 2020

@tuxrinku Yes it has. Using US layout usually fixes such issues. As a french layout user as well, I have found that using US layout by default, then setting it to french through my DE also fixes it, without affecting my day to day typing needs (as in, I don't have to switch layouts at any point, and it survives rebooting).

Tk-Glitch on 11 Mar 2020

Latest MHW update seems to have broken something, the game doesn't launch and i'm not sure where to get diagnostic info.

AlexLewandowski on 12 Mar 2020

@Tk-Glitch alright, there's been another patch... does it run for you? I'm using your latest build and it doesn't even start for me.

Not even getting a message on the steam console.

GoLD-ReaVeR on 12 Mar 2020

No the last patch broke the game on Proton. It'll run without Guy's patch (Proton <5.0-4) but with the previous unplayable performance issue, making it virtually not playable anymore on Linux.

Edit: I've been Denuvo banned for the next 24 hours due to testing - sigh - but if someone is willing to try, Guy sent me a patch to test : removed (I won't explain how to use :frog: )

Edit2: Many Windows users are also affected by that new update and can't play anymore, so I tend to think Capcom will be forced to do something. But it might take a while considering how slow they usually are at fixing things.

Edit3: I have removed the test patch posted earlier as I was able to try the game with it (with similar results - game doesn't run)

Tk-Glitch on 12 Mar 2020

I'm glad to see I'm not the only one experiencing this new patch problem. I hope in the near future someone can figure out a fix.

sebby4900982 on 12 Mar 2020

I'm not getting those messages in my dmesg. Which version of proton are you running?

GoLD-ReaVeR on 12 Mar 2020

Can confirm game won't launch either with official proton or the GE version I was using that was working nicely until now.

Also read some Windows users on Steam saying it's not booting for them too.

alosarjos on 12 Mar 2020

I can confirm it as well. So sad, the latest proton worked perfectly before the mhw update lands.

tuxrinku on 12 Mar 2020

@alosarjos

Also read some Windows users on Steam saying it's not booting for them too.

They've found their work-around, just turn off the anti-virus and the game works again. The last update brings even more virus-like behaviours, now we have more scanners to scan your disk again over again. Though, Windows users get their fps dropped down again due to this, but they have their work-around, they can play the game now without the reaction from CAPCOM. So, I believe that CAPCOM will not release a patch recently to fix this problem (maybe even not a problem for Windows users).

Mr-indescribable on 12 Mar 2020

@alosarjos

Also read some Windows users on Steam saying it's not booting for them too.

They've found their work-around, just turn off the anti-virus and the game works again. The last update brings even more virus-like behaviours, now we have more scanners to scan your disk again over again. Though, Windows users get their fps dropped down again due to this, but they have their work-around, they can play the game now without the reaction from CAPCOM. So, I believe that CAPCOM will not release a patch recently to fix this problem (maybe even not a problem for Windows users).

Having to disable the antivirus is not acceptable

alosarjos on 12 Mar 2020

That doesn't work for all windows users. Does anyone know if any other new denuvo games have this issue?

GoLD-ReaVeR on 12 Mar 2020

It doesn't seem to be Denuvo tbh. More like a continuation of their custom "anticheat" attempt that will never work because they don't know what they are doing. Capcom will have to do something about it, but the delay is the blurry part.

Tk-Glitch on 12 Mar 2020

As I understood it, it was denuvo that slowed everything to a standstill under proton. If the undoing Guy's original patch fixes the crash but reintroduces the slowdown then it's reasonable to suspect denuvo of this change. Further more, none of the injectors made for MHW have targeted the framerate reduction that proton has received, which would also imply that that was not denuvo's doing but capcom. Special K has also stated previously to me that denuvo in his experience always tries to maintain performance of a game they are protecting; naturally wine support is not their goal and the wineserver crashed and burned because of this. But if the wine implementation can stop debug calls, anyone replacing or injecting the ntdll/kernel in windows could do the same. I'd presume that the game now crashes because they are checking this. This also would explain why it triggers just about every virus scanner on the planet.

That said, if you could bake me a release with the new patch applied (or any new patches you wish to apply for sake of testing), I'm more than happy to spend my 5 tries a day for it. Perhaps others are willing as well.

GoLD-ReaVeR on 12 Mar 2020

👍2

I can confirm the following:

it does work with previous versions of Proton, when setting/re-setting the registry (making the expensive _wineserver_ call) was in place - the FPS is really bad.
it doesn't work with new version of Proton when we don't set debug flags

Looks like @GoLD-ReaVeR is correct: the anti cheat software is now enforcing the check of debug registry being set.
This is very sad.

@Guy1524

edit

Feels like this time it's going to be grim - or the _wineserver_ performance gets tackled or we'll have to find a way for the anti-cheat (?denuvo?) to be tricked into thinking the debug registers have been set...

edit 2

Seems like the denuvo protection kicks in _after_ the crash with Proton 5. This makes me think that perhaps the issue is not with the debug registers, but with Proton 5.0 itself.
Unfortunately I've run out of my denuvo tries, but tomorrow I'll patch _ntdll.dll_ for Proton 4.11 and see if the game works or not.
Funny enough, now that I have exhausted my tries, if I run Proton 5 I don't even get the denuvo window. Proton 4.11 instead does do it (even with a patched dll).

Emanem on 13 Mar 2020

👍5

I still have a proton 4 build on my system with the previous patch. Also, how can denuvo stop you from starting when its protection kicks in after the crash? Or did you skip a few things?

EDIT: The build that initially was supplied to circumvent the issue in iceborne crashes all the same.

GoLD-ReaVeR on 13 Mar 2020

I can confirm that latest Proton and GE won't launch the game with its latest update, just to throw my hat into the ring. I also tried testing other proton builds and I also got locked out of the game for 24hr due to Denuvo.

Capcom have been phasing out Denuvo from their games here and there - DMC5 being the latest - do we know if there's any news on them doing the same for MHW?

ghost on 13 Mar 2020

I'm willing to help with my 5 tries tho i have already spend some

edit: no more tries :D

edit2: I probably have my tries back.

ThomasT75 on 13 Mar 2020

I'll hope capcom just dumps denuvo but idk how much hope I have since they're just advising people to exclude the game from their anti-virus instead of undoing the bit they added with the Stygian patch that's tripping av's.

cj360 on 14 Mar 2020

Did a little digging through old forum posts, though it doesn't help solve the issue immediately it does explain why Denuvo is causing such a slowdown, especially in the wineserver. According to a hacking forum from around the start of the slowdowns, Capcom is running 24 threads at all times performing the CRC checks. Denuvo is aiming to maintain efficiency, but only when it's not turned into a constant memory scan by Capcom.

onesol on 14 Mar 2020

... right some news.

The bad: the game seems to be a bit unstable, it does crash sometimes after 5 sometimes after 20 mins - or longer. Not sure if related to the patch.

The good: I'm able to run it actually:
mhw_linux

In short, I've created a patch for _Proton 4.11_ which will execute the infamous register setting calls, but instead of going to _wineserver_ it stays in the current process. The performance is ok-ish currently, almost at same level as before.

In long, I'm now maintaining a state of all threads and their contexts local to the process, intercept all set and get calls and try to respond to requests without going to _wineserver_ as much as I can.
I also try to 'clean-up' dynamically resources, but that is not working properly (I have suspicion of a bug there) - and the current management of thread contexts can be optimized further (and I will do).

Attached the patch for ntdll, just apply to wine for _Proton 4.11_ branch and you can compile it.
I'm not attaching the _ntdll.dll.so_ because even the logging is a bit 'rough around the edges' hence it is what is is for now - if you can apply the patch and compile, it means you're aware in what poor status it is - and you can help out improving or pointing out my silly mistakes.

It's a start though.

I would love for someone to review the patch and provide feedback.
This patch is a 'calculated hack', I wouldn't expect to go nowhere in its shape or form.

@Guy1524 , would particularly appreciate your feedback.

Emanem on 15 Mar 2020

👍10

@Emanem Great Work! I'm pretty sure that wine already has a mechanism for caching the debug registers for this purpose. If I'm not mistaken, this is what your patch is doing. If it is, can you check if this patch works on top of 4.11?

Guy1524 on 15 Mar 2020

@Emanem Great Work! I'm pretty sure that wine already has a mechanism for caching the debug registers for this purpose. If I'm not mistaken, this is what your patch is doing. If it is, can you check if this patch works on top of 4.11?

@Guy1524 your patch doesn't work because it always assumes that the 'setting' and 'getting' of debug registers always happens for the same thread (_self_).
My understanding of the purpose of CAPCOM's work is that their _anti-cheat_ system has got new _control_ threads which set the debug registers for other threads, and then you have another class of _control_ threads which expect to retrieve the very same value.
This is why your patch (original) doesn't work anymore.

I don't think wine has this caching mechanism, I basically had to port a _rudimentary_ implementation of the server into the process client - relying on the fact that _all_ the threads are always within the same process at least.

Emanem on 15 Mar 2020

Update.

Attached a more _stable_ patch. I managed to go to _Guiding lands_ and get the _Stygian Zinogre_ quest done. Played cutscenes and whatnot.

The game now consistently crash when exiting the _Gathering Hub_ or entering the _Training Room_ - I've added some logging and using PROTON_LOG=1 would print out logs like _MH:W patch ..._.
What is interesting is that now I log all events and calls which may cause trouble, but everything seems to be fine patch wise.

I fear this is just poor development from CAPCOM and we may be stuck...

The patch is: mhw.4-11.v3.patch.txt.
As usual feedback is appreciated.

This time I have put a compiled ntdll.dll.so, the password is 'mhw'.
Again, if you use it, it's at your own risk.
I suggest to run it with PROTON_LOG=1 and see if the crash is the usual 'stack_overflow'...

Update

Ported my patch to _Proton 5.0_ and it crashes straight away.
MY main suspicion is that the same factor to trigger the crash in _Proton 5.0_ and the one with _Proton 4.11_ with my patch is the _same_.
I think the _anti cheat_ from CAPCOM does something dodgy. That's bad.

Emanem on 15 Mar 2020

👍8

Have you tried applying this patch to a 5.x branch? Maybe the gathering hub issue will be solved too then.

GoLD-ReaVeR on 15 Mar 2020

Have you tried applying this patch to a 5.x branch? Maybe the gathering hub issue will be solved too then.

As per update, when applying this patch to _Proton 5.0_ the game crashes straight away. As per above, my fear is that this is caused by _bad_ code within CAPCOM remit...

Emanem on 15 Mar 2020

No, I KNOW it's bad code within CRAPCUM's game. I mean all performance issues, mouse issues, crashes, etc. aren't happening for me in Code Vein, so there's definitely something wrong with THIS game specifically. But if proton 5.x fails and 4.x doesn't there's some kind of regression there too. Furthermore, could you try Tk-Glitch and GE patchsets? Their versions seem much more stable. (sorry, I should've asked that the first time)

GoLD-ReaVeR on 15 Mar 2020

The GE patchsets is mine I believe - I thin they used my original (i.e. already tried :-).
There is definitely a regression between Proton 4.11 and 5.0-4 (_regression_ according to the high coding standards from CAPCOM of course :-); if we find this regression I bet the below error won't happen and we'll be able to fully play on 4.11 or 5.0-4...

I've executed more tests, especially around the issue with stack-overflow.
Apparently we end up with stack overflow, but really, this is what is causing it (only the thread responsible for the crash):

1562.173:0030:0074:fixme:thread:get_thread_context  [MH:W patch] mhw_get_context(717960960, 0x2acaeb80) flags 00000010 self 1 (0x2acaea54)
1562.173:0030:0074:fixme:thread:get_thread_context  [MH:W patch] mhw_get_context(717960960, 0x2acaeb80) flags 00000010 self 1 (0x2acaea54)
1562.174:0030:0074:fixme:thread:get_thread_context  [MH:W patch] mhw_get_context(717960960, 0x2acaeb80) flags 00000010 self 1 (0x2acaea54)
1562.174:0030:0074:fixme:thread:get_thread_context  [MH:W patch] mhw_get_context(717960960, 0x2acaeb80) flags 00000010 self 1 (0x2acaea54)
1562.174:0030:0074:fixme:thread:get_thread_context  [MH:W patch] mhw_get_context(717960960, 0x2acaeb80) flags 00000010 self 1 (0x2acaea54)
1562.174:0030:0074:fixme:thread:get_thread_context  [MH:W patch] mhw_get_context(717960960, 0x2acaeb80) flags 00000010 self 1 (0x2acaea54)
1562.175:0030:0074:fixme:thread:get_thread_context  [MH:W patch] mhw_get_context(717960960, 0x2acaeb80) flags 00000010 self 1 (0x2acaea54)
1562.175:0030:0074:fixme:thread:set_thread_context  [MH:W patch] mhw_set_context(717960960, 0x2acaeb90) self 1 on handle 0xfffffffffffffffe (0x2acaea84)
1562.175:0030:0074:trace:seh:NtRaiseException code=c0000005 flags=0 addr=0x7bcb38c3 ip=7bcb38c3 tid=0074
1562.175:0030:0074:trace:seh:NtRaiseException  info[0]=0000000000000000
1562.175:0030:0074:trace:seh:NtRaiseException  info[1]=ffffffffffffffff
1562.175:0030:0074:trace:seh:NtRaiseException  rax=0000000000000000 rbx=0000000000000000 rcx=00000000194bc298 rdx=00000000194bb350
1562.175:0030:0074:trace:seh:NtRaiseException  rsi=0000000000000000 rdi=000000015cc6b3d3 rbp=3a70252074612073 rsp=000000002acaeb50
1562.175:0030:0074:trace:seh:NtRaiseException   r8=00000000194bc298  r9=00000000194bbce0 r10=000000000006a542 r11=0000000000000712
1562.175:0030:0074:trace:seh:NtRaiseException  r12=0000000000000000 r13=0000000000000000 r14=0000000021110560 r15=0000000000000000
1562.175:0030:0074:trace:seh:call_vectored_handlers calling handler at 0x69060aa0 code=c0000005 flags=0

Interesting bits:

One of the 'mhw control threads' keeps on calling _get_thread_context_ within a very short amount of time; the address you can see on the right hand side it's the stack.
As you can observe, this is just dodgy CAPCOM code which keeps looping and checking the same condition _over and over and over_ again.
Then the same thread calls _set_thread_context_, and boom, calls _NtRaiseException_ with an error apparently related to dereference an invalid memory location (error _c0000005_), then it spins on the same and goes into stack overflow

Patch used: mhw.4-11.v5.patch.txt

@Guy1524 @Plagman @kisak-valve I have only mad respect for what you do - dealing with this code is nerve-wracking sometimes.

edit

I've done 1 hour of investigations back to back, with different weapons and online. Very stable.
The issue is really w.r.t. accessing/exiting some locations, hopefully the folks at Valve/Wine have the instruments to pin-point the bad memory access and sort it out.

Emanem on 15 Mar 2020

👍5

@Emanem Ah I see, great job finding that out. If I'm not mistaken, the performance degradation of the method in regular wine right now is due to the target thread being suspended in order for the server to get the debug registers. Do the control threads need to run fast? If not, it may suffice to just cache the registers in wineserver and skip the ptrace stuff. What do you think?

If that doesn't work out, I think we'd be happy to incorporate some form of your current patch into Proton, @aeikum ?

Guy1524 on 15 Mar 2020

👍6

@Emanem Ah I see, great job finding that out. If I'm not mistaken, the performance degradation of the method in regular wine right now is due to the target thread being suspended in order for the server to get the debug registers. Do the control threads need to run fast? If not, it may suffice to just cache the registers in wineserver and skip the ptrace stuff. What do you think?

My understanding of the performance degradation is due to:

having to go and query off-processs (to wineserver) - this is slow no matter what (server runs an _epoll_ in single thread)
potentially a thread needs suspending (even slower)
as you can see by the verbose logging in the latest patch, this happens a lot and it's unpredictable

I would reccomend the following:

find the cause of the crash/regression (experience/gut feeling tells me it's similar for both 4.11 and 5.0-4)
polish my patch keeping the essentials (perhaps use other data structures instead of searching through linear arrays when managing the map of threads and context_t)

My patch contains some debug functions you may want to get rid of.
Please feel free to use it in whatever shape or form (would be good to get mentioned, that's all :).

Emanem on 15 Mar 2020

👍9

I'd like to say, I really appreciate all of your guys hard work

sebby4900982 on 15 Mar 2020

👍13

@Emanem I tried your patch over 5.4, unfortunately while it does apply, the game still doesn't launch

Edit - apologies, i scrolled up and realized this was already addressed

GloriousEggroll on 16 Mar 2020

@GloriousEggroll did you remove the old patch for mhw from 5.0-4 ? if not you could try adding the patch to proton 5.0-3 to see if it will launch

ThomasT75 on 16 Mar 2020

... and the plot thickens.

I've tried to trace the wrong memory access issue (following the guides from @aeikum here and there) with the flags

WINEDEBUG=+seh,+relay,+tid

And guess what? It doesn't happen. No crash.
No crash also with

WINEDEBUG=+relay,+tid

When we set such flags, do we also initialize memory to _zero_ or something along those line?
Do we do something esoteric too?

I remove the flags - the crash happens straight away (getting in and out of _Seliana's_ _Gathering Hub_).

@Guy1524 @aeikum @Plagman

edit

I tried the following:

Introduce a delay of 5 and then 2 _msec_ in the _set_thread_context_ function before the _return_ statement: the crash still happens
Initialize the allocated memory to 0x00 in the function 'RtlAllocateHeap' and the crash does happen as usual (i.e. during loading screen when changing locations) but much before (i.e. looks like we manage to load less resources)

The crash always happens at the same pointer/address:

NtRaiseException code=c0000005 flags=0 addr=0x7bcb38c3 ip=7bcb38c3

edit 2

Now I tried to cache only the _get_thread_context_ calls and I've observed the following:

the FPS takes a massive hit (expected)
seems like the CAPCOM engine does _set..._ calls proportionally to the objects on the screen
the game crashes at the same stage, same pointer, but even more delayed than usual, when loading resources. May be a sync issue in DXVK (not pointing fingers, just guessing given it's resource related)?

Emanem on 16 Mar 2020

👀3

Hmm, when this happens it's usually data synchronization issues. Logging tends to slow everything down a little which tends to make sure stuff happens in the order it's supposed to.

GoLD-ReaVeR on 16 Mar 2020

If that doesn't work out, I think we'd be happy to incorporate some form of your current patch into Proton, @aeikum ?

My first thought is that is a _lot_ of code. But it sounds like there's more work going on here, so I'll wait to review more thoroughly when you're closer to having this finished.

aeikum on 16 Mar 2020

I'm currently working on two versions of enamen's patch. One that does the caching in wineserver (and thus reduces the code footprint), and one that keeps the caching client-side, with more concise code.

Guy1524 on 16 Mar 2020

Some updates.

Usually the _'control thread'_ plays with setting and resetting the debug flags - my patch manages this just fine.

The crash does happen when the control thread resets both CONTEXT_DEBUG_REGISTERS and CONTEXT_CONTROL. in that case we would fall back to using the wine function _set_full_cpu_context_ which according to wine ASM would restore _all_ the registers, not just the ones set by the flags.

Maybe that's the cause of the crash?

Emanem on 16 Mar 2020

UPDATE - I think I figured it out

Proton 4.11

So, there's two main objectives of this patch:

Cache all the results of setting and getting CONTEXT_DEBUG_REGISTERS
Never reset the cpu context when the flag CONTEXT_DEBUG_REGISTERS is set

This mhw.4-11.v7.working.patch.txt is highly unpolished and full of suboptimal/debug code.
I'm just sharing for openness reasons.
I will be releasing a polished patch later on

Fresh form the oven, both a more decent mhw.4-11.v8.working.patch.txt and the ntdll.dll.so for Proton 4.11 - password is "_works!_" (please note the patch only kicks in when running MH:W, you should be safe to replace your current ntdll.dll.so - always make a backup copy).
This link has expired, further down below a newer link down below
Performance may be further optimized, happy hunting!

Proton 5.0-4

Haven't had time to look into this yet.

@GloriousEggroll

Ps. Safi Jiva quest end as proof :)
safi_jiva

Emanem on 16 Mar 2020

🎉7 👍7

I just wrote a version of your patch which instead caches in wineserver, as this considerably reduces the code size. Can you test if performance is comparable?
mhw_serverside.diff.txt

On my end, I see wineserver is eating around half of a core, so I'm inclined to believe we're not doing too bad on that front.

Guy1524 on 16 Mar 2020

I just wrote a version of your patch which instead caches in wineserver, as this considerably reduces the code size. Can you test if performance is comparable?
mhw_serverside.diff.txt

On my end, I see wineserver is eating around half of a core, so I'm inclined to believe we're not doing too bad on that front.

Just a couple of things:

going to _wineserver_ will _always_ be worse than local in process cache
You should also include the part of patch w.r.t. _signal_x86_64.c_ otherwise it will crash

I will try as soon as I have time - thought I understand caching at _winesever_ would be more elegant.
I suspect the patch of _signal_x86_64.c_ may perhaps fix Proton 5.0?

Emanem on 16 Mar 2020

going to wineserver will always be worse than local in process cache

IRT performance, I'm aware. However keeping a cache of handles locally is a messy and somewhat incorrect solution. If we can get similar performance when caching the registers in wine-server, we should.

the part of patch w.r.t. signal_x86_64.c

Which part? FWIW, I tested my patch on wine-git with windows steam, and the main menu did open. I do realize that I forgot to zero-init the cached context on creation, so here's an update with that:
dbg_ctx_cache.diff.txt

Guy1524 on 16 Mar 2020

If you can get this working over shared memory like proton has done with esync, I think the wineserver performance hit can be avoided quite easily. There were other games where esync was mandatory for the game to function in online mode (e.g. Guilty Gear Xrd series) and it was due to the wineserver overload. The socket implementation on the wineserver by itself is a really slow implementation, nevermind the stuff that would have to come after.

GoLD-ReaVeR on 16 Mar 2020

How would we do handle lookups over shared memory? Do you want us to expose the handle table to userspace?

Guy1524 on 16 Mar 2020

I'm not sure about the details, I would just try to follow the spirit of the esync implementation. It did the job quite handsomely for the games that were affected.

I can't stress enough that while wineserver may be a comfortable implementation, it is the worst offender when it comes to performance issues. And it only stands to become worse as applications start to fire more and more threads to fully utilize the CPU (in windows, their target OS).

GoLD-ReaVeR on 16 Mar 2020

@GoLD-ReaVeR Agreed - wineserver is going to be a bottleneck (well actually already is).

@Guy1524 I have also patched _signal_x86_64.c_ to avoid further crashes, there is a problem with the ASM function _set_full_cpu_context_. Try to go into the _Training Room_ and see it it crashes or not with your patch.

I do agree that a wineserver implementation is elegant and my patch is quite messy and doesn't follow exact protocol.
But as pointed out by before, in order to remove the slow _wineserver_ implementation you may want to use shared memory and synchronization to get it right. Indeed not a trivial task.

Emanem on 16 Mar 2020

@Emanem I don't play this game, and I couldn't find the training room, but I started a new game and stuff seemed to work just fine. I don't think I need your additional hack since i only activate my hack when debug registers are the only thing being set or get.

Guy1524 on 16 Mar 2020

I just wanted to say I appreciate the work I would love to help but my coding knowledge is limited (mainly a few small mods here and there) and I tried following but I'm lost I'm not even sure where those files go. XD

Jean3000 on 16 Mar 2020

I just wanted to say I appreciate the work I would love to help but my coding knowledge is limited (mainly a few small mods here and there) and I tried following but I'm lost I'm not even sure where those files go. XD

If you want to use the patch for _Proton 4.11_, just copy the _ntdll.dll.so_ into the directory
/home/<your username here>/.steam/SteamApps/common/Proton 4.11/dist/lib64/wine
or wherever you installed _Proton 4.11_. I reccomend you take a backup of the same file in the directory before you copy and overwrite it.

Emanem on 17 Mar 2020

👍6

Thank you for the quick response I was putting it in /home//.steam/SteamApps/common/Proton 4.11/dist/lib64 like an idiot

Jean3000 on 17 Mar 2020

I tried to port my patch to _Proton 5.0_ but I get another crash.
This seems to be unrelated

5411.443:0034:0035:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\vulkan-1.dll" at 0x64d40000: PE builtin
5411.444:0034:0035:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\winevulkan.dll" at 0x7f59c5330000: builtin
5411.445:0034:0035:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\d3d11.dll" at 0x6a340000: native
5411.448:0034:0035:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\msacm32.dll" at 0x66440000: PE builtin
5411.448:0034:0035:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\WINMM.dll" at 0x637c0000: PE builtin
5411.450:0034:0035:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\propsys.dll" at 0x69c80000: PE builtin
5411.450:0034:0035:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\rtworkq.dll" at 0x65680000: PE builtin
5411.450:0034:0035:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\MFPlat.DLL" at 0x71200000: PE builtin
5411.451:0034:0035:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\MFReadWrite.dll" at 0x6cd80000: PE builtin
5411.453:0034:0035:trace:loaddll:load_so_dll Loaded L"Z:\\disk5\\SteamLibrary\\steamapps\\common\\Monster Hunter World\\amd_ags_x64.dll" at 0x7f59c50c0000: builtin
5411.453:0034:0035:trace:loaddll:free_modref Unloaded module L"Z:\\disk5\\SteamLibrary\\steamapps\\common\\Monster Hunter World\\amd_ags_x64.dll" : builtin
5411.453:0034:0035:trace:loaddll:load_native_dll Loaded L"Z:\\disk5\\SteamLibrary\\steamapps\\common\\Monster Hunter World\\amd_ags_x64.dll" at 0x180000000: native
5411.525:0034:0035:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION
5411.526:0034:0035:trace:seh:raise_exception code=406d1388 flags=0 addr=0x7b00fc3e ip=7b00fc3e tid=0035
5411.526:0034:0035:trace:seh:raise_exception  info[0]=0000000100001000
5411.526:0034:0035:trace:seh:raise_exception  info[1]=0000000144fd924d
5411.526:0034:0035:trace:seh:raise_exception  info[2]=0000000000000037
5411.526:0034:0035:trace:seh:raise_exception  rax=000000000022f9d0 rbx=0000000144fd9200 rcx=000000000022f9b0 rdx=0000000000000000
5411.526:0034:0035:trace:seh:raise_exception  rsi=000000000022faa8 rdi=000000000022f9e8 rbp=0000000000000000 rsp=000000000022f990
5411.526:0034:0035:trace:seh:raise_exception   r8=0000000000000003  r9=000000000022fa90 r10=000000007b42c9a0 r11=0000000000000246
5411.526:0034:0035:trace:seh:raise_exception  r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000
5411.526:0034:0035:trace:seh:call_vectored_handlers calling handler at 0x6a435690 code=406d1388 flags=0
5411.526:0034:0035:trace:seh:call_vectored_handlers handler at 0x6a435690 returned ffffffff
5411.526:0034:0035:trace:seh:raise_exception code=406d1388 flags=0 addr=0x7b00fc3e ip=7b00fc3e tid=0035
5411.526:0034:0035:trace:seh:raise_exception  info[0]=0000000100001000
5411.526:0034:0035:trace:seh:raise_exception  info[1]=0000000144fd92ed
5411.526:0034:0035:trace:seh:raise_exception  info[2]=0000000000000038
5411.526:0034:0035:trace:seh:raise_exception  rax=000000000022f9d0 rbx=0000000144fd92a0 rcx=000000000022f9b0 rdx=0000000000000000
5411.526:0034:0035:trace:seh:raise_exception  rsi=000000000022faa8 rdi=000000000022f9e8 rbp=0000000000000000 rsp=000000000022f990
5411.526:0034:0035:trace:seh:raise_exception   r8=0000000000000003  r9=000000000022fa90 r10=000000007b42c9a0 r11=0000000000000246
5411.526:0034:0035:trace:seh:raise_exception  r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000
5411.526:0034:0035:trace:seh:call_vectored_handlers calling handler at 0x6a435690 code=406d1388 flags=0
5411.526:0034:0035:trace:seh:call_vectored_handlers handler at 0x6a435690 returned ffffffff
5411.526:0034:0037:warn:seh:set_cpu_context  [MH:W patch] skipping restoring full context
5411.526:0034:0037:warn:seh:set_cpu_context  [MH:W patch] skipping restoring full context
5411.526:0034:0038:warn:seh:set_cpu_context  [MH:W patch] skipping restoring full context
5411.526:0034:0038:warn:seh:set_cpu_context  [MH:W patch] skipping restoring full context
5411.679:0034:0035:trace:seh:raise_exception code=c0000005 flags=0 addr=0x14ed8bda3 ip=14ed8bda3 tid=0035
5411.679:0034:0035:trace:seh:raise_exception  info[0]=0000000000000000
5411.679:0034:0035:trace:seh:raise_exception  info[1]=0000000010905a4d
5411.679:0034:0035:trace:seh:raise_exception  rax=0000000000000000 rbx=000000000000001e rcx=0000000010905a4d rdx=ffff80a6346087f0
5411.679:0034:0035:trace:seh:raise_exception  rsi=0000000010000000 rdi=000000007b410000 rbp=000000000021c100 rsp=000000000021c000
5411.679:0034:0035:trace:seh:raise_exception   r8=000000000000001e  r9=0000000000000003 r10=0000000000010000 r11=000000000021c1d0
5411.679:0034:0035:trace:seh:raise_exception  r12=0000000000000040 r13=0000000010000000 r14=0000000000000000 r15=0000000010000000
5411.679:0034:0035:trace:seh:call_vectored_handlers calling handler at 0x6a435690 code=c0000005 flags=0
5411.679:0034:0035:trace:seh:call_vectored_handlers handler at 0x6a435690 returned 0
5411.679:0034:0035:trace:seh:RtlVirtualUnwind type 1 rip 14ed8bda3 rsp 21c000
5411.679:0034:0035:trace:seh:dump_unwind_info **** func ed8bc81-ed8c42a
5411.679:0034:0035:trace:seh:dump_unwind_info unwind info at 0x143b2dd88 flags 4 prolog 0x0 bytes function 0x14ed8bc81-0x14ed8c42a

Looks like an issue w.r.t. management of exception 406d1388 - used to set thread names, now it appears to trigger another invalid memory access exception (c0000005) - note in the above log the offending thread is _0035_.

Apologies if I don't dig further into this, but it's fully working with _Proton 4.11_, I would leave to the professionals.
Please note if you change wine version and core libraries too much _Denuvo_ will ban you for 24 hours - and I wouldn't want to be!

@Guy1524 have you compared the FPS (run with DXVK_HUD=version,fps,devinfo %command%) between patches (your _wineserver_ and my _less conventional_)?
Even just moving the character in the starting areas would do - those are full with details.

@GloriousEggroll You can integrate my mhw.4-11.v9.working.patch.txt in your 4.11 build if you wish so, it has decent performance. I've also noticed 57 70 folks have downloaded the binaries.

All, please feel free to provide feedback to any of us on this thread!

Emanem on 17 Mar 2020

👍1

As a small piece of happy feedback, I can confirm that the patch when added to /home/<your username here>/.steam/SteamApps/common/Proton 4.11/dist/lib64/wine is making the game run again! I am on vanilla MHW (I don't have Iceborne) and I'm barely into the game (HR 5), so I can only give the patch a thumbs up for this beginning vanilla portion and running around Astera and doing a hunt. However, this is FAR more than I've been able to do since the latest update, so a BIG THANK YOU to everyone working on this! I'll let you know I run into major and persistent performance problems.

ghost on 17 Mar 2020

Tested the v8 ntdll.dll.so with the game and it seems to work perfectly, performance is nearly identical to previous versions of the game

EDIT: I'm currently doing end-game quests and no crashes

BlazeKl on 17 Mar 2020

I tested the v8 patch too, and ran into some minor (black flashing patches on certain objects, hardly noticable) and some heavy graphical glitches related to the dynamic snow (flashing white and black pillars). I first suspected ACO, but these glitches persisted with LLVM, too. Strangely the pillars do not appear when entering Seliana from the main menu as it seems to not load the dynamic snow at all, but after the first quest/expedition they appear.
https://imgur.com/a/ruUenMj

TheHooly on 17 Mar 2020

@Emanem
The link to your download is giving me a message saying that it has expired ~~and asking for a password.~~

Edit: I know see that I suck at reading comprehension for the password bit but now it just says outright expired

Equivocal90 on 18 Mar 2020

@Emanem I just want to give more feedback, confirming that your patch has made MHW work again. I am wondering though if anyone's had any luck with controller functionality? My PS4 controller works fin in other Proton supported games, but MHW does not seem to recognize any input except for the tracking pad. I don't know if this has been a issue before, since I ironically only decided to install MHW on linux the very day of the update that borked it.

Ampsersanddd on 18 Mar 2020

Hey @Emanem , you rock. The mhw.4-11.v8 patch works perfectly. I just want to say thank you very much.

tranlethaison on 18 Mar 2020

@Emanem Seems to work fine on my end as well.
@Ampsersanddd My steam controller seems to work just fine.

TexZeTech on 18 Mar 2020

patch appears to work just fine - no noticeable performance loss, no encountered crashes. great work!

ka1tlyn on 18 Mar 2020

@Emanem

replace your current _ntdll.dll.so

can you share it again? Firefox send say`s link end of life

IDeathByte on 18 Mar 2020

@Emanem Just to add my experience here. With your v8 patch the game runs perfectly well! I even get higher FPS, consistently around 5-10 more with my Vega 64, especially in resource expensive areas like Seliana. My Nintendo Switch Pro controller also works fine. Didn't get a single crash or glitch.

So big thanks to everyone who contributed to this, it keeps getting better in spite of Capcom's attempts to kill the game!

Jojonintendo on 18 Mar 2020

New link; the password is "_works!_".

Second link: ntdll.dll.so.tar.gz <Note: Added directly to Github by moderator>

This time I xz'd it - you have to extract it; as usual, put it in /home/<your username here>/.steam/SteamApps/common/Proton 4.11/dist/lib64/wine or equivalent location. Do _always_ take backups! I do too (I don't trust my clumsiness :).

Happy hunting!

Emanem on 18 Mar 2020

🚀1 😄1

@Emanem question how do you go about building the patch from your text files. Please point me in a direction to look up more information on this if you don't want to just tell me :smile:

TexZeTech on 18 Mar 2020

@Emanem question how do you go about building the patch from your text files. Please point me in a direction to look up more information on this if you don't want to just tell me smile

Look, if I was you I'd do the same, hence my answer.
It's _relatively_ simple:

clone the correct wine version from _Valve_'s github
Switch over to the correct branch
Apply the patch to your current sourcecode (git apply <patch filename> from the _wine_ directory)
Build wine - you will need to ensure you have all the dependency packages installed and then initialize a build directory - this point alone may take time
You should get a _ntdll.dll.so_ file in your <build dir>/dlls/ntdll path - you may want to strip it to reduce the size (strip ntdll.dll.so)

Job done. To be quite frank I don't want to _pollute_ my main Ubuntu install with dev packages, hence I usually run all the above in a dedicated VM.

@kisak-valve @Plagman @Guy1524
I've been messing around with _Proton 5.0_ and I get the feeling we have a _regression_ there in the way we manage some exceptions (i.e. the one used to change the thread name) compared to _Proton 4.11_.
Unfortunately I don't have much time to mess with it, but let us know how we can help.

Have you tried the performance between your patch and mine? Again, I'm curious to see how much going to _wineserver_ would hit us in performance terms.
I do agree my patch is not elegant - but at the same time I think an elegant and efficient way to _really_ solve _wineserver_ performance issues is to overhaul the IPC mechanisms and use shared memory and named mutexes or semaphores.

What is your view , SMEs?

Emanem on 18 Mar 2020

@Emanem facepalm should have thought about looking under git. I'm still what I would consider a new user so I thank you for the quick and simple answer.

TexZeTech on 18 Mar 2020

Just some more feedback. Firstly thanks for the hard work to all for managing to get this working again!

@Emanem Patch is working great and I'm getting the same performance as I was before the March 11th patch. Only minor kink I'm having is that quitting the game through the in-game menu closes the window but I'm left with a process called "Monster" that keeps running in the background with steam not recognising that the game has ended. Force quitting the process works fine, so as I said, only a minor issue.
@Ampsersanddd I use a PS4 controller and it works fine. I found this comment useful for setting up the controller initially https://github.com/ValveSoftware/Proton/issues/1549#issuecomment-447654643 . With this patch I have had issues with the game not recognising the controller but unplugging and plugging it in again seems to fix the issue, alternatively starting the game from stream's big picture mode seems to work fine as well.

motorlatitude on 18 Mar 2020

@Emanem
I have very low performance with this fix(
Around 5-10fps in main menu
Maybe i make wrong prefix?
My steps - I change ntdll.dll.so in vanila proton 4.11, recreate game prefix and add mfplat for video (as in old instructions for valve proton). without mfplat situation not changed.
ryzen 1600 /RX560 4gb/ mesa 20.0.1 ACO enabled.
With disabled ACO same situation, but 60-70% extra CPU usage

screen mode - borderless

IDeathByte on 18 Mar 2020

@motorlatitude Thanks for that, forcing the steam input to off fixed the issue entirely.

Ampsersanddd on 18 Mar 2020

@Emanem
I have very low performance with this fix(
Around 5-10fps in main menu
Maybe i make wrong prefix?
My steps - I change ntdll.dll.so in vanila proton 4.11, recreate game prefix and add mfplat for video (as in old instructions for valve proton). without mfplat situation not changed.
ryzen 1600 /RX560 4gb/ mesa 20.0.1 ACO enabled.
With disabled ACO same situation, but 60-70% extra CPU usage

screen mode - borderless

Are you sure you overwrote the right dll?
Most likely it's the setup at your end having issues.
Also _mfplat_ is only relevant when you see movies, which is at the end of the main game and if you look at weapons tutorials.

Emanem on 18 Mar 2020

@Emanem
Are you sure you overwrote the right dll?

I think if i overwrite another dll, game just didn`t start =)
~/Proton 4.11/dist/lib64/wine/ntdll.dll.so

IDeathByte on 18 Mar 2020

I think if i overwrite another dll, game just didn`t start =)
~/Proton 4.11/dist/lib64/wine/ntdll.dll.so

Most likely you're not using the right setup - i.e. as you're mentioning perhaps the prefix is not properly setup.

Emanem on 18 Mar 2020

Now i relaunch steam and recreate prefix again...
Now performance good, but sligtly badly than on 5.2-ge before patch from 11 march.

Thank for fix =)

IDeathByte on 18 Mar 2020

I just wanted to say that I used to play on Windows 8.1 before I switched to linux and with this patch it is running smoother then before on my computer... except for when I'm online but that is my internet being slow
though it does seem not close without restarting my computer not a problem for me to just restart but thought I might mention it

Jean3000 on 18 Mar 2020

Even before ice bourne mhw didn't reliably close correctly I've also had to force close it as it'll leave a hanging process otherwise. Next time I get it running on my linux setup I'll try and share a log if it does show anything helpful.

cj360 on 18 Mar 2020

@Emanem Really appreciate your work. I have performance comparable with that on windows, except
minor kinks. I do not have hanging process after quitting the game, though I had this sometime before. Hope wine/proton team can find a way to integrate your patch.

ljn917 on 19 Mar 2020

@Emanem can confirm the patch is working well for me.
Thanks!

StylinGreymon on 19 Mar 2020

@Emanem First off, thanks for the patch. It works great, but I found a weird interaction with Firefox. If I run Firefox alongside mhw, it turns extremely sluggish, and if I open a YouTube-video, mhw will crash after a random amount of time (5 tests, all between roughly 5 and 120 seconds, Sound continues playing but the window will not be redrawn). I don't believe it is a resource problem, as my ram is at 7G/32G (htop), cpu is at roughly at 60% per core (also htop) and my vram is at 3G/4G (nvidia-smi). Also noteworthy is that at the moment of the crash the name as shown by nvidia-smi changes from ...ter Hunter World\MonsterHunterWorld.exe to -. The same behavior does not happen if I use chromium instead of firefox. It also does not crash if I use an unpatched Proton 4.11 for mhw (I ran in circles in Seliana, speaking to different npcs for roughly 5 mins).

Distro: Arch
Kernel: 5.5.9-arch1-2
GPU: NVIDIA GeForce GTX 980
Driver: nvidia-beta 440.64-1
CPU: i7-6700K
RAM: 32GB
Firefox version: 74.0-2

Orcthanc on 19 Mar 2020

New link; the password is "_works!_".

Second link: ntdll.dll.so.tar.gz <Note: Added directly to Github by moderator>

This time I xz'd it - you have to extract it; as usual, put it in /home/<your username here>/.steam/SteamApps/common/Proton 4.11/dist/lib64/wine or equivalent location. Do _always_ take backups! I do too (I don't trust my clumsiness :).

Happy hunting!

Great the patch worked alright. Occasional stutter here and there with the framer ate at 60fps. Was a bit nervous about editing a proton file at first.... Thanks a bunch.

Mera1506 on 20 Mar 2020

New link; the password is "_works!_".
Second link: ntdll.dll.so.tar.gz <Note: Added directly to Github by moderator>
This time I xz'd it - you have to extract it; as usual, put it in /home/<your username here>/.steam/SteamApps/common/Proton 4.11/dist/lib64/wine or equivalent location. Do _always_ take backups! I do too (I don't trust my clumsiness :).
Happy hunting!

Great the patch worked alright. Occasional stutter here and there with the framer ate at 60fps. Was a bit nervous about editing a proton file at first.... Thanks a bunch.

For stutters please ensure you're running your CPU governor in _performance_ mode.
(i.e. on Intel echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor)

Emanem on 20 Mar 2020

@Emanem Thanks! It works again and it seems that I can run it with XMP profile on without CTD (which was the case before with {5.1,5.2}-ge, I spent some time to find out that it was the core of the issue, but meanwhile there was a mobo bios update that said “Improve memory support”, so I can't say for sure what helped here), which catch back from the FPS loss that I had.

Unfortunately, like @TheHooly I have the snow glitch issue: https://tmp.epheme.re/mhw_ice.jpg

I'm running it with 16GB of RAM, AMD ryzen 7 3700x, Radeon RX 5700 xt on an x570 motherboard.

If you need more logs or so, I can provide it.

Chouhartem on 20 Mar 2020

still having the occasional CTD and connection issues, but these have always been present for me in some capacity.

saw some new errors in my steam log, maybe they'll be of use.
steam-582010.log

StylinGreymon on 20 Mar 2020

@Emanem Thanks! It works again and it seems that I can run it with XMP profile on without CTD (which was the case before with {5.1,5.2}-ge, I spent some time to find out that it was the core of the issue, but meanwhile there was a mobo bios update that said “Improve memory support”, so I can't say for sure what helped here), which catch back from the FPS loss that I had.

Unfortunately, like @TheHooly I have the snow glitch issue: https://tmp.epheme.re/mhw_ice.jpg

I'm running it with 16GB of RAM, AMD ryzen 7 3700x, Radeon RX 5700 xt on an x570 motherboard.

If you need more logs or so, I can provide it.

Wow, your hardware is almost exactly the same as mine. Except for the CPU, Ryzen 7 3800X.
I can report that the glitch does happen sporadically, sometimes the glitch is not present in Seliana. Most of the time, unfortunately, it is present.
It is caused exclusively by dynamic snow on the ground, the kind that changes when someone walks through it. The tundra biome in the guiding lands is not affected (there is no dynamic snow).
Major parts of the hoarfrost reach are basically unplayable.
Interestingly in area 3, where Beotodus goes to sleep, the very deep snow does NOT cause this glitch, even if the remaining snow does.

This may be related more to the Vulkan-drivers than this patch, as this exact glitch is present in BF4, too. It only appeared a couple of weeks ago, and seems to be sporadic, too.

TheHooly on 21 Mar 2020

I think there is a pattern here 😉

Yes, I can confirm that it's sporadic. I add that from a software point of view, I'm running on archlinux with linux-mainline (5.6.0-rc6-1-mainline) with mesa 19.3.4.

Chouhartem on 21 Mar 2020

With Proton 4.11-13 (with or without the "patched" ntdll.dll.so file), the game launches, but the menu and everything beyond runs at ~5 FPS.
Weirdly enough, htop reports low CPU usage, low I/O usage, and low memory usage.
nvidia-smi also reports that GPU usage is sitting at around 10% at most.

Distro: Arch
Kernel: 5.5.10.arch1-1
GPU: GTX 970
Driver: nvidia 440.64-5
CPU: Ryzen 5 1600
RAM: 16GB

HubbeKing on 21 Mar 2020

That's because one of your cores is running wineserver at 100% stalling everything else as everything else is waiting for wineserver responses.

GoLD-ReaVeR on 21 Mar 2020

I have the same problem as @HubbeKing, what would be the workaround to allow the computation to be distributed between the cores?

I have tried the already generated DLL with Egroll Build and the 4.11 (default). With the Egroll Build the game fails immediately (after 5 seconds steam allows to click "Play" again) and with 4.11 the game is very slow (and seems to have like 5 FPS). I will try to compile the DLL myself using the patch.

henriquebecker91 on 21 Mar 2020

👍1

@henriquebecker91
Check out the post from "BoostCookie" on protondb. I have just about the same hardware as you and @HubbeKing and I got it to work without dropping to 5frames

lundjrl on 21 Mar 2020

I just learnt my original link to the _ntdll.dll.so_ has expired twice, I won't post again, there's the _github_ link.

Thanks everyone for sharing the feedback. _MH:W_ on Linux has many players (well at least 200), I hope I'll meet some of you online.

@kisak-valve @Guy1524 @aeikum @Plagman do you guys have a strategy to tackle the issue with _Proton 5.xxx_ and also how to patch in mainline?
I'm curious and let us know if you need any help!

Emanem on 22 Mar 2020

👍1

Okay, my graphical glitches were NOT caused by this patch. but my own incompetence. I had both the "AMDGPU" AND "AMDVLK" drivers installed, which would also explain why these glitches happened so sporadically.

I manually removed the packages "amdvlk" and "lib32-amdvlk", since then i had no graphical glitches anymore.
https://imgur.com/dDpMV3x

@Chouhartem please check which AMD and Vulkan drivers you have installed and try the solution above.

TheHooly on 22 Mar 2020

Thanks @TheHooly 😁

I relaunched the game twice after uninstalling amdvlk and its 32 bits friend, and it seems to have solved the issue so far : https://tmp.epheme.re/mhw_ice2.jpg

Now it just left me with the “have to manually kill the game” issue, which does not affect the game so it's ok so far…

Chouhartem on 22 Mar 2020

I just learnt my original link to the _ntdll.dll.so_ has expired twice, I won't post again, there's the _github_ link.

Thanks everyone for sharing the feedback. _MH:W_ on Linux has many players (well at least 200), I hope I'll meet some of you online.

@kisak-valve @Guy1524 @aeikum @Plagman do you guys have a strategy to tackle the issue with _Proton 5.xxx_ and also how to patch in mainline?
I'm curious and let us know if you need any help!

Well My name tag is BLASTER on steam, feel free to add me.

blastermaster77 on 24 Mar 2020

Hey @Emanem, can we get a new link to the patch? The Firefox link expired :(

ooloros on 26 Mar 2020

It seems the game now works on 5.0-5 with the last game update

BlazeKl on 27 Mar 2020

🎉1

I confirm it works on 5.0-5 now. It looks like crapcom removed the anti-debugging mechanism to pass some antivirus software.

ljn917 on 27 Mar 2020

Latest update is running as it was before the stygian zinogre release. Maybe even before the iceborne release but I haven't tested that.

GoLD-ReaVeR on 27 Mar 2020

Seems to be working just fine - I agree with @GoLD-ReaVeR @ljn917, looks like CAPCOM have removed their _anti-cheat_ debug registers setting code...

Emanem on 27 Mar 2020

I can confirm it works now with 5.0-5 on my build too.

On Fri, Mar 27, 2020, 9:28 AM Emanem notifications@github.com wrote:

Seems to be working just fine - I agree with @GoLD-ReaVeR
https://github.com/GoLD-ReaVeR , looks like CAPCOM have removed their
anti-cheat debug registers setting code...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/175#issuecomment-605000900,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACHAHPUDMCGQB2A2ETBSUJLRJSSZVANCNFSM4FRB5W2A
.

blastermaster77 on 27 Mar 2020

The previous patch that fixed the performance is still needed, thankfully 5.0-5 still has the patch applied

BlazeKl on 27 Mar 2020

The previous patch that fixed the performance is still needed, thankfully 5.0-5 still has the patch applied

So now they have stopped checking the debug registers flag, but still setting it and given we're short-circuiting such operation in 5.0-5 we're fine?

Emanem on 27 Mar 2020

New install of Ubuntu and Steam (beta client). Game doesn't start for me with 5.0-5.

Distro: Ubuntu 18.04
Kernel: 5.3.0-45
GPU: RTX 2080 SUPER
Driver: 440.64
CPU: Ryzen 9 3900X
RAM: DDR4 3200MHz 64GB

Log snippet

3478.469:0034:0035:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\ole32.dll" at 0x65000000: PE builtin
3478.472:0034:0035:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\shlwapi.dll" at 0x68a40000: PE builtin
3478.472:0034:0035:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\shcore.dll" at 0x64940000: PE builtin
3478.472:0034:0035:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\shell32.dll" at 0x7ff02b6e0000: builtin
3478.473:0034:0035:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\mpr.dll" at 0x6d9c0000: PE builtin
3478.474:0034:0035:trace:loaddll:load_so_dll Loaded L"C:\\windows\\system32\\ws2_32.dll" at 0x7ff02b690000: builtin
3478.474:0034:0035:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\wininet.dll" at 0x6b2c0000: PE builtin
3478.529:0034:0035:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\imm32.dll" at 0x6bec0000: PE builtin
3478.747:0034:0035:trace:seh:raise_exception code=c0000005 flags=0 addr=0x160a59fd6 ip=160a59fd6 tid=0035
3478.747:0034:0035:trace:seh:raise_exception  info[0]=0000000000000000
3478.747:0034:0035:trace:seh:raise_exception  info[1]=ffffffffffffffff
3478.747:0034:0035:trace:seh:raise_exception  rax=000000000000000d rbx=0000000160a59fd0 rcx=000000007ed8320b rdx=00000000461fe8de
3478.747:0034:0035:trace:seh:raise_exception  rsi=0000000000000000 rdi=000000000c7630fb rbp=000000000022ffd0 rsp=000000000022f8a8
3478.747:0034:0035:trace:seh:raise_exception   r8=000000007fffffff  r9=b7cb1454c7a8f154 r10=0000000000000000 r11=0000000160a5a001
3478.747:0034:0035:trace:seh:raise_exception  r12=0000000140000000 r13=000000000022f900 r14=0000000000000003 r15=0000000000000000
3478.747:0034:0035:warn:seh:virtual_unwind exception data not found in L"MonsterHunterWorld.exe"
3478.747:0034:0035:trace:seh:RtlVirtualUnwind type 1 rip 15205c9b7 rsp 22f8c0
3478.747:0034:0035:trace:seh:dump_unwind_info **** func 9783eba-1d68ba49
3478.747:0034:0035:trace:seh:dump_unwind_info unwind info at 0x143c55000 flags 4 prolog 0x0 bytes function 0x149783eba-0x15d68ba49
3478.747:0034:0035:trace:seh:dump_unwind_info     0x0: movaps %xmm7,0x70(%rsp)
3478.747:0034:0035:trace:seh:dump_unwind_info     0x0: movaps %xmm6,0x80(%rsp)
3478.747:0034:0035:trace:seh:dump_unwind_info     0x0: movq %r13,0x90(%rsp)
3478.747:0034:0035:trace:seh:dump_unwind_info     0x0: movq %r12,0xd0(%rsp)
3478.747:0034:0035:trace:seh:dump_unwind_info     0x0: movq %rdi,0xc8(%rsp)
3478.747:0034:0035:trace:seh:dump_unwind_info     0x0: movq %rbx,0xc0(%rsp)
3478.747:0034:0035:trace:seh:dump_unwind_info     chained to function 0x15d676fb0-0x15d67cc98

Update: disabling the umip instruction with clearcpuid=514 fixed it for me. Appears to be an instance of issue 2927.

jasonphi on 2 Apr 2020

Distro: Manjaro
Kernel: 5.5.13-arch2-1-fsync
GPU: AMD RX 480
Driver: Mesa 20.1.0-devel (git-548fab0d5b) + ACO
CPU: Ryzen 7 1700
RAM: 16GB

Proton: 5.0.5

The game stopped working today (it worked like a charm two days ago), it crashed at launch. I don't think there's been any update to MH since.

steam-582010.log

steam.log

Update: Mesa just got downgraded to 20.1.0-devel (git-ffc7574ff7) but the problem still persists.

przmkg on 5 Apr 2020

I can confirm it's currently broken on mesa-git. Simply rolling back didn't fix it for me, I also had to get rid of my mesa shader cache for the game to run again. I haven't yet been able to pinpoint the commit(s) responsible for the breakage.

Tk-Glitch on 5 Apr 2020

The patch for DOOM: Eternal support broke the Wolfenstein 2 compatibility. Maybe this one too?

https://gitlab.freedesktop.org/mesa/mesa/-/issues/2734

alosarjos on 5 Apr 2020

No, the patch was reverted since. It's something else.

Tk-Glitch on 5 Apr 2020

@Tk-Glitch Could you tell me where the shaders are so I can try as well? Thanks

przmkg on 5 Apr 2020

@przmkg If you have the steam shader cache sharing option turned off, it'll be ~/.cache/mesa_shader_cache by default, and if you you have the option turned on (default, I think), it'll be in your steam library path for the game (varying path depending if the game was installed in a different drive - default being ~/.steam/root on Manjaro) in /steamapps/shadercache/582010.

Edit: Also, it seems critical to get rid of DXVK's state cache, that will end up next to the game's executable with steam shader cache turned off.

Edit2: The culprit is https://gitlab.freedesktop.org/mesa/mesa/-/commit/507956ed04fcdcfd44419d1b16f032e1d81d0dcb . It doesn't revert cleanly so I have made a patch to do so: mhw-revert.mymesapatch.txt. With cold caches and the revert patch applied, the game works again.

Edit3: The issue is now fixed with the following pending merge request: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4465 so probably fixed upstream pretty soon.

Edit4: Now fixed upstream with https://gitlab.freedesktop.org/mesa/mesa/-/commit/cc8a85d05a9cf47e89c6a8c5e6db98caba79e00d

Tk-Glitch on 5 Apr 2020

👍3

Anyone encounters a green swirl just swirling forever whenever attempting to play tutorial videos?

Cxpher on 11 Apr 2020

Noob question but is it possible to run the smarthunter mod on Steam with Proton ? Or is there an equivalent program for Linux ?

cvignal on 11 Apr 2020

Noob question but is it possible to run the smarthunter mod on Steam with Proton ? Or is there an equivalent program for Linux ?

Many of these _add-ons_ rely on intercepting the process memory, scanning it and finding _canary patterns_ and then looking up data structures to monitor/edit.

Unfortunately those don't quite work when running in _wine_, simply because the memory layout changes (_wine_ allocations in _Linux_ are different than _Windows_), and unless someone from the hacking community posts the sources of the current lookups in _Windows_, it's going to be almost impossible to try porting it to _wine_.

I did try last year when i got ahold of the sources of the basic DPS monitor, and was only able to lookup parts of the _canary patterns_ unfortunately.

Please note _CAPCOM_ is dead against those, especially the so called _damage meters_ that the _pro_ community uses to improve.

Emanem on 12 Apr 2020

Distro:KDE neon User Edition 5.18
Kernel:5.3.0-46-generic
RAM:16 GB
GPU:NVIDIA 440.82
GPU:NVIDIA GeForce GTX 1660 SUPER
CPU:AMD Ryzen 7 3700X 8-Core
PROTON: 5.0-6

I had already read that in Ubuntu/Debian-based distros with KDE there was no way it would work. In fact, it won't even boot.

I leave here the pronton log in case it is helpful since I have seen little information about this game in KDE environments and maybe someone who knows will find it useful

steam-582010.log

alohl669 on 19 Apr 2020

Everything working fine here. Kubuntu.


                          ./+o+-       
                  yyyyy- -yyyyyy+      OS: Ubuntu 19.10 eoan
               ://+//////-yyyyyyo      Kernel: x86_64 Linux 5.3.0-46-generic
           .++ .:/++++++/-.+sss/`      Uptime: 12h 11m
         .:++o:  /++++++++/:--:/-      Packages: 2861
        o:+o+:++.`..```.-/oo+++++/     Shell: bash 5.0.3
       .:+o:+o/.          `+sssoo+/    Resolution: 3839x1080
  .++/+:+oo+o:`             /sssooo.   DE: KDE 5.62.0 / Plasma 5.16.5
 /+++//+:`oo+o               /::--:.   WM: KWin
 \+/+o+++`o++o               ++////.   GTK Theme: Breeze-Dark [GTK2/3]
  .++.o+++oo+:`             /dddhhh.   Icon Theme: breeze
       .+.o+oo:.          `oddhhhh+    Font: Noto Sans Regular
        \+.++o+o``-````.:ohdhhhhh+     CPU: Intel Core i5-8300H @ 8x 2.3GHz
         `:o+++ `ohhhhhhhhyo++os:      GPU: GeForce GTX 1050 Ti
           .o:`.syhhhhhhh/.oo++o`      RAM: 6583MiB / 15827MiB
               /osyyyyyyo++ooo+++/    
                   ````` +oo+++o\:    
                          `oo++.

shigutso on 19 Apr 2020

Hello @alohl669, please give #2927 a read. Your Ryzen 7 3700X processor should be affected by that on kernels older than 5.4.x.

kisak-valve on 19 Apr 2020

❤1

Hello @alohl669, please give #2927 a read. Your Ryzen 7 3700X processor should be affected by that on kernels older than 5.4.x.

@kisak-valve correct, I have managed to start with the correct instruction and the game already starts, however it cracks when it gives to show information of the DLC iceborn

Last proton log:
pid 5170 != 5169, skipping destruction (fork without exec?)

Okay, I can give you the full proton log, or the one I use to see the steam output:

/tmp/dumps/myuser_stdout.txt
my_user_stdout.txt

alohl669 on 19 Apr 2020

@kisak-valve correct, I have managed to start with the correct instruction and the game already starts, however it cracks when it gives to show information of the DLC iceborn

Its because the DLC popup has an embedded video that uses the Media Foundation DLL and crashes (known issue)
There are workarounds:

Patching proton to have the DLL, which is legally problematic
Opening the game in a windows PC to dismiss the popup, then load a save, save the game and exit (so the popup won't show again)
Running on proton 4.11, using the very slow FPS to dismiss the popup before the video loads, then load a save, save the game and exit, then use proton 5.0.6 to play normally

Dl0tt on 19 Apr 2020

❤2

@Dl0tt finally I accidentally found a rather unprofessional solution, but it worked. I simply spam out the "B" button on the pad and the ad was cancelled

So, thank you so much @kisak-valve and @Dl0tt

alohl669 on 19 Apr 2020

Cannot enable VKD3D in Monster Hunter World (ID 582010)

Issue transferred from https://github.com/ValveSoftware/Proton/issues/3795.
@Galcian79 posted on 2020-04-24T19:28:40:

Proton Version: 5.6-GE-2

Issue:

using PROTON_USE_VKD3D=1
forced DirectX12Enable=On in graphics-option.ini

now in game menu shows Directx 12 API: Yes
still DXVK_HUD has a different opinion

Schermata del 2020-04-24 21-11-47 - 1
Any idea how to fix this?

kisak-valve on 24 Apr 2020

Yes, but the requirements aren't available in current versions of proton:
1 - basically latest VKD3D development version from https://github.com/HansKristian-Work/vkd3d;
2 - to pass the VKD3D_FEATURE_LEVEL=12_0 env var while launching the game to fake support for unsupported/incomplete features;
3 - a patch series for Wine which were merged in 5.7 (https://www.winehq.org/pipermail/wine-devel/2020-April/164477.html).

Against DXVK/d3d11 mode, the GPU bound performance is 10-15% lower, while the CPU bound performance is about 30-40% higher.
On a 5GHz hexacore coffeelake i7 and a 5700XT equipped machine, the game is always GPU bound and as a result ~10-15% slower overall with VKD3D/d3d12 than with DXVK/d3d11.

Tk-Glitch on 24 Apr 2020

Yes, but the requirements aren't available in current versions of proton:
1 - basically latest VKD3D development version from https://github.com/HansKristian-Work/vkd3d;
2 - to pass the VKD3D_FEATURE_LEVEL=12_0 env var while launching the game to fake support for unsupported/incomplete features;
3 - a patch series for Wine which were merged in 5.7 (https://www.winehq.org/pipermail/wine-devel/2020-April/164477.html).

Against DXVK/d3d11 mode, the GPU bound performance is 10-15% lower, while the CPU bound performance is about 30-40% higher.
On a 5GHz hexacore coffeelake i7 and a 5700XT equipped machine, the game is always GPU bound and as a result ~10-15% slower overall with VKD3D/d3d12 than with DXVK/d3d11.

So it could help my i5 4570 to gain more frames?

Galcian79 on 25 Apr 2020

I'm currently having severe disk performance issues with the latest version. Is there some sort of caching system that can be hooked into wine to avoid the game loading the same files from disk repeatedly?

GoLD-ReaVeR on 27 Apr 2020

@Galcian79 If your GPU isn't your main limiting factor, yes it could.

edit: MHW d3d12 renderer can now be used with Proton 5.0-7 RC: https://github.com/ValveSoftware/Proton/issues/3814 - You'll need to launch the game with VKD3D_FEATURE_LEVEL=12_0 %command% as stated earlier.

Tk-Glitch on 27 Apr 2020

Out of curiosity, I tried to launch it with VKD3D_FEATURE_LEVEL=12_0 %command% but it still doesn't allow me to set Directx12 in the settings. I tried to set DirectX12Enable=On but I feel like the game is still using dx11 since I haven't noticed any change.
Of course I opted in the "next" beta of Proton 5.0

Edit: Not related, but I just figured that switching to Prime offload from performance mode in nvidia-settings bumped my fps by ~15. I'll gladly take it, but how can this be explained ?

tuxrinku on 29 Apr 2020

@Galcian79 If your GPU isn't your main limiting factor, yes it could.

edit: MHW d3d12 renderer can now be used with Proton 5.0-7 RC: #3814 - You'll need to launch the game with VKD3D_FEATURE_LEVEL=12_0 %command% as stated earlier.

Done. The cpu load is actually 10 - 15 % lower but the gpu load is at 100%, same as dxvk. The performance seems slightly worse.
Tested with Mango HUD.

Galcian79 on 30 Apr 2020

@tuxrinku

Edit: Not related, but I just figured that switching to Prime offload from performance mode in nvidia-settings bumped my fps by ~15. I'll gladly take it, but how can this be explained ?

It cannot.

Galcian79 on 30 Apr 2020

Screenshot from 2020-04-30 15-38-34

Here's an exemple. It's the only game where I can see a big difference. In other games I lose about 2-3 fps since coolbits isn't available with render offload (not that I'm aware of anyway)

tuxrinku on 30 Apr 2020

Does anyone here have issues loading into the rotten vale?

GoLD-ReaVeR on 2 May 2020

@Tk-Glitch the above question seems to be an issue with your latest build (5.6.1). The base proton runs fine. Your build is also telling me to upgrade to an nvidia version not available on Linux, which is quite amazing :P

GoLD-ReaVeR on 2 May 2020

My latest build is 5.7 based though. No such issue on my end (with 5.7r6, that is).

Tk-Glitch on 2 May 2020

I'm having a strange bug using vkd3d, not sure if it's common among others but certain textures and particle effects start moving around as I move the camera. Usually fires, waterfalls, and the scout flies move up and down as I rotate my camera, not where they are supposed to be.
Running proton 5.0.7
CPU: i3-7000
GPU: RX 580 8 GB

It would be nice if vkd3d works as well as dxvk since there is a considerable performance boost due to my CPU bound system.

Pic1: fire is floating and not where it is supposed to be
Pic 2: the snow texture is also floating
Fire tweaking
floating ground

rohitm99 on 3 May 2020

👍3

Well got the winehq staging thing done now. But after importing Monster Hunter World Iceborne from steam to lutris I tried launching it and it said runner not installed. I went to configure but steam wasn't listed as a runner and the lutris version isn't installed I just downloaded steam from the pop shop. But when I try installing it from the runners list on lutris, but it won't install... What runner should I use....

Mera1506 on 3 May 2020

Hello @Mera1506, please use the lutris forums to get help with lutris-specific issues.

kisak-valve on 3 May 2020

My latest build is 5.7 based though. No such issue on my end (with 5.7r6, that is).

5.7 works fine yeah. Thanks.

The recently introduced issue with disk load remains. After playing MHW for a while (time varies) the game freezes a lot and seems to be loading from disk. The most notable player is when any of the players in a quest faints. Whenever this happens and the game gracefully exits after I quit the game, steam is validating the files. I have no clue what level of idiocy has been introduced in the latest MHW patch, but I'd love to circumvent it for obvious reasons.

GoLD-ReaVeR on 6 May 2020

@Tk-Glitch as @GoLD-ReaVeR previously stated

Your build is also telling me to upgrade to an nvidia version not available on Linux,

is infact correct on my end

steam-582010.log
MonserhunterNvidia driver

nutta-git on 6 May 2020

@Tk-Glitch I managed to get d3d12 to work with the base proton builds, but not with yours. I installed vkd3d (yaourt -S vkd3d-git) per instructions found in your deploy release info but it didn't seem to do the trick. Is there anything else I should do?

My experience with the base proton builds so far has been that the game does perform better, but that there's a LOT of rendering glitches at the moment. The game also crashed after completing a hunt which is partly why I want to try a vkd3d git build rather than the bundled vkd3d.

EDIT: Almost forgot to mention, the d3d12 renderer and chromium videoplayer are still not playing nice with eachother. It's a dual monitor setup and I believe hardware acceleration on video player is still disabled, yet the game is still affected and is really choppy because of it.

GoLD-ReaVeR on 15 May 2020

DX12 renderer just complained about a memory overrun, so it's probably leaking from some place.

GoLD-ReaVeR on 16 May 2020

@GoLD-ReaVeR I should change/make the note clearer. The winehq vkd3d git repo is deeply out of date and well behind Proton's version, which is based on HansKristian and Doitsujin's fork. You can get a bleeding edge version of that through the vkd3d-git PKGBUILD I provide, but the AUR version won't cut it for anything except maybe WoW.

Tk-Glitch on 16 May 2020

@Tk-Glitch ok I installed that and the dx12 option is still disabled.

GoLD-ReaVeR on 16 May 2020

@GoLD-ReaVeR did you recompile wine/proton after installing vkd3d-git?

xzn on 16 May 2020

Oh it's not dynamic?

GoLD-ReaVeR on 16 May 2020

@Tk-Glitch Even with building your PKGBUILD it didn't work.

EDIT: I fiddled a little with the user_settings.py and now I'm getting an "ERR14: Graphics API not implemented"

GoLD-ReaVeR on 16 May 2020

Wow so, recently the game has been having trouble launching. I found that I have to restart Steam before playing MHW every time... Even after boot! It's actually not a big deal, but it's annoying.

If I launch the game, close it, and relaunch it will crash on startup. I will need to restart Steam once again!

This is strange. At first I thought it was related to ACO/LLVM, but it doesn't matter which one I use. I'm currently using the Proton GE 5.8, but I've tried other versions of Proton and they have the same issue. It creates a black window, and then closes after a few seconds.

Edit: Well I tested the restart method 3 times, and it worked each time... But today it's not working at all. I have no idea what it is.

Edit 2: Disregard this post. I found that it was actually MangoHUD causing the crash (among other games).

DeathTBO on 17 May 2020

@Tk-Glitch FYI, the last build you made (5.8.r*), compiled on my machine allows me to play MHW and watch a stream side by side without performance issues. In d3d11 at least, I still haven't gotten d3d12 to work.

GoLD-ReaVeR on 19 May 2020

@GoLD-ReaVeR You might want to post in my issue tracker so we can figure out what's wrong on your end. I think we got enough off-topic GE/tkg user-support going on in here already 🐸 Proton's issue tracker shouldn't be used that way and it makes everyone's job harder.

Tk-Glitch on 20 May 2020

I'm not quite sure if this is exactly the right place for this but I'll try anyway because I'm out of options to ask.

I'm using Proton-5.8-GE-2-MF and several things seem to not work as I would expect based on others peoples comments.

There are claims the mf weapon tutorial videos work by default. Not the case for me. I hear the handler talking over the video but the entire game hangs and I have to kill it.
Seems like GE forces Monster Hunter to run with vkd3d when it's launched in DX12 mode. Not a problem on it's on but in this mode (even though I have 5-10 better fps) the game has shadow artifacts near snow maps/areas and outright hangs as soon as I kill a monster.

The only way I can play the game is in DXVK mode (either DX11 or DX12 if using default proton). The game seems to run flawlessly this way except that in no configuration I have working tutorial videos.

I have tested all of this with and without ACO or fsync and it made no difference.

My specs:
AMD Vega56 (mesa drivers and vulkan-radeon)
Intel i5 6600k
Steam-native (Proton-5.8-GE-2-MF, fsync kernel, ACO shaders)

NdranC on 23 May 2020

For 2, there may be a more recent patch for vkd3d that will help you out. If it's not available then turn off Z-prepass. The tests I did with the base proton always ended in crashes hence I tried with the tkg version.

For me the d3d12 renderer now runs flawlessly (with tkg) and I can run the game at max settings at ~60 fps (nvidia GTX1080). Disk load issues I had are gone and I can have twitch open while playing as well. I've had the game running for over 12 hours without a single crash or hint of a crash. The only tidbits I have is that the weapon preview doesn't render properly and the volumetric fog only works properly at the highest setting; but I can live with that.

GoLD-ReaVeR on 23 May 2020

I'm not quite sure if this is exactly the right place for this but I'll try anyway because I'm out of options to ask.

I'm using Proton-5.8-GE-2-MF and several things seem to not work as I would expect based on others peoples comments.
1. There are claims the mf weapon tutorial videos work by default. Not the case for me. I hear the handler talking over the video but the entire game hangs and I have to kill it.

2. Seems like GE forces Monster Hunter to run with vkd3d when it's launched in DX12 mode. Not a problem on it's on but in this mode (even though I have 5-10 better fps) the game has shadow artifacts near snow maps/areas and outright hangs as soon as I kill a monster.
The only way I can play the game is in DXVK mode (either DX11 or DX12 if using default proton). The game seems to run flawlessly this way except that in no configuration I have working tutorial videos.

I have tested all of this with and without ACO or fsync and it made no difference.

My specs:
AMD Vega56 (mesa drivers and vulkan-radeon)
Intel i5 6600k
Steam-native (Proton-5.8-GE-2-MF, fsync kernel, ACO shaders)

verifiy that you have ffmpeg install when using Proton-5.8-GE-2-MF so the videos can play, and if you had the mf workaround y have to delete de compat data of mosnter hunter

blastermaster77 on 24 May 2020

I'm not quite sure if this is exactly the right place for this but I'll try anyway because I'm out of options to ask.
I'm using Proton-5.8-GE-2-MF and several things seem to not work as I would expect based on others peoples comments.
1. There are claims the mf weapon tutorial videos work by default. Not the case for me. I hear the handler talking over the video but the entire game hangs and I have to kill it.

2. Seems like GE forces Monster Hunter to run with vkd3d when it's launched in DX12 mode. Not a problem on it's on but in this mode (even though I have 5-10 better fps) the game has shadow artifacts near snow maps/areas and outright hangs as soon as I kill a monster.
The only way I can play the game is in DXVK mode (either DX11 or DX12 if using default proton). The game seems to run flawlessly this way except that in no configuration I have working tutorial videos.
I have tested all of this with and without ACO or fsync and it made no difference.
My specs:
AMD Vega56 (mesa drivers and vulkan-radeon)
Intel i5 6600k
Steam-native (Proton-5.8-GE-2-MF, fsync kernel, ACO shaders)
verifiy that you have ffmpeg install when using Proton-5.8-GE-2-MF so the videos can play, and if you had the mf workaround y have to delete de compat data of mosnter hunter

I do have ffmpeg installed and I don't have any mf workaround since it's a new game install. Is there any other prerequisite to play the videos with Proton-5.8-GE-2-MF?

For 2, there may be a more recent patch for vkd3d that will help you out. If it's not available then turn off Z-prepass. The tests I did with the base proton always ended in crashes hence I tried with the tkg version.

For me the d3d12 renderer now runs flawlessly (with tkg) and I can run the game at max settings at ~60 fps (nvidia GTX1080). Disk load issues I had are gone and I can have twitch open while playing as well. I've had the game running for over 12 hours without a single crash or hint of a crash. The only tidbits I have is that the weapon preview doesn't render properly and the volumetric fog only works properly at the highest setting; but I can live with that.

Well I did try tkg before. I'm a little new to this so I downloaded the prebuild steam version and it seem to just run dxvk under dx12 instead of vkd3d. I'm not sure if I'm supposed to download the source and patch it myself? Or how to go about it. Looking around the github page I didn't see any option about disabling z-prepass. What did you do about the videos?

NdranC on 25 May 2020

Z-prepass is an ingame setting found in the advanced graphical settings. For videos I used the propriety tool that is available on github but I'm not allowed to mention by name.

For the tkg build I followed the compilation instructions provided as well as @Tk-Glitch's recommendations. I also had to set "PROTON_USE_WINE_DXGI": "1", in the user_settings.py. You should get the latest version now so you should get no further complications. I also set "PROTON_NVAPI_DISABLE": "1" so I don't get the annoying pop-up at the start of the game telling my to upgrade my drivers to a version not available for Linux.

GoLD-ReaVeR on 25 May 2020

Ok so after some testing these are my results:

Issue 1:
-Using DX11(dxvk) or DX12(dxvk): Game runs flawless except for the video movies issue.
-Using DX12(vkd3d): I have from 5 to 10 fps more than with dxvk but I also have graphical artifacts of floating shadows in snow areas. The game is also unplayable do to a crash when killing any monster as soon as it dies.

Proton versions:
Proton-5.8-GE-2-MF DX11(dxvk) DX12(vkd3d)
Proton-tkg-5.9.r0 DX11(dxvk) DX12(dxvk)
Proton 5.0.7 (valve) DX11(dxvk) DX12(dxvk)
I was able to tell which version laucnhing with what thanks to the DXVK_HUD setting. It showed up for every single combo except dx12 proton-5.8-GE-2-MF, so I assume that one was using vkd3d. Unless I'm misunderstanding something.

Ideally since everyone seems to be using GloriousEggroll and enjoying the benefits of DX12 with vkd3d I would like to find out why that isn't working for me. Turning Z-Prepass off only change the artifacts to be white floating snow instead of black. Toggling ACO shadders, f-sync or e-sync did nothing to alleviate this issue. Every test under dxvk (either dx11 or 12) works basically the same with no noticeable differences between all proton versions.

Issue 2: Media Foundation video issues

Proton-5.8-GE-2-MF: It flat out doesn't work. The game hangs when I try to play a movie while I can hear the game sounds on the background. Requires me to manually kill the game. Apparently it's supposed to work by default without having to install anything else but it doesn't. Worth notting that using the mf patch with this version of proton results in a total videocard hang when even trying to boot the game and I need to reboot the system.

-Proton-tkg: It's my understanding that I have to use the mf patch for it to work under this version. I did and It still didn't work. I get the exact same issue as Proton-5.8-GE-2-MF.

-Proton 5.0-7 (valve): Still requires the mf patch. I used it and it still doesn't work but I get a different error. It outright crashes to desktop instead of hanging like the previous ones.

Honestly, I'm not sure what else to do. I guess I can live with playing dxvk without videos but my understanding is that it would eventually be gamebreaking at some point during the story.

NdranC on 28 May 2020

First off, DXVK doesn't handle d3d12 - at all. There is no way around it. If the game effectively runs in d3d12 mode, it's with VKD3D. If you see the DXVK HUD, it's using DXVK and thus runs in d3d11 mode, independently of what you might believe.

Regarding your crashes and graphical anomalies, it's mostly due to VKD3D being much younger than DXVK and ultimately quite buggy/incomplete. Esync/Fsync will only improve CPU performance in most modern games when supported, and outside of very specific cases (MHW not being one of them), won't affect graphics quality or fidelity. Building a newer version of VKD3D might reduce/fix the problem. Mesa (or nv blobs alike) can also have issues periodically, and the 20.0.7 release wasn't too great to say the least.

For your mf problem, Proton-tkg doesn't need any external mf patch as long as it was built with Guy1524's mfplat WIP patch (the 5.9 prebuilts most definitely were). An older version of that patch was used by GE in that -MF build. That being said, it's far from perfect and while tutorial vids will play just fine, the game might/will hang irrecoverably when the video should be looping. Skipping before the end bypasses the issue.
Vanilla Proton requires the legally problematic patch for now until Guy1524's patch gets merged, and I wouldn't expect that to happen just yet considering the few remaining flaws it has.

Since both solutions aren't working for you, I'd blame missing dependencies (gst plugins, possibly), or buggy vulkan drivers/mesa (taking your "total videocard hang" into account).

Tk-Glitch on 28 May 2020

First off, DXVK doesn't handle d3d12 - at all. There is no way around it. If the game effectively runs in d3d12 mode, it's with VKD3D. If you see the DXVK HUD, it's using DXVK and thus runs in d3d11 mode, independently of what you might believe.

Thanks for clearing this up. I haven't had much time these last couple days to sit down and read about them. My conclusion came from just the dxvk_hud showing up or not. I guess since the hud is showing up on what I believe to be dx12 then it must be that it's automatically setting my game to run in dx11 without me changing the setting in the game menu.

Presumably for me to build a newer version of VKD3D into any of the protons I would have to manually build them myself or wait for the respective creators to update it into the prebuilts I've been downloading.

Regarding my mf problem. I was looking for guy1524's github and I'm unable to find a list of dependencies or something that might hint at what I could be missing. Reading the tkg github page I managed to find this:

guy1524_mfplat_WIP.mypatch : MFPlat support patchset from our Lord and Savior Guy1524, binaryless version - You'll likely want _proton_mf_hacks="false" when using it - https://github.com/Guy1524/wine/commits/mfplat_cleanup

But I think these are building instructions and nothing related to running it. Looking into your "gst plugin" suggestion I can see I only have gstreamer, gst-plugins-base-libs and gst-plugins-base. There a lot more I'm missing. If you have a suggestion on which ones should I install or if I should do most of them, that would be great.

PS: I did notice that with the latest tkg prebuilt I can see item previews no problem. So those seem to be fixed.

EDIT: I managed to fix my mf problem. Turns out you were spot on on the missing gst plugin. I decided to go with my gut feeling and installed vaapi and libav and that seemed to fix the issue. Thanks for the suggestion I would've never guessed that. It might be a rare problem for most people since I'm starting from a clean arch install without most of these things preinstalled. Maybe worth pointing out somewhere in the github readme. Unless I missed it.

NdranC on 28 May 2020

So I tested the game with Proton-5.8-GE-2-MF, the most recent TKG release (5.9) and am now running a try with the "official" 5.0.7.

So far my experience has been that vkd3d provides smoother frame timings but worse performance and on Image Quality set to High leads to lots of graphical glitches, no matter which Proton version I use (and no matter which vkd3d version I use).

Best performance by far is provided by using Proton 5.0.7 with vkd3d. This gets me - depending on where I am - 50 to 60 fps on a mix of low to high settings. It's just that the graphical glitches in DX12 mode are super annoying. Basically Guiding Flies are unusable because you can't see them, they are rendered at like 50 feet above you, same goes for similar effects (water foam, fire, dust &c., screenshots to illustrate the problem). Anyone know what causes this and what can be done about it?

nilleairbar on 28 May 2020

@NdranC I'm glad my suggestion helped :)

But I think these are building instructions and nothing related to running it.

That's right. Wine/Proton-tkg are build systems with a bank of custom patches before everything else. The prebuilts offered are just a "display" for what can be achieved with them.

Maybe worth pointing out somewhere in the github readme.

You're absolutely right. Its experimental/optional nature makes it even more unclear. Will do! Thanks.

@nilleairbar

So far my experience has been that vkd3d provides smoother frame timings but worse performance

That vastly depends on your hardware. MHW is very CPU intensive in d3d11 mode, and many people will have their GPU underused as a result. In such a case, VKD3D can give a performance boost by allowing better GPU utilization. On the other hand, with a fast enough CPU you'll see lower performance due to DXVK being faster than VKD3D when GPU bound.

Anyone know what causes this and what can be done about it?

That looks like the Nvidia driver bug that was fixed/worked around with https://github.com/HansKristian-Work/vkd3d/commit/b3be23c066eb51c109c47cd7af0bcf3a0a997c15
If you're not using a nv GPU, you might want to give an older/newer mesa release a try.

Tk-Glitch on 28 May 2020

Related to this game, folks have been asking about modding on Linux but also companion apps such as SmartHunter.

Well it's not that easy but I've managed to prototype a similar app linux-hunter; please have a look at the _README.md_ for some technical details on why it's very hard to port such apps but not totally impossible.

There is a main discussion/thread w.r.t. helping me out testing it on linux_gaming.
Feel free to check it out and ask any questions there and/or github.

Emanem on 29 May 2020

Sorry to update on this, but the black rendering in seliana issue is not solved with the latest vkd3d. The issue has to do with the snow being rendered in correctly. Setting the image quality to mid circumvents the issue. This also fixes any offset issues that there may have been, other settings do not fix any of the d3d12 rendering issues. What they did was change behavior of the settings set to variable in a way that would avoid the issue.

GoLD-ReaVeR on 1 Jun 2020

Sorry to update on this, but the black rendering in seliana issue is not solved with the latest vkd3d. The issue has to do with the snow being rendered in correctly. Setting the image quality to mid circumvents the issue. This also fixes any offset issues that there may have been, other settings do not fix any of the d3d12 rendering issues. What they did was change behavior of the settings set to variable in a way that would avoid the issue.

I'm gonna give it a shot and see if it crashes regardless.

That being said I recommend everybody to use the custom kernel linux-tkg-smp for your specific cpu. Installing this made the battle against Raging Brachydios go from 35 fps at the high of his particle effects to 50-60 fps. In seliana I get a more moderate boost of 5-10 fps. It's so good.

NdranC on 1 Jun 2020

They updated the game again... I supplied my log file, the game's main process goes into zombie mode after failing to launch its threads and modules.

@Tk-Glitch this happens on your proton version as well

steamlog.tar.gz

EDIT: Nevermind, it was strackers.

GoLD-ReaVeR on 4 Jun 2020

I was intrigued so I fired it up to make sure. Everything still working fine, phew 🐸

Tk-Glitch on 4 Jun 2020

Actually... Performance issues :'(

The game with base proton is really choppy and even with your patch set, while it reduces the choppy-ness it's still there and significant. Try aiming with the mouse in guiding lands during a fight and you will notice immediately I think. I've been hit by monsters in places I wasn't standing, people lose connection, etc. One windows user also has this issue and since it came with the patch, it's probably the game being stupid again.

GoLD-ReaVeR on 4 Jun 2020

I got another location: Ancient Forest right outside camp 1, the open area. I've been fiddling with my settings and it seems reflection is a culprit. If you have Ancient Forest in the rain it's simply unplayable.

When moving around the wineserver shows up in top CPU usage. They've done things again...

@Tk-Glitch the above was found on your build.

But to be clear, I'm sure this is much worse with valve proton.

GoLD-ReaVeR on 4 Jun 2020

So, I have tried to reproduce your issue. It took me quite a few resets but I finally got rain on the forest map, got right outside at camp 1 to have a nice view on the large open area, and well, I saw ~73fps @ 1440p with DXVK. I also tested with d3d12/VKD3D afterwards for a check, and saw a bit less with ~71fps, which is the usual pattern on my machine. CPU usage didn't seem unusual either (~42% with DXVK, ~35% with VKD3D). Not great, but far from unplayable.

Their update message seems to indicate they might have fixed their AC and included it back, but at least on my machine I can't see a measurable difference so far. Could it only affect multiplayer? My tests were only done solo.

Testing setup, in case it helps in any way:
8086k @5.2GHz / 32GB 4133 RAM / RX 5700XT, mesa-git, ACO enabled / Archlinux, kernel 5.7.0 with PDS CPU scheduler and Fsync support / Proton-tkg 5.9.r21(staging), Fsync enabled, DXVK/VKD3D git.

Tk-Glitch on 4 Jun 2020

Have you tried moving around and aiming at things using your mouse?

Also that amount of GHz probably surpasses any limiting factors XD You should however see your wineserver spike in htop or similar. That spiking is what seemingly is killing performance for me, other than that neither my CPU nor GPU are maxed.

I will upgrade my proton-tkg in the meantime, but if all this still doesn't help, the valve proton version shows this much easier.

GoLD-ReaVeR on 5 Jun 2020

Hmmm, I killed the avahi-daemon and the performance issue seems to be far less prevalent. I will continue testing tomorrow/this evening and see where it goes.

GoLD-ReaVeR on 5 Jun 2020

So I've come across a Strange issue regarding MHW.

I recently switched from a 1080ti to a 5700xt. When running the game under DXVK the Armor menu lags when a lot of Rarity 12 armor is on screen from Solid 60 down to 45-50fps

Here's the lag
83938297-997a0600-a798-11ea-9fae-63f7a29126e7(2)

If I scroll up just a bit the lag stops
83938304-b1518a00-a798-11ea-8789-d19ef17a1c44

Issue not happening with VKD3D (dont have the 1080ti to show screens from that)
Screenshot from 2020-06-06 09-03-50

This does not happen when using my 1080ti, when using VKD3D, or any other part of the game and is specific only to this menu and this spot of the menu and does it regardless of graphics settings used. It appears 5700xt + DXVK related but I'm having trouble tracking down the why.

I can't get apitrace to run so I can start researching possibly fixing it if possible.

Also to add this happens with Proton GE, Proton TKG, Proton 5.0.7, and Proton 4.11. Tried with/without Fsync and ACO, tried performance governor and game mode tweaks, nothing changes the behavior.

EndeavourOS
Ryzen 5 3600 + 5700xt
Mesa 20.2 git + ACO

Eckoa on 6 Jun 2020

Also Checked on my laptop, same issue as my desktop

EndeavourOS
i7 2960xm + firepro m6100
Mesa 20.2git + ACO
All low settings @720p

This screen doesnt have mangohud as it was a quick sanity check but on my laptop i drop from 52-60fps to 40fps

Screenshot from 2020-06-06 09-38-36

Screenshot from 2020-06-06 09-38-49

2 completely separate and different systems showing this issue with only commonality being OS/Driver and AMD + DXVK (VKD3D uses too much VRAM on my laptop)

Eckoa on 6 Jun 2020

I can reproduce that on my end as well. From ~95 with no r12 to ~65 with only r12 armors on screen. I could also observe the same behavior with the AMDGPU-PRO vk driver as well as with spoofing a Nvidia GPU.
Either the game is doing something extremely stupid, or both drivers are inefficient on that specific case, or there's a problem with how DXVK handles it... Or all combined 🐸

Tk-Glitch on 6 Jun 2020

I can reproduce that on my end as well. From ~95 with no r12 to ~65 with only r12 armors on screen. I could also observe the same behavior with the AMDGPU-PRO vk driver as well as with spoofing a Nvidia GPU.
Either the game is doing something extremely stupid, or both drivers are inefficient on that specific case, or there's a problem with how DXVK handles it... Or all combined 🐸

Do you know/could you point me to how to run apitrace through steam/proton?

I want to try and hunt down the root cause of this be it MHW, CPU, DXVK,etc

Eckoa on 6 Jun 2020

For me the game seems to run fine in the end, but the wineserver spiking concerns me. Not only does it hinder lower performance systems, within a few patches those spikes may be exacerbated to the point the game actually becomes unplayable for many people.

I'd also like to add that the game seems to have more frequent disk loads now, even in d3d12. This is happening during quests and I see no connection between the game events and the disk loads. The game stalls during these loads.

GoLD-ReaVeR on 6 Jun 2020

For me the game seems to run fine in the end, but the wineserver spiking concerns me. Not only does it hinder lower performance systems, within a few patches those spikes may be exacerbated to the point the game actually becomes unplayable for many people.

I'd also like to add that the game seems to have more frequent disk loads now, even in d3d12. This is happening during quests and I see no connection between the game events and the disk loads. The game stalls during these loads.

I haven't yet experienced this, so far the only performance issues I've encountered are the r12 armor menu and the usual bow users and their raining spike thing causing framerate to drop.

I'm using mq-deadline with an Intel 545s SSD on TKGs PDS zen2 kernel so not sure if that does anything for disk access in my case.

Eckoa on 6 Jun 2020

After spending hours trying to get this game to give me logs (dxgi, d3d11, and apitrace) to no avail I decided to try another test. So i tested running the game in windowed mode with a loop of heaven running in the background on low settings 1600x900 to keep the gpu frequency up thinking maybe the GPU frequency is dropping down but getting the same exact behavior. The GPU stays loaded and frequency high but still lose FPS. CPU usage doesnt look to change either minus the bit extra from unigine heaven but thats not much.

Doing some other testing it seems to be 100% r12 gear specific, with all r11 gear in the window the frame rate is good as it is with anything else under r12. Ill keep attempting logs to try and figure this out but im also going to have some windows based clan mates do some testing to see if they can replicate it.

Eckoa on 7 Jun 2020

@Tk-Glitch I was able to confirm the behavior on Windows also. Its happening with my clan mates one dropping from 100fps to 65-70 he has an i5 6600k + gtx1070 and the other with an i7 2600k @4.4ghz + GTX980 sees a similar but smaller drop from 85 to 75.

The issue is something MHW is doing, what and why idk.

Eckoa on 8 Jun 2020

Stopped playing for a week or so and now, after nothing in my system has changed (no updates or anything) the game won't start, no matter the Proton version, no matter if the prefix is completely fresh.

The game will launch but no window opens and after about 30 seconds it just exits without any error code. According to the Proton logs there is no error encountered.

nilleairbar on 12 Jun 2020

Stopped playing for a week or so and now, after nothing in my system has changed (no updates or anything) the game won't start, no matter the Proton version, no matter if the prefix is completely fresh.

The game will launch but no window opens and after about 30 seconds it just exits without any error code. According to the Proton logs there is no error encountered.

This happened to a couple of clan mates on Windows so its not proton but im not sure what caused it. Try a reinstall possibly?

Eckoa on 13 Jun 2020

In case anyone has problems with the game no longer starting, deleting all .dll in the games folder and then verifiying the installation fixed the issue for me.

nilleairbar on 13 Jun 2020

Using the latest proton I was able to play the main story of the game to the end.
Unfortunately after the main story is completed, there is an advertisement video for the iceborn dlc which instantly crashes the game.
I have seen some reports about this suggesting to close the video immediately but this does not work for me, as no matter what I do the application crashes.

I tried with Proton-5.8-GE-2-MF and Proton-5.9-GE-2-MF but no difference.
Although the media foundation pack should already be included in the ge version, I installed it again with the <Workaround removed by moderator> scripts but this also made no difference. I installed vaapi and libav to make sure there are no missing dependencies and still no change.

Was anyone able to solve this issue with the advertisement video?

Sirina32 on 19 Jun 2020

Hello @Sirina32, the workaround you mentioned is legally problematic and has been removed.

kisak-valve on 19 Jun 2020

@Sirina32 I suggest you follow the advice of what is written on protondb or ask on a forum such reddit.
Another solution is to load the savegame in Windows, skip the cutscene, save and then reload again in Linux. You can pass the savegame to a friend in case you don't have Windows.

Having said this, hopefully the workaround won't be needed anymore because wine will soon finally support the MF libraries and formats...

Emanem on 20 Jun 2020

Hello @nutta-git, that workaround is legally problematic, which is why your comment was removed.

kisak-valve on 17 Jul 2020

Looks like the latest Ubuntu kernel update Linux scv 5.4.0-42-generic #46~18.04.1-Ubuntu SMP Fri Jul 10 07:21:24 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux may have a tiny performance regression (the game has not been updated).

Apparently even setting the CPU governor to _performance_:
echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor
yields to some micro-stutter.

~~My rig is:~~

~~i7-8700k~~
~~64 GiB RAM @ 3200 MHz~~
~~M.2 SSDs~~
~~Nvidia RTX 2080 Ti - Proprietary drivers 440.100~~
~~OS Ubuntu 18.04.3 (current LTS - will updated to 20.04.1 once it's recommended/safe)~~

~~The only thing that changed overnight has been updating the kernel - that's why I got this suspicion...~~

~~Anyone else experiencing it?~~

Please ignore the above.

I am playing using the utility nv-pwr-ctrl to control the GPU temperature/fan speed (via limiting power - sudo ./nv-pwr-ctrl --fan-ctrl gpu_temp) and a couple of days back was particularly warm and I had my case closed: as a result the GPU was being limited more than usual (the 2080 Ti RTX default power limit is 250000 mW) and it may have reached even levels around <200000 mW.

Played this morning with case open, control GPU temperature around 80 C and the power limit was kept around 225000 mW, more than enough to play without issues.

Emanem on 22 Jul 2020

I'm facing an old issue launching the game. If I launch the game with the 5.0-9 proton build, the game starts normally but crashes when I try to load my character. Using the Proton-5.9-GE-5-ST build, the character selection works fine, but the game itself randomly crash instantly after hitting the Play button on steam, and I have to repeat clicking on it plenty of time until it decides to start.

I believe there was some workaround for this issue, but I can't find it through all the posts on here. Anyone knows how to fix it ?

tuxrinku on 12 Sep 2020

I'm facing an old issue launching the game. If I launch the game with the 5.0-9 proton build, the game starts normally but crashes when I try to load my character. Using the Proton-5.9-GE-5-ST build, the character selection works fine, but the game itself randomly crash instantly after hitting the Play button on steam, and I have to repeat clicking on it plenty of time until it decides to start.

I believe there was some workaround for this issue, but I can't find it through all the posts on here. Anyone knows how to fix it ?

Scour through this thread - Are you using an AMD CPU?

Emanem on 14 Sep 2020

Scour through this thread - Are you using an AMD CPU?

Nah I have an Intel one, i7-10875H

tuxrinku on 14 Sep 2020

Scour through this thread - Are you using an AMD CPU?

Nah I have an Intel one, i7-10875H

I suggest to set the maximum log level, use 5.0-9 and post the exception/error?

Emanem on 15 Sep 2020

Here's the logs of proton 5.0-9 and proton-ge.

I'll try proton-ge with esync disabled since the error in the log is quite explicit about it. Still no hint in the log about why 5.0-9 crashes after selecting the character.

proton5.0-9.log
proton5.9-ge-5-st.log

tuxrinku on 15 Sep 2020

Looks like you're trying to run in d3d12 mode:

warn:d3d12
...
...

I suggest to change settings and use D3D11 (with official proton 5.0-9) - It would render via DXVK; let us know how it goes.

Emanem on 15 Sep 2020

Sorry I didn't mention it, but the exact same error happens with DXVK :
pid 1388032 != 1388031, skipping destruction (fork without exec?)

I'm using vkd3d and proton5.9-ge-5-st cause it's more stable with the HD textures dlc, while dxvk stutters. The only issue is the random starts.

tuxrinku on 15 Sep 2020

Sorry I didn't mention it, but the exact same error happens with DXVK :
pid 1388032 != 1388031, skipping destruction (fork without exec?)

I'm using vkd3d and proton5.9-ge-5-st cause it's more stable with the HD textures dlc, while dxvk stutters. The only issue is the random starts.

Have you set your CPU governor to performance with DXVK?

echo performance | sudo tee /sys/devices/system/cpu/cpu*/cpufreq/scaling_governor

Up until Iceborne we didn't have scheduling issues, but then CAPCOM changed the logic and without this you get micro-stutters with DXVK. I too have an Intel (albeit it's and i7-8700k).

Could you post the log of a DXVK crash?

Emanem on 16 Sep 2020

That's weird, it doesn't crash anymore after changing it back to proton 5.0-9... And yea the governor is set to performance. I'm using Feral gamemode for that. The stuttering doesn't happen without the HD textures, and only in DXVK mode. I have 8gb vram which should be enough to handle the textures.

Using VKD3D, I can use the HD Textures without any stuttering, but I have to use the proton-GE build.

tuxrinku on 16 Sep 2020

That's weird, it doesn't crash anymore after changing it back to proton 5.0-9... And yea the governor is set to performance. I'm using Feral gamemode for that. The stuttering doesn't happen without the HD textures, and only in DXVK mode. I have 8gb vram which should be enough to handle the textures.

Using VKD3D, I can use the HD Textures without any stuttering, but I have to use the proton-GE build.

Looks like that DXVK may end up using slightly more resources than your VRAM when using HD textures, hence the game stutters.
VKD3D12 is not yet in _primetime_ on official proton, that's why you have to use GE for it.

Emanem on 16 Sep 2020

Today I'm experiencing a startup crash too, I don't think MHW received an update, but I might have missed it. After pressing "Play", there is a black window that appears, as always before going to fullscreen, but it just closes itself after a few seconds.

After trying different Proton versions, it triggered a full re-download of the game (changing Proton versions from Steam deleted the full game somehow), I don't think it's normal, but anyway it didn't change anything.

I attach the Steam log from the point where I press "Play", and can also provide other logs if needed. Thanks all for your help on this thread.
log.txt

Edit: Ryzen 1700, Vega 64, latest openSUSE Tumbleweed.

Jojonintendo on 22 Sep 2020

Today I'm experiencing a startup crash too, I don't think MHW received an update, but I might have missed it. After pressing "Play", there is a black window that appears, as always before going to fullscreen, but it just closes itself after a few seconds.

After trying different Proton versions, it triggered a full re-download of the game (changing Proton versions from Steam deleted the full game somehow), I don't think it's normal, but anyway it didn't change anything.

I attach the Steam log from the point where I press "Play", and can also provide other logs if needed. Thanks all for your help on this thread.
log.txt

Edit: Ryzen 1700, Vega 64, latest openSUSE Tumbleweed.

Could you please attach logs with higher level of details? Apologies but I can't make out the reason behind.

Please note the log will be gigantic and application will be slower :)

Ps. please also be aware that after _x_ different versions of Wine/binaries, the game detects a "different" setup and the anti-copy mechanism kicks in...

Emanem on 23 Sep 2020

@Emanem I have tried the Steam Flatpak version and the game now works fine. I will have to try again with standard Steam to give you more output (reinstall needed, small nvme drive!). Thanks for your time.

Jojonintendo on 23 Sep 2020

I have tried with more debug output as you suggested, but now the behavior is different: the game window appears as before, but it never closes itself, to the point I have force closed it after 15 min. Should I have waited some more? There seemed to be no activity at all. If I remove the debug flags and press start, then the game window closes after half a second.

Also now that you mentioned the anti-copy kicking in, this could be the case, however I didn't change the Proton version at all today, only restarted the game multiple times to test the different debug options.

steam-582010.log

Jojonintendo on 24 Sep 2020

@Jojonintendo I can see a bunch of _dodgy_ log entries:

0124:err:heap:HEAP_GetPtr Invalid heap (nil)!

then many warning about not being able ot use _esync_:

0084:warn:esync:get_object Failed to retrieve fd for handle 0x40, status 0xc0000002.

then (which to me it's the failing one)

00c8:err:vulkan:wine_vkCreateInstance Failed to create instance, res=-6

So looks like _ESYNC_ is not supported in your kernel but you're running proton with it, _HEAP_GetPtr_ can't allocate memory and then you can't initialize Vulkan: _wine_vkCreateInstance_ (this is one of the main entry functions).
According to VkResult definition, the error you're getting is VK_ERROR_LAYER_NOT_PRESENT; have you defined and using a Vulkan overlay/plug-in?
Because the API is hinting at the fact it can't load a vulkan _layer_ (i.e. MangoHud), which may be not correctly setup.

Would be good to compare same log but from flatpak...

Emanem on 25 Sep 2020

@Emanem You're right, I am using vkBasalt as the only vk layer (without it the colors looks horrible on my calibrated monitor). However it worked really good at first, no issues at all for a few days and different reboots.

I have removed the launch option of vkBasalt, but the same behavior happened. Even after deleting vkBasalt completely, it fails the same way. I attach the log after this last attempt. It's weird that on the terminal I have Steam loaded from, there is a line saying:

esync: up and running.

However in the more complete log, it shows as you pointed out that esync is somehow not working. I will try to investigate further and also test with the flatpak Steam.

steam-582010.log

Jojonintendo on 25 Sep 2020

Hello @Jojonintendo, please give https://github.com/ValveSoftware/steam-for-linux/issues/7368 a read.

kisak-valve on 25 Sep 2020

👍1

Anyone else getting a page fault exception on launch?

GoLD-ReaVeR on 1 Oct 2020

Yep, the game now crashes. Good job CAPCOM...

Edit: my _guesstimate_ would be related to perhaps some protection or anti-cheat code?

Emanem on 1 Oct 2020

https://steamcommunity.com/app/582010/discussions/0/2931238448325495057/ <--- looks some dev broke it again yeah.

GoLD-ReaVeR on 1 Oct 2020

Has anyone tried using the 'proper' debug register implementation? Maybe that will fix it. Maybe if we keep yapping at CRAPCUM's feet for 2 weeks they may undo that change. Maybe money will grow on trees some day, who knows!

GoLD-ReaVeR on 1 Oct 2020

Another idea: maybe PROTON_USE_SECCOMP=1 is required for MHW now just like a few other Denuvo–protected games?

Saancreed on 1 Oct 2020

👍3

LOL, that fixed it!

GoLD-ReaVeR on 1 Oct 2020

😄4 👍2

I can launch the game with PROTON_USE_SECCOMP=1, but controller isn't working anymore =\ (Steam Controller)

Update:
Nevermind, doing Steam > Settings > Controller > General Controller Settings > check xbox fixed it.

KycKyc on 1 Oct 2020

Another idea: maybe PROTON_USE_SECCOMP=1 is required for MHW now just like a few other Denuvo–protected games?

I tried that fix and my Monster Hunter World would load indefinitely.
After trying for a second time Denuvo locked me out and I have to wait 24 hours.
All I did was use 2 different Proton versions to test.

My GF was able to start the game with "PROTON_USE_SECCOMP=1 %command%" in the start parameters.

Skibbo on 1 Oct 2020

I was able to launch the game and play using Proton-5.4-GE-3
Though I ran into a bug causing graphical corruption when I used Alt-Enter.

TheHooly on 1 Oct 2020

Confirming, using the launch option PROTON_USE_SECCOMP=1 %command% is working on Proton 5.0.9

shigutso on 1 Oct 2020

Another idea: maybe PROTON_USE_SECCOMP=1 is required for MHW now just like a few other Denuvo–protected games?

I tried that fix and my Monster Hunter World would load indefinitely.
After trying for a second time Denuvo locked me out and I have to wait 24 hours.
All I did was use 2 different Proton versions to test.

My GF was able to start the game with "PROTON_USE_SECCOMP=1 %command%" in the start parameters.

Same boat here, I tried to change Proton version and ended up locked from playing the game for 24 hours... :/
I can't even test this workaround.

I'll try again tomorrow.

darklink64 on 1 Oct 2020

Alright after trying to get the game running proper I noticed that while that environment variable starts the game, the game is really choppy for me and makes me unable to use my desktop outside of it. These are not conditions I'd be willing to fight Alatreon in, let alone Fatalis.

@Tk-Glitch I will make an issue on your version as that is the one I'm currently using.

GoLD-ReaVeR on 1 Oct 2020

I got it to run with Proton-5.1-GE-2 without launch options. Performance is worse, but with vsync it's stable at 60 fps.

DrWursterich on 2 Oct 2020

Has anyone confirmed when/whether the denuvo 24 hour lockout (how is this legal..?) in relation to debugging the recent issue actually gets lifted?

Moggers on 2 Oct 2020

My "ban" should be lifted in a few minutes to a few hours, I'm going to report back.

EDIT:
I was able to start the game normally again.
So the "ban" gets lifted after 24 hours of your first activation, regardless of any attempts made after the lockout (I tested the whole day if I could start the game again).

Skibbo on 2 Oct 2020

I can report the performance is same as before for me (i7-8700k, 2080 Ti, 64 GiB 3200 MHz RAM, NVMe).
Even the updated linux-hunter (branch 0.1.2) works fine...

Emanem on 2 Oct 2020

After the lockout expired, I was able to get in and play for a few minutes with the SECCOMP env var.
However- I am now getting very frequent crashes since the patch, which look like they're killing the graphics driver (amdgpu) and when this happens, and I subsequently hard boot, I'm once again denuvo'd.

Is anyone else experiencing drastically reduced stability lately?

Moggers on 2 Oct 2020

Another idea: maybe PROTON_USE_SECCOMP=1 is required for MHW now just like a few other Denuvo–protected games?

I tried that fix and my Monster Hunter World would load indefinitely.
After trying for a second time Denuvo locked me out and I have to wait 24 hours.
All I did was use 2 different Proton versions to test.

My GF was able to start the game with "PROTON_USE_SECCOMP=1 %command%" in the start parameters.

I'm using proton-ge-5rc-mhw and the PROTON_USE_SECCOMP=1 %command% in start parameters and the game loads and plays just fine for me. Didn't experience any crashes but I was only running around Seliana and didn't do any quests yet.

Vorthas on 2 Oct 2020

Has anyone confirmed when/whether the denuvo 24 hour lockout (how is this legal..?) in relation to debugging the recent issue actually gets lifted?

It always gets lifted. This is common. And yes, legal.

Every time you try to launch the game after changing your wine/Proton configuration (especially changing to a different version) or a new prefix, the game thinks you're launching from a completely different machine, because effectively you are. Obviously copies of the game are limited in the amount of machines you can launch them from in a day, because no one with a legitimate copy is going to try and play the same game on 10 different machines in one day.

After the 24 hours, the ban will absolutely be lifted. This has been a thing we've been dealing with for a long time.

gardotd426 on 2 Oct 2020

👀1

Apologies if this is off-topic, but how do we tell if an issue is with proton or with denuvo? When I try to run the game, it immediately closes. PROTON_LOG=1 yields nothing of substance (location of game executable, options, etc) so I feel like my testing process is highly unscientific—just changing things at random—and also probably why denuvo temp banned me.

d-arn on 2 Oct 2020

Very easy: look at the MHW tech help forum and you will see the myriad of threads popping up with people that can't launch their games or have performance issues to the point of breaking their PC. Now unless all of those users complaining are Linux users, and if that's the case they should really make a Linux client, we can safely assume that windows users share our problems. The simple fact the game was working before the patch and no longer works after the patch is also a clear giveaway that CRAPCUM changed something in the patch they were not supposed to.

As such I recommend you don't buy games from a publisher that breaks the game with every other release because they think it's fair that half the player base can't play the game so they can stop 5 pirates from playing for maybe a month. I also recommend extreme caution with games that have 3rd party protection and considering forgoing purchase until it gets removed.

GoLD-ReaVeR on 3 Oct 2020

@GoLD-ReaVeR, consider this a warning, drop the name calling or take your feedback elsewhere. This is an issue tracker for technical issues and not a forum for general discussion.

kisak-valve on 3 Oct 2020

So when will this get fixed then?

GoLD-ReaVeR on 3 Oct 2020

👎1

@GoLD-ReaVeR this is an issue tracker specifically for Proton issues and Proton issues only. In addition, it's for technical discussion and fixes/workarounds, not other discussion. Please drop the attitude.

If a game update is causing issues for Windows users as you said, then it's likely this has nothing to do with Proton.

gardotd426 on 3 Oct 2020

@gardotd426 I gave an answer to the person above me and got invalidated by the moderator. So clearly this must be a Proton issue.

GoLD-ReaVeR on 3 Oct 2020

👎1

Hadn't played in a while. Updated the game last night and launched it using PROTON_USE_SECCOMP=1 %command% With my recent 5.9 stable build (both 6 and in-progress 7 linked in the mafia de thread). Worked without issue, including the controller. Afaik the only requirement is the seccomp flag.

GloriousEggroll on 3 Oct 2020

I would not say you were invalidated, but rather recommended to leave the you know whats elsewhere.

Keep it civil, and most of all, technical, folks, I'd say!

Edit: Apologies to anyone mis-tagged; I'm still not too used to this GitHub crud.

Chiitoo on 3 Oct 2020

👍1

Hadn't played in a while. Updated the game last night and launched it using PROTON_USE_SECCOMP=1 %command% With my recent 5.9 stable build (both 6 and in-progress 7 linked in the mafia de thread). Worked without issue, including the controller. Afaik the only requirement is the seccomp flag.

Alright, I found out why I have the performance issue. Everyone: remove the PROTON_LOG=1 from your command line.

@GloriousEggroll @Tk-Glitch You will want to patch this as it's impossible to send a log if something happens while playing.

This is what the log currently looks like:
steam-582010.log.gz

GoLD-ReaVeR on 3 Oct 2020

Taking a performance hit while Proton logging is enabled is expected and not a bug. This is exactly why it's disabled by default and why you need to explicitly ask for it while troubleshooting. Any number of things can be exceptionally chatty which result in large logs and the performance overhead costs that come with that.

kisak-valve on 3 Oct 2020

I'm pretty sure that having your system (not just the game) spammed to death due to logging is not an intended side-effect. And even if it was it makes it impossible for users to draw logs from the game preventing the developers from seeing what is going on if the game crashes 30 minutes in for example. I'm advising them because it's in their own best interest, I can disable logs and be off just fine, hence I recommended that to people.

GoLD-ReaVeR on 3 Oct 2020

Game crashed on GE's build when entering Alatreon's Dawn's Triumph mission. (d3d12) I still get slowdowns when I focus my browser or have twitch open. Doesn't matter which twitch player I use, it hampers game performance on the GE build. I'm going to verify whether this is the same with tkg build.

GoLD-ReaVeR on 3 Oct 2020

With the SECCOMP flag enabled I notice no performance hit whatsoever, everything in-game works fine so far.

Edit: this is with default Proton and no mods.

Jojonintendo on 3 Oct 2020

Performance issues on either mine or tkg's builds are irrelevant here. Standard proton is where the focus needs to be. Our builds are provided for additional functionality but are completely separate from valve's and should not be used for comparison.

Additionally as Kisak has stated, logging should not be enabled, and is disabled by default. You will always take a performance hit while logging.

If dx12 gives you issues, use dx11 instead.

GloriousEggroll on 3 Oct 2020

Working fine for me with regular proton with PROTON_USE_SECCOMP=1. Just played for about five hours straight.

ryliejamesthomas on 3 Oct 2020

If dx12 gives you issues, use dx11 instead.

I've went through quite a bit of effort to get dx12 working some time ago for the very simple reason that dx11 performs a lot worse and crashes a lot. The crashes I have reported here and thus far nothing has happened to resolve it (that's over 6 months). The performance issues dx11 has are MHW related, it causes the screen to freeze when players faint, it extends loading times and gives a huge fps drop when twitch is open; even before the latest MHW patch. So dx11 is out of the question.

GoLD-ReaVeR on 4 Oct 2020

If dx12 gives you issues, use dx11 instead.

I've went through quite a bit of effort to get dx12 working some time ago for the very simple reason that dx11 performs a lot worse and crashes a lot. The crashes I have reported here and thus far nothing has happened to resolve it (that's over 6 months). The performance issues dx11 has are MHW related, it causes the screen to freeze when players faint, it extends loading times and gives a huge fps drop when twitch is open; even before the latest MHW patch. So dx11 is out of the question.

IDK if that's just an AMD issue or what, but I don't have this issue with DX11 on Nvidia. I never drop below 80 fps and average about 120 at 1440p all high settings.

gardotd426 on 4 Oct 2020

Apparently the crash is a GTX 1080 specific issue. The freezes also happen to windows users to the point entire hunts can get disconnected. The performance on dxvk has always been worse for me than it has to be. I think I get about double the framerate using d3d12 as my video card gets fully utilized; where as with dxvk it wouldn't even get past 50% utilization.

GoLD-ReaVeR on 4 Oct 2020

The performance on dxvk has always been worse for me than it has to be. I think I get about double the framerate using d3d12 as my video card gets fully utilized; where as with dxvk it wouldn't even get past 50% utilization.

@GoLD-ReaVeR Are you sure that your DXVK is up to date? MHW does some… questionable things, like reading from uncached memory (lol) and to work around that, apitrace mode is now enabled by default for MHW since version 1.7.1.

Case in point: someone posted this comparison on a friendly Discord server, which looks about right to me.

Saancreed on 4 Oct 2020

Oh, I didn't know about that change, nor about the performance improvements. I shall try one more time.

EDIT: Ok, entering Seliana and starting twitch player flat out murdered performance. I couldn't move my mouse anywhere, keyboard was so laggy that I had to switch to a non-X terminal to kill MHW.

GoLD-ReaVeR on 4 Oct 2020

Yeah, the 'twitch player' was not included in that screenshot afaik :stuck_out_tongue:

I imagine it's bringing your CPU (if using software decoding, most likely) or GPU (if using hardware decoding, unlikely) utilization to levels that your machine just can't handle gracefully.

Saancreed on 4 Oct 2020

By the way, with what graphics settings were those screenshots taken? It's a lot more amicable to have twitch and the game running now that I've turned down all my settings. Still wouldn't do Fatalis with it though.

GoLD-ReaVeR on 4 Oct 2020

Game is crashing post Fatalis update with @GloriousEggroll builds even with PROTON_USE_SECCOMP=1 on my deskop machine (Fedora 32, 5.8.5-fsync.301.fc32.x86_64, i7 9700k, RTX 2080, 455.22.04). Only get a black screen for a few seconds before it crashes.
It does work with stock Proton 5.0-9 however.

On my laptop (Fedora 33 beta, 5.8.13-300.fc33.x86_64, Ryzen 7 4700U, Renoir, Mesa 20.2.0, Xorg) it DOES work with with the ge Proton builds.

RPGHiro on 5 Oct 2020

For me the game runs fine using latest GE release or 5.0-9 but I got some random crashes when playing and my system log is spammed with wineserver[49569]: segfault at 7f942279c3bc ip 00007f6b566ffc68 sp 00007ffe42422800 error 6 in gameoverlayrenderer.so[7f6b566f3000+37000]
Also got the in-game message that my graphics device crashed. Only happens in mhw so far, and never saw that before the latest release

tuxrinku on 5 Oct 2020

That's the steam overlay crashing it looks like, unless the game is
crashing for some other reason before that and you just missed it, and it
causes the Steam overlay to crash.

On Mon, Oct 5, 2020 at 2:34 PM tuxrinku notifications@github.com wrote:

For me the game runs fine using latest GE release or 5.0-9 but I got some
random crashes when playing and my system log is spammed with wineserver[49569]:
segfault at 7f942279c3bc ip 00007f6b566ffc68 sp 00007ffe42422800 error 6 in
gameoverlayrenderer.so[7f6b566f3000+37000]
Also got the in-game message that my graphics device crashed. Only happens
in mhw so far, and never saw that before the latest release

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/175#issuecomment-703812450,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AM5Y332PZOIZKRJ77UPGMYLSJIGUDANCNFSM4FRB5W2A
.

gardotd426 on 5 Oct 2020

That's the steam overlay crashing it looks like, unless the game is crashing for some other reason before that and you just missed it, and it causes the Steam overlay to crash.

Yea that's what I thought. I disabled it and so far no crash occured.

tuxrinku on 6 Oct 2020

After the lockout expired, I was able to get in and play for a few minutes with the SECCOMP env var.
However- I am now getting very frequent crashes since the patch, which look like they're killing the graphics driver (amdgpu) and when this happens, and I subsequently hard boot, I'm once again denuvo'd.

Is anyone else experiencing drastically reduced stability lately?

Same here. Disabling DX12 seems to have helped but I need to play more to confirm.

RodrigoLeiteF on 6 Oct 2020

If DirectX 12 is somehow involved in the Steam Overlay crash, maybe it's related to "Fixed a crash when switching between Direct3D 11 and 12 or vice versa in Serious Sam 4" in the 2020-09-28 Steam client beta update. Are those affected using the mainline or beta version of the Steam client and does switching between them have an effect?

kisak-valve on 6 Oct 2020

If DirectX 12 is somehow involved in the Steam Overlay crash, maybe it's related to "Fixed a crash when switching between Direct3D 11 and 12 or vice versa in Serious Sam 4" in the 2020-09-28 Steam client beta update. Are those affected using the mainline or beta version of the Steam client and does switching between them have an effect?

This is a different crash, unrelated to the Steam Overlay. It's an error with the AMD driver resetting the GPU for seemingly no reason.

RodrigoLeiteF on 6 Oct 2020

i am getting a crash after a few hours of play.
system hardlocks for 5-10 seconds, then recovers. but the game remains frozen. i have to kill the game.
Has been happening in the guiding lands end game area.

i have the steam overlay enabled, i will try disabling it next time i play.

maverck on 7 Oct 2020

I get graphics card resets very regularly only during loading screens. This is using Wayland, with an RX 5700 XT and amdgpu, so slightly unconventional graphics setup.
Googling around shows that this is a moderately regular issue on windows (graphics card voiding itself during loading screens), with the resolution being to underclock the RX 5700 XT, tried that and saw a slight improvement, but not beyond the margin of error.

This is already with steam overlay disabled.

Moggers on 7 Oct 2020

For those on nvidia still having issues, nvidia released a driver update about a week ago that seemingly has solved the performance issues with MHW for me. The performance still isn't where it used to be but at least the input registers properly now.

GoLD-ReaVeR on 8 Oct 2020

A couple days ago I locked myself out with the Denuvo thing. I heard about the SECOMP environment variable. I threw it on there, and waited for it to expire.

Fast forward to today... Today was frustrating. I go to launch MHW, and it begins to download ~98GB of content. I immediately pause it and check the install directory. Only 10MB of content was sitting there (log files, config, save backup). I can't find the game anywhere on the drive. There is plenty of space and it is not failing whatsoever.

So I download the game again. Launch it, and it runs through what I think is the Iceborne conversion process. Very concerning, but I don't have another option. It seems to work and I get to the menu. Everything looks smooth and normal. I hit start. The "Welcome to Iceborne" video pops up, and the game freezes. Attempting to skip/stop the video does not work.

I normally play with Proton-GE, but the same thing happens on 5.0-9. I installed the mf-plat fix, and tested with both again. Still nothing.

Kernel 5.8.14 - Fedora 33
Ryzen 2700
5700xt - Mesa 20.2.0 / ACO

Edit: Well, I cleaned the prefix for the thousandth time, and relaunched the game. This time the welcome video did not show. Able to play just fine now.

DeathTBO on 15 Oct 2020

you dont need mf-plat fix with Proton-GE

On Wed, Oct 14, 2020 at 7:54 PM DeathTBO notifications@github.com wrote:

A couple days ago I locked myself out with the Denuvo thing. I heard about
the SECOMP environment variable. I threw it on there, and waited for it to
expire.

Fast forward to today... Today was frustrating. I go to launch MHW, and it
begins to download ~98GB of content. I immediately pause it and check the
install directory. Only 10MB of content was sitting there (log files,
config, save backup). I can't find the game anywhere on the drive. There is
plenty of space and it is not failing whatsoever.

So I download the game again. Launch it, and it runs through what I think
is the Iceborne conversion process. Very concerning, but I don't have
another option. It seems to work and I get to the menu. Everything looks
smooth and normal. I hit start. The "Welcome to Iceborne" video pops up,
and the game freezes. Attempting to skip/stop the video does not work.

I normally play with Proton-GE, but the same thing happens on 5.0-9. I
installed the mf-plat fix, and tested with both again. Still nothing.

Kernel 5.8.14 - Fedora 33
Ryzen 2700
5700xt - Mesa 20.2.0 / ACO

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ValveSoftware/Proton/issues/175#issuecomment-708720728,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ACHAHPVKYFTHW4PO7ST4MS3SKY24PANCNFSM4FRB5W2A
.

blastermaster77 on 15 Oct 2020

Just wanna report that MHW doesn't not run with Proton 5.13-1, but does work with Proton 5.0-10-rc4.
the log file is 35 mb, so I can't upload it to GitHub.
mhw

What I notice in common with other issues I am currently facing with Proton 5.13-1 is networking. The Division, TitanFall 2 and MHW all have networking issues with Proton 5.13-1.
Since 2 variables got updated; Steam runtime and Proton, i don't know if the problem is caused by runtime or Proton.

nutta-git on 17 Oct 2020

@nutta-git, I think you might have some issues on your end, because I literally just played a match of Titanfall 2, networking was fine.

gardotd426 on 17 Oct 2020

@gardotd426
let me compile tkgs proton and report back. welp that failed to compile
2132.686:00cc:00d0:warn:seh:virtual_unwind exception data not found in L"MonsterHunterWorld.exe"

2132.686:00cc:00d0:err:virtual:virtual_setup_exception stack overflow 1664 bytes in thread 00d0 addr 0x7f0444728e68 stack 0x120980 (0x120000-0x121000-0x220000)
this if what I found from the logs, hope its helpful.

nutta-git on 17 Oct 2020

Go to tkg issue tracker and tell it doesn't compile and tkg will sort it out for you when he gets to it. I compiled a version about a week ago and it ran with the SECCOMP flag just fine. No special vkd3d dll patchings, no special settings other than fs_hack disabled (btw, disable that, it allows your mouse to leave the window when menus are open).

GoLD-ReaVeR on 17 Oct 2020

Go to tkg issue tracker and tell it doesn't compile and tkg will sort it out for you when he gets to it. I compiled a version about a week ago and it ran with the SECCOMP flag just fine. No special vkd3d dll patchings, no special settings other than fs_hack disabled (btw, disable that, it allows your mouse to leave the window when menus are open).

Actually don't do that.

TKG still being able to provide fsync and esync functionality is dependent on a whole litany of hotfixes, and that plus the general philosophy of his wine/proton build system fundamentally requires tracking upstream in a very specific manner. This means that pretty much evening while people in Europe are asleep (where he lives), wine-tkg-git and proton-tkg will fail to build if you do a fresh git clone, because there will inevitably be a commit to either wine or wine-staging that temporarily prevents compilation, and it's always fixed within hours.

This is just inherent to the way TKG's wine and proton build systems work. Inundating him with bug reports over things that aren't bugs is not helpful. Trust me, before I realized this, I posted plenty myself, and it was always something that would have resolved itself had I just waited another hour or two to compile.

So whenever building TKG's wine or proton from source, if it fails to compile, just wait a few hours, do a pull, and try again. If it still fails, then possibly report the issue. Alternatively, you can just go grab the previous wine-staging commit hash and put it in __staging_version in the config file and it will compile successfully (and it's always obvious which commit breaks it, because it will have been done in the evening/overnight TKG time).

gardotd426 on 17 Oct 2020

Just wanna report that MHW doesn't not run with Proton 5.13-1, but does work with Proton 5.0-10-rc4.
the log file is 35 mb, so I can't upload it to GitHub.

What I notice in common with other issues I am currently facing with Proton 5.13-1 is networking. The Division, TitanFall 2 and MHW all have networking issues with Proton 5.13-1.
Since 2 variables got updated; Steam runtime and Proton, i don't know if the problem is caused by runtime or Proton.

Update: no longer getting network connection errors, but MHW just crashes on launch without creating logs.

nutta-git on 18 Oct 2020

I recommend the following launch options:
PROTON_USE_SECCOMP=1 DXVK_STATE_CACHE=0 VKD3D_FEATURE_LEVEL=12_0 %command%
The first one you will need, it sets the correct emulation/simulation of debug registers, which is what denuvo now uses because god knows why. The second one disables DXVK caching which prevents cache misses in DX11 hanging your game for 1-2 seconds and the third is needed to enable DX12 should your proton version support it; and yes, the tkg version supports it and you should use it since DX11 support since iceborne has been a disaster (various hangs, slow quest loading, etc. These are windows issues but they happen in proton all the same).

GoLD-ReaVeR on 18 Oct 2020

SECCOMP is obsoleted with proton 5.13 -1. It's not a DXVK or Vkd3d issue because the game(3~4 seconds) after pressing the play button on steam. I did try the command, but I am getting the same result. Thanks for the tip though!

update: MHW does run with tkgs-proton 5.19.r12.gbe9c9681

nutta-git on 18 Oct 2020

I'm able to run it fine on 5.13.

gardotd426 on 18 Oct 2020

Proton 5.13-1
Looking the Steam Logs (when running steam through terminal while opening MHW) I am noticing these errors in the logs:
bwrap: Can't mkdir /usr/lib32/gconv: Read-only file system
ln: failed to create symbolic link '/run/user/1000/SteamLinuxRuntime.d5d4b9af6c1477c2/socket' -> '': No such file or directory
pressure-vessel-launch[140611]: Can't connect to peer socket: Could not connect: No such file or directory

nutta-git on 18 Oct 2020

That's the same issue people are getting over on #4278

gardotd426 on 18 Oct 2020

👍1

Looks like my problems did a full 360,
I am not having intimidate crashes anymore, but network issues.
I disabled my firewall, but that proved no use.
Games that don't use internet like The Witcher 3 and Euro Truck Sim 2 works fine.

nutta-git on 22 Oct 2020

Hello which version of proton would you recommand to optimize my performances. I currently have a lot of stuttering and fps drops when I play in the Guiding Lands which is pretty annoying.

Distro : Arch 5.9.1
GPU: GTX970M
Driver: 455.28
CPU: i5-6300HQ
RAM: DDR4 16GB

I have been using Proton 5.0.9 for a few months but I'm not satisfied with its performances.

Thanks in advance for your help

cvignal on 24 Oct 2020

I would recommend tkg proton as it takes less effort to compile first and foremost and for me it feels like it performs slightly better. It has also a bunch of options you can configure at compile time, so you can for example disable fs_hack which can help with both perfromance and focusing issues or pick your own vkd3d version to avoid bad d3d builds.

GoLD-ReaVeR on 24 Oct 2020

Proton: Monster Hunter World (582010)

Most helpful comment

All 886 comments

time=1d490ce3aaf5900

Compatibility Report

System Information

I confirm:

Symptoms

Reproduction

Compatibility Report

System Information

I confirm:

Symptoms

Reproduction

System Information

Options: set()

Related issues