[Bug 44650] New: Multiple Blizzard games need dxgi and d3d11 dlls mapped without hole between two LOAD segments (Diablo III v2. 6. 1. 49286+, World of Warcraft, Overwatch)
https://bugs.winehq.org/show_bug.cgi?id=44650 Bug ID: 44650 Summary: Multiple Blizzard games need dxgi and d3d11 dlls mapped without hole between two LOAD segments (Diablo III v2. 6. 1. 49286+, World of Warcraft, Overwatch) Product: Wine Version: 3.3 Hardware: x86-64 OS: Linux Status: NEW Severity: normal Priority: P2 Component: ntdll Assignee: wine-bugs(a)winehq.org Reporter: focht(a)gmx.net Distribution: --- Hello folks, this is mentioned in bug 40479 (first in https://bugs.winehq.org/show_bug.cgi?id=40479#c9 with some hack) but was never properly explained to a wider audience. Bug 40479 is already horribly messed up with various issues mixed in and end-user support/discussion hence I'm tracking this interesting problem here to discuss a proper solution. The inaccessible memory "hole" is by design. Relevant trace log: --- snip --- $ pwd /home/focht/wine-games/wineprefix64-bnet/drive_c/Program Files (x86)/Overwatch $ WINEDEBUG=+seh,+loaddll,+relay,+ntdll,+virtual wine64 ./Overwatch.exe
log.txt 2>&1 ... 0030:trace:module:get_load_order looking for L"C:\\windows\\system32\\dxgi.dll" 0030:trace:module:get_load_order got hardcoded default for L"dxgi.dll" 0030:trace:module:load_dll L"C:\\windows\\system32\\dxgi.dll" is a fake Wine dll 0030:trace:module:load_builtin_dll Trying built-in L"dxgi.dll" 0030:trace:virtual:virtual_create_builtin_view created 0x7fc4ad700000-0x7fc4ad938000 0030:trace:virtual:VIRTUAL_DumpView View: 0x7fc4ad700000 - 0x7fc4ad937fff (builtin image) 0030:trace:virtual:VIRTUAL_DumpView 0x7fc4ad700000 - 0x7fc4ad700fff c-r-- 0030:trace:virtual:VIRTUAL_DumpView 0x7fc4ad701000 - 0x7fc4ad936fff c-r-x 0030:trace:virtual:VIRTUAL_DumpView 0x7fc4ad937000 - 0x7fc4ad937fff c-rw- ... 0030:trace:virtual:NtProtectVirtualMemory 0xffffffffffffffff 0x7fc4ad937000 00001000 00000008 0030:trace:virtual:mprotect_exec forcing exec permission on 0x7fc4ad937000-0x7fc4ad937fff 0030:trace:virtual:VIRTUAL_DumpView View: 0x7fc4ad700000 - 0x7fc4ad937fff (builtin image) 0030:trace:virtual:VIRTUAL_DumpView 0x7fc4ad700000 - 0x7fc4ad700fff c-r-- 0030:trace:virtual:VIRTUAL_DumpView 0x7fc4ad701000 - 0x7fc4ad936fff c-r-x 0030:trace:virtual:VIRTUAL_DumpView 0x7fc4ad937000 - 0x7fc4ad937fff c-rW- 0030:trace:module:load_builtin_callback loaded dxgi.dll 0x65680 0x7fc4ad700000 0030:trace:module:load_dll Loaded module L"C:\\windows\\system32\\dxgi.dll" (builtin) at 0x7fc4ad700000 0030:trace:virtual:NtProtectVirtualMemory 0xffffffffffffffff 0x7fc4adc01d98 00000018 00000004 0030:trace:virtual:mprotect_exec forcing exec permission on 0x7fc4adc01000-0x7fc4adc01fff 0030:trace:virtual:VIRTUAL_DumpView View: 0x7fc4ad970000 - 0x7fc4adc03fff (builtin image) 0030:trace:virtual:VIRTUAL_DumpView 0x7fc4ad970000 - 0x7fc4ad970fff c-r-- 0030:trace:virtual:VIRTUAL_DumpView 0x7fc4ad971000 - 0x7fc4adc00fff c-r-x 0030:trace:virtual:VIRTUAL_DumpView 0x7fc4adc01000 - 0x7fc4adc01fff c-rW- 0030:trace:virtual:VIRTUAL_DumpView 0x7fc4adc02000 - 0x7fc4adc03fff c-rw- 0030:trace:imports:import_dll --- CreateDXGIFactory1 dxgi.dll.2 = 0x7fc4ad710440 0030:trace:imports:import_dll --- DXGID3D10CreateDevice dxgi.dll.4 = 0x7fc4ad71047c 0030:trace:imports:import_dll --- DXGID3D10RegisterLayers dxgi.dll.5 = 0x7fc4ad7104a0 ... 0030:Call KERNEL32.VirtualAlloc(00000000,00238000,00001000,00000004,) ret=14001f538 0030:trace:virtual:NtAllocateVirtualMemory 0xffffffffffffffff (nil) 00238000 1000 00000004 0030:trace:virtual:map_view got mem in reserved area 0x3690000-0x38c8000 0030:trace:virtual:create_view forcing exec permission on 0x3690000-0x38c7fff 0030:trace:virtual:VIRTUAL_DumpView View: 0x3690000 - 0x38c7fff (valloc) 0030:trace:virtual:VIRTUAL_DumpView 0x3690000 - 0x38c7fff c-rw- 0030:Ret KERNEL32.VirtualAlloc() retval=03690000 ret=14001f538 0030:trace:seh:NtRaiseException code=c0000005 flags=0 addr=0x14001f5fa ip=14001f5fa tid=0030 0030:trace:seh:NtRaiseException info[0]=0000000000000000 0030:trace:seh:NtRaiseException info[1]=00007fc4ad737000 0030:trace:seh:NtRaiseException rax=00000000079e4455 rbx=00007fc4ad700040 rcx=0000000000201000 rdx=000000007bdb5210 0030:trace:seh:NtRaiseException rsi=00007fc4ad737000 rdi=00000000036c7000 rbp=00000000002360a0 rsp=0000000000235fa0 0030:trace:seh:NtRaiseException r8=0000000003690000 r9=000000014001f538 r10=0000000000000000 r11=0000000000000246 0030:trace:seh:NtRaiseException r12=0000000000000014 r13=000000007ffe0030 r14=000000007b472568 r15=0000000000065680 ... --- snip ---
Overwatch/WoW make private in-memory copies of 'dxgi.dll' and 'd3d11.dll' as early as possible (loader notifications). This is done as another anti-cheat measure/method to detect hooking/hotpatching/proxying of DirectX interfaces at runtime by comparing real API entry points with the copies. It assumes that all parts of the in-memory image are readable but it's not due to the way the static and dynamic linker work. Relevant 'strace' part, annotated. --- snip --- $ strace -e trace=mmap,mprotect,munmap,open -o strace.log wine64 ./Overwatch.exe ... open("/home/focht/projects/wine/wine.repo/install/bin/../lib64/wine/dxgi.dll.so", O_RDONLY|O_CLOEXEC) = 11 ; --- map first "LOAD" segment (.text, ...) mmap(NULL, 2391592, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 11, 0) = 0x7f195c3e3000 ; --- make alignment "hole" inaccessible mprotect(0x7f195c42a000, 2093056, PROT_NONE) = 0 ; --- map second "LOAD" segment (.data, .bss, ...) mmap(0x7f195c629000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 11, 0x46000) = 0x7f195c629000 ; --- .got.plt .data sections within segment mprotect(0x7f195c3e3000, 290816, PROT_READ|PROT_WRITE) = 0 mprotect(0x7f195c3e3000, 290816, PROT_READ|PROT_EXEC) = 0 mprotect(0x7f195c629000, 4096, PROT_READ) = 0 ; --- remaining zero-filled sections (e.g. .bss) mmap(0x7f195c400000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7f195c400000 ... ; --- Page fault due to game code accessing the "hole". --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7f195c42a000} --- ... --- snip --- Dumping the ELF headers: --- snip --- $ readelf -a install/lib64/wine/dxgi.dll.so ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: DYN (Shared object file) Machine: Advanced Micro Devices X86-64 Version: 0x1 Entry point address: 0x20320 Start of program headers: 64 (bytes into file) Start of section headers: 693488 (bytes into file) Flags: 0x0 Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 7 Size of section headers: 64 (bytes) Number of section headers: 35 Section header string table index: 32 ... Section Headers: [Nr] Name Type Address Offset Size EntSize Flags Link Info Align [ 0] NULL 0000000000000000 00000000 0000000000000000 0000000000000000 0 0 0 [ 1] .note.gnu.build-i NOTE 00000000000001c8 000001c8 0000000000000024 0000000000000000 A 0 0 4 [ 2] .gnu.hash GNU_HASH 00000000000001f0 000001f0 0000000000000044 0000000000000000 A 3 0 8 [ 3] .dynsym DYNSYM 0000000000000238 00000238 0000000000000270 0000000000000018 A 4 2 8 [ 4] .dynstr STRTAB 00000000000004a8 000004a8 00000000000001cb 0000000000000000 A 0 0 1 [ 5] .gnu.version VERSYM 0000000000000674 00000674 0000000000000034 0000000000000002 A 3 0 2 [ 6] .gnu.version_r VERNEED 00000000000006a8 000006a8 0000000000000050 0000000000000000 A 4 2 8 [ 7] .rela.dyn RELA 00000000000006f8 000006f8 000000000000eb98 0000000000000018 A 3 0 8 [ 8] .rela.plt RELA 000000000000f290 0000f290 0000000000000030 0000000000000018 AI 3 10 8 [ 9] .init PROGBITS 000000000000f2c0 0000f2c0 0000000000011024 0000000000000000 AX 0 0 4 [10] .plt PROGBITS 00000000000202f0 000202f0 0000000000000030 0000000000000010 AX 0 0 16 [11] .text PROGBITS 0000000000020320 00020320 00000000000149fd 0000000000000000 AX 0 0 16 [12] .fini PROGBITS 0000000000034d20 00034d20 0000000000000009 0000000000000000 AX 0 0 4 [13] .rodata PROGBITS 0000000000034d40 00034d40 000000000000bdb0 0000000000000000 A 0 0 32 [14] .eh_frame_hdr PROGBITS 0000000000040af0 00040af0 0000000000000974 0000000000000000 A 0 0 4 [15] .eh_frame PROGBITS 0000000000041468 00041468 000000000000556c 0000000000000000 A 0 0 8 [16] .init_array INIT_ARRAY 0000000000246dc8 00046dc8 0000000000000008 0000000000000000 WA 0 0 8 [17] .fini_array FINI_ARRAY 0000000000246dd0 00046dd0 0000000000000008 0000000000000000 WA 0 0 8 [18] .jcr PROGBITS 0000000000246dd8 00046dd8 0000000000000008 0000000000000000 WA 0 0 8 [19] .data.rel.ro PROGBITS 0000000000246de0 00046de0 0000000000000008 0000000000000000 WA 0 0 8 [20] .dynamic DYNAMIC 0000000000246de8 00046de8 00000000000001f0 0000000000000010 WA 4 0 8 [21] .got PROGBITS 0000000000246fd8 00046fd8 0000000000000028 0000000000000008 WA 0 0 8 [22] .got.plt PROGBITS 0000000000247000 00047000 0000000000000028 0000000000000008 WA 0 0 8 [23] .data PROGBITS 0000000000247030 00047030 0000000000000dc0 0000000000000000 WA 0 0 16 [24] .bss NOBITS 0000000000247df0 00047df0 0000000000000038 0000000000000000 WA 0 0 16 ... Key to Flags: W (write), A (alloc), X (execute), M (merge), S (strings), l (large) I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown) O (extra OS processing required) o (OS specific), p (processor specific) There are no section groups in this file. Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x00000000000469d4 0x00000000000469d4 R E 200000 LOAD 0x0000000000046dc8 0x0000000000246dc8 0x0000000000246dc8 0x0000000000001028 0x0000000000001060 RW 200000 DYNAMIC 0x0000000000046de8 0x0000000000246de8 0x0000000000246de8 0x00000000000001f0 0x00000000000001f0 RW 8 NOTE 0x00000000000001c8 0x00000000000001c8 0x00000000000001c8 0x0000000000000024 0x0000000000000024 R 4 GNU_EH_FRAME 0x0000000000040af0 0x0000000000040af0 0x0000000000040af0 0x0000000000000974 0x0000000000000974 R 4 GNU_STACK 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 0x0000000000000000 RW 10 GNU_RELRO 0x0000000000046dc8 0x0000000000246dc8 0x0000000000246dc8 0x0000000000000238 0x0000000000000238 R 1 Section to Segment mapping: Segment Sections... 00 .note.gnu.build-id .gnu.hash .dynsym .dynstr .gnu.version .gnu.version_r .rela.dyn .rela.plt .init .plt .text .fini .rodata .eh_frame_hdr .eh_fr ame 01 .init_array .fini_array .jcr .data.rel.ro .dynamic .got .got.plt .data .bss 02 .dynamic 03 .note.gnu.build-id 04 .eh_frame_hdr 05 06 .init_array .fini_array .jcr .data.rel.ro .dynamic .got --- snip --- * LOAD segment "00" -> align 0x200000 (x86_64 default) * LOAD segment "01" -> align 0x200000 (x86_64 default) ELF's "linking view": The 0x200000 alignment of the two LOAD segments is default for static linker 'ld' on x86_64. ELF's "execution view": The dynamic linker/loader 'ld.so' will set the page protection of the alignment gap between the LOAD segments to 'PROT_NONE', creating an inaccessible "hole" by design. https://sourceware.org/git/?p=glibc.git;a=blob;f=elf/dl-map-segments.h;h=d36... --- snip --- 21 /* This implementation assumes (as does the corresponding implementation 22 of _dl_unmap_segments, in dl-unmap-segments.h) that shared objects 23 are always laid out with all segments contiguous (or with gaps 24 between them small enough that it's preferable to reserve all whole 25 pages inside the gaps with PROT_NONE mappings rather than permitting 26 other use of those parts of the address space). */ ... --- snip --- There is a Wine-Staging patch here: https://github.com/wine-staging/wine-staging/tree/master/patches/ntdll-Built... Specifically: https://github.com/wine-staging/wine-staging/blob/master/patches/ntdll-Built... The patch essentially allows app code to access the memory between the LOAD segments (alignment gaps/holes marked as 'VPROT_SYSTEM'). It's certainly doable this way ... but lets hear how Alexandre thinks of this. An alternative to "fix" the holes is by using the static linker. The default 'ld' setting for alignment of LOAD segments without using a custom linker script can be adjusted by using '-z max-page-size=N' and/or '-z common-page-size=N' (target page size). Wine actually already makes use of this for modules which need to be "prelinked" at fixed address ranges (core dlls): https://source.winehq.org/git/wine.git/blob/HEAD:/tools/winegcc/winegcc.c#l1... --- snip --- 1136 default: 1137 if (opts->image_base) 1138 { 1139 if (!try_link(opts->prefix, link_args, "-Wl,-z,max-page-size=0x1000")) 1140 strarray_add(link_args, "-Wl,-z,max-page-size=0x1000"); 1141 if (!try_link(opts->prefix, link_args, strmake("-Wl,-Ttext-segment=%s", opts->image_base))) 1142 strarray_add(link_args, strmake("-Wl,-Ttext-segment=%s", opts->image_base)); 1143 else 1144 prelink = PRELINK; 1145 } 1146 break; 1147 } --- snip --- Example: https://source.winehq.org/git/wine.git/blob/HEAD:/dlls/kernel32/Makefile.in#... --- snip --- 6 EXTRADLLFLAGS = -nodefaultlibs -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b400000 --- snip --- --- snip --- $ readelf -a install/lib64/wine/kernel32.dll.so ... Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flags Align LOAD 0x0000000000000000 0x000000007b400000 0x000000007b400000 0x00000000002c3bcc 0x00000000002c3bcc R E 1000 LOAD 0x00000000002c3dc8 0x000000007b6c4dc8 0x000000007b6c4dc8 0x00000000001b1448 0x00000000001b1ad0 RW 1000 --- snip --- Due to platform (target) page granularity, there is no hole anymore in between the two LOAD segments. Giving 'dxgi' and 'd3d11' dlls fixed load addresses basically achieves the same but at static link time: --- snip --- $ grep -Hrni image-base dlls/ dlls/dxgi/Makefile.in:4:EXTRADLLFLAGS = -Wl,--image-base,0x71710000 dlls/kernel32/Makefile.in:6:EXTRADLLFLAGS = -nodefaultlibs -Wb,-F,KERNEL32.dll -Wl,--image-base,0x7b400000 dlls/ntdll/Makefile.in:6:EXTRADLLFLAGS = -nodefaultlibs -Wl,--image-base,0x7bc00000 dlls/opengl32/Makefile.in:5:EXTRADLLFLAGS = -Wl,--image-base,0x7a800000 dlls/riched20/Makefile.in:4:EXTRADLLFLAGS = -Wl,--image-base,0x7ac00000 dlls/d3d11/Makefile.in:4:EXTRADLLFLAGS = -Wl,--image-base,0x77590000 --- snip --- Alternatively, decouple the 'ld' option from Wine's 'image-base' option. Anyway, chose between the static link time vs. runtime link time (permission fixup -> staging patch) method ;-) $ wine --version wine-3.3 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- URL| |https://eu.battle.net/accou | |nt/download/ Keywords| |download, obfuscation -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED Staged patchset| |https://github.com/wine-sta | |ging/wine-staging/tree/mast | |er/patches/ntdll-Builtin_Pr | |ot --- Comment #1 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, marking 'staged' here in case the runtime fixup solution is used. Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 Ker noa <blue-t(a)web.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |blue-t(a)web.de -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |RESOLVED Fixed by SHA1| |395a94d308d77786809eee9eb77 | |b4e35c78fbf9e Resolution|--- |FIXED --- Comment #2 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, this is fixed by commit https://source.winehq.org/git/wine.git/commitdiff/395a94d308d77786809eee9eb7... Thanks Alexandre who took my suggestion ;-) Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |z.figura12(a)gmail.com --- Comment #3 from Zebediah Figura <z.figura12(a)gmail.com> --- Did you test that this fixes the bug with Blizzard games? The test attached to the Staging patch still crashes: wine: Unhandled page fault on read access to 0xf7204000 at address 0x7effb05e (thread 0009), starting debugger... ... ELF f711f000-f7370000 Deferred shell32<elf> \-PE f7130000-f7370000 \ shell32 i.e. at offset 0xe5000. Dumping the section headers shows this: shell32.dll.so: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn ... 15 .eh_frame 0001ef84 000c5684 000c5684 000c5684 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 16 .init_array 00000004 000e6550 000e6550 000e5550 2**2 CONTENTS, ALLOC, LOAD, DATA .eh_frame stretches from 0xc5684 to 0xe4608, but .init_array has a VMA of 0xe6550. Thus there's still one empty page from 0xe5000-0xe5fff, which thus has no access and causes a crash. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|FIXED |--- Status|RESOLVED |REOPENED --- Comment #4 from Anastasius Focht <focht(a)gmx.net> --- Hello Zebediah, yeah my bad, not sure what happened. I thought that I had tested this with a local patch on top of vanilla Wine. The gap between '.eh_frame' and '.init_array' sections is nicely explained here: https://stackoverflow.com/questions/33944047/why-is-there-unused-empty-space... --- quote --- You can consult the documentation for builtin functions for GNU ld linker scripts at https://sourceware.org/binutils/docs/ld/Builtin-Functions.html. But beware that DATA_SEGMENT_ALIGN documentation is incorrect, as reported by Stephen Kell at binutils bug #19203: "DATA_SEGMENT_ALIGN documentation is not consistent with behaviour", apparently since Jakub Jelinek's [PATCH] Fix DATA_SEGMENT_ALIGN. DATA_SEGMENT_ALIGN itself was introduced at a binutils' mailing list thread called [RFC PATCH] Smarter aligning of data segment. Somehow, the following: . = ALIGN (CONSTANT (MAXPAGESIZE)) - ((CONSTANT (MAXPAGESIZE) - .) & (CONSTANT (MAXPAGESIZE) - 1)); . = DATA_SEGMENT_ALIGN (CONSTANT (MAXPAGESIZE), CONSTANT (COMMONPAGESIZE)); causes a 1-page jump, which in your example would move you from 0x0804856c to 0x0804956c. When the linker option -z relro is used, requesting relocations fixed up at load time to be marked read-only, DATA_SEGMENT_RELRO_END causes the previous DATA_SEGMENT_ALIGN to add enough padding to cause the sum of the two arguments of DATA_SEGMENT_RELRO_END to be aligned to a new page. --- quote --- https://sourceware.org/ml/binutils/2002-02/msg00265.html ("[RFC PATCH] Smarter aligning of data segment") Reopening. Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|REOPENED |NEW --- Comment #5 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, and confirming again for the remaining gap due to default 'ld' linker script. --- snip --- ... 0009:trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\dxgi.dll" at 0x7fa8a9370000: builtin 0009:trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\d3d11.dll" at 0x7fa8a93e0000: builtin 0009:trace:loaddll:load_builtin_dll Loaded L"C:\\windows\\system32\\winex11.drv" at 0x7fa8a9000000: builtin 0009:trace:seh:NtRaiseException code=c0000005 flags=0 addr=0x140022ed3 ip=140022ed3 tid=0009 0009:trace:seh:NtRaiseException info[0]=0000000000000000 0009:trace:seh:NtRaiseException info[1]=00007fa8a93a2000 0009:trace:seh:NtRaiseException rax=0000000000000001 rbx=00007fa8a9370040 rcx=0000000000003000 rdx=0000000000035000 0009:trace:seh:NtRaiseException rsi=00007fa8a93a2000 rdi=0000000003752000 rbp=0000000000225a50 rsp=0000000000225950 0009:trace:seh:NtRaiseException r8=0000000003720000 r9=0000000000000000 r10=0000000000000008 r11=0000000000000246 0009:trace:seh:NtRaiseException r12=000000007ffe0030 r13=0000000000000a3a r14=00000000000543a0 r15=0000000000000014 --- snip --- Strace: --- snip --- ... 28288 [00007fa8b46505a0] openat(AT_FDCWD, "/home/focht/projects/wine/wine.repo/install/bin/../lib64/wine/dxgi.dll.so", O_RDONLY|O_CLOEXEC) = 12 28288 [00007fa8b46505f7] read(12, "\177ELF\2\1\1\0\0\0\0\0\0\0\0\0\3\0>\0\1\0\0\0\200\2\2\0\0\0\0\0"..., 832) = 832 ... 28288 [00007fa8b4650863] mmap(NULL, 294424, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 12, 0) = 0x7fa8a935d000 28288 [00007fa8b4650927] mprotect(0x7fa8a93a2000, 4096, PROT_NONE) = 0 28288 [00007fa8b4650863] mmap(0x7fa8a93a3000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 12, 0x45000) = 0x7fa8a93a3000 28288 [00007fa8b465074a] close(12) = 0 28288 [00007fa8b4650927] mprotect(0x7fa8a935d000, 282624, PROT_READ|PROT_WRITE) = 0 28288 [00007fa8b4650927] mprotect(0x7fa8a935d000, 282624, PROT_READ|PROT_EXEC) = 0 28288 [00007fa8b4650927] mprotect(0x7fa8a93a3000, 4096, PROT_READ) = 0 28288 [00007fa8b3d73db3] mmap(0x7fa8a9370000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0) = 0x7fa8a9370000 ... 28288 [00007fa8b4650927] mprotect(0x7fa8a90bd000, 2727936, PROT_READ|PROT_WRITE) = 0 28288 [00007fa8b4650927] mprotect(0x7fa8a90bd000, 2727936, PROT_READ|PROT_EXEC) = 0 28288 [00007fa8b4650927] mprotect(0x7fa8a9357000, 4096, PROT_READ) = 0 .... 28288 [00007fa8b3d73e97] mprotect(0x7fa8a935b000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 ... 28288 [00007fa8b3d73e97] mprotect(0x7fa8a93a4000, 4096, PROT_READ|PROT_WRITE|PROT_EXEC) = 0 ... 28288 [0000000140022ed3] --- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_ACCERR, si_addr=0x7fa8a93a2000} --- ... --- snip --- --- snip --- $ objdump -h install/lib64/wine/dxgi.dll.so install/lib64/wine/dxgi.dll.so: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn 0 .note.gnu.build-id 00000024 00000000000001c8 00000000000001c8 000001c8 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 1 .gnu.hash 00000044 00000000000001f0 00000000000001f0 000001f0 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 2 .dynsym 00000240 0000000000000238 0000000000000238 00000238 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 3 .dynstr 000001b7 0000000000000478 0000000000000478 00000478 2**0 CONTENTS, ALLOC, LOAD, READONLY, DATA 4 .gnu.version 00000030 0000000000000630 0000000000000630 00000630 2**1 CONTENTS, ALLOC, LOAD, READONLY, DATA 5 .gnu.version_r 00000050 0000000000000660 0000000000000660 00000660 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 6 .rela.dyn 0000eb80 00000000000006b0 00000000000006b0 000006b0 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA 7 .init 00011021 000000000000f230 000000000000f230 0000f230 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 8 .plt 00000010 0000000000020260 0000000000020260 00020260 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 9 .plt.got 00000008 0000000000020270 0000000000020270 00020270 2**3 CONTENTS, ALLOC, LOAD, READONLY, CODE 10 .text 000149f1 0000000000020280 0000000000020280 00020280 2**4 CONTENTS, ALLOC, LOAD, READONLY, CODE 11 .fini 00000009 0000000000034c74 0000000000034c74 00034c74 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 12 .rodata 0000bdd0 0000000000034c80 0000000000034c80 00034c80 2**5 CONTENTS, ALLOC, LOAD, READONLY, DATA 13 .eh_frame_hdr 0000097c 0000000000040a50 0000000000040a50 00040a50 2**2 CONTENTS, ALLOC, LOAD, READONLY, DATA 14 .eh_frame 00003b34 00000000000413d0 00000000000413d0 000413d0 2**3 CONTENTS, ALLOC, LOAD, READONLY, DATA <====== 1 page gap =======> 15 .init_array 00000008 0000000000046e08 0000000000046e08 00045e08 2**3 CONTENTS, ALLOC, LOAD, DATA 16 .fini_array 00000008 0000000000046e10 0000000000046e10 00045e10 2**3 CONTENTS, ALLOC, LOAD, DATA 17 .data.rel.ro 00000008 0000000000046e18 0000000000046e18 00045e18 2**3 CONTENTS, ALLOC, LOAD, DATA 18 .dynamic 000001c0 0000000000046e20 0000000000046e20 00045e20 2**3 CONTENTS, ALLOC, LOAD, DATA 19 .got 00000020 0000000000046fe0 0000000000046fe0 00045fe0 2**3 CONTENTS, ALLOC, LOAD, DATA 20 .got.plt 00000018 0000000000047000 0000000000047000 00046000 2**3 CONTENTS, ALLOC, LOAD, DATA 21 .data 00000dc0 0000000000047020 0000000000047020 00046020 2**4 CONTENTS, ALLOC, LOAD, DATA 22 .bss 00000038 0000000000047de0 0000000000047de0 00046de0 2**4 ALLOC ... --- snip --- $ wine --version wine-3.5-56-g09356cf42b Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 tokktokk <fdsfgs(a)krutt.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fdsfgs(a)krutt.org -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |STAGED --- Comment #6 from Zebediah Figura <z.figura12(a)gmail.com> --- Restoring STAGED status, unless you think there's some reason not to. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 --- Comment #7 from Anastasius Focht <focht(a)gmx.net> --- Hello Zebediah, no problem since the Wine-Staging patch fixes the issue - although at runtime. The alternative would be a custom linker script, not using DATA_SEGMENT_ALIGN directive and align manually to next page boundary to fix this issue at "static" link time. Downside: replacing the default linker script with a custom one just for fixing the segments mapping might be overkill/too expensive to maintain. Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 mirh <mirh(a)protonmail.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mirh(a)protonmail.ch -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 Zebediah Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |joseph.dunnigan(a)gmail.com --- Comment #8 from Zebediah Figura <z.figura12(a)gmail.com> --- *** Bug 40479 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 Chris Y. <emailofchris(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |emailofchris(a)gmail.com -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 --- Comment #9 from Matteo Bruni <matteo.mystral(a)gmail.com> --- *** Bug 45499 has been marked as a duplicate of this bug. *** -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 --- Comment #10 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, revisiting. Not sure if this type anti-cheat measure is still active in all the current game clients. At least for WoW and Diablo III (f2p) it doesn't seem to be. I can't check Overwatch as one needs to pay for it. Instead of going with Wine-Staging and/or custom linker script solutions we could leverage from the conversion of the affected dlls to PE format (cross-compile with mingw). 'd3d11.dll' was already converted some time ago: https://source.winehq.org/git/wine.git/commitdiff/d216374962b199cf028d07194f... ("d3d11: Build with msvcrt.") --- snip --- ... 002b:trace:module:load_builtin_dll Trying built-in L"d3d11.dll" 002b:trace:ntdll:FILE_CreateFile handle=0x22ee00 access=80100000 name=L"\\??\\Z:\\home\\focht\\projects\\wine\\mainline-install-x86_64\\bin\\..\\lib64\\wine\\d3d11.dll" objattr=00000040 root=(nil) sec=(nil) io=0x22ee20 alloc_size=(nil) attr=00000000 sharing=00000005 disp=1 options=00000060 ea=(nil).0x00000000 002b: create_file( access=80100000, sharing=00000005, create=1, options=00000060, attrs=00000000, objattr={rootdir=0000,attributes=00000040,sd={},name=L""}, filename="/home/focht/wine-games/wineprefix64-bnet/dosdevices/z:/home/focht/projects/wine/mainline-install-x86_64/bin/../lib64/wine/d3d11.dll" ) 002b: create_file() = 0 { handle=2384 } 002b: get_handle_fd( handle=2384 ) 002b: *fd* 2384 -> 286 002b: get_handle_fd() = 0 { type=1, cacheable=1, access=00120089, options=00000060 } 002b: create_mapping( access=000f000d, flags=01000000, file_access=00000001, size=00000000, file_handle=2384, objattr={} ) 002b: create_mapping() = 0 { handle=238c } 002b: close_handle( handle=2384 ) 002b: close_handle() = 0 002b: unmap_view( base=17400000 ) 002b: unmap_view() = 0 002b: get_mapping_info( handle=238c, access=0000000c ) 002b: get_mapping_info() = 0 { size=00292000, flags=01800000, shared_file=0000, image={base=64f40000,entry_point=64f6ca30,map_size=00292000,stack_size=00200000,stack_commit=00001000,zerobits=00000000,subsystem=00000003,subsystem_low=0002,subsystem_high=0005,gp=00000000,image_charact=2026,dll_charact=0100,machine=8664,contains_code=1,image_flags=40,loader_flags=00000000,header_size=00000600,file_size=002b936a,checksum=002c0361,cpu=x86_64} } 002b: get_handle_fd( handle=238c ) 002b: *fd* 238c -> 297 002b: get_handle_fd() = 0 { type=1, cacheable=1, access=000f000d, options=00000020 } 002b:trace:virtual:map_view got mem in reserved area 0x17400000-0x17692000 002b:trace:module:map_image mapped PE file at 0x17400000-0x17692000 002b:trace:module:map_image mapping section .text at 0x17401000 off 600 size 2c400 virt 2c3f0 flags 60500020 002b:trace:module:map_image clearing 0x1742d400 - 0x1742e000 002b:trace:module:map_image mapping section .data at 0x1742e000 off 2ca00 size 200 virt 110 flags c0500040 002b:trace:module:map_image clearing 0x1742e200 - 0x1742f000 002b:trace:module:map_image mapping section .rodata at 0x1742f000 off 2cc00 size 600 virt 410 flags c0300040 002b:trace:module:map_image clearing 0x1742f600 - 0x17430000 002b:trace:module:map_image mapping section .rdata at 0x17430000 off 2d200 size 18000 virt 17f80 flags 40600040 002b:trace:module:map_image mapping section .pdata at 0x17448000 off 45200 size 2800 virt 2634 flags 40300040 002b:trace:module:map_image clearing 0x1744a800 - 0x1744b000 002b:trace:module:map_image mapping section .xdata at 0x1744b000 off 47a00 size 2a00 virt 2808 flags 40300040 002b:trace:module:map_image clearing 0x1744da00 - 0x1744e000 002b:trace:module:map_image mapping section .bss at 0x1744e000 off 0 size 0 virt 140 flags c0600080 002b:trace:module:map_image mapping section .edata at 0x1744f000 off 4a400 size ee00 virt ec3c flags 40300040 002b:trace:module:map_image clearing 0x1745de00 - 0x1745e000 002b:trace:module:map_image mapping section .idata at 0x1745e000 off 59200 size 2600 virt 25ac flags c0300040 002b:trace:module:map_image clearing 0x17460600 - 0x17461000 002b:trace:module:map_image mapping section .rsrc at 0x17461000 off 5b800 size 400 virt 3b0 flags c0400040 002b:trace:module:map_image clearing 0x17461400 - 0x17462000 002b:trace:module:map_image mapping section .reloc at 0x17462000 off 5bc00 size 800 virt 620 flags 42300040 002b:trace:module:map_image clearing 0x17462800 - 0x17463000 002b:trace:module:map_image mapping section /4 at 0x17463000 off 5c400 size 400 virt 310 flags 42100040 002b:trace:module:map_image clearing 0x17463400 - 0x17464000 002b:trace:module:map_image mapping section /19 at 0x17464000 off 5c800 size 17d800 virt 17d78e flags 42100040 002b:trace:module:map_image clearing 0x175e1800 - 0x175e2000 002b:trace:module:map_image mapping section /31 at 0x175e2000 off 1da000 size 3a00 virt 3963 flags 42100040 002b:trace:module:map_image clearing 0x175e5a00 - 0x175e6000 002b:trace:module:map_image mapping section /45 at 0x175e6000 off 1dda00 size c600 virt c43e flags 42100040 002b:trace:module:map_image clearing 0x175f2600 - 0x175f3000 002b:trace:module:map_image mapping section /57 at 0x175f3000 off 1ea000 size ca00 virt c9c0 flags 42400040 002b:trace:module:map_image clearing 0x175ffa00 - 0x17600000 002b:trace:module:map_image mapping section /70 at 0x17600000 off 1f6a00 size 1a400 virt 1a2f8 flags 42100040 002b:trace:module:map_image clearing 0x1761a400 - 0x1761b000 002b:trace:module:map_image mapping section /81 at 0x1761b000 off 210e00 size 77000 virt 76f89 flags 42100040 002b: map_view( mapping=238c, access=0000000c, base=17400000, size=00292000, start=00000000 ) 002b: map_view() = 0 002b:trace:virtual:VIRTUAL_DumpView View: 0x17400000 - 0x17691fff (image) 002b:trace:virtual:VIRTUAL_DumpView 0x17400000 - 0x17400fff c-r-- 002b:trace:virtual:VIRTUAL_DumpView 0x17401000 - 0x1742dfff c-r-x 002b:trace:virtual:VIRTUAL_DumpView 0x1742e000 - 0x1742ffff c-rW- 002b:trace:virtual:VIRTUAL_DumpView 0x17430000 - 0x1744dfff c-r-- 002b:trace:virtual:VIRTUAL_DumpView 0x1744e000 - 0x1744efff c-rW- 002b:trace:virtual:VIRTUAL_DumpView 0x1744f000 - 0x1745dfff c-r-- 002b:trace:virtual:VIRTUAL_DumpView 0x1745e000 - 0x17461fff c-rW- 002b:trace:virtual:VIRTUAL_DumpView 0x17462000 - 0x17691fff c-r-- 002b: close_handle( handle=238c ) 002b: close_handle() = 0 ... 002b:trace:loaddll:load_native_dll Loaded L"C:\\windows\\system32\\d3d11.dll" at 0x17400000: PE builtin 002b:trace:module:load_dll Loaded module L"\\??\\C:\\windows\\system32\\d3d11.dll" at 0x17400000 002b:trace:module:process_attach (L"d3d11.dll",(nil)) - START 002b:Call LDR notification callback (proc=0x140181420,reason=1,data=0x22f710,context=(nil)) 002b:Ret LDR notification callback (proc=0x140181420,reason=1,data=0x22f710,context=(nil)) 002b:Call PE DLL (proc=0x1742ca30,module=0x17400000 L"d3d11.dll",reason=PROCESS_ATTACH,res=(nil)) ... 002b:Ret PE DLL (proc=0x1742ca30,module=0x17400000 L"d3d11.dll",reason=PROCESS_ATTACH,res=(nil)) retval=1 002b:trace:module:process_attach (L"d3d11.dll",(nil)) - END 002b:Ret ntdll.LdrLoadDll() retval=00000000 ret=7105c003 ... 002b:Ret KERNEL32.LoadLibraryA() retval=17400000 ret=1405c5a3f 002b:Call KERNEL32.GetProcAddress(17400000,14208c5f8 "D3D11CreateDevice") ret=1405c5a8b 002b:Ret KERNEL32.GetProcAddress() retval=1740137c ret=1405c5a8b ... --- snip --- Not sure why the conversion of components to PE format happens less frequently now. Maybe MinWin refactoring (kernelbase <-> kernel32) has higher priority? More component owners could do it themselves to speed up to conversion process. Like Hans did: * https://source.winehq.org/git/wine.git/commitdiff/e3057aea62c911fc7d7ae73d30... ("winhttp: Build with msvcrt.") * https://source.winehq.org/git/wine.git/commitdiff/dba0dd41613a91f17142a9bd8e... ("wbemprox: Build with msvcrt.") I propose to convert 'dxgi.dll' and 'd3d12.dll' to PE as well to have this issue resolved - maybe before Wine 5.0 happens ;-) $ wine --version wine-4.21-187-gf81e4cc8fb Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 --- Comment #11 from Alexandre Julliard <julliard(a)winehq.org> --- (In reply to Anastasius Focht from comment #10)
Not sure why the conversion of components to PE format happens less frequently now. Maybe MinWin refactoring (kernelbase <-> kernel32) has higher priority?
Because I've been doing the easy ones first ;-) The remaining ones are harder, and will take more time. But we'll get there eventually... -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 Yao Mitachi <yaomtcmail(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|yaomtcmail(a)gmail.com | -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- URL|https://eu.battle.net/accou |https://web.archive.org/web |nt/download/ |/20210627121051/https://eu. | |battle.net/download/getInst | |aller?os=win&installer=Batt | |le.net-Setup.exe --- Comment #12 from Anastasius Focht <focht(a)gmx.net> --- Hello folks, adding stable link to Battle.net Desktop App, even though it's only a bootstrapper. https://web.archive.org/web/20210627121051/https://eu.battle.net/download/ge... Wine source: https://source.winehq.org/git/wine.git/blob/c518a5362b925379b1a79e8323d60e19... $ sha1sum Battle.net-Setup.exe c58756f233cae6628867e11c163bd68c2d8393e6 Battle.net-Setup.exe $ du -sh Battle.net-Setup.exe 4.7M Battle.net-Setup.exe $ wine --version wine-6.13-76-gc518a5362b9 Regards -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 Sven Arvidsson <sa(a)whiz.se> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sa(a)whiz.se --- Comment #13 from Sven Arvidsson <sa(a)whiz.se> --- The games WRC 8 and WRC 9 also needs this patchset or they crash on launch. I presume this is also some sort of cheat countermeasure as the WRC titles are used for esport. I can file individual bugs for both games if necessary. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 jokeyrhyme(a)jokeyrhy.me changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jokeyrhyme(a)jokeyrhy.me -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 Zeb Figura <z.figura12(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|STAGED |RESOLVED Resolution|--- |FIXED Fixed by SHA1|395a94d308d77786809eee9eb77 |6b8cbfe3fdc1ab8c6efd55dc51d |b4e35c78fbf9e |f7c3d738c4a47 --- Comment #14 from Zeb Figura <z.figura12(a)gmail.com> --- dxgi was done way back in 6b8cbfe3fd, so I'm going to go ahead and assume this is fixed. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
https://bugs.winehq.org/show_bug.cgi?id=44650 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #15 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 8.1. -- Do not reply to this email, post in Bugzilla using the above URL to reply. You are receiving this mail because: You are watching all bug changes.
participants (2)
-
wine-bugs＠winehq.org -
WineHQ Bugzilla