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.

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

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 what's your hardware and software stack?

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

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

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

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.

Anyone tried with 396.54 drivers?

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

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 does enabling vsync help?

@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.

@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 still, 2 hours is an improvement. Before I turned on vsync, I wouldn't last more than 20 minutes (on 369.54)

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

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

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).

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).

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

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

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

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

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

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 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.

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.

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

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.

@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?

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.

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

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.

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

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

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

Certainly, here you go, @damienleone.

nvidia-bug-report.log.gz

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.

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 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 @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.

@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.

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

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

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.

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

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

Testing if the crash is reproducible with that driver

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

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

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?

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

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.

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

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 See
https://github.com/ValveSoftware/Proton/issues/175#issuecomment-415886153
and
https://github.com/ValveSoftware/Proton/issues/175#issuecomment-415942845

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 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

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

@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

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.

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

@lieff I will test later and report back.

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

@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.

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! :)

@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.

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 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

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

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!

@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.

@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.

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

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

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......

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

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?

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

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
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
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

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

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

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

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 I use GNOME.

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
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

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

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

A patch was released, 396.54.05 I believe.

I'll update and test tonight

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.

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.

396.45.1

Please update to 396.54.

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

@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.

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

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

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
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

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.

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 Could it be the same driver bug as this?

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

@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

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.

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.

See also:

• reddit thread about the "bug"
• askubuntu discussion about Windows Media Feature Pack

Having fixed this issue, the game runs smoothly at 1080p 60+fps on a Core i7 8700K with a GTX 1070 Ti on Arch Linux with nvidia-396.54 and kernel 4.18.9-arch1-1-ARCH. On 1440p, I get 30-45 fps. There are occasionally crashes every several hours, but it seems to be greatly mitigated by running the game in borderless windowed mode. All settings are on highest except v-sync and volumetric fog are turned off, as both impact performance severely.

Distro: Ubuntu 18.04 LTS
Kernel: 4.15.0-34-generic
GPU: NVidia GeForce 760, Driver 390.87
CPU: AMD Ryzen 3 1200
RAM: 8GB

The same loads fine, cutscenes play fine, I can even actually play the game fine, but what appears to be noise renders ontop of everything except for some GUI elements.

I don't suppose anyone has a clue as to why my game would render like this?

@N-B-Kelly I had the same problem. Once I updated to the newer nvidia drivers from the official ppa, the issues went away.

@tryton-vanmeer Yikes, that was it. For some reason I thought I was on the latest driver already.

Thanks!

Alright it seems like the newest proton beta and steam beta client seems to fix the random freezing on nvidia.
can anyone else confirm?

Still experiencing the recurring issues with Monster Hunter closing abruptly. Help would be appreciated!

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

Gameplay can range from only a few minutes to ~30-40 minutes before closing. Updated logs attached:

steam-582010.log
MonsterHunterWorld_d3d11.log
MonsterHunterWorld_dxgi.log

Hello @HMSS013, can you run ulimit -Hn and verify that it is a high value and not 4096.

Thanks for the reply @kisak-valve, ulimit -Hn does return 4096.

Wow, it was an esync issue, I thought I had corrected that. I'll fix that and try again.

Thanks for being willing to help!

This is odd, now in the middle of play a huge number of windows clot up in the background:

When using alt+tab i can see several of them labelled _#MT FRAMEWORK 3.0_ like this:

MT FRAMEWORK.jpg

@roadh0use still freezing for me. On latest beta and nvidia 410.57

@roadh0use Looks like the latest version of Steam Play Beta also fixed it for me.

On Nvidia 396.54

Still receiving occasional full system lock ups on the latest Proton 3.7-7 beta and DXVK 0.81, stopping all video and only updating audio until I cycle power. I'm not sure if it's related to the window losing focus as was discussed a ways back; until now I'd been playing with two monitors, playing MHW in Borderless Window with mixed medium settings/no vysnc on one while alt-tabbing to the other for a browser. For what it's worth, it's really smooth when doing so, no sudden lag or spikes in stuttering

Linux Mint 19, kernel 4.15.0-36
1060 6GB, Nvidia driver 396.45

Firstly, I'd like to thank everyone posting here. You've been a great help!

On Kernel 4.15 with Nvidia driver 396.54 (GTX 1080) with proton 3.7-7 Beta (pre-shader cache disabled), vsync turned on, volumetric fog disabled

• Full system lockup, hard reboot required.
• Game freezes are usually within 20 minutes to an hour of play

On Kernel 4.18 with Nvidia driver 410.57 (GTX 1080) with proton 3.7-7 Beta (pre-shader cache disabled), vsync turned on, volumetric fog disabled

• Game plays smoothly for over an hour, but will freeze
• System remains functional, can ALT+TAB to kill the MonsterHunterWorld.exe process just fine
• Can restart the game just fine and play for another 1hr+

Based on the replies from @roadh0use and @LP0101 , the solution to the freezing problem on Nvidia systems may be to do the following

• Update the kernel to 4.18
• Use the 396.54 Nvidia Driver
• Use Steam Play Beta 3.7-7
• Play in Borderless Window Mode

I will rollback the Nvidia 410.57 driver to 396.54 and try running the game for a few hours. More commentary can be found here

Updating to kernel 4.18 seems to have done it. Not only did I play for a couple hours with plenty of alt-tabbing back and forth but I was able to exit and have the process end gracefully without having to kill it.

Thanks for your work so far!

Scratch that, just had another full system lock up with latest stable kernel, nvidia driver, proton, dxvk, etc

Not to mention the process ending itself correctly seems to have been a fluke, that's still not happening.

EDIT: When you say "pre-shader cache disabled," is that the setting in the regular Steam options or something done through DXVK launch options? Has that helped the freezing at all?

The game works perfectly without do anything in RX Vega 64. Only the stuttering reported on Windows as well. Can be fixed in part by limit FPS to 60 and activating V-sync.

