https://bugs.winehq.org/show_bug.cgi?id=49476
Bug ID: 49476 Summary: Overwatch doesn't start on 5.10, 5.11 Product: Wine-staging Version: unspecified Hardware: x86-64 OS: Linux Status: UNCONFIRMED Severity: critical Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: cysp74@gmail.com CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Created attachment 67590 --> https://bugs.winehq.org/attachment.cgi?id=67590 LOG
Since 5.10, 5.11 staging versions Overwatch can't start.
Last working version is 5.9.r16.g6387991c
Related environment variables: export WINEPREFIX=$(pwd) export WINEARCH=win64 export __GL_THREADED_OPTIMIZATIONS=0 export __GL_SHADER_CACHE=$WINEPREFIX/shadercache export __GL_SHADER_DISK_CACHE_PATH=$WINEPREFIX/shadercache export DXVK_STATE_CACHE_PATH=$WINEPREFIX/dxvkcache export MESA_GLTHREAD=FALSE
Another try took place without __GL_THREADED_OPTIMIZATIONS and MESA_GLTHREAD but didn't make difference. DXVK 1.7 has been installed
https://bugs.winehq.org/show_bug.cgi?id=49476
juliansperling@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |juliansperling@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=49476
mata sutupud@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sutupud@yahoo.com
--- Comment #1 from mata sutupud@yahoo.com --- I'm seeing the same, but for me 5.10 from archlinux (5.10-2) works, which is wine 5.10 (3cc3b445752902e07231900befc296f74ad6576e) with patches from wine-staging 044cb930662d61f401a5d1bdd7b8e75d59cea5ea applied as fix for https://bugs.winehq.org/show_bug.cgi?id=49326. Building from source in that configuration confirms that it works, with and without dxvk enabled.
Building with wine-staging 9a4c8c5631101f8571dbdce726ae864060e446c9 and wine 17529582402ebe27ef975fc7dcb8353f4f95e629 (next rebase) results in the bug being present, Overwatch fails to start, doesn't matter if using dxvk or not.
, so possibly this is a regression in wine, but I'm not sure how to check which of the 4 commits between those versions could be the reason since the patches fail to apply cleanly.
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #2 from mata sutupud@yahoo.com --- I was counting wrong, there aren't 4 but 35 commits between those revisions. One should never try to compare hashes by just looking at them.
https://bugs.winehq.org/show_bug.cgi?id=49476
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be Product|Wine-staging |Wine Component|-unknown |ntdll Version|unspecified |5.10 Severity|critical |normal
--- Comment #3 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Filling some fields: - Issues in a single application are severity 'normal'. - First affected version is 5.10 according to comments. - More likely an upstream wine bug in ntdll than a wine-staging one.
If a full regression testing is not possible, I suggest to at least compile wine at commit b3af087 with staging commit 044cb93 and a manual partial rebase from there (manually apply ntdll related changes from staging commit 9a4c8c5).
That will split the commits between the few ntdll NtContinue related changes and the rest.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #4 from mata sutupud@yahoo.com --- I found out that staging commit 9a4c8c5 applies cleanly on top of wine 683583f, which also shows the error.
So that would leave those commits:
commit 173644b08fae3f45149b7b6351f572ad22215e7a Author: Alexandre Julliard julliard@winehq.org Date: Sat Jun 6 16:43:48 2020 +0200
kernel32: Use a vectored exception handler to catch Ctrl-C.
Signed-off-by: Alexandre Julliard julliard@winehq.org
commit 20c91c5e803090bd40fe3045a0d9fea0a68913e4 Author: Alexandre Julliard julliard@winehq.org Date: Sat Jun 6 15:41:24 2020 +0200
ntdll: Use NtContinue() to set the thread initial context.
Signed-off-by: Alexandre Julliard julliard@winehq.org
commit 7f28a1c521341399da1f3559358f2abf876d34be Author: Alexandre Julliard julliard@winehq.org Date: Sat Jun 6 15:17:07 2020 +0200
ntdll: Use NtContinue() to restore context after an exception.
Signed-off-by: Alexandre Julliard julliard@winehq.org
commit 95e2d05e5d6b92a2f6b28e00f36064b7bf6b249a Author: Alexandre Julliard julliard@winehq.org Date: Sat Jun 6 15:16:38 2020 +0200
ntdll: Implement NtContinue() in the Unix library.
Signed-off-by: Alexandre Julliard julliard@winehq.org
commit e561ce4b9259071f79d219dddf62f05cdd8dd07b Author: Alexandre Julliard julliard@winehq.org Date: Sat Jun 6 13:56:19 2020 +0200
ntdll: Move NtRaiseException() implementation to the Unix library.
Signed-off-by: Alexandre Julliard julliard@winehq.org
Unfortunately I couldn't really figure out how to do the rebase manually, and I've ran out of time for now.
https://bugs.winehq.org/show_bug.cgi?id=49476
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression
https://bugs.winehq.org/show_bug.cgi?id=49476
Simon the Sorcerer sur3@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sur3@gmx.de
https://bugs.winehq.org/show_bug.cgi?id=49476
Paul Gofman pgofman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman@codeweavers.com
--- Comment #5 from Paul Gofman pgofman@codeweavers.com --- Can you please try it with the latest Staging git? If you will be doing this, please make sure you are building with mingw (i. e., getting, e. g., kernelbase.dll and not kernelbase.dll.so).
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #6 from mata sutupud@yahoo.com --- I finally found the time to try that out. Unfortunately it doesn't change much, it still fails to start. Altough now it shows as message box saying:
"Game Initialization Failed: I"
With debugging enabled I can see it going in some kind of error handling loop before that message shows up.
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #7 from mata sutupud@yahoo.com --- Created attachment 67755 --> https://bugs.winehq.org/attachment.cgi?id=67755 error popup
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #8 from mata sutupud@yahoo.com --- Created attachment 67756 --> https://bugs.winehq.org/attachment.cgi?id=67756 error trace
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #9 from Simon the Sorcerer sur3@gmx.de --- Regression is still persistent in 5.14.
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #10 from mata sutupud@yahoo.com --- I tried again today with the newest staging (32082f4d) and wine (1ec8bf9b73) heads, and I can confirm that the problem still persists.
Also I wanted to see if other Blizzard games might also be affected, so I tried with StarCraft, and it also is affected, same error message as for Overwatch.
StarCraft can be installed through the BattleNet launcher without logging in (by selecting "Continue Without Logging In" from the gear icon menu on the login screen of the launcher), so it might be a more easily available program for testing. The game itself can be started directly without the launcher by using e.g.: $ $WINE_BUILD_DIR/wine64 'C:\Program Files (x86)\StarCraft\x86_64\StarCraft.exe' -launch It works fine with the earlier versions before the mentioned changesets.
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #11 from Paul Gofman pgofman@codeweavers.com --- Starcraft I / II as well as some other Battle.net games are reported to work in the recent Staging.
Can it be that you are using a build without mingw? This can be checked, e. g., by observing binary file names in the Wine installation directory. If there is, e. g., kernelbase.dll.so and not kernelbase.dll then it is the build without mingw.
It won't work this way, Battle.Net games in particular requires the functionality that was previously implemented through some workarounds in non-mingw builds but now when most of that is upstream the only way is to use PE builds for that which is the default for a while now.
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #12 from Simon the Sorcerer sur3@gmx.de --- I seem to have both kernelbase.dll and kernelbase.dll.so: /usr/lib/wine-staging-5.14/wine/fakedlls/kernelbase.dll /usr/lib/wine-staging-5.14/wine/kernelbase.dll.so /usr/lib/wine-staging-5.14/wine/libkernelbase.def /usr/lib64/wine-staging-5.14/wine/fakedlls/kernelbase.dll /usr/lib64/wine-staging-5.14/wine/kernelbase.dll.so /usr/lib64/wine-staging-5.14/wine/libkernelbase.def
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #13 from mata sutupud@yahoo.com --- Yes, I built using `--with-mingw`, and there is only `dlls/kernelbase/kernelbase.dll`.
However, the problem must have something to do with my build, since now I tried the newest version from arch (wine-staging-5.14-2), and everything works fine with that version. I was sure I tried with that version before, but that must have been 5.14-1, which was built without mingw (https://github.com/archlinux/svntogit-community/blob/2dd0e471c9fb429945a9720...).
So for my part it seems fixed, sorry for the confusion.
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #14 from Simon the Sorcerer sur3@gmx.de --- I opened a downstream bug report for my distribution: https://bugs.gentoo.org/736657
https://bugs.winehq.org/show_bug.cgi?id=49476
kolAflash kolAflash@kolahilft.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kolAflash@kolahilft.de
https://bugs.winehq.org/show_bug.cgi?id=49476
Kron4ek kron4ek@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kron4ek@gmail.com
--- Comment #15 from Kron4ek kron4ek@gmail.com --- Overwatch doesn't work for me too on Wine-Staging versions newer than 5.9 (tried each version from 5.10 to 6.0-rc1). So the issue is still present in 6.0-rc1 release, and the regression is somewhere between 5.9 and 5.10 versions.
Besides, if i enable full debug with WINEDEBUG="+all", the game gives me different error than with debug disabled, does this mean that there is a race condition somewhere?.
https://bugs.winehq.org/show_bug.cgi?id=49476
Storm Engineer hewanci@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hewanci@gmail.com
--- Comment #16 from Storm Engineer hewanci@gmail.com --- As of today, it's still not working on Arch with the most recent version of Staging 5.22.1.
5.10 --> Battle.net fails to start
5.11, 5.12, 5.13 --> Clicking the play button turns into "launching", then after a few seconds back to "play" as if I never launched the game.
5.14, 5.15.2, 5.16, 5.17.2, 5.18, 5.19, 5.20, 5.21, 5.22 --> Overwatch is starting, but crashes on the black screen before anything loads. Blizzard crash reporter comes up.
https://bugs.winehq.org/show_bug.cgi?id=49476
Dmitry Skvortsov (Iglu47) lvb.crd@protonmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lvb.crd@protonmail.com
--- Comment #17 from Dmitry Skvortsov (Iglu47) lvb.crd@protonmail.com --- (In reply to Kron4ek from comment #15)
Besides, if i enable full debug with WINEDEBUG="+all", the game gives me different error than with debug disabled, does this mean that there is a race condition somewhere?.
I don't know if this is the same regression or if it requires a separate bug report (a problem with the Battle.net launcher, does not allow me to do an accurate bisecting test). But I looked at wine-6.0rc3.r0.g56e7cd12ce0 with WINEDEBUG="-all,+relay" - it helps and the game started on my machine. (It seems to work from the versions after which the Battle.net launcher works.)
When changing to WINEDEBUG="" or adding '&> /dev/null' the game crashes the CrashMailer popup appears. ``` EXCEPTION_ACCESS_VIOLATION writing to 0x0000003400360077 **Crashing Thread** (ID: 1112) DBG-ADDR<0000000140E5AE46>() DBG-ADDR<0000000140E3CD92>() DBG-ADDR<0000000140E5F9EC>() DBG-ADDR<0000000141802533>() ```
Please specify what kind of information will be useful.
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #18 from mata sutupud@yahoo.com --- I haven't had any problems with Overwatch on any of these versions since the original bug was fixed, so the problem probably isn't related to this bug. I had some unrelated problems with other applications, which were fixed in later versions so at the moment I'm using a self built wine-staging 6.0rc3 since arch packages still seem stuck on 5.22. Also, dxvk is installed though winetricks. No problems with that setup.
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #19 from Simon the Sorcerer sur3@gmx.de --- I had some problems on 5.22 with the Blizzard App crashing during my Overwatch updates, but besides that Overwatch is working for me since I built it with mingw support which is now available in gentoo linux via crossdev and a useflag. For those still having problems, is your wine built with mingw PE libraries?
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #20 from Kron4ek kron4ek@gmail.com --- (In reply to Simon the Sorcerer from comment #19)
For those still having problems, is your wine built with mingw PE libraries?
Yes, at least in my case Wine is built with MinGW.
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #21 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- Hello,
Those that still have issues, please attach terminal output. Otherwise, we can't tell if it's the same or a different issue.
The fact that Overwatch doesn't start is not sufficient, as multiple issues may cause that.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #22 from Kron4ek kron4ek@gmail.com --- Created attachment 68990 --> https://bugs.winehq.org/attachment.cgi?id=68990 WINEDEBUG="+all"
Full debug with WINEDEBUG="+all" from Wine-Staging 6.0-rc1. Compressed with xz as the log file is big (260 MB).
The game ran directly from Overwatch.exe avoiding Battle.net to reduce the log size.
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #23 from Kron4ek kron4ek@gmail.com --- Created attachment 68991 --> https://bugs.winehq.org/attachment.cgi?id=68991 Overwatch log
And here is the log with default debug channels.
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #24 from Dmitry Skvortsov (Iglu47) lvb.crd@protonmail.com --- looks like changing Windows Version in winecfg from win7 to 8/8.1/10 - helps https://wiki.winehq.org/Winecfg#Windows_Version
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #25 from Kron4ek kron4ek@gmail.com --- (In reply to Dmitry Skvortsov (Iglu47) from comment #24)
looks like changing Windows Version in winecfg from win7 to 8/8.1/10 - helps https://wiki.winehq.org/Winecfg#Windows_Version
Can confirm, the game works after changing Windows version to 8, 8.1 or 10.
https://bugs.winehq.org/show_bug.cgi?id=49476
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Overwatch doesn't start on |Overwatch doesn't start |5.10, 5.11 |with Wine version set to | |Windows 7
--- Comment #26 from Zebediah Figura z.figura12@gmail.com --- Interesting. According to https://us.battle.net/support/en/article/65159 the game should support Windows 7, so I guess I'd tentatively say there's a fixable bug here. It may be hard to determine and fix, though; my guess is it's validating some version-specific behaviour in its anticheat engine.
https://bugs.winehq.org/show_bug.cgi?id=49476
--- Comment #27 from Paul Gofman pgofman@codeweavers.com --- (In reply to Zebediah Figura from comment #26)
Interesting. According to https://us.battle.net/support/en/article/65159 the game should support Windows 7, so I guess I'd tentatively say there's a fixable bug here. It may be hard to determine and fix, though; my guess is it's validating some version-specific behaviour in its anticheat engine.
IIRC it worked for me with Win 7 as well, but if it is not the case (or maybe not the case now after some game updates), I am not sure we should treat that as a bug, not sure if that worth the effort debugging. There are a lot of things which may concern, e. g., DRM, which have differences between Win7 and later, and currently we are trying to follow Win10 behaviour without probably any example of simulating earlier Windows based on reported version. We are leaving Win7 test failures as broken and, I guess, are about to drop even marking that 'broken' soon.
So if the game works on Win10 prefix and fails on Win7 I guess this bug should be closed, and maybe it is about time to create Win10 prefixes by default?
https://bugs.winehq.org/show_bug.cgi?id=49476
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED
--- Comment #28 from Alexandre Julliard julliard@winehq.org --- I don't think we are going to bother fixing it for Win 7 if it works with Win 10, since that's the default version now.
https://bugs.winehq.org/show_bug.cgi?id=49476
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #29 from Austin English austinenglish@gmail.com --- Closing.