https://bugs.winehq.org/show_bug.cgi?id=46142
Bug ID: 46142 Summary: Games launched through Windows Steam no longer launch. Product: Wine-staging Version: 3.20 Hardware: x86 OS: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown Assignee: wine-bugs@winehq.org Reporter: abienz@gmail.com CC: leslie_alistair@hotmail.com, z.figura12@gmail.com Distribution: ---
Created attachment 62784 --> https://bugs.winehq.org/attachment.cgi?id=62784 Console output
Since a new update to the Steam client from last week games no longer load.
using the following command:
WINEPREFIX=~/.wineprefixes/grim-dawn WINEDEBUG=fixme-all,+error,+trace DXVK_LOG_LEVEL=error wine .wine/drive_c/Program\ Files\ (x86)/Steam/Steam.exe
Steam loads successfully with some errors in console (see SteamLaunch.txt).
Upon launching the game (Grim Dawn in this case) I get a black screen and can hear the intro music (see GameLaunch.txt).
Normally I would see the Developer logo and can press any key to skip, but no logo appears and no keypresses do anything, eventually I am presented with a 'non response' dialogue and can force quit.
I have to date tried:
* Reinstalling the game in a new prefix * Removing DLC and trying the vanilla version * Changing DLL overrides * Launching the game with DX9 mode instead of DX11 * Changing Windows version through winecfg * Installing Samba due to an error received in the console (error no longer shows, but doesn't improve situation) * Tried with and without DXVK
I have also created a forum post here:
https://forum.winehq.org/viewtopic.php?f=8&t=31431&sid=afd6cc677f7d5...
My system is as follows:
OS: Arch Linux Kernel: x86_64 Linux 4.18.16-arch1-1-ARCH CPU: Intel Core i5-4670K @ 4x 3.8GHz [27.8°C] GPU: GeForce GTX 1070 RAM: 3129MiB / 15913MiB
Wine-staging 3.19 and 3.20 were used in testing, installed via the AUR
https://bugs.winehq.org/show_bug.cgi?id=46142
abienz@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |abienz@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #1 from Zebediah Figura z.figura12@gmail.com --- What other games fail to run?
Is this problem present with upstream (non-Staging) Wine?
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #2 from abienz@gmail.com --- I've also tried The Witcher 3, another user has come across this issue can't play Skyrim anymore.
We did find that it seems to be related to direct3D, as OpenGL games work such as Doki Doki, and No Man's Sky.
More information here: https://www.reddit.com/r/wine_gaming/comments/9vgivt/steam_stack_overflow_er...
I haven't tried regular Wine, but I feel this issue is to do with the Steam update.
https://bugs.winehq.org/show_bug.cgi?id=46142
alasky@codeweavers.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |alasky@codeweavers.com
https://bugs.winehq.org/show_bug.cgi?id=46142
Ivan Kalvachev iive@yahoo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |iive@yahoo.com
--- Comment #3 from Ivan Kalvachev iive@yahoo.com --- Created attachment 62785 --> https://bugs.winehq.org/attachment.cgi?id=62785 Left4Dead2 backtrace of crash related to SteamOverlayRenderer
I'm having the same issue.
My wineprefix is quite old, used to be "WinXP" until recently. It is currently set to "Win7". I'm using upstream Wine (no staging). After a "Steam" update most of my games crash at startup. Some games crash after launch, other seems to play fine. It tested with Wine-3.20, Wine-3.19 and Wine-3.01.
I think the issue is related to steamoverlayrenderer. I'm currently poking with Left4Dead2.exe as it crashes at launch. ("HL2 Lost Coast "demo seems to do the same.)
When I start steam with `WINEDEBUG=+relay` one additional perk is that SEH seems to be overridden and I am able to get winedbg backtrace. (I'm attaching a saved result.).
The crash seems to happen in xinput1_3.dll.so . The backtrace point to __x86.get_pc_thunk.dx+0x61() , however that is red herring. The real function crashing is __wine_spec_relay_entry_points()
SteamOverlayLog.txt shows that it 8 functions from Xinput are been hooked. That seems to be all exported ones.
I tried adding "DECLSPEC_HOTPATCH" to all the functions in `wine-3.20/dlls/xinput1_3/xinput_main.c`. Unfortunately this did not fix the issue. I even tried replacing the xinput1_3.dll fakedll.
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #4 from Ivan Kalvachev iive@yahoo.com --- I just want to add that I do not have joystick or gamepad. This is important as xinput seems to be about gamepads.
I added "xinput1_3" to the dll overrides and set it to (disabled).
This allowed me to start the game. So try that as workaround.
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #5 from Ivan Kalvachev iive@yahoo.com --- Well, there is a setback. With the workaround it seems I am not getting mouse movements. Buttons do work.
Now.. the bug may indeed be linked to Direct3D too.
The l4d2 game starts and works in the menu, but when I start a singleplayer level, it hangs in the first second. I do not see crash, the sound just loops. I can switch away and kill it. Nothing interesting in the logs.
The more interesting thing is that when I use Gallium Nine, the game actually works, I just get the mouse issue. I know for a fact that Nine has ms-hook (DECLSPEC_HOTPATCH) on every single function, so there is good chance that it might be patching issue. (Gallium Nine does not work without the xinput workaround.)
Oh, btw. Steam Overlay is loaded even if you try to disable it for the game...
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #6 from Andrey Gusev andrey.goosev@gmail.com --- Spintires: MudRunner crashes upon entering main menu.
'err:seh:setup_exception_record stack overflow 1248 bytes in thread 01c5 eip 7bc448b6 esp 00240e50 stack 0x240000-0x241000-0x340000'
With 'xinput1_3 - disabled' game launches with 3-5 FPS. Camera movement is slow. With 'gameoverlayrenderer - disabled' game launches and runs smoothly.
wine-3.20-70-gead7e637c0
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #7 from Ivan Kalvachev iive@yahoo.com --- Winetricks can install native windows `xinput` that seems to work fine. So I got mouse movement back in l4d2 with Nine.
WineD3D still hangs.
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #8 from abienz@gmail.com --- So adding 'gameoverlayrenderer' to my Library overrides, and setting it to 'disabled' allowed me to launch and play my games with usual performance.
In my game prefixes I don't have xinput overrides, but in my standard wine prefix where Steam is installed I have the following:
xinput1_3 (native, builtin) xinput9_1_0 (native, builtin)
Not sure if this is relevant to the above issues mentioned in the comments too.
https://bugs.winehq.org/show_bug.cgi?id=46142
Zebediah Figura z.figura12@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Product|Wine-staging |Wine Component|-unknown |-unknown
--- Comment #9 from Zebediah Figura z.figura12@gmail.com --- Setting product to Wine as per comment 3.
Comments 3 and 5 strongly suggest hot-patching, but you state that you tried and failed to hot-patch xinput1. Did you make sure +relay was off while running it? Hot-patching won't work if relay thunks are used.
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #10 from Ivan Kalvachev iive@yahoo.com --- Just to be 100% sure I did retest again.
I still get the stack corruption with all xinput_main.c functions having the ms-hook-prologue attribute. I did add it to DllMain() too, just in case. No dice.
From the GameOverlayRenderer.log I know that all 8 functions are patched, so
they need the hook attribute.
Unfortunately there seems to be unknown problem that still needs investigation.
I can't find a way to debug that myself as running `winedbg` is nightmare... I'm getting millions of exception for float point lost precision in gdi32.dll .
Let me ask you, can you start 'HL2 Lost Coast' on your system? AFAIK it is a tech demo so it should be freely accessible.
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #11 from Zebediah Figura z.figura12@gmail.com --- (In reply to Ivan Kalvachev from comment #10)
Just to be 100% sure I did retest again.
Alright, thanks for testing. I guess something else is strange that causes native xinput1 to work...
I can't find a way to debug that myself as running `winedbg` is nightmare... I'm getting millions of exception for float point lost precision in gdi32.dll .
If you're running in --gdb mode, you can `handle SIGFPE noprint` to ignore those. (There's no equivalent option for non-gdb mode; it's something I've been meaning to change, but I have quite a lot on my plate)
Let me ask you, can you start 'HL2 Lost Coast' on your system? AFAIK it is a tech demo so it should be freely accessible.
I'll try to find the time to try that one out.
https://bugs.winehq.org/show_bug.cgi?id=46142
Kimmo Myllyvirta kimmo.myllyvirta@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |kimmo.myllyvirta@gmail.com
--- Comment #12 from Kimmo Myllyvirta kimmo.myllyvirta@gmail.com --- Created attachment 62801 --> https://bugs.winehq.org/attachment.cgi?id=62801 fix for xinput1_3
Did some debugging;
<repeats thousands of times> 009e:009f:trace:xinput:XInputGetState (index 0, state 0x1434d0)! 009e:009f:trace:xinput:XInputGetState (index 0, state 0x143350)! 009e:009f:trace:xinput:XInputGetState (index 0, state 0x1431d0)! 009e:009f:trace:xinput:XInputGetState (index 0, state 0x143050)! 009e:009f:trace:xinput:XInputGetState (index 0, state 0x142ed0)! 009e:009f:trace:xinput:XInputGetState (index 0, state 0x142d50)! 009e:009f:trace:xinput:XInputGetState (index 0, state 0x142bd0)! 009e:009f:err:seh:setup_exception stack overflow 1728 bytes in thread 009f eip 00007fcaf508e5ea esp 0000000000140f50 stack 0x140000-0x141000-0x2140000
Notice that XInputGetState calls XInputGetStateEx unconditionally, but its trace is missing. XInputGetStateEx is hooked, and the hook eventually calls XInputGetState -> infinite recursion.
For example, with Witcher 3; Stopped on breakpoint 1 at 0x00007efc917d0929 XInputGetState+0x82 [/home/des/projects/wine-git-staging/dlls/xinput1_3/xinput_main.c:94] in xinput1_3 94 ret = XInputGetStateEx(index, state); 0x00007efc917d073a XInputGetStateEx in xinput1_3: jmp 0x00007efc8ed6070d 0x00007efc8ed6070d: jmpl *(%rip) -> gameoverlayrenderer64 0x000000000299cb10: movq %rdx,%r8 .... 0x000000000299b8d7: calll *%r8d 00da:fixme:winedbg:be_x86_64_is_func_call Unsupported yet call insn (rex=0x01 0xFF 0xd0) at 0x299b8d8 0x00007efc8ed606c0: leaq (%rsp),%rsp 0x00007efc8ed606c8: jmp 0x00007efc917d08a7 XInputGetState -> and here we go again 0x00007efc917d08a7 XInputGetState [/home/des/projects/wine-git-staging/dlls/xinput1_3/xinput_main.c:89] in xinput1_3: pushq %rbp ...
So, XInputGetState must not call XInputGetStateEx. Here's a quick fix, tested with Witcher 3 and Sprintires Mudrunner.
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #13 from Ivan Kalvachev iive@yahoo.com --- (In reply to Kimmo Myllyvirta from comment #12)
Created attachment 62801 [details] fix for xinput1_3
Did some debugging;
<repeats thousands of times> 009e:009f:trace:xinput:XInputGetState (index 0, state 0x1434d0)! 009e:009f:trace:xinput:XInputGetState (index 0, state 0x143350)!
[...]
So, XInputGetState must not call XInputGetStateEx. Here's a quick fix, tested with Witcher 3 and Sprintires Mudrunner.
I can confirm that the proposed patch fixes the issue for me too. At least for these who use xinput1_3.
That was a good catch. I really can't believe I missed enabling +xinput verbosity. Well, at least from now on I will know that this stack error likely means infinite loop.
Thinking about that, it makes sense, as historically XInputGetState() is likely implemented first, so the *Ex() extended function would call the old one. But in wine the opposite happens.
Anyway, great work at solving the mystery!
Now only the D3D problem remains.
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #14 from Zebediah Figura z.figura12@gmail.com --- (In reply to Ivan Kalvachev from comment #13)
Thinking about that, it makes sense, as historically XInputGetState() is likely implemented first, so the *Ex() extended function would call the old one. But in wine the opposite happens.
Well, no, not really; Ex functions have more features than their original counterparts, so you can't implement them like that. (E.g. we would lose the information about whether XINPUT_GAMEPAD_GUIDE is set.)
More likely both call down to a common function. I've sent a patch to that effect.
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #15 from Ivan Kalvachev iive@yahoo.com --- (In reply to Zebediah Figura from comment #14)
(In reply to Ivan Kalvachev from comment #13)
Thinking about that, it makes sense, as historically XInputGetState() is likely implemented first, so the *Ex() extended function would call the old one. But in wine the opposite happens.
Well, no, not really; Ex functions have more features than their original counterparts, so you can't implement them like that. (E.g. we would lose the information about whether XINPUT_GAMEPAD_GUIDE is set.)
Why would you lose information? You just call the old function first, it fills the old fields, then you add the new information.
Also XInputGetStateEx() seems to be undocumented function and it seems to take pointer to a structure that is containing additional DWORD. That's why you need a new function, to use bigger structure than the old one.
Anyway, moving the code to internal function is fine solution that would work in all cases.
More likely both call down to a common function. I've sent a patch to that effect.
Your patch does not add HOTPATCH to all the functions. That should be done too.
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #16 from Zebediah Figura z.figura12@gmail.com --- The issue reported in comment 12 has been fixed by https://source.winehq.org/git/wine.git/commitdiff/b72da1fdef65ced62c8d7bf681.... I'm hesitant to close this bug just yet, mind, since it seems likely all of the problems reported here are of the same class of bug, and filing a chain of bug reports in the interest of separation just seems gratuitous.
(In reply to Ivan Kalvachev from comment #15)
Why would you lose information? You just call the old function first, it fills the old fields, then you add the new information.
Well, yes, but that would require repeating the calls to whatever XInputGetState() used to gather its information. Almost always it makes more sense to implement an older function on top of a newer one.
Your patch does not add HOTPATCH to all the functions. That should be done too.
Has that been established?
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #17 from Ivan Kalvachev iive@yahoo.com --- (In reply to Zebediah Figura from comment #16)
Your patch does not add HOTPATCH to all the functions. That should be done too.
Has that been established?
As I've said, I've seen this in the Steam/GameOverlayRenderer.log : --- Sat Nov 17 01:59:55 2018 UTC - hookDirect3DCreate9 called Sat Nov 17 01:59:56 2018 UTC - XInput Hooked XInputEnable Version 13 Sat Nov 17 01:59:56 2018 UTC - XInput Hooked XInputGetBatteryInformation Version 13 Sat Nov 17 01:59:56 2018 UTC - XInput Hooked XInputGetCapabilities Version 13 Sat Nov 17 01:59:56 2018 UTC - XInput Hooked XInputGetDSoundAudioDeviceGuids Version 13 Sat Nov 17 01:59:56 2018 UTC - XInput Hooked XInputGetKeystroke Version 13 Sat Nov 17 01:59:56 2018 UTC - XInput Hooked XInputGetState Version 13 Sat Nov 17 01:59:56 2018 UTC - XInput Hooked XInputGetStateEX Version 13 Sat Nov 17 01:59:56 2018 UTC - XInput Hooked XInputSetState Version 13 Sat Nov 17 01:59:58 2018 UTC - Game is using dxgi (dx10/dx11), preparing to hook. ---
Maybe steam hook engine is smart enough to handle what my current compiler generates, but there is no guarantee that this will be valid for all (current and future) compilers.
https://bugs.winehq.org/show_bug.cgi?id=46142
Robert Walker bob.mt.wya@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |bob.mt.wya@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #18 from Zebediah Figura z.figura12@gmail.com --- Apologies; I missed that. https://source.winehq.org/git/wine.git/commitdiff/69e0e1cf3f91043786f2a7dcc2... has been committed for that; I guess the last thing blocking this bug is d3d? Is there a list of d3d hooks?
https://bugs.winehq.org/show_bug.cgi?id=46142
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |b72da1fdef65ced62c8d7bf6813 | |cc11ca364528c Component|-unknown |xinput Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED
--- Comment #19 from Matteo Bruni matteo.mystral@gmail.com --- I think it's time to close this bug. The original issue is fixed by b72da1fdef65ced62c8d7bf6813cc11ca364528c, which is in Wine 3.21. Thank you Kimmo for the analysis.
https://bugs.winehq.org/show_bug.cgi?id=46142
Anthony Jagers noonetinone@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |noonetinone@gmail.com
https://bugs.winehq.org/show_bug.cgi?id=46142
Matteo Bruni matteo.mystral@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |milo@meelo.org
--- Comment #20 from Matteo Bruni matteo.mystral@gmail.com --- *** Bug 46131 has been marked as a duplicate of this bug. ***
https://bugs.winehq.org/show_bug.cgi?id=46142
--- Comment #21 from Ivan Kalvachev iive@yahoo.com --- (In reply to Zebediah Figura from comment #18)
Apologies; I missed that. https://source.winehq.org/git/wine.git/commitdiff/ 69e0e1cf3f91043786f2a7dcc20b866d6c3a4395 has been committed for that; I guess the last thing blocking this bug is d3d? Is there a list of d3d hooks?
Unfortunately, the log does not list individual d3d hooks.
However when the game hangs I can switch and see that wined3d_query_get_data() is running 75% of the time.
Starting the game with WINEDEBUG=d3d, produces huge number of the following lines: --- 012f:trace:d3d:wined3d_query_get_type query 0x2853c580. 012f:trace:d3d:wined3d_query_get_data query 0x2853c580, data 0x4d57fcfc, data_size 4, flags 0x1. 012f:warn:d3d:wined3d_query_get_data Ignoring flags 0x1. 012f:trace:d3d:wined3d_query_get_type query 0x2853c580. 012f:trace:d3d:wined3d_query_get_data query 0x2853c580, data 0x4d57fcfc, data_size 4, flags 0x1. 012f:warn:d3d:wined3d_query_get_data Ignoring flags 0x1.
---
It is likely another infinite loop, but this one probably does not crash because of the csmt. Unfortunately the functions from the log does not call each-other directly.
Is there already another bugreport for this bug? Should I open a new one?
https://bugs.winehq.org/show_bug.cgi?id=46142
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #22 from Alexandre Julliard julliard@winehq.org --- Closing bugs fixed in 4.0-rc1.
-
wine-bugs＠winehq.org