The game works perfectly without do anything in RX Vega 64. Only the stuttering reported on Windows as well. Can be fixed in part by limit FPS to 60 and activating V-sync.

Are you seeing the specular highlighting problem anymore?

Are you seeing the specular highlighting problem anymore?

I see some unnatural reflections on the wood if you meaning this with specular highlightning.

I'm still having a weird issue where the game hangs and starts spitting out hundreds of background windows on my desktop all named something like _.......#MT FRAMEWORK 3.0......_.

Eventually the game closes and it generates a massive log file (~215MB)

ScreenShot

Log (215MB)

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

Have an issue with this game where my keyboard input no longer registers, mouse is fine.
Edit: this appears to occur after using Insert for chat.
Edit2: appears to happen after quest is completed and other players leave your party
Edit3: just had it happen in a party, pressed Ins to chat, message went through, keyboard input stopped

Just switched from my 1060 6GB to an RX 580 8GB using kernel 4.18.13 and latest stable Mesa/LLVM/Proton/DXVK

The infrequent full-system lock up appears to be gone, but I am experiencing all the surfaces in the hub having specular shine like they're covered in oil. It appears to _only_ be in the hub, so it's ignorable, but definitely still an error.

The latest version of DXVK in proton 3.16 seems to fix the stuttering. Also I have activated shader precaching again and it works fine.

I'm still having a weird issue where the game hangs and starts spitting out hundreds of background windows on my desktop all named something like _.......#MT FRAMEWORK 3.0......_.

Eventually the game closes and it generates a massive log file (~215MB)

ScreenShot

Log (215MB)

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

Just switched from my 1060 6GB to an RX 580 8GB using kernel 4.18.13 and latest stable Mesa/LLVM/Proton/DXVK

The infrequent full-system lock up appears to be gone, but I am experiencing all the surfaces in the hub having specular shine like they're covered in oil. It appears to _only_ be in the hub, so it's ignorable, but definitely still an error.

I can confirm these two errors still in Proton 3.16-1

ArchLinux - 4.18.12 - KDE
Ryzen 1700X / 16GB RAM
RX Vega 64 (Mesa 18.2.2)
Proton 3.16-1

ArchLinux - 4.18.14 - bspwm
Ryzen 1600 / 16GB RAM
Nvidia 1070ti (nvidia-vulkan-dkms 396.54.09)
Proton 3.16-1

I've noticed the game can freeze before title screen or crash from the tradeyard. But both MonsterHunterWorld_d3d11.log and MonsterHunterWorld_dxgi.log are empty. Am I skipping something for the crash(s) to be logged?

Edit although today after selecting proton beta 3.16 again to double check it's been downloaded the game runs fine was it just a bug in proton? (I do like that my cpu runs cooler with mhw & proton. Guess wine/linux manage the cpu threads better than windows.)

Also have the following in my launch options for dxvk info, then to ensure the game is closed when I quit.
DXVK_HUD=fps,devinfo,frametimes %command%; pgrep -i monster | xargs kill -9

I'm still having a weird issue where the game hangs and starts spitting out hundreds of background windows on my desktop all named something like _.......#MT FRAMEWORK 3.0......_.

Eventually the game closes and it generates a massive log file (~215MB)

ScreenShot

Log (215MB)

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

Still having this error with Kernel 4.18.14.200 and Proton 3.16-3.

It really does seem like it takes longer to crash your first time back if you haven't played in a little while.

I got 30 minutes of play earlier, saved and closed with no issue, but after that the crashes would happen after only a few minutes.

