[Bug 49436] New: 64-bit Diablo III hangs on startup since 5.11
https://bugs.winehq.org/show_bug.cgi?id=49436 Bug ID: 49436 Summary: 64-bit Diablo III hangs on startup since 5.11 Product: Wine Version: 5.11 Hardware: x86-64 URL: https://www.blizzard.com/en-gb/download/confirmation?p roduct=d3 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs(a)winehq.org Reporter: maciej.stanczew+b(a)gmail.com Regression SHA1: e561ce4b9259071f79d219dddf62f05cdd8dd07b Distribution: ArchLinux Created attachment 67524 --> https://bugs.winehq.org/attachment.cgi?id=67524 64-bit client on Staging 5.11 After updating to Staging 5.11, 64-bit Diablo III client hangs after starting, with message: 00d8:err:seh:setup_exception stack overflow 1920 bytes in thread 00d8 eip 00000001402fed5b esp 0000000000c10e90 stack 0xc10000-0xc11000-0xd10000 32-bit client launches correctly. I'm not able to test vanilla Wine, because the game doesn't work there due to bug #45443. Regression testing lead me to the very first commit after 5.10 release: commit e561ce4b9259071f79d219dddf62f05cdd8dd07b Author: Alexandre Julliard <julliard(a)winehq.org> Date: Sat Jun 6 13:56:19 2020 +0200 ntdll: Move NtRaiseException() implementation to the Unix library. The two final configurations I built were: - good: Wine 3cc3b44575, Staging 044cb930, patch ntdll-NtContinue excluded - bad: Wine e561ce4b92, Staging 044cb930, patch ntdll-NtContinue excluded, incremented NTDLL_UNIXLIB_VERSION to allow staging patches to apply ntdll-NtContinue had to be excluded because it conflicts with ntdll changes in Wine (it was removed from Staging in the following rebase). But as we can see, even with it being excluded from 5.10 (without e561ce4b92), the game runs. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #1 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- Created attachment 67525 --> https://bugs.winehq.org/attachment.cgi?id=67525 64-bit client on Staging 5.10 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #2 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- Created attachment 67526 --> https://bugs.winehq.org/attachment.cgi?id=67526 32-bit client on Staging 5.11 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #3 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- Created attachment 67527 --> https://bugs.winehq.org/attachment.cgi?id=67527 32-bit client on Staging 5.10 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #4 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- One more piece of information: after the initial "err:seh:setup_exception stack overflow" I can do a Ctrl+C in the terminal, which then goes to another exception. Flow is like this: # the game hangs 00d8:err:seh:setup_exception stack overflow 1920 bytes in thread 00d8 eip 00000001402fed5b esp 0000000000c10e90 stack 0xc10000-0xc11000-0xd10000 # Ctrl+C, 'Diablo' process becomes a zombie 00c8:err:seh:setup_exception stack overflow 2656 bytes in thread 00c8 eip 00000001402fed5b esp 0000000000120bb0 stack 0x120000-0x121000-0x220000 # Another Ctrl+C 00cc:err:seh:setup_exception stack overflow 1808 bytes in thread 00cc eip 00000001402fed5b esp 00000000342f0f00 stack 0x342f0000-0x342f1000-0x343f0000 # Another Ctrl+C 00d4:err:seh:setup_exception stack overflow 3104 bytes in thread 00d4 eip 00000001402fed5b esp 00000000008a09f0 stack 0x8a0000-0x8a1000-0x9a0000 # Any other Ctrl+C after this does nothing I can only close the process by sending it SIGTERM. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 pioruns2019(a)gmx.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pioruns2019(a)gmx.com --- Comment #5 from pioruns2019(a)gmx.com --- Confirming. Works perfectly fine on 5.10, but does not launch on 5.11. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #6 from pioruns2019(a)gmx.com --- Created attachment 67531 --> https://bugs.winehq.org/attachment.cgi?id=67531 wine output wine output from beginning when I opened launcher and it worked fine, and then I pressed Play and everything dissapeared with errors in the log. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 pioruns2019(a)gmx.com changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #67531|wine output |wine 64-bit output description| | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #7 from pioruns2019(a)gmx.com --- Maciej is there a way to do DLL override, so this library you mentioned doesn't crash Diablo? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #8 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- Which library? I don't know of any overrides that could help, as I've tested in a clean prefix, without any modifications. For now I'm just using Staging 5.10, and waiting for this bug to get attention. Other option would be to use 32-bit Diablo until this gets resolved. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 Paul Gofman <pgofman(a)codeweavers.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman(a)codeweavers.com --- Comment #9 from Paul Gofman <pgofman(a)codeweavers.com> --- Created attachment 67555 --> https://bugs.winehq.org/attachment.cgi?id=67555 PoC patch for illustration only (will allow the game to start but will break a lot of apps) I've tested the game. While the game was working in Wine 5.10 and it is technically a regression, I found nothing wrong with the blamed commit so far. It just allows some parts of DRM to work which break on other things. As a bottom line I suppose this will have to wait for ntdll.dll converted to PE (hopefully soon). I am not sure if this is the last unimplemented thing it wants but this is the place where it is stuck now. The game's DRM hooks itself from the TLS callbacks in the main exe. In the first TLS callback it overwrites the TLS callback table with the other addresses of (obfuscated) callbacks. Those callbacks do nothing on the first run, but start doing some things on the consequent runs during thread attach. With the current Wine git it fails early (much earlier than in 5.11), for the two reasons: 1. TLS callbacks were not called at all in 5.11 (and some versions earlier) due to regression. 2. With the fix for TLS callbacks added recently it fails after unsuccessful NtSetInformationThread(..., ThreadHideFromDebugger,...) called for the other thread. The failure for any non-current thread is a recent regression and should hopefully be fixed soon. With the p 2. fixed the game continues, and the subsequent run of the same callbacks on thread attach it loads ntdll.dll file to memory, guesses the addresses of DbgBreakPoint() and DbgUserBreakPoint() from on-disk ntdll (wrongly) and tries to hotpatch them. Then it seemingly does not like something in the (fake) on disk ntdll regardless of those functions and close the mapping, only to fail with access violation soon after accessing just closed mapping. So it seems reasonable to assume that this might be fixed as soon as we get PE ntdll.dll, or if not, it will make sense to continue from this point. If we skip calling TLS callbacks on thread attach (as it was the case in 5.11 release and some time before), the game continues to launch, starts Battle.net client, and after running the game by pressing 'Play' in the client it hangs with exception stack overflow probably the same way as reported in this bug. That's where the blamed commit from 5.11 comes into play. The game hotpatches KiUserExceptionDispatcher() and since the blamed commit the hook starts working on some exception handling (as it is supposed to on Windows). Before the blamed commit this function was a stub and never called from Wine exception handling. It is probably pointless searching what exactly is wrong with it now as we already skipped calling its TLS callbacks earlier, this can be enough reason for it to break in any way. I am attaching the patch on top of current Staging which allows the game to start the same way as it did in 5.10. I have no idea how (and if) it was working in some earlier Wine versions when the TLS callbacks were also called on thread attach. Not sure if investigating that makes practical sense, the way to go seems to be to wait for PE ntdll and see if it works with it or debug further from that point. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #10 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- Thank you for a great summary. You can launch the game directly, skipping Battle.net Launcher, by running: $ wine 'Diablo III64.exe' -launch Then the part about TLS callbacks doesn't seem to come into play and break anything. I have compiled Staging 5.11 with the 'tmpKiUserExceptionDispatcher' hack *and* with 1dc3383389da636617bfa7d9570e7de5c94f7882 applied, and the game launches without issues. (Btw, does this mean that 1dc3383389da636617bfa7d9570e7de5c94f7882 breaks Battle.net Launcher?) I then compiled Staging 5.11 with 1dc3383389da636617bfa7d9570e7de5c94f7882 (without the hack), and added some logs to KiUserExceptionDispatcher. First of all, behavior changed a bit: after the exception, there is now: 00d4:err:seh:setup_exception stack overflow 1728 bytes in thread 00d4 eip 00007f7d426a6029 esp 00000000008a0f50 stack 0x8a0000-0x8a1000-0x9a0000 00c8:err:ntdll:RtlpWaitForCriticalSection section 0x7bd1b520 "../../../wine-staging/dlls/ntdll/loader.c: loader_section" wait timed out in thread 00c8, blocked by 00d4, retrying (60 sec) What I found from the logs is that there are repeated (recursive?) calls to KiUserExceptionDispatcher just before the stack overflow exception. New exceptions are generated on dereferencing of 'rec' and/or 'context' variables. But I don't really understand how this hotpatching works, so I don't know if those logs make any sense at all. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #11 from Paul Gofman <pgofman(a)codeweavers.com> --- Interesting. I will look what happens with -launch option on Monday. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #12 from Paul Gofman <pgofman(a)codeweavers.com> --- (In reply to Maciej Stanczew from comment #10)
What I found from the logs is that there are repeated (recursive?) calls to KiUserExceptionDispatcher just before the stack overflow exception. New exceptions are generated on dereferencing of 'rec' and/or 'context' variables. But I don't really understand how this hotpatching works, so I don't know if those logs make any sense at all.
Thank you very much for your analysis, I was about to skip the core problem here. The fact is, the exception after (unsuccessful) ntdll.dll loading from disk happens regardless of -launch parameter (sooner or later), but the application handler is willing to catch the exception and continue regardless. The problem is that KiUserExceptionDispatcher has a different ABI (call parameters) on x64 from how it is currently implemented in Wine. So if the exception is properly processed the game launches, with or without -launch option (provided the regression from 537bb7a8aee278d285cb77669fd9258dfaa3222f is bypassed). The ABI difference comes into play only when KiUserExceptionDispatcher is found and hotpatched by the program, that's why the hack which renames the implementation helps. The context and exception record are just copied to the stack, the function seem to have no explicit pointers to those. Also there is no return address on the stack (the latter requires special care to make sure stack unwinding from the called handlers still works, the game depends on that). I've got a very draft implementation for x64 KiUserExceptionDispatcher which allows the game to work without the hacks. I will send it after bringing it to some sensible form. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #13 from Paul Gofman <pgofman(a)codeweavers.com> --- Created attachment 67610 --> https://bugs.winehq.org/attachment.cgi?id=67610 Fix x64 KiUserExceptionDispatcher I am attaching the patch which fixes the issue for me. Tested on top of Staging 37fc290f7786687b95a90b58e31fba00e3f092f2. This patch is also needed: https://source.winehq.org/patches/data/187864 It is still crashing in mainstream Wine after reading the same ntdll.dll (but now in non-recoverable way). I can guess the relevant patchset in Staging which makes it work is winebuild-FakeDlls while I did not check that yet. The latest Staging git has this patchset temporary disabled. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 Gijs Vermeulen <gijsvrm(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #14 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- (In reply to Paul Gofman from comment #13)
I am attaching the patch which fixes the issue for me. Tested on top of Staging 37fc290f7786687b95a90b58e31fba00e3f092f2. This patch is also needed: https://source.winehq.org/patches/data/187864 Tested on Wine 13b2587d4f55d64a1381c60ac34acf4abe6bb1e8 with cherry-picked eef527723f02abcdb301b02cae059b123f277d26 and e1e34cdc375baf2d1d5a2266ae0faa885987ab37 + Wine Staging 37fc290f7786687b95a90b58e31fba00e3f092f2 + your patch, and I can confirm the game runs.
It is still crashing in mainstream Wine after reading the same ntdll.dll (but now in non-recoverable way). I can guess the relevant patchset in Staging which makes it work is winebuild-FakeDlls while I did not check that yet. It does look like it; with Wine 5.10 I get 00ac:err:seh:setup_exception stack overflow 1600 bytes in thread 00ac eip 000000007bcb3f86 esp 0000000000120fd0 stack 0x120000-0x121000-0x220000 and with winebuild-FakeDlls applied the game continues past that, but then hits "D3D Error: Diablo III was unable to initialize D3D. Click OK to retry." If I then install DXVK, the game successfully launches to the login menu.
The latest Staging git has this patchset temporary disabled. Yeah, I also tried compiling Wine 359ee2ecc21b08e4118f0f77b3a208e4b5e1e63d + Staging 262df397efd272d375fd93be8ee29240faf9ed80, and the game hits 00b8:err:seh:setup_exception stack overflow 832 bytes in thread 00b8 eip 00007fb7de35bd13 esp 00000000001212f0 stack 0x120000-0x121000-0x220000 similarly to the way it is happening in plain Wine. I guess I'll be staying on Staging 5.10 for a bit longer then…
-- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #15 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- Small correction to the last paragraph: it was Wine 359ee2ecc21b08e4118f0f77b3a208e4b5e1e63d + Staging 262df397efd272d375fd93be8ee29240faf9ed80 + your patch. I see there are some new commits in both Wine and Staging, including your fix. Unsurprisingly, Wine 10b17932fa829fac10a5e6717d96ed5d56de80fe + Staging cbdc68f558627cd09404c9ab4768d1c38353f383 result in the same stack overflow exception as above. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #16 from pioruns2019(a)gmx.com --- Hi all, New wine-staging 5.12 has landed to Debian today. Diablo III still doesn't work. Results in clean profile attached. Command used: WINEPREFIX="/home/pioruns/.wine64-test" wine /home/pioruns/DiabloIII/Diablo\ III.exe -launch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #17 from pioruns2019(a)gmx.com --- Created attachment 67654 --> https://bugs.winehq.org/attachment.cgi?id=67654 wine-staging 5.12 output -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 mboquien(a)free.fr changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mboquien(a)free.fr -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 David Chalmers <aff(a)affsdiary.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |aff(a)affsdiary.com --- Comment #18 from David Chalmers <aff(a)affsdiary.com> --- I believe I am also affected by this on several Debian Bullseye systems. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 clm(a)martindroessler.de changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |clm(a)martindroessler.de --- Comment #19 from clm(a)martindroessler.de --- I've not (yet) tested with Diablo 3, but I have similar Problems with StarCraft 2 and World of Warcraft (Retail), since wine-staging 5.11 StarCraft 2 just won't start up and hang. World of Warcraft just crashes on startup with "err:seh:setup_exception stack overflow" After downgrading to 5.9 (5.10 was not in my pacman cache) it worked again without problems. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #20 from pioruns2019(a)gmx.com --- Hello clm(a)martindroessler.de, Could you please attach output from wine 5.9 and 5.11, so we can compare and confirm if it's the same error? Certainly would not hurt the case, and could help developers to fix it. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #21 from Paul Gofman <pgofman(a)codeweavers.com> --- (In reply to pioruns2019 from comment #20)
Hello clm(a)martindroessler.de,
Could you please attach output from wine 5.9 and 5.11, so we can compare and confirm if it's the same error? Certainly would not hurt the case, and could help developers to fix it.
The game doesn't work in Staging 5.12 because winebuild-FakeDlls patchset is disabled (see comment #14), it is unrelated to the issue this bug report is about. No additional logs are required. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #22 from pioruns2019(a)gmx.com --- Thank you. Is there any indication or plan when will this be fixed? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 Bjoern Bidar <theodorstormgrade(a)googlemail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |theodorstormgrade(a)googlemai | |l.com --- Comment #23 from Bjoern Bidar <theodorstormgrade(a)googlemail.com> --- wine-tkg has some fix on top of staging that fixes this kind of error at least with World of Warcraft. I was running wine-staging before that and the bug triggered for me between 5.10.0 and 5.10.0.r39 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 Robert Walker <bob.mt.wya(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #24 from Paul Gofman <pgofman(a)codeweavers.com> --- The issue discussed in the latest comments should be fixed in Staging by d2d0366ce5df254957a96bb6b7eb02c1616dba1d now. That has no relation to the problem concerned in this bug report though (which was fixed earlier). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 Ivan <iangullo(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |iangullo(a)gmail.com --- Comment #25 from Ivan <iangullo(a)gmail.com> --- Chiming in to report the same problem with 'vanilla' staging 5-12 in debian bullseye (AMDGPU driver, teste in wayland and Xorg, with and without dxvk). Battle.net loads fine, can install, remove and configure games ok. Cannot launch anything in 32 or 64 bits - either via the launcher or direct calls to the exe files. 'wine-stable' (v5.0.1) can't get Battle.net to load or install. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #26 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- (In reply to Paul Gofman from comment #24)
The issue discussed in the latest comments should be fixed in Staging by d2d0366ce5df254957a96bb6b7eb02c1616dba1d now. When compiling Wine fdb3d9ae320363c1bd9fa716b167a7ad313e638b with Staging d2d0366ce5df254957a96bb6b7eb02c1616dba1d (or 3acacd0ee1f884d382406e06b97de5327c914520), I'm getting the following errors:
../../../wine-staging/dlls/ntdll/ntdll.spec:1591: external symbol 'pe_syscall_table' is not a function ntdll.cji6r5.s: Assembler messages: ntdll.cji6r5.s: Error: .size expression for NtAcceptConnectPort does not evaluate to a constant ntdll.cji6r5.s: Error: .size expression for NtAccessCheck does not evaluate to a constant ntdll.cji6r5.s: Error: .size expression for NtAccessCheckAndAuditAlarm does not evaluate to a constant ntdll.cji6r5.s: Error: .size expression for NtAddAtom does not evaluate to a constant ntdll.cji6r5.s: Error: .size expression for NtAdjustGroupsToken does not evaluate to a constant (...) // the list continues -- there are 208 "size expression" errors in total winebuild: /usr/bin/gcc failed with status 1 winegcc: ../../tools/winebuild/winebuild failed make[1]: *** [Makefile:2089: ntdll.dll.so] Error 2 make[1]: Leaving directory '/tmp/makepkg/build/wine-staging/src/wine-staging-64-build/dlls/ntdll' make: *** [Makefile:9192: dlls/ntdll] Error 2 make: *** Waiting for unfinished jobs.... Is there anything else needed to make this work? -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #27 from Paul Gofman <pgofman(a)codeweavers.com> --- (In reply to Maciej Stanczew from comment #26)
make[1]: *** [Makefile:2089: ntdll.dll.so] Error 2
Is there any reason you are making a non-PE build? The default way of building Wine is using mingw now. I don't want to say non-PE builds are not supported, I will test what happens with a non-PE build and probably fix that. But non-PE builds receive much less testing now and some applications may not work by design with that (there are reasons why Wine is switching to PE DLLs as much as possible). Diablo 3, in particular, loads ntdll.dll from disk directly, I did not test that but I expect Diablo 3 not to work with ntdll.dll.so (that is, fake ntdll.dll on disk) even with the syscall thunks been there. The part which was previously in Staging which brought in some better fake ntdll is not there anymore, as it is solved in a better way with PE ntdll now. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #28 from pioruns2019(a)gmx.com --- Forgive me my ignorance, I am not a developer or skilled :) But does that mean, that this problem is solved, and Diablo will work again in next wine-staging release? :) I am using 5.10 currently as nothing newer released in repository work (I am using Debian 10). -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 Giacomo Orlandi <gia_(a)inwind.it> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gia_(a)inwind.it --- Comment #29 from Giacomo Orlandi <gia_(a)inwind.it> --- Paul Gofman might confirm this, but I suspect that this is fixed on staging by this commit: https://github.com/wine-staging/wine-staging/commit/d2d0366ce5df254957a96bb6... It says it's restoring the fake dlls functionality, which is what caused this issue, according to comment 21 -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #30 from Paul Gofman <pgofman(a)codeweavers.com> --- (In reply to pioruns2019 from comment #28)
Forgive me my ignorance, I am not a developer or skilled :) But does that mean, that this problem is solved, and Diablo will work again in next wine-staging release? :)
I hope so, yes. It worked for me with the latest Staging git (default build with mingw, that's how releases are built). I could login and start the actual game (didn't try to go any further). (In reply to Giacomo Orlandi from comment #29)
which is what caused this issue, according to comment 21
The issue the bug report is about is fixed in mainstream Wine 5.12. Yes, this is hard to follow as unfortunately the game was affected by multiple regressions and unrelated problems. The issue discussed since comment #16 is Bug #45349. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #31 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- (In reply to Paul Gofman from comment #27)
Is there any reason you are making a non-PE build? I am following official Arch Linux PKGBUILD: https://git.archlinux.org/svntogit/community.git/tree/trunk/PKGBUILD?h=packa... I don't see any mention of mingw there. In fact, not much changed in the build process since more than two years. I assume this means Wine packages in Arch repositories are non-PE.
The default way of building Wine is using mingw now. Where can I find more information about this? The "Building Wine" page on the Wiki doesn't say anything about PE or mingw.
… Well, I was finally able to build PE Wine (54b2a10659871032720df31ae9ca6cba2ff4acf0 + 103195f07d3fbb40ce6b91ef2247c5d7bc9f240a, same PKGBUILD but with mingw-w64-gcc installed). I can confirm that 64-bit D3 is launching properly, both without and with DXVK. Tomorrow I'll do some more testing, including gameplay and launching through Battle.net App. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #32 from Maciej Stanczew <maciej.stanczew+b(a)gmail.com> --- And now with Staging 5c4729e4ce2fe2c2dce99237bd39ea45cac45dfd and a non-PE build, compilation is successful, but D3 still hits the exception (just as you predicted): 00b8:err:seh:setup_exception stack overflow 1616 bytes in thread 00b8 eip 00007f98fdedc286 esp 0000000000120fe0 stack 0x120000-0x121000-0x22000078 Starcraft II and Heroes of the Storm are also fixed: they hit 'setup_exception stack overflow' with non-PE build, but run correctly with PE one. Starcraft Remastered and Warcraft III hit 'LdrInitializeThunk "ClientSdk.dll" failed to initialize' with non-PE build. With PE build they go further, but then crash without anything specific in the logs (there is 'fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION' and then the "Send to Blizzard" error window appears). But the original issue is fixed, so those two games will probably get their own bug report :) For me this bug is fixed with PE build. Thank you for all the effort in making this possible. What now remains is to suggest moving to PE builds in Arch packaging. I would appreciate any links to guidelines and examples regarding PE builds, as it would contribute to a more solid feature request. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 Filippe LeMarchand <gasinvein(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gasinvein(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #33 from mboquien(a)free.fr --- I confirm Maciej's findings with wine 5.13 with World of Warcraft. With a non-PE build it crashes with a stack overflow whereas it starts properly when the package is compiled with mingw-w64-gcc installed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Fixed by SHA1| |c198390c78acefdfd95ef3474f1 | |92a44f8e80b2c Status|UNCONFIRMED |RESOLVED CC| |o.dierick(a)piezo-forte.be --- Comment #34 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- (In reply to Paul Gofman from comment #30)
The issue the bug report is about is fixed in mainstream Wine 5.12. Yes,
(In reply to Maciej Stanczew from comment #32)
For me this bug is fixed with PE build. Thank you for all the effort in making this possible.
Hello, Reported fixed, by commit c198390c78acefdfd95ef3474f192a44f8e80b2c (as of comment 13). For "stack overflow" errors in 64-bit games see comment 21 (→ bug 45349). For "clientsdk.dll" errors see bug 49525 (→ bug 42741). For non-PE build issues see comment 27. If non-PE build support is mandatory to you, please open a new bug. Regards. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #35 from pioruns2019(a)gmx.com --- Just tested in on wine-staging 5.13, everything works perfectly as before, thank you! -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #36 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 5.14. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 chris(a)novazur.fr changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris(a)novazur.fr --- Comment #37 from chris(a)novazur.fr --- (In reply to Alexandre Julliard from comment #36)
Closing bugs fixed in 5.14.
I don't understand. I have this bug with 5.11, 5.14, 5.16, 5.17 with World Of Warcraft under gentoo. Works with 5.10, but not with more recent version. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #38 from mboquien(a)free.fr --- (In reply to chris from comment #37)
I don't understand. I have this bug with 5.11, 5.14, 5.16, 5.17 with World Of Warcraft under gentoo. Works with 5.10, but not with more recent version.
You need a PE-build of wine. Compiling wine while having mingw-gcc installed should do the trick. At least it did for me with Arch. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #39 from chris(a)novazur.fr --- (In reply to mboquien from comment #38)
You need a PE-build of wine. Compiling wine while having mingw-gcc installed should do the trick. At least it did for me with Arch.
I'll try that. Thanks. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 --- Comment #40 from pioruns2019(a)gmx.com --- (In reply to chris from comment #37)
(In reply to Alexandre Julliard from comment #36)
Closing bugs fixed in 5.14.
I don't understand. I have this bug with 5.11, 5.14, 5.16, 5.17 with World Of Warcraft under gentoo. Works with 5.10, but not with more recent version.
I can confirm it works with 5.17. However, I use https://dl.winehq.org/wine-builds/debian repository on Debian Buster, not gentoo. No compilation required, just binary straight out of repo. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kolAflash(a)kolahilft.de --- Comment #41 from Olivier F. R. Dierick <o.dierick(a)piezo-forte.be> --- *** Bug 49798 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=49436 hash <HASH.DuOrden(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |HASH.DuOrden(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (1)
-
WineHQ Bugzilla