http://bugs.winehq.org/show_bug.cgi?id=36059 --- Comment #2 from Anastasius Focht <focht(a)gmx.net> --- Hello Stefan, --- quote --- Setting xinput1_*=disabled in winecfg for Steam.exe works for me. That's more permanent than deleting the file, and doesn't have to be done for each game. --- quote --- Yes, there are several ways to work around .. the list was not meant to be exhaustive :) More ways: * Place 'xinput1_3.dll' in the folder where 'Steam.exe' lives. Due to loader search strategy, this one will be picked up and hence avoid locking the one from 'system32', allowing replacement. * Pass 'SDL_XINPUT_ENABLED=0' environment variable when starting Steam client. Magic happens. --- quote --- I suspected that the problem happens because our xinput1_1 loads xinput1_3, but after reading your analysis and doing more checks I realized my theory was incorrect. --- quote --- Builtin 'xinput1_4.dll' is explicitly loaded by Steam client, it late binds to xinput1_4.XInputSetState(). Due to forwarder mechanism, builtin 'xinput1_3.dll' gets delay loaded (xinput1_4.XInputSetState -> xinput1_3.XInputSetState). Wine's builtin 'xinput1_3.dll' gets unloaded again because of native preference (pre-attach hook) and native 'xinput1_3.dll' is ultimately loaded from 'system32' folder. 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.