:(

So I've had a chance to do some more testing and it looks promising.

Specs are:
Manjaro Linux
KDE Plasma Desktop
4.19.0 Kernel
GTX 1080ti driver version 410.73
Proton 3.16-3 Beta

I ran the game for about 3 hours in Astera without any crashing. I occasionally moved around and I saved the game and interacted with vendors. Game was running in Borderless Window mode capped at 60 fps. Before this when I would play the game would last 5-30 minutes before crashing, even if I just stayed in Astera with no inputs, so this seems like a great improvement. It doesn't seem like it would be due to me having not played it for awhile because I try to launch it every couple days to see if it's fixed.

It does still hang when I exit the game so I still have to manually kill the process.

I am going to do more testing tomorrow by going on (hopefully) multiple hunts.

Everything in this game has worked fine for me except it crashes if you select "play movie" on a weapon in your box.

I've played for hours with no crashes otherwise though, including multiplayer. Good performance too.

RX580 running 4.19 and mesa/llvm git/svn.

So it turns out that yesterday was a fluke. I started a hunt today and the game locked up after about 15 minutes. So the crashing bug is not fixed yet on Nvidia.

OS: Ubuntu 18.04
NVidia drivers 410(gtx 1080)
Proton all three versionsI currently am having the issue that in monster hunter the screen completely freezes, music still plays in a loupe.

I'm mortal combat , xweather it's v-sync or g-sync I keep getting screen tearing

OS: Ubuntu 18.10
NVIDIA Driver: 410.73
Kernel Version: 4.18.0-10
Proton Version: 3.16-4
Full System Info: GIST

Game Graphics Options

[GraphicsOption]
ScreenMode=FullScreen
Resolution=2560x1440
FrameRate=30
V-Sync=Off
OptionMode=Manual
ResolutionScaling=High
TextureQuality=512
AmbientOcclusion=Off
VolumeRenderingQuality=Off
ShadowQuality=Mid
Anti-Aliasing=FXAA
LODBias=Mid
MaxLODLevel=No Limit
FoliageSway=On
SubSurfaceScattering=Off
ScreenSpaceReflection=Off
AnisotropicFiltering=Mid
WaterReflection=Off
SHDiffuse=Low
DynamicRange=64-bit
Z-Prepass=On
MotionBlur=Off
[Window]
PosX=0
PosY=0

My game seems to run fine for around 20-30mins before black screening with the music still playing in the background. Only way to close the app is to kill the process.

It doesn't work for me.

Error: The server is not reachable, check your Internet connection and click "Retry".

I'm try:
-nofriendsui -udpforce
-nofriendsui -udp
-nofriendsui -tcp

Log

@mrdev023 try using stean runtime instead of native libraries

Arch 4.19.2
ryzen 1600
Proton 3.16-4
nvidia vulkan beta | nvidia-vulkan-dkms 396.54.09-3

Heads up the dante devil charge blade can crash the game for me randomly. Doing the event quest code red twice with it equipped crashed the game once within five minutes of starting the quest then again 20 minutes it crashed starting the quest again. Both times the game froze with the background music playing fine but seemed like it was a unrecoverable error and I killed the game process.

It the best way to log this just calling the game via its appid in cli?

Hello @cj360, you can add PROTON_LOG=1 %command% to the game's launch options, reproduce your issue, then find the generated $HOME/steam-$APPID.log.

@BlazeKl It work but crash often in game with Steam but is playable.

Manjaro Deepin 4.20-rc2 (for ae-5 sound card)
AMD Threadthripper 2990wx 32c 64
Proton 3.16-4
AMD R9 390X | Mesa 18.2.5 OpenGL 4.5 Vulkan 1.1.70

Crash DUMP
Proton LOG

I guess the issue was I was some how missing game files maybe? Ran a integrity check, said 8 files missing will download. Then the I ran the mission once as a failure then again successfully but no crashes. Same weapon as when it did crash. Here's a log anyway though it seems I have to see if the crash will happen again when logging is enabled.

http://ix.io/1tcj

Xubuntu 18.04.1
Intel(R) Core(TM) i7-2600K CPU @ 3.40GHz
NVIDIA Corporation GeForce GTX 970/PCIe/SSE2

Still getting lock-ups after some time using the 415.13 drivers. The GPU resets and prints this message to kern.log:

[ 2546.530874] NVRM: GPU at PCI:0000:01:00: GPU-31cce69c-7592-a02b-a7f1-537eb763536f
[ 2546.530878] NVRM: Xid (PCI:0000:01:00): 31, Ch 00000023, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_T1_5 faulted @ 0x0_00000000. Fault is of type FAULT_PDE ACCESS_TYPE_READ

So I noticed mhw crashed for me in the middle of the code red quest and lunastra special quest and had the game crash on me the middle of those quests. Saw this in the following log

https://gist.github.com/cj360/4970bd5a32327a52b9e8671b8fe6fa97

After upgrading to Linux 4.19.2 (previously 4.14) the freezing problem seems to be gone. I managed to play several hours in a row without crashing.

I am using NixOS unstable
Linux 4.19
nvidia GTX 1070 driver 410.78
Proton 3.16-4

Options used :

• borderless
• no vsync
• volumetric fog disabled

I got multiple freeze 😢

Sometime I can play several hours in a row and other time it will freeze after 20 min of gameplay.

I can only go 15-20 minutes before a lock-up happens and I have to force reboot my computer. I tried windowed borderless which allowed me to alt-tab smoothly but I still have the crashes. I'm only on the first mission where you fight the great jagras and I've already had this happen 4 times total. I have the frame rate uncapped and vsync off.

Specs:
4.19.2-arch
GTX 1080ti
Threadripper 1900x
nvidia 415.18
Proton 3.16-4

I also have this issue, exactly has described by dseguin, however it occurs on Just Cause 3. I'm on arch with a gtx 770. Before a recent nvidia driver update the error thrown in dmesg was less detailed. Considering the error is virtually identical to dseguin (not just a generic Xid 31 error, mine and his include PAGE_FAULT, an address etc) it insinuates that this is a driver error and not just an application error. Perhaps this increased verbosity in dmesg flags an upcoming patch from nvidia, who knows.

Mine is inconsistent on how long it will go without the full system lock up. Was able to play for almost an hour earlier before crashing.

Specs:
4.19.2-Ubuntu (18.04.1)
GTX 1080ti
nvidia 415.18
Proton 3.7-8 currently, but have gotten it on the betas as well.

Some combination of turning off volumetric fog, vignette effects, DOF, and turning on vsync seems to have had a minor mitigating effect. Gotten it up to about an hour.

I believe I may have found the root cause of this issue. Despite nvidia listing xid 31 errors as 'driver' and 'application' errors, it seems that the page fault xid 31 refers to may actually be caused by a lack of vram and not just some arbitrary bad pointer somewhere. However, I am not running Monster Hunter World, rather Just Cause 3, yet I experienced the same symptoms as those listed here.

I have also discovered that the video memory consumed by Just Cause 3 increases by approximately 70 megabytes each time an alt-tab is performed when the focus is shifted to another application. Similarly, vram consumption jumps up phenomenally when fullscreen and windowed mode is cycled. This could explain the seemingly random crashing behaviour as I doubt anybody has correlated alt-tabs to increased crash frequency.

I am requesting that someone monitors their vram during crashes to confirm this. I used the tool 'nvidia-smi' to monitor my vram usage as it ships with nvidia-settings (i think). Place a terminal in a viewable location and run 'watch -n 0.5 nvidia-smi' to recursively update vram usage stats every .5 seconds. Obviously, launch Monster Hunter World, find when it crashes and post results.

I'm running a GTX 770 4gb btw.

@newnah so according to this logic we should get less crashes with minimum details as this would consume less vram ?

@newnah I just tested your theory and for me the game stops responding with only the music still playing but the VRam usage is only around ~2100MiB which is roughly 50% on my gtx 980 4gb. So running out of Vram seemed not to be the issue.
But I noticed some other, probably interesting things:

1. The Terminal with the watch nvidia-smi running kept on updating on a second monitor
2. With Ctr+Alt+F4 I can switch to another login screen. There I can login into a sudo user and kill the Monster Hunter World process.
3. When pressing the shortcut to switch to the sudo user the monitor goes black for about 2 Minutes before I can login but with the power settings set to "prefer maximum performance" the waiting time goes down to 30 seconds

For the record: I produced my crash by fighting Kulve Taroth (solo) a few times and then switching to another online session (with other players) to obtain rewards. Crashed on running away from the quest lady

CPU: i7 4790
GPU: GTX 980 4Gb
Driver: 396.54
Proton 16-4 Beta

@Estard Usually if I waited enough most times the game would resume, as if you paused the execution no less, no side effects or anything, only online disconnecting by timeout, it is identical to pausing a program using a debugger.

I attempted the change tty to login and kill, but I can't remember any time I managed something.

Should be noted that in my case even the second display would stay frozen, usually it would update 1 frame or 2 before a full system lock-up.

And all of that, kinda, changed today with the new 415.18.04 vulkan-beta driver. I haven't tested enough, since it is really tiresome having to restart the PC every time the game crashes, but there was a change on the screen after freezing, it would revert, on both screens, to showing the desktop wallpaper after some time, sometimes with whatever was on the second display returning.

I can only speculate, but I think that there might be something CPU sided, while playing a youtube video when the system freezes will continue the audio for a few (up to 30) seconds and then stop, after some time the audio will resume with both screens still frozen, the game background music remains looping all the time as always, this might be indicative that the CPU recovered from whatever happened but the GPU didn't

Before the 415.18.04 update the amount of freezes, both temporary and not, was steadily reducing with every new kernel or driver, Saturday I even managed to play pretty much the whole day with only a few temporary freezes, with the new driver, freezes seems more frequent, on what can be noticed in a few hours of testing.

I might be biased, but I had more permanent freezes while fighting Kushala Daora than any other monster, can't only say it is the wind fault since many of them happened on the reward screen but I think it might have some relation.

One thing that seems to go against the VRAM hypothesis is that after I increased the game resolution to 1440p from 1080p, after buying a new display, I the game seems to behave better, but I'm more inclined to believe that the volumetric fog is on average the biggest culprit, while not the only one.

There might be some network influence, since many times the game would freeze not long after a player entering my, originally, solo session. If I'm not the session host, recovering from a freeze means disconnecting from the session and going in offline mode, however if I am the session host and the only player in a mission if the game recovers from a freeze and I return to Astera all players would remain connected.

CPU: Ryzen 7 2700X
GPU: GTX 1070
Driver: 415.18.04 vulkan-beta
Proton 16-4 Beta

EDIT: I just got the game to freeze only itself, quiet interesting things with the new driver

I can also now confirm that the vram issue is separate to the xid 31 issue, I managed to get JC3 to crash without exceeding vram, sorry for the false alert. I have updated to the new drivers as well but I haven't noticed any differences.

I noticed that you said you have to reboot after each crash. Not sure if it's specific to JC3 but I bound 'pkill -9 -f .exe' to a hotkey and when it freezes I mash that button a bit. It takes a few seconds but it eventually sigkills it. Hopefully that will make it a bit easier for you.

I also want to specify that in Just Cause 3 the 31 occurs almost always when flying in a jet or helicopter. Probably some in game logic which affects rendering when flying. It goes without saying there are practically infinite variables which could be triggering this error, but maybe it has something to do with LOD or draw distance? I'm not sure, but I do know this pathetic guessing isn't getting us anywhere. I'm going to open an issue on the dxvk github page in the meantime.

I have a potential workaround which has solved the issue on Just Cause 3.

After ticking 'Disable desktop effects' in the lutris options (game->configure->system options->Disable desktop effects) I have managed to clock ~3 hours without any crashing, regardless of whether I was flying. I restarted the game but with it enabled, crashing after ~15 seconds of entering a helicopter. Restarting again but with it disabled once more, I repeated my actions in game (same time, place and helicopter) and did not crash (even after 15mins+ of flying!).

The option in lutris refers to desktop compositing in your display manager (probably xorg). If you aren't using lutris you should be able to specify which application does what. I'm sure proton has similar settings, although I don't use it so I can't confirm. This may be helpful: https://wiki.archlinux.org/index.php/Xorg#Composite

I sincerely hope this solves the problem in Monster Hunter World as I know just how frustrating it is.

I think this might have worked, played for around 2 hours with no kind of freezing or crashing, thanks newnah!

I will update should I get any freeze or crash

Also it seems like this party trick only works once per session. If you close the game and relaunch it for some reason it is just as susceptible to crashing as with desktop compositing enabled, at least in lutris. Obviously you can work around this by a reboot or a faster 'systemctl restart lightdm' (you could simply not close the game!). Anyway I'm glad this has seemed to mitigate the issue. Not sure if this is a bug in lutris... but for now I don't really care.

Just a heads up, I defeated Xeno'jiiva the 'last boss' and when it went to the saving screen I think there is a movie sequence that you have to see in order to progress, there the game crashes to the desktop and renders the save file unplayable. They only work around is to play the movie sequence is to play it on windows. :( and then go back to the game on Linux, I have not done so. Is there any way to make the video playback work.?

Does it crash with a xid 31 error (if no, that's good)? Could you post the terminal output?

I can confirm the crash after Xeno'jiiva the "last boss", it is the movie sequence. Which can be triggered also by watching the sequence "denouncement" alone, no need to defeat the boss to reproduce this.

crash log

If I read this correctly

84373.656:0024:00c6:trace:seh:call_vectored_handlers calling handler at 0x6a41dfc0 code=406d1388 flags=0
84373.656:0024:00c6:trace:seh:call_vectored_handlers handler at 0x6a41dfc0 returned ffffffff
84377.791:0024:002e:trace:module:LdrGetDllHandle L"steam_api64.dll" -> 0x3b400000 (load path L"Z:\\home\\buscher\\Done\\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")
84377.984:0024:002e:fixme:mfplat:MFStartup (131184, 0): stub
84378.213:0024:002e:fixme:mfplat:mfattributes_SetUINT32 0x5e1570, {a634a91c-822b-41b9-a494-4de4643612b0}, 1
84378.213:0024:002e:fixme:mfplat:mfattributes_SetUINT32 0x5e1570, {aa456cfd-3943-4a1e-a77d-1838c0ea2e35}, 1
84378.213:0024:002e:fixme:mfplat:src_reader_GetNativeMediaType 0x5e0320, 0x00000000, 0, 0xddfc00
84378.213:0024:002e:trace:seh:NtRaiseException code=c0000005 flags=0 addr=0x141ec1d47 ip=141ec1d47 tid=002e
84378.213:0024:002e:trace:seh:NtRaiseException  info[0]=0000000000000000
84378.213:0024:002e:trace:seh:NtRaiseException  info[1]=0000000000000000
84378.214:0024:002e:trace:seh:NtRaiseException  rax=0000000080004001 rbx=0000000080004001 rcx=0000000000000000 rdx=0000000142e5cb40
84378.214:0024:002e:trace:seh:NtRaiseException  rsi=0000000000000000 rdi=00007f0f985426b0 rbp=0000000000000000 rsp=0000000000ddfba0
84378.214:0024:002e:trace:seh:NtRaiseException   r8=0000000000ddfbc0  r9=0000000000ddf792 r10=0000000000000000 r11=0000000000000000
84378.214:0024:002e:trace:seh:NtRaiseException  r12=0000000000000000 r13=0000000000000000 r14=00000000012dfbb8 r15=00000001416811b4
84378.214:0024:002e:trace:seh:call_vectored_handlers calling handler at 0x6a41dfc0 code=c0000005 flags=0
84378.214:0024:002e:trace:seh:call_vectored_handlers handler at 0x6a41dfc0 returned 0
84378.214:0024:002e:trace:seh:call_vectored_handlers calling handler at 0x6f2826e0 code=c0000005 flags=0
84378.214:0024:002e:trace:seh:call_vectored_handlers handler at 0x6f2826e0 returned 0

the fixme:mfplat:src_reader_GetNativeMediaType might be the interesting part, as this is the last output before the exception output and mfplat is a FIXME. So my humble guess, MHW calls this function but does not check the return value and blindly uses the data -> crash.
If I should be right then wine needs to implement this mfplat.

Watching the sequence under windows work fine, afterward, I could continue to play under Linux/proton.

Specs:

• kernel 4.19.8
• xorg-server xorg-server-1.20.3
• nvidia-drivers-415.22 (geforce 1060gtx)
• Proton 3.16-4 Beta

NOTE: This crash is unrelated to the freezes, at least I could not find any connection. I am also having those freezes and tried several setting/tips from this post, but it still freezes randomly.

for the freezes I get

[74924.495990] NVRM: GPU at PCI:0000:09:00: GPU-b96024f0-36ab-06dc-cbe4-9532fcd667e5
[74924.495992] NVRM: GPU Board Serial Number: 
[74924.495995] NVRM: Xid (PCI:0000:09:00): 31, Ch 00000053, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_T1_2 faulted @ 0x0_00000000. Fault is of type FAULT_PDE ACCESS_TYPE_READ
[79879.456414] NVRM: Xid (PCI:0000:09:00): 31, Ch 00000053, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_T1_0 faulted @ 0x0_00000000. Fault is of type FAULT_PDE ACCESS_TYPE_READ
[82736.768536] NVRM: Xid (PCI:0000:09:00): 31, Ch 00000053, intr 10000000. MMU Fault: ENGINE GRAPHICS GPCCLIENT_T1_9 faulted @ 0x0_00000000. Fault is of type FAULT_PDE ACCESS_TYPE_READ

in the dmesg output, multiple different freezes, because I wanted to play ;-)

And for the record, using PROTON_USE_WINED3D=1 just results in a black screen.
With tons of

...
88353.129:0024:002e:fixme:d3d11:d3d_query_init Ignoring MiscFlags 0x1.
...
88353.696:0024:002e:fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier 0x00155543.
88353.696:0024:002e:fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier 0x800000c2.
...
88371.986:0024:0047:fixme:d3d_shader:shader_glsl_sprintf_cast Unhandled cast from 0x1 to 0x5.
...
88372.567:0024:0047:fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier 0x80002302.
88372.567:0024:0047:fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier 0x00199983.
...

Trimmed Log

My hope was to workaround the freeze using wined3d, but it didn't work out.

Can someone point me in the right dirrection on how to locate de crash log
and learn how to read it to help contribute? Thanks.

On Tue, Dec 11, 2018, 11:05 AM Bernd Buschinski <[email protected]
wrote:

And for the record, using PROTON_USE_WINED3D=1 just results in a black
screen.
With tons of

...
88353.129:0024:002e:fixme:d3d11:d3d_query_init Ignoring MiscFlags 0x1.
...
88353.696:0024:002e:fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier 0x00155543.
88353.696:0024:002e:fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier 0x800000c2.
...
88371.986:0024:0047:fixme:d3d_shader:shader_glsl_sprintf_cast Unhandled cast from 0x1 to 0x5.
...
88372.567:0024:0047:fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier 0x80002302.
88372.567:0024:0047:fixme:d3d_shader:shader_sm4_read_instruction_modifier Unhandled modifier 0x00199983.
...

Trimmed Log
https://nopaste.xyz/?8a9f8bb93460b0ca#TCL2E8LNiewHCC3Q5NFctkamrsbCm+ADdjkRowO9h2M=

My hope was to workaround the freeze using wined3d, but it didn't work out.

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

I tried to play with composition disabled in KDE but this didn't help

I think this is my crash log
steam-582010.log
__

For the crashes related to beating the final boss, you need to copy some files from a windows instalation

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.

See also:

• reddit thread about the "bug"
• askubuntu discussion about Windows Media Feature Pack

Having fixed this issue, the game runs smoothly at 1080p 60+fps on a Core i7 8700K with a GTX 1070 Ti on Arch Linux with nvidia-396.54 and kernel 4.18.9-arch1-1-ARCH. On 1440p, I get 30-45 fps. There are occasionally crashes every several hours, but it seems to be greatly mitigated by running the game in borderless windowed mode. All settings are on highest except v-sync and volumetric fog are turned off, as both impact performance severely.

For the crashes related to beating the final boss, you need to copy some files from a windows instalation

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.
See also:

• reddit thread about the "bug"
• askubuntu discussion about Windows Media Feature Pack

Having fixed this issue, the game runs smoothly at 1080p 60+fps on a Core i7 8700K with a GTX 1070 Ti on Arch Linux with nvidia-396.54 and kernel 4.18.9-arch1-1-ARCH. On 1440p, I get 30-45 fps. There are occasionally crashes every several hours, but it seems to be greatly mitigated by running the game in borderless windowed mode. All settings are on highest except v-sync and volumetric fog are turned off, as both impact performance severely.

Im trying to do what you posted but I cant get it right, can you make a tutorial for newbs like me.

@blastermaster77

You will need a 64-bits windows 7 install, it can't be korean (or CE edition if I'm not mistaken) since it lacks the needed codecs, it MUST be a windows 7 install, while I haven't tested with 8, the w10 files doesn't work.

