Well, no luck. Crashing on ALSA as well after 30 minutes of gameplay. To me it seems then that audio-related messages in the log don’t seem to be the issue, but rather a side effect. I’m stumped.
I’m also experiencing this; having some trouble getting apport to give me a coredump. I have a pretty ordinary PulseAudio setup.
Lutris 6.0 did not work for me (regular crashes), both with default DXVK (1.8.1L) and 1.7.1L.
What does seem to work is, as others have reported, Lutris 5.7-11 and DXVK 1.7.1L. I don’t know if a more recent DXVK version would work, maybe I’ll be able to test it later.
I had issues getting apport to give me a coredump too. What helped was to set my user’s ulimit core size to unlimited:
$ echo “$USER hard core unlimited” | sudo tee -a /etc/security/limits.conf
$ ulimit -c unlimited
$ ulimit -c
Then run your Lutris from the terminal that has unlimited core size and you should get a core file next to your Overwatch.exe binary on next crash.
My core file was some 5-6 GB though, and I think I’m lacking memory pages currently being executed from.
aha, I did apparently get a core dump (also 6GB), I was just looking in the wrong place. I am not competent enough to be able to do anything useful with it, though 
Lutris 5.7-11 and DXVK 1.8.1L does appear to work.
Yes I was also able to work with latest DXVK on Wine 5.7-11 (didn’t crash during testing at least). I think we should open up a Github issue on Lutris Wine repo since this seems to be highly related to that.
I think we should open up a Github issue on Lutris Wine repo since this seems to be highly related to that.
I’m not too sure about that, as it’s probably an issue upstream in the main WINE repo, as this error also occurs in wine-tgk. Also if we don’t have anything conclusive of what’s causing it, there’s really nothing the developers can do to address the issue.
UPDATE: The issues I had with not being able to use comms on anything 5.7-11 up to 6.0 were solved by changing my Audio Driver from “Auto (default)” to “PulseAudio”! 
I agree it isn’t specifically related to the Lutris builds of Wine, since I’ve had the crashes using the patrickl/fedora-wine-tkg-esync-fsync build of Wine (Fedora COPR). Has anyone tried running the game without fsync and/or esync and seeing if that fixes the issue? I know it’s an entirely random suggestion, but without any logs or relevant outputs I can’t think of a way of pinpointing it, and I have unfortunately no idea where to even start with a core dump.
I mean, at this point what I think we can safely say is that the crashing was introduced by the last OW update and has to be related to some change to the game code. Unfortunately even running the game from the terminal does not produce any relevant info to stdout. Could someone try and raise this question on Blizzard forums? I’m not familiar with them, but if someone is, then I think Blizzard devs could maybe shine some light on it despite not offically supporting Linux as a platform, since they’ve at least addressed the ban issue and such in the past.
Another idea is trying out the Wine 6.8 dev build, if by chance any of the bugfixes introduced in that version would solve the issue, although I doubt the time window would be enough and if it did happen, then it’d most likely be a fix by accident.
I guess in the meantime I have to resort back to dual-booting.
It doesn’t have to be specifically related to the Lutris Wine builds but it is related to Wine one way or another. I have checked WineHQ for Overwatch and reports are very old which means that many people are not interested in getting Overwatch run with vanilla Wine. Lutris can push experimental patches or even different Wine build for specific games. If vanilla Wine wanted to apply those patches they have to test those patches out on many other programs, Lutris doesn’t have to do that. So that is why it is better to report this issue on Lutris Github imo.
I have been testing the game for like 2-3 hours with wine-tkg 6.8 with no crashes can someone else test and see if they get a crash?
I’ve tried to compile 6.8-tkg, but it segfaults mid-way. I’ll wait for the COPR repo maintainer to build rpms and try whenever it’s released.
I was having the same exact issue with Heroes of the Storm. I just switched to Wine-Staging-6.8 using the Wine repo, and it runs, albeit slowly.
Wine-tkg 6.8 still crashes. So I guess we will have to stick with 5.7-11 still.
@Awsim I’ve switched from Lutris 5.7-11 to Wine-tkg 5.22r2 and it seems to be working. Anything below 6.0 appears to work I guess.
@Asudem how does performance compare to Lutris 5.7-11? And does in-game voice communication work out of the box with Wine-tkg 5.22r2?
1 Like
6.8-tkg, crashed within an hour.
@Awsim It works considerably better in my opinion. If comms don’t work, like I said up here just switch your Lutris audio driver setup.
I’ve been playing under wine-tkg 5.22.r2.g0ae73155 with dxvk v1.7.1L for roughly 10 hours, and I’ve yet to experience any crash. wine-tkg 6.8 worked consistently better than -staging or -ge, but I still had crashes occur every ~1-3 hours.
Past the initial caches buildup, performance under 5.22.r2.g0ae73155 / v1.7.1L is on par with latest, possibly just about 10 FPS lower. I’m still having some stutters but I believe they’re due to what’s left to be cached. No audio/comms issues.
Well, that’s… Good to hear and underwhelming at the same time. I hope it gets eventually fixed in a 6.9 or 6.10 release. I already have a shader cache built, so will try the 5.22-tkg w/ DXVK 1.8.1, at least I won’t have to reboot to WIndows just to play a game.
I mean the game runs ok with 5.7-11 and DXVK (1.7.3) from Lutris. I can get 100-250 FPS depending on the map but I would say I get around 130-150 FPS usually with my Nvidia GTX 1650 TI laptop GPU on the low settings. Performance was of course much more better with 6.x Wine versions but nothing unplayable for me at least.
EDIT: It was misconfiguration that was causing DXVK 1.8.1L not working fixed it.
What/where is the 5.7-11 setting? I’m not finding it in the lutris menus and see it suggested from time to time to change two numbers, not just the dxvk.