https://bugs.winehq.org/show_bug.cgi?id=39454
Bug ID: 39454 Summary: StarCraft II v3.0 crashes immediately on startup Product: Wine Version: 1.7.52 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: winehq@iooioio.orion.uberspace.de Distribution: ---
Created attachment 52568 --> https://bugs.winehq.org/attachment.cgi?id=52568 Console output on starting the game
Since the recent StarCraft II update (I'm on 3.0.1.38215, but probably anything
3.0 is affected) the game has stopped working via Wine.
I have attached some output. Everything up to line 148 is simply starting the Battle.net client. The output that follows is the result of clicking the play button.
My specs:
Wine 1.7.52 (64bit) Linux Mint 17.2 (3.19.0-26-generic) Proprietary nVIDIA drivers (352.30)
https://bugs.winehq.org/show_bug.cgi?id=39454
Josh winehq@iooioio.orion.uberspace.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |winehq@iooioio.orion.ubersp | |ace.de Hardware|x86 |x86-64
https://bugs.winehq.org/show_bug.cgi?id=39454
--- Comment #1 from lahmbi5675@gmx.de --- Someone in the winehq user forum with a very similar issue mentioned, that switching to 32 bit color depth in the battle.net options might help. I don't have battle.net installed under linux, so I can't try at the moment.
https://bugs.winehq.org/show_bug.cgi?id=39454
--- Comment #2 from Josh winehq@iooioio.orion.uberspace.de --- Thanks for pointing that out. I can confirm that switching to a 32bit executable (nothing to do with color) from the battle.net client got me all the way to the main menu. I can't do any further testing right now though so not sure how useful this workaround actually is.
https://bugs.winehq.org/show_bug.cgi?id=39454
K1773R K1773R@darkgamex.ch changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |K1773R@darkgamex.ch
https://bugs.winehq.org/show_bug.cgi?id=39454
hekark@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hekark@gmail.com
--- Comment #3 from hekark@gmail.com --- Have the same issue with the 64bit client. The game crashes on startup.
Switching to 32bit client allows the game to start, but it suffers from issue: https://bugs.winehq.org/show_bug.cgi?id=33802, where the game is unplayable due to missing textures.
Wine 1.7.52 (64bit) Fedora 22 (4.0.4-301.fc22.x86_64) Intel HD Graphics Starcraft 3.0.2.38624
https://bugs.winehq.org/show_bug.cgi?id=39454
foxxyz+bugzilla@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |foxxyz+bugzilla@gmail.com
--- Comment #4 from foxxyz+bugzilla@gmail.com --- Created attachment 52693 --> https://bugs.winehq.org/attachment.cgi?id=52693 output log
https://bugs.winehq.org/show_bug.cgi?id=39454
--- Comment #5 from foxxyz+bugzilla@gmail.com --- Confirmed on Arch Linux. Instant crash on 64-bit client, on 32-bit client Wine complains about graphics drivers.
Relevant part of output (after clicking "Play" and subsequent crash) attached.
Linux 4.2.5-1-ARCH Wine 1.7.54 (64bit) Starcraft II 3.0.3.38749
https://bugs.winehq.org/show_bug.cgi?id=39454
Alonso alonso.javier.torres@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alonso.javier.torres@gmail. | |com
--- Comment #6 from Alonso alonso.javier.torres@gmail.com --- (In reply to lahmbi5675 from comment #1)
Someone in the winehq user forum with a very similar issue mentioned, that switching to 32 bit color depth in the battle.net options might help. I don't have battle.net installed under linux, so I can't try at the moment.
It's true. I had this problem but with the Battle.net launcher, go to settings and then check the "Launch 32-bit client (instead of 64-bit)." option.
Now the game starts
https://bugs.winehq.org/show_bug.cgi?id=39454
Ivan Set s.i.v.892@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |s.i.v.892@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=39454
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Summary|StarCraft II v3.0 crashes |StarCraft II v3.0 64-bit |immediately on startup |client crashes immediately | |on startup Ever confirmed|0 |1
--- Comment #7 from Matteo Bruni matteo.mystral@gmail.com --- Let's make this bug specifically about the 64-bit client crash.
If someone has issues with the 32-bit client, please open a separate bug (after checking that there isn't a bug report already for it.)
https://bugs.winehq.org/show_bug.cgi?id=39454
John Schoenick john@pointysoftware.net changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |john@pointysoftware.net
https://bugs.winehq.org/show_bug.cgi?id=39454
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download, obfuscation URL| |http://eu.blizzard.com/en-g | |b/games/sc2/ CC| |focht@gmx.net Component|-unknown |ntdll Summary|StarCraft II v3.0 64-bit |64-bit StarCraft II v3.0 |client crashes immediately |client crashes immediately |on startup |on startup | |(SetThreadContext on self | |with only DRx | |registers/CONTEXT_DEBUG_REG | |ISTERS provided)
--- Comment #8 from Anastasius Focht focht@gmx.net --- Hello folks,
confirming.
--- snip --- $ pwd /home/focht/wine-games/wineprefix-battlenet/drive_c/Program Files (x86)/StarCraft II/Support64
$ WINEDEBUG=+tid,+seh,+relay,+server wine ./SC2Switcher_x64.exe >>log.txt 2>&1 ... 0024:Call KERNEL32.CreateProcessW(0022b360 L"C:\Program Files (x86)\StarCraft II\Versions\Base38996\SC2_x64.exe",0022b780 L""C:\Program Files (x86)\StarCraft II\Versions\Base38996\SC2_x64.exe"",00000000,00000000,00000000,00000000,00000000,0022b570 L"C:\Program Files (x86)\StarCraft II\Support64",0022b2f0,0022b2d0) ret=140002def ... 0024: new_process() = 0 { info=0054, pid=0029, phandle=0058, tid=002a, thandle=005c } ... 0024:Ret KERNEL32.CreateProcessW() retval=00000001 ret=140002def ... 002a:Call KERNEL32.SetUnhandledExceptionFilter(14002b3d0) ret=14002b5aa 002a:Ret KERNEL32.SetUnhandledExceptionFilter() retval=1414c4f8c ret=14002b5aa 002a:Call KERNEL32.GetModuleHandleW(141ac1158 L"kernel32.dll") ret=14002b4e1 002a:Ret KERNEL32.GetModuleHandleW() retval=7b860000 ret=14002b4e1 002a:Call KERNEL32.GetProcAddress(7b860000,141ac4f60 "SetUnhandledExceptionFilter") ret=14002b4fb 002e: *fd* 15 <- 32 002a:Ret KERNEL32.GetProcAddress() retval=7b86edbc ret=14002b4fb 002a:Call KERNEL32.WriteProcessMemory(ffffffffffffffff,7b86edbc,0023fa10,0000000c,00000000) ret=14002b543 002e: *fd* 17 <- 33 002a: write_process_memory( handle=ffffffff, addr=7b86edbc, data={48,b8,c0,b4,02,40,01,00,00,00,ff,e0} ) 002a: *signal* signal=19 002a: write_process_memory() = 0 002a:Ret KERNEL32.WriteProcessMemory() retval=00000001 ret=14002b543 ... 002a:Call KERNEL32.LoadLibraryW(03819460 L"Battle.net-64.dll") ret=141603362 ... 002a:Ret PE DLL (proc=0x3cd0a8c0,module=0x3c910000 L"Battle.net-64.dll",reason=PROCESS_ATTACH,res=(nil)) retval=1 002a:Ret KERNEL32.LoadLibraryW() retval=3c910000 ret=141603362 002a:Call msvcr100.memset(03819680,00000000,00000024) ret=140007960 002a:Ret msvcr100.memset() retval=03819680 ret=140007960 002a:Call KERNEL32.GetProcAddress(3c910000,00000001) ret=1415ffb86 002a:Ret KERNEL32.GetProcAddress() retval=3c9868b0 ret=1415ffb86 002a:Call KERNEL32.GetProcAddress(3c910000,00000002) ret=1415ffba4 002a:Ret KERNEL32.GetProcAddress() retval=3c9869e0 ret=1415ffba4 002a:Call KERNEL32.GetProcAddress(3c910000,00000003) ret=1415ffbc2 002a:Ret KERNEL32.GetProcAddress() retval=3c986ad0 ret=1415ffbc2 002a:Call KERNEL32.GetProcAddress(3c910000,00000004) ret=1415ffbe0 002a:Ret KERNEL32.GetProcAddress() retval=3c9868d0 ret=1415ffbe0 002a:Call KERNEL32.IsDebuggerPresent() ret=3ccae65a 002a:Ret KERNEL32.IsDebuggerPresent() retval=00000000 ret=3ccae65a 002a:Call KERNEL32.IsDebuggerPresent() ret=3d18c4a6 002a:Ret KERNEL32.IsDebuggerPresent() retval=00000000 ret=3d18c4a6 002a:Call KERNEL32.SetThreadContext(fffffffffffffffe,01f294e0) ret=3ca7254b 002a: set_thread_context( handle=fffffffe, suspend=1, context={cpu=x86_64,dr0=3c9abbc0,dr1=3ca94610,dr2=3ca2e920,dr3=3ca2ec00,dr6=00000000,dr7=00000155} ) 002a: *signal* signal=19 002a: set_thread_context() = 0 { self=1 } 002a:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7ffb838f848b ip=7ffb838f848b tid=002a 002a:trace:seh:raise_exception rax=00007fffff7e8000 rbx=0000000000015160 rcx=00007ffb83b82d16 rdx=00000000000178e8 002a:trace:seh:raise_exception rsi=72745365646f6369 rdi=0000000000000000 rbp=6e55406e65657774 rsp=0000000001f28c70 002a:trace:seh:raise_exception r8=0000000000000000 r9=00320035006e0069 r10=006c006c0064002e r11=0000000000000000 002a:trace:seh:raise_exception r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 002a:trace:seh:call_vectored_handlers calling handler at 0x3ca730d0 code=c0000005 flags=0 002a:trace:seh:call_vectored_handlers handler at 0x3ca730d0 returned 0 002a:trace:seh:dwarf_virtual_unwind function 7ffb838f848b base 0x7ffb838f835c cie 0x7ffb83948dd8 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip 002a:trace:seh:execute_cfa_instructions 7ffb838f835c: DW_CFA_def_cfa %rsp, 8 002a:trace:seh:execute_cfa_instructions 7ffb838f835c: DW_CFA_offset %rip, -8 002a:trace:seh:dwarf_virtual_unwind fde 0x7ffb8395d7b8 len 14 personality (nil) lsda (nil) code 7ffb838f835c-7ffb838f848d 002a:trace:seh:execute_cfa_instructions 7ffb838f835c: DW_CFA_advance_loc 4 002a:trace:seh:execute_cfa_instructions 7ffb838f8360: DW_CFA_def_cfa_offset 48 002a:trace:seh:dwarf_virtual_unwind next function rip=00007ffb8390cfad 002a:trace:seh:dwarf_virtual_unwind rax=00007fffff7e8000 rbx=0000000000015160 rcx=00007ffb83b82d16 rdx=00000000000178e8 002a:trace:seh:dwarf_virtual_unwind rsi=72745365646f6369 rdi=0000000000000000 rbp=6e55406e65657774 rsp=0000000001f28ca0 002a:trace:seh:dwarf_virtual_unwind r8=0000000000000000 r9=00320035006e0069 r10=006c006c0064002e r11=0000000000000000 002a:trace:seh:dwarf_virtual_unwind r12=0000000000000000 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 002a:trace:seh:dwarf_virtual_unwind function 7ffb8390cfad base 0x7ffb8390cce3 cie 0x7ffb83948dd8 len 14 id 0 version 1 aug 'zR' code_align 1 data_align -8 retaddr %rip 002a:trace:seh:execute_cfa_instructions 7ffb8390cce3: DW_CFA_def_cfa %rsp, 8 002a:trace:seh:execute_cfa_instructions 7ffb8390cce3: DW_CFA_offset %rip, -8 002a:trace:seh:dwarf_virtual_unwind fde 0x7ffb83960bc0 len 4c personality (nil) lsda (nil) code 7ffb8390cce3-7ffb8390cff6 002a:trace:seh:execute_cfa_instructions 7ffb8390cce3: DW_CFA_advance_loc 1 002a:trace:seh:execute_cfa_instructions 7ffb8390cce4: DW_CFA_def_cfa_offset 16 002a:trace:seh:execute_cfa_instructions 7ffb8390cce4: DW_CFA_offset %rbp, -16 002a:trace:seh:execute_cfa_instructions 7ffb8390cce4: DW_CFA_advance_loc 3 002a:trace:seh:execute_cfa_instructions 7ffb8390cce7: DW_CFA_def_cfa_register %rbp 002a:trace:seh:execute_cfa_instructions 7ffb8390cce7: DW_CFA_advance_loc1 66 002a:trace:seh:execute_cfa_instructions 7ffb8390cd29: DW_CFA_offset %rdi, -24 002a:trace:seh:execute_cfa_instructions 7ffb8390cd29: DW_CFA_offset %rsi, -32 002a:trace:seh:execute_cfa_instructions 7ffb8390cd29: DW_CFA_offset %xmm6, -192 002a:trace:seh:execute_cfa_instructions 7ffb8390cd29: DW_CFA_offset %xmm7, -176 002a:trace:seh:execute_cfa_instructions 7ffb8390cd29: DW_CFA_offset %xmm8, -160 002a:trace:seh:execute_cfa_instructions 7ffb8390cd29: DW_CFA_offset %xmm9, -144 002a:trace:seh:execute_cfa_instructions 7ffb8390cd29: DW_CFA_offset %xmm10, -128 002a:trace:seh:execute_cfa_instructions 7ffb8390cd29: DW_CFA_offset %xmm11, -112 002a:trace:seh:execute_cfa_instructions 7ffb8390cd29: DW_CFA_offset %xmm12, -96 002a:trace:seh:execute_cfa_instructions 7ffb8390cd29: DW_CFA_offset %xmm13, -80 002a:trace:seh:execute_cfa_instructions 7ffb8390cd29: DW_CFA_offset %xmm14, -64 002a:trace:seh:execute_cfa_instructions 7ffb8390cd29: DW_CFA_offset %xmm15, -48 002a:trace:seh:execute_cfa_instructions 7ffb8390cd29: DW_CFA_advance_loc2 713 002a:trace:seh:raise_exception code=c0000005 flags=0 addr=0x7ffb838f5f2b ip=7ffb838f5f2b tid=002a 002a:trace:seh:raise_exception rax=6e55406e65657764 rbx=00007ffb8390cce3 rcx=0000000000000004 rdx=0000000000000020 002a:trace:seh:raise_exception rsi=0000000000000004 rdi=0000000001f250e0 rbp=0000000001f250c0 rsp=0000000001f250c0 002a:trace:seh:raise_exception r8=00000000000002c9 r9=0000000000000000 r10=00007ffb83bc3d13 r11=000000317b38dad0 002a:trace:seh:raise_exception r12=00007ffb83948de1 r13=0000000000000000 r14=0000000000000000 r15=0000000000000000 002a:trace:seh:call_vectored_handlers calling handler at 0x3ca730d0 code=c0000005 flags=0 002a:trace:seh:call_vectored_handlers handler at 0x3ca730d0 returned 0 --- snip ---
'Battle.net-64.dll' contains lots of obfuscated code (already from entry point). The dll employs some anti-debugging/reversing mechanisms, probably an attempt to thwart hacking game/protocol/client ;-)
Consuming of four hardware breakpoints using 'KERNEL32.SetThreadContext()' seems part of it (single step trap caught/handled with SEH).
--- snip --- Wine-dbg>bt
Backtrace: =>0 0x000000007b8e9eeb SetThreadContext+0x10(handle=0xfffffffffffffffe, context=0x1f29740) [/home/focht/projects/wine/wine.repo/src/dlls/kernel32/thread.c:220] in kernel32 (0x0000000001f296e0) 1 0x000000003ca7254b in battle.net-64 (+0x16254a) (0x0000000001f29f70) 2 0x000000003ca73065 in battle.net-64 (+0x163064) (0x0000000001f29f70) 3 0x000000003c9868be in battle.net-64 (+0x768bd) (0x0000000001f29f70) 4 0x00000001415ffbf2 in sc2_x64 (+0x15ffbf1) (0x0000000001f29f70) 5 0x000000014160031e in sc2_x64 (+0x160031d) (0x0000000001f29f70) 6 0x00000001415ecc89 in sc2_x64 (+0x15ecc88) (0x0000000001f29f70) 7 0x0000000140896476 in sc2_x64 (+0x896475) (0x0000000001f29f70) 8 0x0000000140897367 in sc2_x64 (+0x897366) (0x0000000001f29f70) 9 0x00000001400aa3ab in sc2_x64 (+0xaa3aa) (0x0000000001f29f70) 10 0x00000001400a6229 in sc2_x64 (+0xa6228) (0x0000000001f2b140) 11 0x00000001400a8a74 in sc2_x64 (+0xa8a73) (0x0000000001f2b3d0) 12 0x000000014000204b in sc2_x64 (+0x204a) (0x0000000001f2f2f0) 13 0x00000001400023b8 in sc2_x64 (+0x23b7) (0x0000000001f2f410) 14 0x0000000140002405 in sc2_x64 (+0x2404) (0x0000000001f2fff0) 15 0x000000007b88e953 start_fiber+0x57(arg=0x5e860) [/home/focht/projects/wine/wine.repo/src/dlls/kernel32/fiber.c:65] in kernel32 (0x0000000001f2fff0) 16 0x00007f0aede76e7b wine_call_on_stack+0x12() in libwine.so.1 (0x000000000023fa80)
Wine-dbg>p *context {P1Home=0, P2Home=0, P3Home=0, P4Home=0, P5Home=0, P6Home=0, ContextFlags=0x100010, MxCsr=0, SegCs=0, SegDs=0, SegEs=0, SegFs=0, SegGs=0, SegSs=0, EFlags=0, Dr0=0x3c9abbc0, Dr1=0x3ca94610, Dr2=0x3ca2e920, Dr3=0x3ca2ec00, Dr6=0, Dr7=0x155, Rax=0, Rcx=0, Rdx=0xffffffffffff0000, Rbx=0, Rsp=0x101010100000000, Rbp=0x7972657571, Rsi=0x62616e6500000000, Rdi=0, R8=0, R9=0x4040404040404040, R10=0x4040404040404040, R11=0x5b5b5b5b5b5b5b5b, R12=0x5b5b5b5b5b5b5b5b, R13=0x6e55406e65657774, R14=0x72745365646f6369, R15=0, Rip=0, ={FltSave={ControlWord=0, StatusWord=0, TagWord=0, Reserved1=0, ErrorOpcode=0, ErrorOffset=0, ErrorSelector=0, Reserved2=0, DataOffset=0, DataSelector=0, Reserved3=0, MxCsr=0, MxCsr_Mask=0, FloatRegisters={{Low=0, High=0}, {Low=0, High=0}, {Low=0, High=0xffffff000000}, {Low=0, High=0}, {Low=0, High=0}, {Low=0, High=0}, {Low=0, High=0}, {Low=0, High=0}}, XmmRegisters={{Low=0, High=0}, {Low=0, High=0}, {Low=0, High=0}, {Low=0, High=0}, {Low=0, High=0}, {Low=0x1f29a30, High=0x7f0aedb68698}, {Low=0x5f55708, High=0x10000}, {Low=0x80000004, High=0}, {Low=0x80000004, High=0}, {Low=0x80000004, High=0}, {Low=0x3d0d335f, High=0}, {Low=0xf, High=0x3d7af213}, {Low=0x7f0aede1e408, High=0x50e31b0}, {Low=0x3dc79972, High=0x3c9d771d}, {Low=0x1d00000000, High=0xffffffffffffffff}, {Low=0x7f0af0000000, High=0x50e31b0}}, Reserved4="??"}, ={Header={{Low=0, High=0}, {Low=0, High=0}}, Legacy={{Low=0, High=0}, {Low=0, High=0}, {Low=0, High=0xffffff000000}, {Low=0, High=0}, {Low=0, High=0}, {Low=0, High=0}, {Low=0, High=0}, {Low=0, High=0}}, Xmm0={Low=0, High=0}, Xmm1={Low=0, High=0}, Xmm2={Low=0, High=0}, Xmm3={Low=0, High=0}, Xmm4={Low=0, High=0}, Xmm5={Low=0x1f29a30, High=0x7f0aedb68698}, Xmm6={Low=0x5f55708, High=0x10000}, Xmm7={Low=0x80000004, High=0}, Xmm8={Low=0x80000004, High=0}, Xmm9={Low=0x80000004, High=0}, Xmm10={Low=0x3d0d335f, High=0}, Xmm11={Low=0xf, High=0x3d7af213}, Xmm12={Low=0x7f0aede1e408, High=0x50e31b0}, Xmm13={Low=0x3dc79972, High=0x3c9d771d}, Xmm14={Low=0x1d00000000, High=0xffffffffffffffff}, Xmm15={Low=0x7f0af0000000, High=0x50e31b0}}}, VectorRegister={{Low=0xffffffff0000000f, High=0}, {Low=0, High=0x1}, {Low=0x1f29a98, High=0x50e31b0}, {Low=0x80000004, High=0}, {Low=0x80000004, High=0}, {Low=0x80000004, High=0}, {Low=0x80000004, High=0}, {Low=0x80000004, High=0}, {Low=0x80000004, High=0}, {Low=0x80000004, High=0}, {Low=0x80000004, High=0}, {Low=0x80000004, High=0}, {Low=0x3d8dcda9, High=0}, {Low=0xffffff000000, High=0x1f29f70}, {Low=0x1f29f70, High=0x1f29f70}, {Low=0x1f29f70, High=0x1f29f70}, {Low=0x1f29f70, High=0x1f29f70}, {Low=0x1f29f70, High=0x1f29f70}, {Low=0x1f29f70, High=0x1f29f70}, {Low=0x1f29f70, High=0x1f29f70}, {Low=0x1f29f70, High=0x1f29f70}, {Low=0x1f29f70, High=0x1f29f70}, {Low=0x3d8dcda9, High=0x3ceb84c9}, {Low=0x7ffe7b547490, High=0x7f0aede1e408}, {Low=0x1f2a100, High=0x10780}, {Low=0, High=0x50e31b0}}, VectorControl=0x1f2a100, DebugControl=0x1f29b14, LastBranchToRip=0x7f0aede1e400, LastBranchFromRip=0x1f29bc8, LastExceptionToRip=0, LastExceptionFromRip=0x3c9ab9ba}
... --- snip ---
The code sets the DRx registers on *self* (current thread = main thread) using 'CONTEXT_CONTROL | CONTEXT_DEBUG_REGISTERS' (ContextFlags=0x100010) by providing a partially filled context. Only DRx values are valid. No other control registers have useful values, see my dump: SegCs, Rsp, Rip ...
I wrote a small 64-bit test app that only clears DRx on current thread and indeed it causes a fault immediately on 'IRET' execution.
--- snip --- $ wine64 winedbg --gdb ./test.exe.so 002c:002d: create process 'Z:\home\focht\Downloads\test.exe'/0x10b90 @0x7f25023b3934 (0<0>) 002c:002d: create thread I @0x7f25023b3934 ... 002c:002d: loads DLL C:\windows\system32\KERNEL32.dll @0x7b860000 (0<0>) 002c:002d: loads DLL C:\windows\system32\ntdll.dll @0x7f2508ef0000 (0<0>) ... 0x00007f2508f90f69 in DbgBreakPoint () at /home/focht/projects/wine/wine.repo/src/dlls/ntdll/signal_x86_64.c:3740 3740 } ... Wine-gdb> cont Continuing.
Program received signal SIGSEGV, Segmentation fault. 0x00007f2508f8a6c7 in set_cpu_context () at /home/focht/projects/wine/wine.repo/src/dlls/ntdll/signal_x86_64.c:1737 1737 } Wine-gdb> bt #0 0x00007f2508f8a6c7 in set_cpu_context () at /home/focht/projects/wine/wine.repo/src/dlls/ntdll/signal_x86_64.c:1737 #1 0x00007f2508f9f1e9 in NtSetContextThread (handle=<error reading variable: Cannot access memory at address 0x10>, context=<error reading variable: Cannot access memory at address 0x18>) at /home/focht/projects/wine/wine.repo/src/dlls/ntdll/thread.c:794 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Wine-gdb> disas Dump of assembler code for function set_cpu_context: 0x00007f2508f8a598 <+0>: sub $0x28,%rsp 0x00007f2508f8a59c <+4>: ldmxcsr 0x34(%rdi) 0x00007f2508f8a5a0 <+8>: mov 0x38(%rdi),%ax 0x00007f2508f8a5a4 <+12>: mov %rax,0x8(%rsp) 0x00007f2508f8a5a9 <+17>: mov 0x42(%rdi),%ax 0x00007f2508f8a5ad <+21>: mov %rax,0x20(%rsp) 0x00007f2508f8a5b2 <+26>: mov 0x44(%rdi),%rax 0x00007f2508f8a5b6 <+30>: mov %rax,0x10(%rsp) 0x00007f2508f8a5bb <+35>: mov 0x80(%rdi),%rcx 0x00007f2508f8a5c2 <+42>: mov 0x88(%rdi),%rdx 0x00007f2508f8a5c9 <+49>: mov 0x90(%rdi),%rbx 0x00007f2508f8a5d0 <+56>: mov 0x98(%rdi),%rax 0x00007f2508f8a5d7 <+63>: mov %rax,0x18(%rsp) 0x00007f2508f8a5dc <+68>: mov 0xa0(%rdi),%rbp 0x00007f2508f8a5e3 <+75>: mov 0xa8(%rdi),%rsi 0x00007f2508f8a5ea <+82>: mov 0xb8(%rdi),%r8 0x00007f2508f8a5f1 <+89>: mov 0xc0(%rdi),%r9 0x00007f2508f8a5f8 <+96>: mov 0xc8(%rdi),%r10 0x00007f2508f8a5ff <+103>: mov 0xd0(%rdi),%r11 0x00007f2508f8a606 <+110>: mov 0xd8(%rdi),%r12 0x00007f2508f8a60d <+117>: mov 0xe0(%rdi),%r13 0x00007f2508f8a614 <+124>: mov 0xe8(%rdi),%r14 0x00007f2508f8a61b <+131>: mov 0xf0(%rdi),%r15 0x00007f2508f8a622 <+138>: mov 0xf8(%rdi),%rax 0x00007f2508f8a629 <+145>: mov %rax,(%rsp) 0x00007f2508f8a62d <+149>: fxrstor 0x100(%rdi) 0x00007f2508f8a634 <+156>: movdqa 0x1a0(%rdi),%xmm0 0x00007f2508f8a63c <+164>: movdqa 0x1b0(%rdi),%xmm1 0x00007f2508f8a644 <+172>: movdqa 0x1c0(%rdi),%xmm2 0x00007f2508f8a64c <+180>: movdqa 0x1d0(%rdi),%xmm3 0x00007f2508f8a654 <+188>: movdqa 0x1e0(%rdi),%xmm4 0x00007f2508f8a65c <+196>: movdqa 0x1f0(%rdi),%xmm5 0x00007f2508f8a664 <+204>: movdqa 0x200(%rdi),%xmm6 0x00007f2508f8a66c <+212>: movdqa 0x210(%rdi),%xmm7 0x00007f2508f8a674 <+220>: movdqa 0x220(%rdi),%xmm8 0x00007f2508f8a67d <+229>: movdqa 0x230(%rdi),%xmm9 0x00007f2508f8a686 <+238>: movdqa 0x240(%rdi),%xmm10 0x00007f2508f8a68f <+247>: movdqa 0x250(%rdi),%xmm11 0x00007f2508f8a698 <+256>: movdqa 0x260(%rdi),%xmm12 0x00007f2508f8a6a1 <+265>: movdqa 0x270(%rdi),%xmm13 0x00007f2508f8a6aa <+274>: movdqa 0x280(%rdi),%xmm14 0x00007f2508f8a6b3 <+283>: movdqa 0x290(%rdi),%xmm15 0x00007f2508f8a6bc <+292>: mov 0x78(%rdi),%rax 0x00007f2508f8a6c0 <+296>: mov 0xb0(%rdi),%rdi => 0x00007f2508f8a6c7 <+303>: iretq --- snip ---
The current 64-bit implementation of 'NtSetContextThread' -> 'set_cpu_context' assumes there is always a complete context provided by the client side which isn't the case here since the client only wants to set debug registers (CONTEXT_DEBUG_REGISTERS) on current thread.
--- snip --- -=[ ProtectionID v0.6.6.7 DECEMBER]=- (c) 2003-2015 CDKiLLER & TippeX Build 24/12/14-22:48:13 Ready... Scanning -> C:\Program Files (x86)\StarCraft II\Support64\SC2Switcher_x64.exe File Type : 64-Bit Exe (Subsystem : Win GUI / 2), Size : 953392 (0E8C30h) Byte(s) Compilation TimeStamp : 0x5642DA98 -> Wed 11th Nov 2015 06:05:12 (GMT) [TimeStamp] 0x5642DA98 -> Wed 11th Nov 2015 06:05:12 (GMT) | PE Header | - | Offset: 0x00000000:000000E8 | VA: 0x00000001:400000E8 | - [TimeStamp] 0x5642DA98 -> Wed 11th Nov 2015 06:05:12 (GMT) | DebugDirectory | - | Offset: 0x00000000:00003544 | VA: 0x00000001:40004344 | - -> File Appears to be Digitally Signed @ Offset 0E7600h, size : 01630h / 05680 byte(s) [File Heuristics] -> Flag #1 : 00000100000001001101000000010100 (0x0404D014) [Entrypoint Section Entropy] : 6.00 (section #0) ".text " | Size : 0x2CFC (11516) byte(s) [DllCharacteristics] -> Flag : (0x8140) -> ASLR | DEP | TSA [SectionCount] 6 (0x6) | ImageSize 0xEB000 (962560) byte(s) [VersionInfo] Company Name : Blizzard Entertainment. Inc. [VersionInfo] Product Name : SC2Switcher (Retail) [VersionInfo] Product Version : Version 3.0.5.39117 [VersionInfo] File Description : SC2Switcher [VersionInfo] File Version : 3.0.5.39117 [VersionInfo] Original FileName : SC2Switcher.exe [VersionInfo] Internal Name : SC2Switcher [VersionInfo] Version Comments : Based on build Base38996 [VersionInfo] Legal Copyrights : © 2010-2015 Blizzard Entertainment. Inc. [Debug Info] (record 1 of 1) (file offset 0x3540) Characteristics : 0x0 | TimeDateStamp : 0x5642DA98 (Wed 11th Nov 2015 06:05:12 (GMT)) | MajorVer : 0 / MinorVer : 0 -> (0.0) Type : 2 (0x2) -> CodeView | Size : 0x5D (93) AddressOfRawData : 0x5244 | PointerToRawData : 0x4444 CvSig : 0x53445352 | SigGuid 6BBA0566-5F25-4C18-9444FE6650267256 Age : 0x2 | Pdb : D:\Work\branches\SC2.3.0.Void\Code\Bin\Support64\SC2Switcher_x64.pdb [CompilerDetect] -> Visual C++ 10.0 (Visual Studio 2010) [!] File appears to have no protection or is using an unknown protection - Scan Took : 0.613 Second(s) [000000265h (613) tick(s)] [179 of 573 scan(s) done]
Scanning -> C:\Program Files (x86)\StarCraft II\Support64\Battle.net-64.dll File Type : 64-Bit Dll (Subsystem : Win GUI / 2), Size : 23344176 (01643430h) Byte(s) Compilation TimeStamp : 0x5637DDA4 -> Mon 02nd Nov 2015 22:03:16 (GMT) [TimeStamp] 0x5637DDA4 -> Mon 02nd Nov 2015 22:03:16 (GMT) | PE Header | - | Offset: 0x00000000:00000110 | VA: 0x00000000:3C910110 | - [TimeStamp] 0x5637DDA4 -> Mon 02nd Nov 2015 22:03:16 (GMT) | Export | - | Offset: 0x00000000:0066A814 | VA: 0x00000000:3CF7C214 | - [TimeStamp] 0x5637DDA4 -> Mon 02nd Nov 2015 22:03:16 (GMT) | DebugDirectory | - | Offset: 0x00000000:00490744 | VA: 0x00000000:3CDA2144 | - -> File Appears to be Digitally Signed @ Offset 01641E00h, size : 01630h / 05680 byte(s) [File Heuristics] -> Flag #1 : 00000100000001111101000100010100 (0x0407D114) [Entrypoint Section Entropy] : 6.69 (section #0) ".text " | Size : 0x48D200 (4772352) byte(s) [DllCharacteristics] -> Flag : (0x0140) -> ASLR | DEP [SectionCount] 7 (0x7) | ImageSize 0x167E200 (23585280) byte(s) [Export] 100% of function(s) (4 of 4) are in file | 0 are forwarded | 4 code | 0 data | 0 uninit data | 0 unknown | [VersionInfo] Company Name : Blizzard Entertainment [VersionInfo] Product Name : Battle.net [VersionInfo] Product Version : 1. 0. 0. 59540 [VersionInfo] File Description : Battle.net Client Library [VersionInfo] File Version : 1. 0. 0. 59540 [VersionInfo] Original FileName : Battle.net [VersionInfo] Internal Name : Battle.net [VersionInfo] Version Comments : Production.67Void. build 2786 [VersionInfo] Legal Copyrights : Copyright © 2003-2015 Blizzard Entertainment. All Rights Reserved. [Debug Info] (record 1 of 1) (file offset 0x490740) Characteristics : 0x0 | TimeDateStamp : 0x5637DDA4 (Mon 02nd Nov 2015 22:03:16 (GMT)) | MajorVer : 0 / MinorVer : 0 -> (0.0) Type : 2 (0x2) -> CodeView | Size : 0x2A (42) AddressOfRawData : 0x5CBDD8 | PointerToRawData : 0x5CA3D8 CvSig : 0x53445352 | SigGuid B99D2D6D-1606-4AEF-8DB883CBDFFB20AE Age : 0x1 | Pdb : Battle.net-64.pdb [CdKeySerial] found "Test Version" @ VA: 0x0049F272 / Offset: 0x0049D872 [CdKeySerial] found "TestVersion" @ VA: 0x0053B09B / Offset: 0x0053969B [CdKeySerial] found "TestVersion" @ VA: 0x00589FF6 / Offset: 0x005885F6 [CdKeySerial] found "TestVersion" @ VA: 0x005A26D8 / Offset: 0x005A0CD8 [CdKeySerial] found "Invalid code" @ VA: 0x005C8F28 / Offset: 0x005C7528 [CompilerDetect] -> Visual C++ 10.0 (Visual Studio 2010) [!] File appears to have no protection or is using an unknown protection - Scan Took : 5.960 Second(s) [0000013B0h (5040) tick(s)] [162 of 573 scan(s) done] --- snip ---
$ wine --version wine-1.7.55
Regards
https://bugs.winehq.org/show_bug.cgi?id=39454
Tom B tom@r.je changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |tom@r.je
--- Comment #9 from Tom B tom@r.je --- This is a particularly show-stopping problem because the 32bit client often crashes due to memory limitations. Currently the 32bit client will run out of memory when using High or Ultra quality textures, there are several posts about this here: https://appdb.winehq.org/objectManager.php?sClass=version&iId=20882 however the memory issue would not be a problem if the 64bit client worked correctly.
https://bugs.winehq.org/show_bug.cgi?id=39454
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de Assignee|wine-bugs@winehq.org |sebastian@fds-team.de
--- Comment #10 from Sebastian Lackner sebastian@fds-team.de --- (In reply to Tom B from comment #9)
This is a particularly show-stopping problem because the 32bit client often crashes due to memory limitations. Currently the 32bit client will run out of memory when using High or Ultra quality textures, there are several posts about this here: https://appdb.winehq.org/objectManager.php?sClass=version&iId=20882 however the memory issue would not be a problem if the 64bit client worked correctly.
With the full analysis (thanks Anastasius!) its very easy to solve, I'll provide a patch later today.
https://bugs.winehq.org/show_bug.cgi?id=39454
Aron Schatz aronschatz@aselabs.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |aronschatz@aselabs.com
--- Comment #11 from Aron Schatz aronschatz@aselabs.com --- I'll confirm this bug happens to me (and probably everyone).
Just to add additional confirmation that this is a bigger problem due to this bug: http://bugs.winehq.org/show_bug.cgi?id=33247 as mentioned by comment 9.
However, the 32-bit client being broken in WINE shouldn't be ignored once the 64-bit version starts working. I doubt Windows folks are having these crashes on the 32-bit client like we are. It really seems like a memory leak.
It would be nice to not worry about ladder games crashing again due to memory errors.
https://bugs.winehq.org/show_bug.cgi?id=39454
sjuk sjuk@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sjuk@gmx.de
--- Comment #12 from sjuk sjuk@gmx.de --- I can confirm the crash on start with the 64 bit client. I tested it with 64 bit prefix an the following wine versions: 1.7.55, 1.7.51, 1.7.46, 1.7.33, 1.7.22.
Could there be a wine version which perhaps work with the 64 bit client of starcraft 2?
Please tell me if I could help by testing a new patch.
Thanks sjuk
https://bugs.winehq.org/show_bug.cgi?id=39454
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED CC| |erich.e.hoover@wine-staging | |.com, michael@fds-team.de Staged patchset| |https://github.com/wine-com | |pholio/wine-staging/tree/ma | |ster/patches/ntdll-x86_64_s | |et_cpu_context
https://bugs.winehq.org/show_bug.cgi?id=39454
--- Comment #13 from Sebastian Lackner sebastian@fds-team.de --- I have added a staged patchset for this bug. Could someone please give it a try?
https://github.com/wine-compholio/wine-staging/tree/master/patches/ntdll-x86...
https://bugs.winehq.org/show_bug.cgi?id=39454
David Trail wine@vaunt.eu changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |wine@vaunt.eu
--- Comment #14 from David Trail wine@vaunt.eu --- Created attachment 52940 --> https://bugs.winehq.org/attachment.cgi?id=52940 Error log when launching after applying patch
I tried applying the patch and running but it throws up the "Report error to Blizzard" and won't launch via SC2Switcher_x64.exe.
Great investigation / patching though you guys! Gotta love open source.
https://bugs.winehq.org/show_bug.cgi?id=39454
--- Comment #15 from sjuk sjuk@gmx.de --- I can confirm that. 64 bit client crashes on start with or without the patch.
https://bugs.winehq.org/show_bug.cgi?id=39454
adrussel@hotmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |adrussel@hotmail.com
https://bugs.winehq.org/show_bug.cgi?id=39454
Hristo Venev mustrumr97@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mustrumr97@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=39454
Stefan hybrid@onlinehome.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hybrid@onlinehome.de
--- Comment #16 from Stefan hybrid@onlinehome.de --- Created attachment 53051 --> https://bugs.winehq.org/attachment.cgi?id=53051 winedebug=warn+all SC2Switcher_x64.exe
https://bugs.winehq.org/show_bug.cgi?id=39454
--- Comment #17 from Stefan hybrid@onlinehome.de --- Confirmed, patch not working here either. Patched wine-staging-1.7.52, wine-staging-1.7.54 and wine-staging-1.8-rc3 with https://github.com/wine-compholio/wine-staging/commit/b14f029f048e1faa5a32e7... - no luck.
WINEDEBUG=+tid,+seh,+relay,+server results in a 6.3gb log file, if you have something specific you want me to look for I'll be happy to help.
Also ran the SC2Switcher_x64.exe with WINEDEBUG=warn+all, maybe that contains some useful information.
https://bugs.winehq.org/show_bug.cgi?id=39454
--- Comment #18 from Anastasius Focht focht@gmx.net --- Hello folks,
although the patch prevents the crash in Wine code, allowing the launcher to run much further, it still fails - at the login procedure.
--- snip --- ... 0029:Ret PE DLL (proc=0x3cd0a8c0,module=0x3c910000 L"Battle.net-64.dll",reason=PROCESS_ATTACH,res=(nil)) retval=1 0029:Ret KERNEL32.LoadLibraryW() retval=3c910000 ret=141603362 0029:Call msvcr100.memset(0381b2b0,00000000,00000024) ret=140007960 0029:Ret msvcr100.memset() retval=0381b2b0 ret=140007960 0029:Call KERNEL32.GetProcAddress(3c910000,00000001) ret=1415ffb86 0029:Ret KERNEL32.GetProcAddress() retval=3c9868b0 ret=1415ffb86 0029:Call KERNEL32.GetProcAddress(3c910000,00000002) ret=1415ffba4 0029:Ret KERNEL32.GetProcAddress() retval=3c9869e0 ret=1415ffba4 0029:Call KERNEL32.GetProcAddress(3c910000,00000003) ret=1415ffbc2 0029:Ret KERNEL32.GetProcAddress() retval=3c986ad0 ret=1415ffbc2 0029:Call KERNEL32.GetProcAddress(3c910000,00000004) ret=1415ffbe0 0029:Ret KERNEL32.GetProcAddress() retval=3c9868d0 ret=1415ffbe0 0029:Call KERNEL32.IsDebuggerPresent() ret=3ccae65a 0029:Ret KERNEL32.IsDebuggerPresent() retval=00000000 ret=3ccae65a 0029:Call KERNEL32.LoadLibraryA(01f29ba0 "ntdll.dll") ret=3d9e2d08 0029:Ret KERNEL32.LoadLibraryA() retval=7fae1d280000 ret=3d9e2d08 0029:Call KERNEL32.GetProcAddress(7fae1d280000,01f29ba0 "NtQueryInformationProcess") ret=3d505c73 0029:Ret KERNEL32.GetProcAddress() retval=7fae1d284acc ret=3d505c73 0029:Call ntdll.NtQueryInformationProcess(ffffffffffffffff,0000001e,01f29c88,00000008,01f29cb4) ret=3d4ac0d3 0029:Ret ntdll.NtQueryInformationProcess() retval=c0000353 ret=3d4ac0d3 0029:Call KERNEL32.FreeLibrary(7fae1d280000) ret=3ca418ac 0029:Ret KERNEL32.FreeLibrary() retval=00000001 ret=3ca418ac 0029:Call KERNEL32.SetThreadContext(fffffffffffffffe,01f29980) ret=3ca7254b 0029: set_thread_context( handle=fffffffe, suspend=1, context={cpu=x86_64,dr0=3c9abbc0,dr1=3ca94610,dr2=3ca2e920,dr3=3ca2ec00,dr6=00000000,dr7=00000155} ) 0029: *signal* signal=19 0029: set_thread_context() = 0 { self=1 } 0029:fixme:seh:set_cpu_context setting debug registers not supported 0029:Ret KERNEL32.SetThreadContext() retval=00000001 ret=3ca7254b ... 0029:Call KERNEL32.GetThreadContext(fffffffffffffffe,01f27310) ret=3ca7289a 0029:Ret KERNEL32.GetThreadContext() retval=00000001 ret=3ca7289a 0029:Call msvcr100.memset(12387870,00000000,00000014) ret=140007960 0029:Ret msvcr100.memset() retval=12387870 ret=140007960 0029:Call msvcr100.memset(17357530,00000000,00000014) ret=140007960 0029:Ret msvcr100.memset() retval=17357530 ret=140007960 0029:Call msvcr100.memset(1228e9e0,00000000,00000014) ret=140007960 0029:Ret msvcr100.memset() retval=1228e9e0 ret=140007960 0029:Call msvcr100._beginthreadex(00000000,00004000,3ccb3010,1228e9e0,100000000,17357538) ret=3ccb312e 0029:Call KERNEL32.CreateThread(00000000,00004000,3ccb3010,1228e9e0,00000000,17357538) ret=7fae14e0695b 0029: *fd* 236 <- 279 0029: new_thread( access=001fffff, attributes=00000000, suspend=1, request_fd=236 ) 0029: new_thread() = 0 { tid=0052, handle=04a0 } 0029: resume_thread( handle=04a0 ) 0029: resume_thread() = 0 { count=1 } 0029:Ret KERNEL32.CreateThread() retval=000004a0 ret=7fae14e0695b 0052: *fd* 238 <- 283 0029:Ret msvcr100._beginthreadex() retval=000004a0 ret=3ccb312e 0052: *fd* 240 <- 284 0029:Call KERNEL32.WaitForSingleObject(000004a0,ffffffff) ret=3ccb319f 0052: init_thread( unix_pid=21794, unix_tid=22318, debug_level=1, teb=7ffffe028000, entry=3ccb3010, reply_fd=238, wait_fd=240, cpu=x86_64 ) 0052: init_thread() = 0 { pid=0028, tid=0052, server_start=1d134194f75f0e8 (-633.4852040), info_size=0, version=490, all_cpus=00000003 } 0029: select( flags=2, cookie=01f26cb4, timeout=infinite, prev_apc=0000, result={}, data={WAIT,handles={04a0}} ) 0029: select() = PENDING { timeout=infinite, call={APC_NONE}, apc_handle=0000 } 0052:Call PE DLL (proc=0x7fae16665fa1,module=0x7fae16570000 L"user32.dll",reason=THREAD_ATTACH,res=(nil)) ... 0052:Call PE DLL (proc=0x7fae114c11b8,module=0x7fae11460000 L"wininet.dll",reason=THREAD_ATTACH,res=(nil)) 0052:Ret PE DLL (proc=0x7fae114c11b8,module=0x7fae11460000 L"wininet.dll",reason=THREAD_ATTACH,res=(nil)) retval=1 0052:Starting thread proc 0x3ccb3010 (arg=0x1228e9e0) 0052:Call msvcr100.memset(0dbe32b0,00000000,00000034) ret=140007960 0052:Ret msvcr100.memset() retval=0dbe32b0 ret=140007960 0052:Call msvcr100.memset(0dd475a0,00000000,00020004) ret=140007960 0052:Ret msvcr100.memset() retval=0dd475a0 ret=140007960 0052:Call msvcr100.memset(0de59390,00000000,00005024) ret=140007960 0052:Ret msvcr100.memset() retval=0de59390 ret=140007960 0052:Call msvcr100.memset(0dbe32f0,00000000,00000024) ret=140007960 0052:Ret msvcr100.memset() retval=0dbe32f0 ret=140007960 0052:trace:seh:raise_exception code=c0000005 flags=0 addr=0xffffffffb3037b9b ip=ffffffffb3037b9b tid=0052 0052:trace:seh:raise_exception info[0]=0000000000000000 0052:trace:seh:raise_exception info[1]=ffffffffb3037b9b 0052:trace:seh:raise_exception rax=00000000de393e54 rbx=0000000012387870 rcx=0000000012387870 rdx=ffffffffb3037b9b 0052:trace:seh:raise_exception rsi=000000001228e9e0 rdi=000000003ca727d0 rbp=00000000051ee6b0 rsp=00000000051ee508 0052:trace:seh:raise_exception r8=0000000000000020 r9=0000000000000010 r10=0000000001190010 r11=00000000051ee4d8 0052:trace:seh:raise_exception r12=0000000001f26b3f r13=00000000051ef700 r14=0000000000000000 r15=0000000000000001 0052:trace:seh:call_vectored_handlers calling handler at 0x3ca730d0 code=c0000005 flags=0 ... 0052:trace:seh:call_stack_handlers found wine frame 0x51ee5b0 rsp 51ee6c0 handler 0x7fae1d340137 0052:trace:seh:call_teb_handler calling TEB handler 0x7fae1d340137 (rec=0x51ee3d0, frame=0x51ee5b0 context=0x51ed760, dispatcher=0x51ed228) 0052:Call KERNEL32.UnhandledExceptionFilter(051ed1d0) ret=7fae1d340191 ... --- snip ---
The code in 'Battle.net-64.dll' is highly obfuscated so it's hard to debug this garbage but it seems it relies on debug register values preserved and retrieved again (multiple times).
I cached the 64-bit context debug register Dr0-3, Dr6, Dr7 values on the client side (spare TEB area) to allow later 'GetThreadContext' calls to retain the values. Interestingly the actual 'on execute' hardware breakpoints are not hit after login so a real setting seems not needed here.
With that hack in place, further crashes are prevented and I successfully played some tutorial mission.
Regards
https://bugs.winehq.org/show_bug.cgi?id=39454
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |patch
https://bugs.winehq.org/show_bug.cgi?id=39454
--- Comment #19 from Hristo Venev mustrumr97@gmail.com --- (In reply to Anastasius Focht from comment #18)
I cached the 64-bit context debug register Dr0-3, Dr6, Dr7 values on the client side (spare TEB area) to allow later 'GetThreadContext' calls to retain the values. Interestingly the actual 'on execute' hardware breakpoints are not hit after login so a real setting seems not needed here.
Could you share the patch? I tried doing the same but for me the game seems to enter an infinite loop.
https://bugs.winehq.org/show_bug.cgi?id=39454
--- Comment #20 from Sebastian Lackner sebastian@fds-team.de --- I've updated the patch, please give it a try. GetThreadContext will now correctly return the values set in an earlier call. It doesn't contain caching on the client-side yet, but Hristo Venev is working on that. For now it will just always do a wineserver call.
https://bugs.winehq.org/show_bug.cgi?id=39454
lompik lompikvoila@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |lompikvoila@gmail.com
--- Comment #21 from lompik lompikvoila@gmail.com --- I could not start the game in 64bit before. Now with wine-1.9.0 (staging) and only in low settings (switch to 32bit to change this setting) the 64bit version launches and used memory can exceed 4GB without issues. In Medium or above settings it would freeze (starts but freeze with black screen). Changing the settings with 64bit also freezes the app but I guess this is a different issue.
https://bugs.winehq.org/show_bug.cgi?id=39454
--- Comment #22 from Hristo Venev mustrumr97@gmail.com --- For the freeze, see http://eu.battle.net/sc2/en/forum/topic/16946432559
https://bugs.winehq.org/show_bug.cgi?id=39454
--- Comment #23 from Stefan hybrid@onlinehome.de --- I'm getting the same results lompik described in comment 21 on this bug report with 1.9.0-staging. In short: sc2 starts in 64bit mode on low graphics settings, switching graphics settings in 64bit results in a freeze, starting with higher settings result in black screen.
https://bugs.winehq.org/show_bug.cgi?id=39454
--- Comment #24 from Stefan hybrid@onlinehome.de --- I don't mean to complicate things even more, but I just realized that sc2 now mimics the behaviour of Blizzard's heroes of the storm. A heroes/battle.net patch shortly before or after release rendered the 64bit client useless, it wouldn't start anymore. So ever since one had to use the 32bit client. Now with wine-staging 1.9.0 (haven't tried previous versions anymore tho) trying to start the heroes 64bit client with the game on higher graphics settings starts the client but results in a black screen freeze; starting the 64bit client with graphics settings set to low now actually works. Resetting the graphics settings in-game in the 64bit client has the client freeze, just like in sc2.
I don't mean to distract whoever is working on this sc2 bug and I certainly don't try to dig for support for heroes in this (at this point) sc2 bug. Just saying you might get two for one if you figure this one out!
Happy new year to everyone
https://bugs.winehq.org/show_bug.cgi?id=39454
Dave signups@davidarvelo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |signups@davidarvelo.com
--- Comment #25 from Dave signups@davidarvelo.com --- Happy New Year, everyone!
If it helps, no graphics setting freezes the game for me except for the "Shaders" setting. All others can be set to high. Once I set "Shaders" above low, I get the same freeze or black screen as everyone else.
https://bugs.winehq.org/show_bug.cgi?id=39454
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |7c468f8eca3af45eb8d8422f161 | |c3f9782e55370 Status|STAGED |RESOLVED Resolution|--- |FIXED
--- Comment #26 from Sebastian Lackner sebastian@fds-team.de --- This issue is fixed with http://source.winehq.org/git/wine.git/commit/7c468f8eca3af45eb8d8422f161c3f9... and previous commit.
The issues with freezing screen for some graphics settings sounds unrelated, please open a new bug report for that.
https://bugs.winehq.org/show_bug.cgi?id=39454
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mstefani@redhat.com Target Milestone|--- |1.8.x
https://bugs.winehq.org/show_bug.cgi?id=39454
Stephen Griffiths computing@stevegriff.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |computing@stevegriff.com
https://bugs.winehq.org/show_bug.cgi?id=39454
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #27 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.9.1.
https://bugs.winehq.org/show_bug.cgi?id=39454
Michael Stefaniuc mstefani@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Target Milestone|1.8.x |---
--- Comment #28 from Michael Stefaniuc mstefani@redhat.com --- Removing 1.8.x milestone from bugs included in 1.8.1.
https://bugs.winehq.org/show_bug.cgi?id=39454
Zentarim zentarim@rambler.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |zentarim@rambler.ru
https://bugs.winehq.org/show_bug.cgi?id=39454
Zentarim zentarim@rambler.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- CC|zentarim@rambler.ru |
-
wine-bugs＠winehq.org