Copy the dlls:

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

From the system32 and syswow64 folders (you will have 2 sets of dlls one for 32-bits and one for 64), open the registry editor and find the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Media Foundation entry and export it to a file called wmf.reg

Transfer those to your linux installation, and create a new file called mf.reg, paste this into it:

REGEDIT4

[HKEY_LOCAL_MACHINE\Software\Wine\LicenseInformation]
"msmpeg2adec-AACDecoderV2AddInEnable"=dword:00000001
"msmpeg2adec-AACDecoderV2InSKU"=dword:00000001
"msmpeg2adec-DolbyDigitalDecoderV2AddInEnable"=dword:00000001
"msmpeg2adec-DolbyDigitalDecoderV2InSKU"=dword:00000001
"msmpeg2vdec-H264VideoDecoderV2AddInEnable"=dword:00000001
"msmpeg2vdec-H264VideoDecoderV2InSKU"=dword:00000001
"msmpeg2vdec-MPEG2VideoDecoderV2AddInEnable"=dword:00000001
"msmpeg2vdec-MPEG2VideoDecoderV2InSKU"=dword:00000001

[HKEY_CLASSES_ROOT\CLSID\{271C3902-6095-4c45-A22F-20091816EE9E}]
@="MPEG4 Byte Stream Handler"

