[Bug 45349] New: Multiple applications and games crash due to missing support for 64-bit syscall thunks (StreetFighter V)
https://bugs.winehq.org/show_bug.cgi?id=45349
Bug ID: 45349 Summary: Multiple applications and games crash due to missing support for 64-bit syscall thunks (StreetFighter V) Product: Wine Version: 3.10 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs@winehq.org Reporter: focht@gmx.net Distribution: ---
Hello folks,
had this one lying around for some time, sadly got distracted from further analysis (there are more bugs).
The game is "StreetFighter V Arcade Edition" and was gifted to me by Valve for investigation, thanks ;-)
https://store.steampowered.com/app/310950/Street_Fighter_V_Arcade_Edition/
It has some custom DRM/protection scheme which uses various 64-bit anti-debug and obfuscation techniques. There are a lot of single-step (TF) exceptions in the code which are there by design (decrypt continuations). At one point it crashes with invalid instruction exception:
--- snip --- ... 002e:trace:seh:NtRaiseException code=80000004 flags=0 addr=0x143fc99e9 ip=143fc99e9 tid=002e 002e:trace:seh:NtRaiseException rax=00000000006000aa rbx=000000000000005e rcx=000000000000005f rdx=000000000000071c 002e:trace:seh:NtRaiseException rsi=0000000143fcf826 rdi=0000000000000000 rbp=00000000005ffbd8 rsp=00000000005ffbd0 002e:trace:seh:NtRaiseException r8=0000000143fd2240 r9=000000000000000c r10=0000000143fd26f8 r11=0000000000000000 002e:trace:seh:NtRaiseException r12=000000000000005f r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 002e:trace:seh:RtlVirtualUnwind type 1 rip 143fc99e9 rsp 5ffbd0 002e:trace:seh:dump_unwind_info **** func 3fc9980-3fca910 002e:trace:seh:dump_unwind_info unwind info at 0x143fd26f0 flags 1 prolog 0x0 bytes function 0x143fc9980-0x143fca910 002e:trace:seh:dump_unwind_info handler 0x143fd2240 data at 0x143fd26f8 002e:trace:seh:call_handler calling handler 0x143fd2240 (rec=0x5ffa90, frame=0x5ffbd0 context=0x5fed30, dispatch=0x5ff200) 002e:trace:seh:call_handler handler at 0x143fd2240 returned 0 002e:trace:module:LdrGetDllHandle L"Kernel32.dll" -> 0x7b460000 (load path L"Z:\home\focht\Downloads;C:\windows\system32;C:\windows\system;C:\windows;.;C:\windows\system32;C:\windows;C:\windows\system32\wbem") 002e:trace:ntdll:NtQueryInformationProcess (0xffffffffffffffff,0x00000007,0x5ffcb0,0x00000008,0x5ffcb0) 002e: get_process_info( handle=ffffffff ) 002e: get_process_info() = 0 { pid=002d, ppid=0000, affinity=000000ff, peb=7fffffeaf000, start_time=1d3e17d69097156 (-0.0309210), end_time=0, exit_code=259, priority=2, cpu=x86_64, debugger_present=0, debug_children=1 } 002e:trace:module:LdrGetDllHandle L"Kernel32.dll" -> 0x7b460000 (load path L"Z:\home\focht\Downloads;C:\windows\system32;C:\windows\system;C:\windows;.;C:\windows\system32;C:\windows;C:\windows\system32\wbem") 002e:trace:seh:NtRaiseException code=c0000096 flags=0 addr=0x143fca968 ip=143fca968 tid=002e 002e:trace:seh:NtRaiseException rax=00000000564d5868 rbx=000000008685d465 rcx=000000000000000a rdx=0000000143fc5658 002e:trace:seh:NtRaiseException rsi=00000000005ffd58 rdi=0000000143fd3344 rbp=00000000005ffc18 rsp=00000000005ffc08 002e:trace:seh:NtRaiseException r8=0000000143fd26f8 r9=000000000000000c r10=0000000143fd26f8 r11=0000000000000000 002e:trace:seh:NtRaiseException r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 002e:trace:seh:RtlVirtualUnwind type 1 rip 143fca968 rsp 5ffc08 002e:trace:seh:dump_unwind_info **** func 3fca910-3fcfbbc 002e:trace:seh:dump_unwind_info unwind info at 0x143fd26f0 flags 1 prolog 0x0 bytes function 0x143fca910-0x143fcfbbc 002e:trace:seh:dump_unwind_info handler 0x143fcbbe8 data at 0x143fd26f8 002e:trace:seh:call_handler calling handler 0x143fcbbe8 (rec=0x5ffac0, frame=0x5ffc08 context=0x5fed60, dispatch=0x5ff230) 002e:trace:seh:call_handler handler at 0x143fcbbe8 returned 0 ... --- snip ---
One has to debug it to see the mess. For that you need to defeat a few anti-debug trickery ;-)
The game protection copies native API entry point code around and assumes 64-bit Windows API entries which have a distinct signature/sequence. A similar problem is described in bug 21232 which is about 32-bit syscall thunks.
Partial copy of 'ntdll.NtQueryInformationProcess' entry point:
--- snip --- 0000000143FCFA88 | 55 | push rbp 0000000143FCFA89 | 48 89 E5 | mov rbp, rsp 0000000143FCFA8C | 57 | push rdi 0000000143FCFA8D | 56 | push rsi 0000000143FCFA8E | 48 81 EC A0 00 00 00 | sub rsp, A0 0000000143FCFA95 | 48 83 E4 F0 | and rsp, FFFFFFFFFFFFFFF0 0000000143FCFA99 | 48 81 EC 40 03 00 00 | sub rsp, 340 0000000143FCFAA0 | 0F 11 B5 50 FF FF FF | movups xmmword ptr ss:[rbp - B0], xmm6 0000000143FCFAA7 | 0F C4 08 33 | pinsrw mm1, word ptr ds:[rax], 33 0000000143FCFAAB | C0 48 83 C4 | ror byte ptr ds:[rax - 7D], C4 0000000143FCFAAF | 28 C3 | sub bl, al 0000000143FCFAB1 | CC | int3 0000000143FCFAB2 | CC | int3 0000000143FCFAB3 | CC | int3 0000000143FCFAB4 | CC | int3 0000000143FCFAB5 | CC | int3 0000000143FCFAB6 | CC | int3 0000000143FCFAB7 | CC | int3 0000000143FCFAB8 | 48 89 5C 24 08 | mov qword ptr ss:[rsp + 8], rbx 0000000143FCFABD | 48 89 6C 24 10 | mov qword ptr ss:[rsp + 10], rbp 0000000143FCFAC2 | 48 89 74 24 18 | mov qword ptr ss:[rsp + 18], rsi 0000000143FCFAC7 | 57 | push rdi 0000000143FCFAC8 | 48 83 EC 30 | sub rsp, 30 0000000143FCFACC | 41 8B D9 | mov ebx, r9d 0000000143FCFACF | 49 8B F0 | mov rsi, r8 0000000143FCFAD2 | 8B EA | mov ebp, edx 0000000143FCFAD4 | 48 8B F9 | mov rdi, rcx 0000000143FCFAD7 | EB 02 | jmp streetfighterv.143FCFADB 0000000143FCFAD9 | 48 EB E8 | jmp streetfighterv.143FCFAC4 --- snip ---
This obviously can't work. On 64-bit Windows the native API entry code is much smaller (< 16 bytes). Due to partial opcode copy a fault is triggered when executing.
Original 64-bit Wine API entry code:
--- snip --- 000000007BCEF058 55 push rbp 000000007BCEF059 48 89 E5 mov rbp, rsp 000000007BCEF05C 57 push rdi 000000007BCEF05D 56 push rsi 000000007BCEF05E 48 81 EC A0 00 00 00 sub rsp, 0A0h 000000007BCEF065 48 83 E4 F0 and rsp, 0FFFFFFFFFFFFFFF0h 000000007BCEF069 48 81 EC 40 03 00 00 sub rsp, 340h 000000007BCEF070 0F 11 B5 50 FF FF FF movups [rbp+var_B0], xmm6 000000007BCEF077 0F 11 BD 60 FF FF FF movups [rbp+var_A0], xmm7 000000007BCEF07E 44 0F 11 85 70 FF FF FF movups [rbp+var_90], xmm8 000000007BCEF086 44 0F 11 4D 80 movups [rbp+var_80], xmm9 000000007BCEF08B 44 0F 11 55 90 movups [rbp+var_70], xmm10 000000007BCEF090 44 0F 11 5D A0 movups [rbp+var_60], xmm11 000000007BCEF095 44 0F 11 65 B0 movups [rbp+var_50], xmm12 000000007BCEF09A 44 0F 11 6D C0 movups [rbp+var_40], xmm13 000000007BCEF09F 44 0F 11 75 D0 movups [rbp+var_30], xmm14 000000007BCEF0A4 44 0F 11 7D E0 movups [rbp+var_20], xmm15 000000007BCEF0A9 48 89 4D 10 mov [rbp+ProcessHandle], rcx 000000007BCEF0AD 89 55 18 mov [rbp+ProcessInformationClass], edx 000000007BCEF0B0 4C 89 45 20 mov [rbp+ProcessInformation], r8 000000007BCEF0B4 44 89 4D 28 mov [rbp+ProcessInformationLength], r9d 000000007BCEF0B8 C7 84 24 3C 03 00 00 00+ mov dword ptr [rsp+3F0h+n+4], 0 000000007BCEF0C3 C7 84 24 38 03 00 00 00+ mov dword ptr [rsp+3F0h+n], 0 000000007BCEF0CE 48 B8 70 CA D9 7B 00 00+ mov rax, offset __wine_dbch_ntdll_6 ... --- snip ---
Wine-Staging patchset: https://github.com/wine-staging/wine-staging/tree/HEAD/patches/winebuild-Fak...
Relevant part: https://github.com/wine-staging/wine-staging/blob/HEAD/patches/winebuild-Fak... (+prerequisite).
Generated 64-bit thunks:
--- snip --- ... 0000000143FCFA88 | B8 70 00 00 00 | mov eax, 70 0000000143FCFA8D | 65 FF 14 25 00 01 00 00 | call qword ptr gs:[100] 0000000143FCFA95 | C3 | ret 0000000143FCFA96 | 00 00 | add byte ptr ds:[rax], al 0000000143FCFA98 | B8 71 00 00 00 | mov eax, 71 0000000143FCFA9D | 65 FF 14 25 00 01 00 00 | call qword ptr gs:[100] 0000000143FCFAA5 | C3 | ret ... --- snip ---
NOTE: I wanted to keep a separate ticket for 64-bit syscall thunks to track/validate it separately from 32-bit parts (bug 21232).
Regards
https://bugs.winehq.org/show_bug.cgi?id=45349
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/HEAD | |/patches/winebuild-Fake_Dll | |s Keywords| |obfuscation, win64 Status|NEW |STAGED
https://bugs.winehq.org/show_bug.cgi?id=45349
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.winehq.org/sho | |w_bug.cgi?id=21232
https://bugs.winehq.org/show_bug.cgi?id=45349
mirh mirh@protonmail.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh@protonmail.ch
https://bugs.winehq.org/show_bug.cgi?id=45349
Adam Bolte abolte@systemsaviour.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |abolte@systemsaviour.com
https://bugs.winehq.org/show_bug.cgi?id=45349
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12@gmail.com
--- Comment #1 from Zebediah Figura z.figura12@gmail.com --- Hi Anastasius,
Mind sharing a few more details? I've tried applying the Staging patches, but I seem to get a crash in the exact same place (with the exact same RIP, even). And yes, I've checked that the on-disk ntdll has the syscall thunks.
I'm also a little confused by your explanation. From the looks of things I'd expect a crash executing the copied entry point (e.g. at the PINSR or ROR instruction or the following INT3), which would then presumably take the form of a STATUS_ACCESS_VIOLATION or STATUS_BREAKPOINT, but the crash is a STATUS_PRIVILEGED_INSTRUCTION, several pages away from that address, and if I dump bytes around the faulty RIP I get this:
0: 4d 56 rex.WRB push %r14 2: bb 65 d4 85 86 mov $0x8685d465,%ebx 7: b9 0a 00 00 00 mov $0xa,%ecx c: 66 ba 58 56 mov $0x5658,%dx 10: ed in (%dx),%eax <- faulty instruction 11: 81 fb 68 58 4d 56 cmp $0x564d5868,%ebx 17: 75 00 jne 19 <foo+0x19> 19: 48 83 c4 10 add $0x10,%rsp 1d: 41 5f pop %r15 1f: 41 rex.B
which doesn't look like a corrupted ntdll entry point to me.
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #2 from Anastasius Focht focht@gmx.net --- Hello Zebediah,
I made trace logs some time ago and accidentally put the wrong snippet here (had multiple logs from different runs with patches applied).
The 64-bit syscall thunk one is this one here:
--- snip --- ... 0030:Call KERNEL32.GetModuleHandleA(143fd1b80 "Kernel32.dll") ret=143fd20a7 0030:Ret KERNEL32.GetModuleHandleA() retval=7b460000 ret=143fd20a7 0030:Call KERNEL32.GetProcAddress(7b460000,143fd2690 "VirtualFree") ret=143fd21ae 0030:Ret KERNEL32.GetProcAddress() retval=7b473eb8 ret=143fd21ae 0030:Call KERNEL32.VirtualFree(00610000,00000000,00008000) ret=143fd21d4 0030:Ret KERNEL32.VirtualFree() retval=00000001 ret=143fd21d4 0030:trace:seh:NtRaiseException code=c000001d flags=0 addr=0x143fcfaa8 ip=143fcfaa8 tid=0030 0030:trace:seh:NtRaiseException rax=0000000000000000 rbx=ffffffffffffffff rcx=00000001440efe20 rdx=00000000000900cc 0030:trace:seh:NtRaiseException rsi=000000000060fd88 rdi=000000000060fd00 rbp=000000000060fdc0 rsp=000000000060fc88 0030:trace:seh:NtRaiseException r8=000000000060fce0 r9=0000000000000008 r10=0000000000000000 r11=000000000060fce0 0030:trace:seh:NtRaiseException r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 0030:warn:seh:call_stack_handlers exception data not found in L"StreetFighterV.exe" 0030:warn:seh:call_stack_handlers exception data not found in L"StreetFighterV.exe" 0030:warn:seh:call_stack_handlers exception data not found in L"StreetFighterV.exe" 0030:warn:seh:call_stack_handlers exception data not found in L"StreetFighterV.exe" 0030:warn:seh:call_stack_handlers exception data not found in L"StreetFighterV.exe" ... 0030:trace:seh:dwarf_virtual_unwind next function rip=0000000000000000 0030:trace:seh:dwarf_virtual_unwind rax=0000000000000000 rbx=ffffffffffffffff rcx=00000001440efe20 rdx=00000000000900cc 0030:trace:seh:dwarf_virtual_unwind rsi=0000000000000000 rdi=0000000000000000 rbp=0000000000000000 rsp=000000000060ffe0 0030:trace:seh:dwarf_virtual_unwind r8=000000000060fce0 r9=0000000000000008 r10=0000000000000000 r11=000000000060fce0 0030:trace:seh:dwarf_virtual_unwind r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 0030:trace:seh:call_stack_handlers found wine frame 0x60fdf0 rsp 60ffe0 handler 0x7b5121f3 0030:trace:seh:call_teb_handler calling TEB handler 0x7b5121f3 (rec=0x60fb40, frame=0x60fdf0 context=0x60ede0, dispatch=0x60f2b0) wine: Unhandled illegal instruction at address 0x143fcfaa8 (thread 0030), starting debugger... 0030:trace:seh:start_debugger Starting debugger "winedbg --auto 47 28" 0030:trace:seh:call_teb_handler handler at 0x7b5121f3 returned 1 0030:warn:seh:call_stack_handlers exception data not found in L"StreetFighterV.exe" Unhandled exception: illegal instruction in 64-bit code (0x0000000143fcfaa8). winedbg: Internal crash at 0x7f9e448a6b09 --- snip ---
rip = 0x143fcfaa8 (compare with my disassembly from initial comment).
The disassembly snippet you posted in commment #1 which matches my initial trace log snippet is a harmless and gracefully handled VMWare backdoor check:
--- snip --- 0000000143FCA918 | 54 | push rsp 0000000143FCA919 | 50 | push rax 0000000143FCA91A | 51 | push rcx 0000000143FCA91B | 52 | push rdx 0000000143FCA91C | 53 | push rbx 0000000143FCA91D | 55 | push rbp 0000000143FCA91E | 56 | push rsi 0000000143FCA91F | 57 | push rdi 0000000143FCA920 | 41 50 | push r8 0000000143FCA922 | 41 51 | push r9 0000000143FCA924 | 41 52 | push r10 0000000143FCA926 | 41 53 | push r11 0000000143FCA928 | 41 54 | push r12 0000000143FCA92A | 41 55 | push r13 0000000143FCA92C | 41 56 | push r14 0000000143FCA92E | 41 57 | push r15 0000000143FCA930 | 48 8B EC | mov rbp, rsp 0000000143FCA933 | 51 | push rcx 0000000143FCA934 | E8 00 00 00 00 | call streetfighterv.143FCA939 0000000143FCA939 | 48 B9 8D FB A2 19.| mov rcx, 19A2FB8D 0000000143FCA943 | 48 01 0C 24 | add qword ptr ss:[rsp], rcx 0000000143FCA947 | 48 B9 55 FB A2 19.| mov rcx, 19A2FB55 0000000143FCA951 | 48 29 0C 24 | sub qword ptr ss:[rsp], rcx 0000000143FCA955 | B8 68 58 4D 56 | mov eax, 564D5868 0000000143FCA95A | BB 65 D4 85 86 | mov ebx, 8685D465 0000000143FCA95F | B9 0A 00 00 00 | mov ecx, A 0000000143FCA964 | 66 BA 58 56 | mov dx, 5658 0000000143FCA968 | ED | in eax, dx 0000000143FCA969 | 81 FB 68 58 4D 56 | cmp ebx, 564D5868 0000000143FCA96F | 75 00 | jne streetfighterv.143FCA971 0000000143FCA971 | 48 83 C4 10 | add rsp, 10 0000000143FCA975 | 41 5F | pop r15 0000000143FCA977 | 41 5E | pop r14 0000000143FCA979 | 41 5D | pop r13 0000000143FCA97B | 41 5C | pop r12 0000000143FCA97D | 41 5B | pop r11 0000000143FCA97F | 41 5A | pop r10 0000000143FCA981 | 41 59 | pop r9 0000000143FCA983 | 41 58 | pop r8 0000000143FCA985 | 5F | pop rdi 0000000143FCA986 | 5E | pop rsi 0000000143FCA987 | 5D | pop rbp 0000000143FCA988 | 5B | pop rbx 0000000143FCA989 | 5A | pop rdx 0000000143FCA98A | 59 | pop rcx 0000000143FCA98B | 58 | pop rax 0000000143FCA98C | 48 83 C4 08 | add rsp, 8 0000000143FCA990 | C3 | ret --- snip ---
One can find this sequence in various commercial protection/DRM systems as they try to figure out if they are running in a virtualized environment.
Regards
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #3 from Zebediah Figura z.figura12@gmail.com --- Right, okay, I see now. Sorry for the confusion.
Just to make sure I've got this right: after applying the patches I still get an immediate shutdown; and +relay gives me this:
87244.790:005b:005c:Call KERNEL32.GetSystemWindowsDirectoryA(0060fb10,00000104) ret=143fed2a9 87244.790:005b:005c:Ret KERNEL32.GetSystemWindowsDirectoryA() retval=0000000a ret=143fed2a9 87244.790:005b:005c:Call KERNEL32.GetModuleHandleA(143fef080 "ntdll.dll") ret=143fed30b 87244.790:005b:005c:Ret KERNEL32.GetModuleHandleA() retval=7bc40000 ret=143fed30b 87244.790:005b:005c:Call KERNEL32.CreateFileA(0060fb10 "C:\windows\system32\ntdll.dll",80000000,00000001,00000000,43005c00000003,6f006d00000000,00000000) ret=143fed343 87244.790:005b:005c:Ret KERNEL32.CreateFileA() retval=00000018 ret=143fed343 87244.790:005b:005c:Call KERNEL32.CreateFileMappingA(00000018,00000000,00000002,00000000,43005c00000000,00000000) ret=143fed37f 87244.790:005b:005c:Ret KERNEL32.CreateFileMappingA() retval=00000024 ret=143fed37f 87244.790:005b:005c:Call KERNEL32.MapViewOfFile(00000024,00000004,00000000,00000000,00000000) ret=143fed3b7 87244.790:005b:005c:Ret KERNEL32.MapViewOfFile() retval=00610000 ret=143fed3b7 87244.790:005b:005c:Call KERNEL32.UnmapViewOfFile(00610000) ret=143fed414 87244.790:005b:005c:Ret KERNEL32.UnmapViewOfFile() retval=00000001 ret=143fed414
followed by some teardown. So there's still some verification that we're failing (and trying to figure out what that verification is is quite difficult...)
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #4 from Anastasius Focht focht@gmx.net --- Hello Zebediah,
--- quote --- Just to make sure I've got this right: after applying the patches I still get an immediate shutdown; and +relay gives me this:
followed by some teardown. So there's still some verification that we're failing (and trying to figure out what that verification is is quite difficult...) --- quote ---
Yes, I've encountered that one too but was distracted by other things before I could provide a full analysis. Anyway, it's a separate issue. There are even more interesting issues present, one I suspect being potentially Linux kernel bug (only encountered during live debugging). But I didn't want to post half information without further proof.
Regards
https://bugs.winehq.org/show_bug.cgi?id=45349
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |45377
https://bugs.winehq.org/show_bug.cgi?id=45349
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|Multiple applications and |Multiple applications and |games crash due to missing |games crash due to missing |support for 64-bit syscall |support for 64-bit syscall |thunks (StreetFighter V) |thunks (StreetFighter V, | |World of Warcraft) CC| |zzhang@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=45349
alasky@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alasky@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=45349
Paul Gofman gofmanp@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gofmanp@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=45349
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset|https://github.com/wine-sta |https://github.com/wine-sta |ging/wine-staging/tree/HEAD |ging/wine-staging/tree/mast |/patches/winebuild-Fake_Dll |er/patches/winebuild-Fake_D |s |lls
https://bugs.winehq.org/show_bug.cgi?id=45349
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |loic.blot@unix-experience.f | |r
--- Comment #5 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- *** Bug 49565 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=45349
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |blue-t@web.de
--- Comment #6 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- *** Bug 49521 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=45349
Paul Gofman pgofman@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pgofman@codeweavers.com
--- Comment #7 from Paul Gofman pgofman@codeweavers.com --- This should now be "staged" again with d2d0366ce5df254957a96bb6b7eb02c1616dba1d
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #8 from Ker noa blue-t@web.de --- World of Warcraft Looks good to me, self compiled wine staging is back to the old days with just a few complaining lines about missing shader and texture stuff running the legacy renderer and some occasional ghost images. No longer crashes or stays black playing sound only.
https://bugs.winehq.org/show_bug.cgi?id=45349
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Staged patchset|https://github.com/wine-sta |https://github.com/wine-sta |ging/wine-staging/tree/mast |ging/wine-staging/tree/mast |er/patches/winebuild-Fake_D |er/patches/winebuild-pe_sys |lls |call_thunks
https://bugs.winehq.org/show_bug.cgi?id=45349
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |idarktemplar@mail.ru
--- Comment #9 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- *** Bug 49582 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #10 from i.Dark_Templar idarktemplar@mail.ru --- *** Bug 49582 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #11 from nerzhul loic.blot@unix-experience.fr --- when the new staging build will come ? next week ?
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #12 from Ker noa blue-t@web.de --- (In reply to nerzhul from comment #11)
when the new staging build will come ? next week ?
It is done already https://build.opensuse.org/package/show/Emulators:Wine:Debian/wine-staging Just wait a little bit until your distro packages get synced over
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #13 from i.Dark_Templar idarktemplar@mail.ru --- Not sure if it should be reported here or in bug 49582. I've built wine-staging 5.13 manually. It is possible that I did it somehow wrong, but it's unlikely. And wine-staging 5.13 still fails to launch Starcraft 2 for me, similar to wine-staging 5.12. I still have to fallback to wine-staging 5.11.
https://bugs.winehq.org/show_bug.cgi?id=45349
Robert Andersson roband@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |roband@pobox.com
--- Comment #14 from Robert Andersson roband@pobox.com --- World of Warcraft still crashes at startup using the 5.13 build from arch linux. Still have to revert to 5.11
https://bugs.winehq.org/show_bug.cgi?id=45349
Maciej Stanczew maciej.stanczew+b@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maciej.stanczew+b@gmail.com
--- Comment #15 from Maciej Stanczew maciej.stanczew+b@gmail.com --- (In reply to Robert Andersson from comment #14)
World of Warcraft still crashes at startup using the 5.13 build from arch linux. Still have to revert to 5.11
That's because Arch builds are non-PE. I have submitted a feature request to have the builds switched to PE: https://bugs.archlinux.org/task/67326 For now, you'll have to compile wine-staging yourself with added 'mingw-w64-gcc' dependency (or stay on 5.11).
(In reply to i.Dark_Templar from comment #13)
Not sure if it should be reported here or in bug 49582. I've built wine-staging 5.13 manually. It is possible that I did it somehow wrong, but it's unlikely. And wine-staging 5.13 still fails to launch Starcraft 2 for me, similar to wine-staging 5.12. I still have to fallback to wine-staging 5.11.
Did you build Wine with PE support? If yes, can you try to launch SC2 manually, with "wine SC2Switcher_x64.exe" from inside of "StarCraft II/Support64" directory? There may be a chance that you're seeing bug 49590.
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #16 from i.Dark_Templar idarktemplar@mail.ru --- (In reply to Maciej Stanczew from comment #15)
(In reply to i.Dark_Templar from comment #13)
Not sure if it should be reported here or in bug 49582. I've built wine-staging 5.13 manually. It is possible that I did it somehow wrong, but it's unlikely. And wine-staging 5.13 still fails to launch Starcraft 2 for me, similar to wine-staging 5.12. I still have to fallback to wine-staging 5.11.
Did you build Wine with PE support? If yes, can you try to launch SC2 manually, with "wine SC2Switcher_x64.exe" from inside of "StarCraft II/Support64" directory? There may be a chance that you're seeing bug 49590.
No. I'm using Gentoo, and official wine packages from Gentoo currently don't support mingw compiler. I think it means wine is built without PE support. At least currently present versions up to 5.12 don't. I'm not sure if Gentoo maintainers have any plans to support compiling wine with mingw, but I guess if they'd have such plans, they'd implement it by now, since wine 5.0 with this feature was released quite some time ago.
Wine staging 5.11 worked fine while it was compiled without mingw, i.e. without PE feature.
I've tried starting Starcraft II as described anyway, and got error similar to one described in bug 49582. Here's log with default debug settings:
002c:fixme:winediag:__wine_start_process Wine Staging 5.13 is a testing version containing experimental patches. 002c:fixme:winediag:__wine_start_process Please mention your exact version when filing bug reports on winehq.org. 0034:err:module:__wine_process_init L"C:\windows\system32\winemenubuilder.exe" not found 002c:err:wineboot:process_run_key Error running cmd L"C:\windows\system32\winemenubuilder.exe -a -r" (126). 00b0:fixme:ntdll:EtwEventRegister ({5eec90ab-c022-44b2-a5dd-fd716a222a15}, 000000014000107C, 0000000140024860, 0000000140024880) stub. 00b0:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 0000000140020520, 43) stub 00b0:fixme:shcore:SetCurrentProcessExplicitAppUserModelID L"BlizzardEntertainment.StarCraftII.StarCraftII": stub 00b8:fixme:ntdll:EtwEventRegister ({5eec90ab-c022-44b2-a5dd-fd716a222a15}, 00000001400D017C, 000000014387BAB0, 000000014387BAD0) stub. 00b8:fixme:ntdll:EtwEventSetInformation (deadbeef, 2, 000000014332C2A0, 43) stub 00c0:fixme:ver:GetCurrentPackageId (000000000962FE40 0000000000000000): stub 00b8:fixme:ntdll:NtQuerySystemInformation info_class SYSTEM_PERFORMANCE_INFORMATION 00b8:err:virtual:virtual_setup_exception stack overflow 1824 bytes in thread 00b8 addr 0x7bc81ee6 stack 0x9ef08e0 (0x9ef0000-0x9ef1000-0xa6f0000)
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #17 from Maciej Stanczew maciej.stanczew+b@gmail.com ---
I have submitted a feature request to have the builds switched to PE: https://bugs.archlinux.org/task/67326
There was already an earlier request, please track it instead: https://bugs.archlinux.org/task/67317
(In reply to i.Dark_Templar from comment #16)
No. I'm using Gentoo, and official wine packages from Gentoo currently don't support mingw compiler. I think it means wine is built without PE support. At least currently present versions up to 5.12 don't. I'm not sure if Gentoo maintainers have any plans to support compiling wine with mingw, but I guess if they'd have such plans, they'd implement it by now, since wine 5.0 with this feature was released quite some time ago.
I would suggest reaching out to the maintainers anyway, as up to this point PE vs non-PE didn't really matter in our use-case, but things have changed significantly in the last two Wine versions to warrant a reaction.
Wine staging 5.11 worked fine while it was compiled without mingw, i.e. without PE feature.
Yeah, that's because Staging 5.11 contained winebuild-Fake_Dlls, which is now replaced by PE ntdll + winebuild-pe_syscall_thunks.
00b8:err:virtual:virtual_setup_exception stack overflow 1824 bytes in thread 00b8 addr 0x7bc81ee6 stack 0x9ef08e0 (0x9ef0000-0x9ef1000-0xa6f0000)
Same on Arch with official non-PE package: 0170:err:virtual:virtual_setup_exception stack overflow 1824 bytes in thread 0170 addr 0x7bc7a99d stack 0x9dc08e0 (0x9dc0000-0x9dc1000-0xa5c0000)
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #18 from nerzhul loic.blot@unix-experience.fr --- hello, i confirm the archlinux build doesn't work currently
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #19 from i.Dark_Templar idarktemplar@mail.ru --- I've built mingw crosscompiler and wine-staging 5.13 with PE support, and I can confirm that wine-staging 5.13 in such configuration can launch Starcraft II for me.
https://bugs.winehq.org/show_bug.cgi?id=45349
Robert Andersson roband@pobox.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|roband@pobox.com |
https://bugs.winehq.org/show_bug.cgi?id=45349
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jeff@jeffreydvp.com
--- Comment #20 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- *** Bug 49605 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=45349
Justin King-Lacroix justin.kinglacroix@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |justin.kinglacroix@gmail.co | |m
--- Comment #21 from Justin King-Lacroix justin.kinglacroix@gmail.com --- Re comment #19: How did you build with PE support? (I'm on Debian.) Is it more than just having mingw-w64 installed?
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #22 from Justin King-Lacroix justin.kinglacroix@gmail.com --- Because if so, I built wine from HEAD with PE support, and SC2 has the same crash.
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #23 from i.Dark_Templar idarktemplar@mail.ru --- (In reply to Justin King-Lacroix from comment #21)
Re comment #19: How did you build with PE support? (I'm on Debian.) Is it more than just having mingw-w64 installed?
I built it on Gentoo. First I built via crossdev crosstoolchain for x86_64-w64-mingw32 and i686-w64-mingw32. For i686 toolchain I added '--enable-threads=posix --disable-sjlj-exceptions --with-dwarf2' configure options, for x86_64 toolchain I added only '--enable-threads=posix'. Not sure if it's relevant.
After building toolchain via crossdev I had following toolchain packages installed: cross-i686-w64-mingw32/binutils cross-i686-w64-mingw32/gcc cross-i686-w64-mingw32/mingw64-runtime cross-x86_64-w64-mingw32/binutils cross-x86_64-w64-mingw32/gcc cross-x86_64-w64-mingw32/mingw64-runtime
And I had following working crosscompilers since I'm building wine both 32bit and 64bit: i686-w64-mingw32-gcc i686-w64-mingw32-g++ x86_64-w64-mingw32-gcc x86_64-w64-mingw32-g++
After that I rebuilt both wine-vanilla-5.13 and wine-staging-5.13 adding '--with-mingw' configure option. wine without staging patchset is called wine-vanilla in Gentoo, btw. I also added two patches from bug #49590 and (unrelated) a rebased patch from bug #38166.
When wine is built with mingw support, different libraries are built. Instead of some '*.dll.so' libraries '*.dll' libraries would be built.
I might remember wrong, but I think when I built wine without mingw, I got api-ms-win-appmodel-identity-l1-1-0.dll.so, and with mingw I got only api-ms-win-appmodel-identity-l1-1-0.dll, for example. I might be wrong with this example, but if you compare wine libraries built with mingw support and without mingw support, you'll be able to find a lot of such libraries.
(In reply to Justin King-Lacroix from comment #22)
Because if so, I built wine from HEAD with PE support, and SC2 has the same crash.
There might be few issues: 1) Did you build wine with staging patchset or without one? I expect SC2 wouldn't work without staging patches yet. 2) Something might be broken in wine HEAD. I think it's unlikely, but it can be a case. In that case building release might help. 3) You might have built wine without using mingw. Explicitly adding '--with-mingw' option should force build system to use mingw crosscompilers or output an error during configure stage if crosstoolchain doesn't work properly or not detected. 4) If you have more than one wine package installed, ensure you're using correct one. 5) Crosscompilers might have been built differently. As I wrote earlier, I added '--enable-threads=posix' besides other options because it was required for building dxvk from source, which I'm using as well. It might have affected result, it might have not.
While writing this comment, I've launched blizzard app, updated SC2 and launched it successfully, so it doesn't look like crash might have been caused by an update to SC2.
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #24 from Justin King-Lacroix justin.kinglacroix@gmail.com --- Figured out that I _did_ have PE support on (--with-mingw FTW...).
Same crash.
Also tried 1) Did you build wine with staging patchset or without one? I expect SC2 wouldn't work without staging patches yet.
This was the next thing I tried -- only applied the winebuild-pe_syscall_thunks staging patch. Also no dice.
I'm building from wine.git commit b7e51a1653320d06a9c04f53d0d9e7eda577c31b, FWIW.
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #25 from Justin King-Lacroix justin.kinglacroix@gmail.com ---
- If you have more than one wine package installed, ensure you're using correct one.
Yep, made sure I removed any distro packages before I started for exactly this reason.
- Crosscompilers might have been built differently. As I wrote earlier, I added '--enable-threads=posix' besides other options because it was required for building dxvk from source, which I'm using as well. It might have affected result, it might have not.
Yep, did exactly this for the same reason.
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #26 from Justin King-Lacroix justin.kinglacroix@gmail.com ---
- Something might be broken in wine HEAD. I think it's unlikely, but it can be a case. In that case building release might help.
Good idea. I will attempt this tonight.
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #27 from i.Dark_Templar idarktemplar@mail.ru --- (In reply to Justin King-Lacroix from comment #24)
Figured out that I _did_ have PE support on (--with-mingw FTW...).
Same crash.
Also tried 1) Did you build wine with staging patchset or without one? I expect SC2 wouldn't work without staging patches yet.
This was the next thing I tried -- only applied the winebuild-pe_syscall_thunks staging patch. Also no dice.
I'm building from wine.git commit b7e51a1653320d06a9c04f53d0d9e7eda577c31b, FWIW.
(In reply to Justin King-Lacroix from comment #26)
- Something might be broken in wine HEAD. I think it's unlikely, but it can be a case. In that case building release might help.
Good idea. I will attempt this tonight.
No, I think what you wrote above might be the cause. Try building wine with full staging patchset, not just with some cherry-picked patches. And try building it from release tag for version 5.13 as well.
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #28 from Justin King-Lacroix justin.kinglacroix@gmail.com --- (In reply to i.Dark_Templar from comment #27)
(In reply to Justin King-Lacroix from comment #24)
Figured out that I _did_ have PE support on (--with-mingw FTW...).
Same crash.
Also tried 1) Did you build wine with staging patchset or without one? I expect SC2 wouldn't work without staging patches yet.
This was the next thing I tried -- only applied the winebuild-pe_syscall_thunks staging patch. Also no dice.
I'm building from wine.git commit b7e51a1653320d06a9c04f53d0d9e7eda577c31b, FWIW.
(In reply to Justin King-Lacroix from comment #26)
- Something might be broken in wine HEAD. I think it's unlikely, but it can be a case. In that case building release might help.
Good idea. I will attempt this tonight.
No, I think what you wrote above might be the cause. Try building wine with full staging patchset, not just with some cherry-picked patches. And try building it from release tag for version 5.13 as well.
Built from wine-5.13 tag, with staging patches tagged v5.13. Still no dice. Though at least an error dialog shows up this time: "An error occurred starting Starcraft II. Please try again. Error (2:0)."
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #29 from Justin King-Lacroix justin.kinglacroix@gmail.com --- (In reply to Justin King-Lacroix from comment #28)
(In reply to i.Dark_Templar from comment #27)
(In reply to Justin King-Lacroix from comment #24)
Figured out that I _did_ have PE support on (--with-mingw FTW...).
Same crash.
Also tried 1) Did you build wine with staging patchset or without one? I expect SC2 wouldn't work without staging patches yet.
This was the next thing I tried -- only applied the winebuild-pe_syscall_thunks staging patch. Also no dice.
I'm building from wine.git commit b7e51a1653320d06a9c04f53d0d9e7eda577c31b, FWIW.
(In reply to Justin King-Lacroix from comment #26)
- Something might be broken in wine HEAD. I think it's unlikely, but it can be a case. In that case building release might help.
Good idea. I will attempt this tonight.
No, I think what you wrote above might be the cause. Try building wine with full staging patchset, not just with some cherry-picked patches. And try building it from release tag for version 5.13 as well.
Built from wine-5.13 tag, with staging patches tagged v5.13. Still no dice. Though at least an error dialog shows up this time: "An error occurred starting Starcraft II. Please try again. Error (2:0)."
HOORAY! IT WORKED!
Built from wine-5.13 tag, with staging patches tagged v5.13. And also against vkd3d at HEAD. Now it works. (Although Battle.net.exe now locks up on exit. That's... somewhat unfortunate.)
https://bugs.winehq.org/show_bug.cgi?id=45349
Zhiyi Zhang zzhang@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|zzhang@codeweavers.com |
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #30 from i.Dark_Templar idarktemplar@mail.ru --- (In reply to Justin King-Lacroix from comment #29)
HOORAY! IT WORKED!
Built from wine-5.13 tag, with staging patches tagged v5.13. And also against vkd3d at HEAD. Now it works. (Although Battle.net.exe now locks up on exit. That's... somewhat unfortunate.)
Try adding 2 patches from bug #49590 too, this fixes Battle.net app issues for me.
https://bugs.winehq.org/show_bug.cgi?id=45349
Filippe LeMarchand gasinvein@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |gasinvein@gmail.com
--- Comment #31 from Filippe LeMarchand gasinvein@gmail.com --- This issue still occurs for me with the winebuild-pe_syscall_thunks patchset, but doesn't occur with all staging patches. Looks like some other patchset is also needed?
https://bugs.winehq.org/show_bug.cgi?id=45349
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |o.dierick@piezo-forte.be
--- Comment #32 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Filippe LeMarchand from comment #31)
This issue still occurs for me with the winebuild-pe_syscall_thunks patchset, but doesn't occur with all staging patches. Looks like some other patchset is also needed?
Hello,
That depends on the application. Most Blizzard applications depends on other patchsets to run, for example.
This bug affects multiple applications so it's not a good place to keep track of all the patchs needed for one application.
You can check the bug list in the AppDB entry of the application or search this bugzilla for bugs containing the name of the application in the comments or summary.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #33 from Justin King-Lacroix justin.kinglacroix@gmail.com --- (In reply to i.Dark_Templar from comment #30)
(In reply to Justin King-Lacroix from comment #29)
HOORAY! IT WORKED!
Built from wine-5.13 tag, with staging patches tagged v5.13. And also against vkd3d at HEAD. Now it works. (Although Battle.net.exe now locks up on exit. That's... somewhat unfortunate.)
Try adding 2 patches from bug #49590 too, this fixes Battle.net app issues for me.
The " 2 patches from bug #49590 " amount to reverting the "ntdll-Heap_Improvements" patchset from 5.13-staging.
I agree that this also fixed the issue for me.
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #34 from Filippe LeMarchand gasinvein@gmail.com --- (In reply to Olivier F. R. Dierick from comment #32)
(In reply to Filippe LeMarchand from comment #31)
This issue still occurs for me with the winebuild-pe_syscall_thunks patchset, but doesn't occur with all staging patches. Looks like some other patchset is also needed?
Hello,
That depends on the application. Most Blizzard applications depends on other patchsets to run, for example.
This bug affects multiple applications so it's not a good place to keep track of all the patchs needed for one application.
You can check the bug list in the AppDB entry of the application or search this bugzilla for bugs containing the name of the application in the comments or summary.
Regards.
I was talking about StarCraft II, sorry, should mention it. I didn't find any other issues preventing it from starting except for this one.
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #35 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- (In reply to Filippe LeMarchand from comment #34)
I was talking about StarCraft II, sorry, should mention it. I didn't find any other issues preventing it from starting except for this one.
Hello,
I guess that Starcraft II is affected by a bug that is not known to affect it.
If someone owning the game has time and motive, he could do a subtractive bisect of wine-staging to identify the minimal set of patchsets that are required for the application.
Once the minimal set is known, he could find the bugs that have those patchset in the staged field and add them on the AppDB bug list, and add a comment in the bugs stating that they affect the application, as well.
Regards.
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #36 from Maciej Stanczew maciej.stanczew+b@gmail.com --- (In reply to Olivier F. R. Dierick from comment #35)
If someone owning the game has time and motive, he could do a subtractive bisect of wine-staging to identify the minimal set of patchsets that are required for the application.
Well, I compiled PE Wine 5.14 with just 'winebuild-pe_syscall_thunks', and I'm able to successfully launch Starcraft II, Starcraft: Remastered, and Heroes of the Storm.
With Diablo III there is a D3D11 initialization error (bug 42191). Adding 'd3d11-Deferred_Context' helps a bit -- the game launches, but with a black screen. This is also the behavior with all staging patches, and seems to be a regression from previous behavior (graphics working, but with 1-2 fps). With DXVK the game works correctly and with good performance.
For Warcraft III, with just 'winebuild-pe_syscall_thunks' the game launches, but gets stuck on loading screen, and 'BlizzardBrowser.exe' crashes appear repeatedly. Adding 'd3d11-Deferred_Context' doesn't change this behavior. With all staging patches the game continues to the login screen, but login input form is missing (and 'BlizzardBrowser.exe' is still crashing). Installing DXVK helps also in this case -- login form is shown and 'BlizzardBrowser.exe' doesn't crash.
I did not verify World of Warcraft and Overwatch.
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #37 from Justin King-Lacroix justin.kinglacroix@gmail.com --- (In reply to Maciej Stanczew from comment #36)
(In reply to Olivier F. R. Dierick from comment #35)
If someone owning the game has time and motive, he could do a subtractive bisect of wine-staging to identify the minimal set of patchsets that are required for the application.
Well, I compiled PE Wine 5.14 with just 'winebuild-pe_syscall_thunks', and I'm able to successfully launch Starcraft II, Starcraft: Remastered, and Heroes of the Storm.
With Diablo III there is a D3D11 initialization error (bug 42191). Adding 'd3d11-Deferred_Context' helps a bit -- the game launches, but with a black screen. This is also the behavior with all staging patches, and seems to be a regression from previous behavior (graphics working, but with 1-2 fps). With DXVK the game works correctly and with good performance.
For Warcraft III, with just 'winebuild-pe_syscall_thunks' the game launches, but gets stuck on loading screen, and 'BlizzardBrowser.exe' crashes appear repeatedly. Adding 'd3d11-Deferred_Context' doesn't change this behavior. With all staging patches the game continues to the login screen, but login input form is missing (and 'BlizzardBrowser.exe' is still crashing). Installing DXVK helps also in this case -- login form is shown and 'BlizzardBrowser.exe' doesn't crash.
I did not verify World of Warcraft and Overwatch.
Same for me.
* Starcraft II on Wine 5.14: 64-bit version still fails to load. * Starcraft II on Wine 5.14 + Staging v5.14 (all patches): no crashes at all; everything seems to work perfectly. * Starcraft II on Wine 5.14 + Staging v5.14 (winebuild-pe_syscall_thunks only): no crashes at all; everything seems to work perfectly.
All of the above builds were:
* Without DXVK. * Against vkd3d a1778b681edf13b8cdb31eb90190a36a23c946f9 (both 32 and 64-bit) * With PE support. * With a WINE prefix containing only Starcraft II and the Battle.net client. * The only winetricks scripts that were run were corefonts and win10.
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #38 from Filippe LeMarchand gasinvein@gmail.com --- winebuild-pe_syscall_thunks patchset alone actually works for me with a clean wineprefix. Seems like my prefix for battle.net games got broken for some reason. Sorry for disturbing.
https://bugs.winehq.org/show_bug.cgi?id=45349
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |govershay@gmail.com
--- Comment #39 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- *** Bug 49741 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=45349
Yonseca yonseca@posteo.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |yonseca@posteo.net
https://bugs.winehq.org/show_bug.cgi?id=45349
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kolAflash@kolahilft.de
--- Comment #40 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- *** Bug 49798 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=45349
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |RESOLVED Fixed by SHA1| |917a206b01c82170a862e8497cb | |e26b6f1bfade0 Resolution|--- |FIXED
--- Comment #41 from Zebediah Figura z.figura12@gmail.com --- 64-bit syscall thunks were implemented upstream in https://source.winehq.org/git/wine.git/commitdiff/917a206b01c82170a862e8497cbe26b6f1bfade0, although many applications here require later committed patches to work. In any case the bug as given is now fixed; please file new bugs for further issues with any of the affected games.
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #42 from Justin King-Lacroix justin.kinglacroix@gmail.com --- Nice! Do you happen to remember what version of WINE https://source.winehq.org/git/wine.git/commitdiff/917a206b01c82170a862e8497c... was released in?
https://bugs.winehq.org/show_bug.cgi?id=45349
--- Comment #43 from Zebediah Figura z.figura12@gmail.com --- (In reply to Justin King-Lacroix from comment #42)
Nice! Do you happen to remember what version of WINE https://source.winehq.org/git/wine.git/commitdiff/ 917a206b01c82170a862e8497cbe26b6f1bfade0 was released in?
The patch itself was committed as part of wine 5.13. However, equivalent functionality to what the linked Staging patch provided was not implemented until wine 5.14 or so. (In particular, while some functions used syscall thunks before 917a206b01c, the majority did not, and were gradually converted until 57f419993 [with a couple stragglers including 54c31d533].)
https://bugs.winehq.org/show_bug.cgi?id=45349
Olivier F. R. Dierick o.dierick@piezo-forte.be changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |katharine.chui@gmail.com
--- Comment #44 from Olivier F. R. Dierick o.dierick@piezo-forte.be --- *** Bug 49567 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=45349
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #45 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 5.21.
https://bugs.winehq.org/show_bug.cgi?id=45349
hash HASH.DuOrden@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |HASH.DuOrden@gmail.com
-
wine-bugs＠winehq.org -
WineHQ Bugzilla