http://bugs.winehq.org/show_bug.cgi?id=36863
Bug ID: 36863 Summary: Mass Effect 3 [Origin] crash on startup Product: Wine Version: 1.7.20 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: directx-d3dx9 Assignee: wine-bugs@winehq.org Reporter: phisig791@gmail.com
Created attachment 48956 --> http://bugs.winehq.org/attachment.cgi?id=48956 Backtrace given by wine
Mass Effect 3 will not start
Error exists in 32-bit or 64-bit wine bottle
To duplicate:
Install Origin Patch Qt5Network.dll Download Mass Effect 3 (and DLC) Enable virtual desktop and mouse capture as instructed by WineHQ
Execute 'wine Binaries/Win32/MassEffect3.exe'
Mass Effect will not start, it will just crash with the error 'Unhandled exception: page fault on read access to 0xfc710040 in 32-bit code (0xfc710040)'.
It has been suggested that removing/renaming IGO32.DLL will resolve this issue, however when I tried it Origin failed to start, complaining that IGO32.DLL did not exist.
Wine build: wine-1.7.20 Platform: i386 Host system: Linux Host version: 3.13.0-24-generic
http://bugs.winehq.org/show_bug.cgi?id=36863
--- Comment #1 from Henri Verbeet hverbeet@gmail.com --- The backtrace is missing debug symbols, which makes it much more harder to say something useful about it. Considering the application crashes as a result of Direct3DCreate9(), it seems likely that this is some kind of issue with your OpenGL setup.
http://bugs.winehq.org/show_bug.cgi?id=36863
--- Comment #2 from Tim phisig791@gmail.com --- Created attachment 48966 --> http://bugs.winehq.org/attachment.cgi?id=48966 Backtrace with debug symbols
http://bugs.winehq.org/show_bug.cgi?id=36863
--- Comment #3 from Tim phisig791@gmail.com --- I have created a backtrace with debug symbols, I hope that shines some light on the issue
http://bugs.winehq.org/show_bug.cgi?id=36863
Tim phisig791@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|1.7.20 |1.7.21
http://bugs.winehq.org/show_bug.cgi?id=36863
Tim phisig791@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Hardware|x86 |x86-64
https://bugs.winehq.org/show_bug.cgi?id=36863
--- Comment #4 from Henri Verbeet hverbeet@gmail.com --- (In reply to Tim from comment #3)
I have created a backtrace with debug symbols, I hope that shines some light on the issue
Not as much as I had perhaps hoped, but it seems to die very early during wined3d initialization. Could you please attach a WINEDEBUG="+seh,+tid,+wgl,+d3d" log? Is this specific to Mass Effect 3, or do other Direct3D applications crash in the same way?
https://bugs.winehq.org/show_bug.cgi?id=36863
--- Comment #5 from Tim phisig791@gmail.com --- Created attachment 48967 --> https://bugs.winehq.org/attachment.cgi?id=48967 WINEDEBUG=+seh,+tid,+wgl,+d3d
https://bugs.winehq.org/show_bug.cgi?id=36863
--- Comment #6 from Tim phisig791@gmail.com --- ME3 is the only D3D game I have available for me to test unfortunately
https://bugs.winehq.org/show_bug.cgi?id=36863
--- Comment #7 from Henri Verbeet hverbeet@gmail.com --- I'm not quite sure what went wrong, but that log doesn't have the requested debug channels.
https://bugs.winehq.org/show_bug.cgi?id=36863
--- Comment #8 from Tim phisig791@gmail.com --- Oops, how embarrassing. The log file with those channels is too big to attach, here is a link to it on filedropper http://www.filedropper.com/me3crash
https://bugs.winehq.org/show_bug.cgi?id=36863
--- Comment #9 from Henri Verbeet hverbeet@gmail.com --- It seems to crash somewhere around wglCreateContext() / wglMakeCurrent() in wined3d_caps_gl_ctx_create(), but earlier calls to that succeeded. At this point my best guess would be some kind of memory corruption, perhaps of the context's GL function table. Is there any chance this is some kind of duplicate of bug 34367? Specifically, does the workaround in https://bugs.winehq.org/show_bug.cgi?id=34367#c14 make it any better?
https://bugs.winehq.org/show_bug.cgi?id=36863
Anastasius Focht focht@gmx.net changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |obfuscation Status|UNCONFIRMED |NEW CC| |focht@gmx.net Component|directx-d3dx9 |opengl Summary|Mass Effect 3 [Origin] |Mass Effect 3 [Origin] |crash on startup |crash on startup (broken EA | |Origins in-game | |overlay/hook engine | |'igo32.dll' needs | |'opengl32.dll' prelinked < | |2GB address range) Ever confirmed|0 |1
--- Comment #10 from Anastasius Focht focht@gmx.net --- Hello folks,
confirming.
It's a bug in EA Origin's in-game overlay hook engine 'igo32.dll' which is uncovered by differences in user process address space layout Windows vs. Linux.
The hook dll is injected in all child processes, starting from the initial process (origin launcher or game).
It checks the process addresses spaces for loaded third-party dlls, patched entry points (already hooked/hacked) and the like.
A number of 'user32.dll', 'opengl32.dll', 'd3d[8|9|10|11].dll' APIs get hooked. The hook engine seems a bit more flexible than Valve's 'gameoverlayrenderer' when it comes to handling of different kinds of entry points (hotchpatch entry is not required).
It disassembles the entry points to figure out the optimal patch pattern (instruction length) and sets up a trampoline for it.
The first choice is the 5-byte 'jmp' relative instruction (opcode 0xE9) which is limited to a range of 2GB from the jump instruction address. 32-bit Windows applications can get almost 3GB of user mode virtual address space. Windows core dlls will be still mapped below the 2GB boundary for compatibility reasons (also limiting how big any one contiguous block can be).
The final jump distance to 'igo32.dll' is validated if 2GB is exceeded (>0x7FFF0000). The hooker emits an IAT style thunk with an absolute jump in that case and gets it _really_ wrong.
Various 32-bit builtin dlls are mapped to high address range in my 64-bit WINEPREFIX (WoW64):
--- snip -- Modules: Module Address Debug info Name (182 modules) PE 390000- 3a6000 Deferred xinput1_3 PE 3b0000- 3db000 Deferred physxextensions PE 400000- 1b16000 Export masseffect3 PE 2100000- 22e5000 Deferred d3dx9_42 PE 3550000- 40b8000 Deferred eacore PE 7980000- 7992000 Deferred physxloader PE 7ab0000- 7b0d000 Deferred physxcooking PE 7c20000- 7f7a000 Deferred physxcore PE 7f80000- 7fed000 Deferred cudart32_41_4 PE 10000000-1020a000 Export igo32 PE 18000000-1803b000 Deferred binkw32 PE 40000000-400f0000 Export awc ELF 7b800000-7ba62000 Dwarf kernel32<elf> -PE 7b810000-7ba62000 \ kernel32 ELF 7bc00000-7bcee000 Dwarf ntdll<elf> -PE 7bc10000-7bcee000 \ ntdll ELF 7bf00000-7bf04000 Dwarf <wine-loader> ... ELF f630a000-f630e000 Deferred libnvidia-tls.so.331.67 ELF f630e000-f6327000 Deferred userenv<elf> -PE f6310000-f6327000 \ userenv ELF f6327000-f6369000 Dwarf d3d9<elf> -PE f6330000-f6369000 \ d3d9 ELF f63c1000-f63dd000 Deferred wsock32<elf> -PE f63d0000-f63dd000 \ wsock32 ELF f63dd000-f63f5000 Deferred d3dx10_42<elf> -PE f63e0000-f63f5000 \ d3dx10_42 ELF f63f5000-f6468000 Deferred setupapi<elf> -PE f6400000-f6468000 \ setupapi ELF f6468000-f6484000 Deferred dinput8<elf> -PE f6470000-f6484000 \ dinput8 ... ELF f6e3c000-f6f58000 Deferred opengl32<elf> -PE f6e60000-f6f58000 \ opengl32 ELF f6f58000-f70cc000 Dwarf wined3d<elf> -PE f6f70000-f70cc000 \ wined3d ELF f70cc000-f70f3000 Deferred dxgi<elf> -PE f70d0000-f70f3000 \ dxgi ... ELF f7546000-f76fc000 Dwarf libwine.so.1 ELF f76fd000-f771e000 Deferred ld-linux.so.2 ELF f771e000-f771f000 Deferred [vdso].so --- snip ---
The hooker saves 8 bytes from API entry away to another structure and sets up a "reverse trampoline".
Basically it looks like this...
0x1xxxxxxx <hook dll/code> ... trampoline_structXX: 0x6xxxxxxx <old entry opcode save> final_trampolineXX: 0x6xxxxxxx jmp 0x1xxxxxxx ... 0xfxxxxxxx (APIENTRY+0) jmp [<abs>] -> 0xFF,0x25,[32-bit thunk table address] 0xfxxxxxxx (APIENTRY+6) [thunk table, 4-byte ptr -> final trampoline 0x6xxxxxxx] 0xfxxxxxxx (APIENTRY+A) <unchanged original opcodes> ...
The code is broken: only a part(!) of the 32-bit thunk table entry gets written out hence the execution of the absolute (indirect) jump will pick up a garbage address, depending on what partial instruction is present at 'APIENTRY+8'.
Some "genius" tried to be clever by using atomic 'LOCK CMPXCHG8B QWORD PTR DS:[EDI]' batch write, missing out the remainder.
Examples:
--- snip --- F6EF9B5A FF25 609BEFF6 jmp [F6EF9B60] ; thunk entry value: 0x83F00040 F6EF9B60 40 inc eax F6EF9B61 00F0 add al,dh F6EF9B63 83EC 40 sub esp,40 F6EF9B66 E8 65BFF7FF call F6E75AD0 ; __x86.get_pc_thunk.bx --- snip ---
--- snip --- F6EE8B4A FF25 508BEEF6 jmp [F6EE8B50] ; thunk entry value: 0x40EC0040 F6EE8B50 40 inc eax F6EE8B51 00EC add ah,ch F6EE8B53 40 inc eax F6EE8B54 E8 77BFF7FF call F6E64AD0 ; __x86.get_pc_thunk.bx --- snip ---
To avoid the broken "reverse trampoline" code, I prelinked 'opengl32.dll' to a virtual address < 2GB.
It allowed the game to run a bit further - only to run into next hook problem which should be subject to a new bug:
'Direct3DCreate9' -> 'wined3d_caps_gl_ctx_create' -> hooked 'wglCreateContext'
The hook calls Wine 'wglCreateContext' _and_ immediately 'wglGetCurrentDC' and 'wglGetCurrentContext' which fails because the caps GL context is made current _after_ return to 'wined3d_caps_gl_ctx_create'.
Regards
http://bugs.winehq.org/show_bug.cgi?id=36863
jre.winesim@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |jre.winesim@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=36863
--- Comment #11 from jre.winesim@gmail.com --- I assume I have the very same here for Origin + SimCity2013.
Workaround: In the Origin window go to "Origin - Application Settings - Origin In Game" and untick "Enable Origin In Game". (In the past it was recommended to remove IGO32.dll instead. But this doesn't work anymore.)
I can provide the backtrace or output of WINEDEBUG=+seh,+tid,+wgl,+d3d. The latter is 100MB, with bzip2 -z9 still 1.7MB. So if you can use it please tell me if I should edit it, split it or post somewhere else.
Probably this bug is a duplicate of bug 33141 reported for SimCity 2013 (https://bugs.winehq.org/show_bug.cgi?id=33141).
https://bugs.winehq.org/show_bug.cgi?id=36863
--- Comment #12 from Anastasius Focht focht@gmx.net --- Hello folks,
I don't see why this should be a dupe of bug 33141 (that bug is kind of messed up anyway). The presence of 'igo32.dll' doesn't automatically mean it's the same issue.
There is no need to act/comment further here since the problem is well understood - at least for the target audience.
Regards
https://bugs.winehq.org/show_bug.cgi?id=36863
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |austinenglish@gmail.com
--- Comment #13 from Austin English austinenglish@gmail.com --- Created attachment 49925 --> https://bugs.winehq.org/attachment.cgi?id=49925 patch
Please test.
https://bugs.winehq.org/show_bug.cgi?id=36863
--- Comment #14 from jre.winesim@gmail.com --- (First off, sorry Anastasius, I definitely don't want to clutter bug reports and waste developers' time. Still one part of my message was aimed to provide users with a working workaround).
I hope it is ok that I post my non-ME3 findings here.
I patched wine 1.7.30 (otherwise using current Debian packaging).
I could start SimCity 2013 from Origin, then the SimCity start menu appeared. After being responsive for a few seconds it froze, while the music still continued. (This happened if I did nothing. If I clicked some IGO-only links in the menu I got an error message that the file type was not registered in Windows (so it worked), then it froze. If I clicked "play" it switched to a black frozen screen.) I could still use e.g. the Origin window though, but couldn't close it or the whole virtual desktop window, since "SimCity is running". After killing the SimCity process everything was back to normal. In about 1 of ten tests SimCity didn't freeze, but crashed.
With an unpatched wine SimCity *always* crashes if IGO is enabled.
So definitely a difference, SimCity freezes instead of crashing. I might test with ME3 once downloading in Origin works again.
https://bugs.winehq.org/show_bug.cgi?id=36863
--- Comment #15 from jre.winesim@gmail.com --- I now tested Austin's patch with ME3 (started from Origin):
- With unpatched wine MassEffect3.exe crashes shortly after starting ME3. (Same "fixme:dbghelp:validate_addr64 Unsupported address ..." followed by "wine: Unhandled page fault on read access to ..." as for Tim.)
- With patched wine it doesn't crash anymore, but freezes shortly after starting ME3 (sometimes just nothing happens, sometimes the screen resolution switches and I get a partly drawn Origin window, but nothing more happens). I have to kill the MassEffect3.exe process to get at least Origin responsive again.
- It works if "Origin In Game" is disabled.
So I assume Austin's patch fixes/workarounds the inital problem, but then just another, independent (?) problem arises. (Just like for Anastasius with his test prelinking 'opengl32.dll' to a virtual address < 2GB.)
Should I provide anymore information here?
https://bugs.winehq.org/show_bug.cgi?id=36863
--- Comment #16 from Anastasius Focht focht@gmx.net --- Hello folks,
--- quote --- Should I provide anymore information here? --- quote ---
Everything needed has been said. Follow-up issues are not being discussed here.
Regards
https://bugs.winehq.org/show_bug.cgi?id=36863
--- Comment #17 from Austin English austinenglish@gmail.com --- https://source.winehq.org/patches/data/107807
https://bugs.winehq.org/show_bug.cgi?id=36863
Sebastian Lackner sebastian@fds-team.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de
--- Comment #18 from Sebastian Lackner sebastian@fds-team.de --- Patch committed:
http://source.winehq.org/git/wine.git/patch/c62514b953fb523107501277520030c3...
https://bugs.winehq.org/show_bug.cgi?id=36863
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |c62514b953fb523107501277520 | |030c335e9accb Status|NEW |RESOLVED Resolution|--- |FIXED
--- Comment #19 from Austin English austinenglish@gmail.com --- (In reply to Sebastian Lackner from comment #18)
Patch committed:
http://source.winehq.org/git/wine.git/patch/ c62514b953fb523107501277520030c335e9accb
Marking fixed.
https://bugs.winehq.org/show_bug.cgi?id=36863
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #20 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 1.7.32.
-
wine-bugs＠winehq.org