[HKEY_CLASSES_ROOT\CLSID\{271C3902-6095-4c45-A22F-20091816EE9E}\InprocServer32]
@="mf.dll"
"ThreadingModel"="Both"

[HKEY_CLASSES_ROOT\CLSID\{477EC299-1421-4bdd-971F-7CCB933F21AD}]
@="File Scheme Handler"

[HKEY_CLASSES_ROOT\CLSID\{477EC299-1421-4bdd-971F-7CCB933F21AD}\InprocServer32]
@="mf.dll"
"ThreadingModel"="Both"

[HKEY_CLASSES_ROOT\CLSID\{48e2ed0f-98c2-4a37-bed5-166312ddd83f}]
@="MFReadWrite Class Factory"

[HKEY_CLASSES_ROOT\CLSID\{48e2ed0f-98c2-4a37-bed5-166312ddd83f}\InprocServer32]
@="mfreadwrite.dll"
"ThreadingModel"="Both"

Open a terminal and run this making the needed changes:
export WINEPREFIX=/path/to/SteamLibrary/steamapps/compatdata/582010/pfx

582010 is the game id, should you need this fix on another game just repeat the process using that game wineprefix

Then run :

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

This will import the registry keys into the wineprefix and then register the dlls, remember that 64-bits and 32-bits have different dlls, if you have any kind of dependency problems it is likely that you mixed up the dlls

Thanks to lieff for finding the fix and daniel-lawrence for originally posting the solution here

Also the game started crashing again on the following day, so composing isn't the issue

@blastermaster77

You will need a 64-bits windows 7 install, it can't be korean (or CE edition if I'm not mistaken) since it lacks the needed codecs, it MUST be a windows 7 install, while I haven't tested with 8, the w10 files doesn't work.

Copy the dlls:

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

From the system32 and syswow64 folders (you will have 2 sets of dlls one for 32-bits and one for 64), open the registry editor and find the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Media Foundation entry and export it to a file called wmf.reg

Transfer those to your linux installation, and create a new file called mf.reg, paste this into it:

REGEDIT4

[HKEY_LOCAL_MACHINE\Software\Wine\LicenseInformation]
"msmpeg2adec-AACDecoderV2AddInEnable"=dword:00000001
"msmpeg2adec-AACDecoderV2InSKU"=dword:00000001
"msmpeg2adec-DolbyDigitalDecoderV2AddInEnable"=dword:00000001
"msmpeg2adec-DolbyDigitalDecoderV2InSKU"=dword:00000001
"msmpeg2vdec-H264VideoDecoderV2AddInEnable"=dword:00000001
"msmpeg2vdec-H264VideoDecoderV2InSKU"=dword:00000001
"msmpeg2vdec-MPEG2VideoDecoderV2AddInEnable"=dword:00000001
"msmpeg2vdec-MPEG2VideoDecoderV2InSKU"=dword:00000001

[HKEY_CLASSES_ROOT\CLSID\{271C3902-6095-4c45-A22F-20091816EE9E}]
@="MPEG4 Byte Stream Handler"

[HKEY_CLASSES_ROOT\CLSID\{271C3902-6095-4c45-A22F-20091816EE9E}\InprocServer32]
@="mf.dll"
"ThreadingModel"="Both"

[HKEY_CLASSES_ROOT\CLSID\{477EC299-1421-4bdd-971F-7CCB933F21AD}]
@="File Scheme Handler"

[HKEY_CLASSES_ROOT\CLSID\{477EC299-1421-4bdd-971F-7CCB933F21AD}\InprocServer32]
@="mf.dll"
"ThreadingModel"="Both"

[HKEY_CLASSES_ROOT\CLSID\{48e2ed0f-98c2-4a37-bed5-166312ddd83f}]
@="MFReadWrite Class Factory"

[HKEY_CLASSES_ROOT\CLSID\{48e2ed0f-98c2-4a37-bed5-166312ddd83f}\InprocServer32]
@="mfreadwrite.dll"
"ThreadingModel"="Both"

Open a terminal and run this making the needed changes:
export WINEPREFIX=/path/to/SteamLibrary/steamapps/compatdata/582010/pfx

582010 is the game id, should you need this fix on another game just repeat the process using that game wineprefix

Then run :

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

This will import the registry keys into the wineprefix and then register the dlls, remember that 64-bits and 32-bits have different dlls, if you have any kind of dependency problems it is likely that you mixed up the dlls

Thanks to lieff for finding the fix and daniel-lawrence for originally posting the solution here

Also the game started crashing again on the following day, so composing isn't the issue

excuse my stupidness but where exactly do I have to put the files, in what folders? is it in the proton system32 and syswow64 or the wine system folders and the mf.reg amd wmf.reg also in what folders?

@blastermaster77 Yes, you need put 64bit dlls in system32 and 32bit in syswow64 in proton prefix or any other wine prefix you use to start the game. When run wine regsvr32 and wine64 regsvr32 you need export WINEPREFIX=/path/to/prefix env variable.

@blastermaster77 Yes, you need put 64bit dlls in system32 and 32bit in syswow64 in proton prefix or any other wine prefix you use to start the game. When run wine regsvr32 and wine64 regsvr32 you need export WINEPREFIX=/path/to/prefix env variable.

I did that and it does not work

Can you post new logs? I see

21498.732:0025:002f:fixme:mfplat:MFStartup (131184, 0): stub

in your last log, that means internal mfplat used instead of real dlls. May be you also need change dll overrides to native.

Can you post new logs? I see

21498.732:0025:002f:fixme:mfplat:MFStartup (131184, 0): stub

in your last log, that means internal mfplat used instead of real dlls. May be you also need change dll overrides to native.

steam-582010.log
Here i my fresh log.

does the win7, has to be updated first to then extract the dlls and registers?

Now it's different

4273.680:0026:0027:warn:module:load_builtin_dll failed to load .so lib for builtin L"C:\\windows\\system32\\MFPlat.DLL": /home/blastermaster/.steam/steam/steamapps/compatdata/582010/pfx/dosdevices/c:/windows/system32/mfplat.dll: invalid ELF header
4273.680:0026:0027:trace:module:load_builtin_callback loaded mfplat.dll 0x5d020 0x7f4481b40000
4273.680:0026:0027:trace:module:MODULE_InitDLL (0x7f4481b40000 L"mfplat.dll",WINE_PREATTACH,(nil)) - CALL
4273.680:0026:0027:trace:module:LdrUnloadDll (L"mfplat.dll") - START
4273.680:0026:0027:trace:module:MODULE_DecRefCount (L"mfplat.dll") ldr.LoadCount: 0
4273.680:0026:0027:trace:module:free_modref  unloading L"C:\\windows\\system32\\mfplat.dll"
=>0 0x000007ff385f7a76 in mfplat (+0x27a76) (0x000007fffffffff8)
  1 0x000007ff386034c1 in mfplat (+0x334c0) (0x00007f43f7917d10)
  2 0x000007ff38602112 in mfplat (+0x32111) (0x00007f43f7917d10)
  3 0x000007ff385f88a7 in mfplat (+0x288a6) (0x00007f43509dfc30)
  4 0x000007ff385df9b9 in mfplat (+0xf9b8) (0x00007f43509dfc30)
  5 0x000007ff385dfb49 in mfplat (+0xfb48) (0x00007f43509dfc30)
  6 0x000007ff38601152 in mfplat (+0x31151) (0x00007f43509dfc30)
PE       7ff385d0000-     7ff3863c000   Export          mfplat

Looks like mfplat.dll & mf.dll override still defaults to builtin.

Now it's different

4273.680:0026:0027:warn:module:load_builtin_dll failed to load .so lib for builtin L"C:\\windows\\system32\\MFPlat.DLL": /home/blastermaster/.steam/steam/steamapps/compatdata/582010/pfx/dosdevices/c:/windows/system32/mfplat.dll: invalid ELF header
4273.680:0026:0027:trace:module:load_builtin_callback loaded mfplat.dll 0x5d020 0x7f4481b40000
4273.680:0026:0027:trace:module:MODULE_InitDLL (0x7f4481b40000 L"mfplat.dll",WINE_PREATTACH,(nil)) - CALL
4273.680:0026:0027:trace:module:LdrUnloadDll (L"mfplat.dll") - START
4273.680:0026:0027:trace:module:MODULE_DecRefCount (L"mfplat.dll") ldr.LoadCount: 0
4273.680:0026:0027:trace:module:free_modref  unloading L"C:\\windows\\system32\\mfplat.dll"
=>0 0x000007ff385f7a76 in mfplat (+0x27a76) (0x000007fffffffff8)
  1 0x000007ff386034c1 in mfplat (+0x334c0) (0x00007f43f7917d10)
  2 0x000007ff38602112 in mfplat (+0x32111) (0x00007f43f7917d10)
  3 0x000007ff385f88a7 in mfplat (+0x288a6) (0x00007f43509dfc30)
  4 0x000007ff385df9b9 in mfplat (+0xf9b8) (0x00007f43509dfc30)
  5 0x000007ff385dfb49 in mfplat (+0xfb48) (0x00007f43509dfc30)
  6 0x000007ff38601152 in mfplat (+0x31151) (0x00007f43509dfc30)
PE         7ff385d0000-     7ff3863c000   Export          mfplat

Looks like mfplat.dll & mf.dll override still defaults to builtin.

oh how do I make them not default to builtin?

You can use:

• WINEDLLOVERRIDES env https://wiki.winehq.org/Wine_User%27s_Guide#WINEDLLOVERRIDES.3DDLL_Overrides
• winecfg
• Modify user.reg->Software\Wine\DllOverrides in prefix like

[Software\\Wine\\DllOverrides] 1536334351
...
"mf"="native,builtin"
"mfplat"="native,builtin"
...

You can use:

* WINEDLLOVERRIDES env https://wiki.winehq.org/Wine_User%27s_Guide#WINEDLLOVERRIDES.3DDLL_Overrides

* winecfg

* Modify user.reg->Software\Wine\DllOverrides in prefix like

[Software\\Wine\\DllOverrides] 1536334351
...
"mf"="native,builtin"
"mfplat"="native,builtin"
...

This is what I have on user.reg

[Software\Wine\DllOverrides] 1544476852

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

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.

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

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).

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.

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...

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/

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

@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 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 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.

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

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

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

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).

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

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.

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.

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.

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.

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

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

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.

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.

@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.

@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 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 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 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 for me max level is 4. Let me know what you find.

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

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
.

@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 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.

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.

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 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

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.

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).

@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.

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).

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?

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

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 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...

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.

@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.

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

@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 no unlikely because I can transfer that file to my windows machine and it will load up fine.

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

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

@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

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-elsayed2017 ah I see. Bummer. Thanks for the detailed explanation though!

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

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-elsayed2017 I believe the proton team is working on a fix for it as well.

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 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

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 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 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.

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
.

@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).

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?

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

@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,

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

Thanks!

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
.

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

That post looks suspicious AF

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 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...

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%

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?

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!

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?

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
.

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

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

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?

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

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
.

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.

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)

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

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.

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

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

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!

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
.

@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

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.

Win10 dlls have issues with wine, win7 dlls needed.

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> 

@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.

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 

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?

I got this error after the with the new highres texture pack (installed & enabled):

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

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

@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
Thank you!
@kisak-valve
This info should be in first post.

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

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

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.

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.

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

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

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

Hello @blastermaster77, no, it is not.

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
.

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

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.

@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

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)

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.

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

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

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

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

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

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

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.

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.

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. ;)

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.

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?

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...

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.

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

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

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?

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?

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?

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 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 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 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 Thank You! I didn't know there was a different fix for this. Sorry for the link as well.

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.

@z0z0z It worked! thanks for the assist!

@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 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 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%

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.

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>

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

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.

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.

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.

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.

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.

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

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

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).

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?

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.

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 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 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.

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 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 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.

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

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
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.

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...

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.

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

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.

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?

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 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:

@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.

@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).

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.

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.

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.

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>.

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

Everything looks fine otherwise.

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.

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

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.

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
.

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

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?

Can someone else confirm it's not just me?

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

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...

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

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

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

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

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

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...

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

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

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:

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.

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

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.

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.

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.

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

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."

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:

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.

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.

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.

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.

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?

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.

How's your performance @DigitalDevilSummoner?

How's your performance @DigitalDevilSummoner?

Bad just like the other reports here

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.

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.

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.

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

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

@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.

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.

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

@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.

@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

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 can you play online?
So you are basically playing before Iceborne was launched?

@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

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.

@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.

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.

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

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;

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

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.

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...

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.

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

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

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/

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.

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

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

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

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

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

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.

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?

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?

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.

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

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?

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

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.

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.

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.

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

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.

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?

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?

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.

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.

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.

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 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

@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.

@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 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

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

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

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

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...

My system specs:

https://pastebin.com/Ckts3fhE

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?

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.

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.

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.

@Mera1506 It did not change anything sadly.

@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.

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 Did you test it locally with a fix of yours ?

@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

I can confirm it works.

Does anyone have a compiled Proton version with the fix by any chance ?

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.

Dude! This is amazing!!!!! Ok, now how can we get this delivered to non-tech people?

Yeah, was just about to ask how I would get this to work.

I would love to know how to make it work too.

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.

@Guy1524 @przmkg You're awesome!

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?

That was the initial assumption but we can't really say. It's possible.

@DeathTBO It seems more likely to be copy protection. They're probably trying to continuously remove hardware breakpoints, but I didn't check.

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

Is it possible that this specific fix will cause bans?

@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.

@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 In Italy we say: "Chi non risica non rosica"

@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.

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.

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.

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!

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

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 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 Thanks!

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

im getting another 80gb download, is this supposed to happen?

Thanks so much, trying this after work......

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.

@przmkg thank you soooo much, it's working amazingly!!

@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.

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.

@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.

Thanks @Guy1524, @Tk-Glitch, @przmkg, game launches like a charm now!

@Guy1524 thanks for finding and fixing that! Now lets hope denuvo doesn't fuck things up again for me :D

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.

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

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?

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

@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 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!

@Emanem All I did is remove the functionality for getting and setting debug registers.

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.

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.

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...

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

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.

I can't load quests anymore without the graphics card freezing my system.

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.

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

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 Since this is also happening on windows I'd say Capcom did a poor job, just like with the whole Iceborne release.

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 Can you generate a log on a run where this happens and upload it here?

@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.

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.

@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.

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!

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.

I crash to desktop every few minutes, now
can't even finish a quest

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.

Mine crashed with V sync, not without.... Not yet at least.

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

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.

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

Or, we could also name it after what it does which is STUB_DEBUG_REGS.

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

@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

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.

1. I havent made an rc3 release, so that's a self compiled build he's using.
2. I have an rc5 build thats working perfectly fine with MHW which i have not released.
3. 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.

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

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.

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%

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 Can you please give the mhw build I have pushed here a try to see if there's any change in behavior?

@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!

@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 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.

@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.

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

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.

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
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 did you turn off the controller support in steam settings? Make sure all of those options are turned off too.

@DigitalDevilSummoner will test that when i can, could take a day or two though. But thanks for the input! :)

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.

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

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 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 ...)

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: