[BUG]: DirectInput Vibration Motor Mappings Crash PCSX2

[RedPanda4552]

Describe the Bug

A user described an issue where on the latest 64 bit dev builds, having a DirectInput based vibration mapping will cause the emulator to crash when the vibration is tested in the menu or when booting a game. They described that there was no obvious issue in the logs, so trace logging or reproducing via VS debugger might be necessary. Their controller is a DS2 clone.

My attempts to reproduce on an Xinput controller yielded no results, and I was unable to map vibration motors on my controller in DirectInput mode.

Reproduction Steps

Bind a vibration motor over DirectInput, hit the Test button or boot a game.

Expected Behavior

Emulator should not crash.

PCSX2 Revision

1.7-2016

Operating System

Windows 10 (64bit)

If Linux - Specify Distro

No response

CPU

Intel i5-2410M

GPU

AMD Radeon 6600M

GS Settings

No response

Emulation Settings

No response

GS Window Screenshots

No response

Logs & Dumps

No response

[Squall-Leonhart]

This is likely one of the various twin stick clones which has a known faulty 64bit FFB library (EZFRD64.DLL) that only works prior to 2016 (broken by windows code security changes in 7, 8 and 10). The driver is also utilised by Mayflash adapters.

My own XBCDR library is unaffected.

Removal of the DLL or using 32bit builds are the only good user side fixes, the crash occurs within the FFB library itself and working around could facilitate undefined behavior or possible security vulnerability.

Shuffle2 investigated back in 2017

There is a fixed version of the library available in Mayflash package W013 but a legitimate dl for it cannot be found and apparently its bound to the mayflash device id programatically.

A hotpatch was introduced in dolphin-emu with https://github.com/dolphin-emu/dolphin/commit/9c8e26bdff4a074f1a58f5fa23a818233e6890f4

[RedPanda4552]

This is likely one of the various twin stick clones which has a known faulty 64bit FFB library (EZFRD64.DLL) that only works prior to 2016 (broken by windows code security changes in 7, 8 and 10). The driver is also utilised by Mayflash adapters.

My own XBCDR library is unaffected.

Removal of the DLL or using 32bit builds are the only good user side fixes, the crash occurs within the FFB library itself and working around could facilitate undefined behavior or possible security vulnerability.

Shuffle2 investigated back in 2017

There is a fixed version of the library available in Mayflash package W013 but a legitimate dl for it cannot be found and apparently its bound to the mayflash device id programatically.

A hotpatch was introduced in dolphin-emu with dolphin-emu/dolphin@9c8e26b

If this is the case I see two viable futures, as we're not really in the interest of lugging around driver patches which ultimately should be other groups' responsibilities.

First future, if someone with a susceptible controller can reproduce the issue and diagnose where in the program it first runs in to trouble, we can catch the problem at runtime and dynamically disable rumble motors, pop a message box or print to console that vibration motors are not supported on x64 and keep them disabled for the rest of the program lifecycle. If we want to avoid this becoming "the DX fix" perhaps there are ways to make it a generic "vibration motor health check".

Second future, say screw this it's not our job to handle it, at all, and leave it be.

Both completely reasonable, just a question of project ideology. Thoughts anyone?

[Squall-Leonhart]

in the latter case rather than doing it dynamically you can outright block the affected DLL, as this project has

https://github.com/7hong13/Aircom/blob/e73a0eae740b8b5aa913940cbf1420b5b156af43/client_pc/AntiHooking/antihookingprotection.cpp

[RedPanda4552]

Some deliberation with staff on Discord - consensus is that it is not the project's responsibility to implement driver patches or driver detection, and this falls to users to patch their controllers, or use some kind of compatibility layer for controllers which have this kind of issue with modern operating systems.

[Squall-Leonhart]

There is no driver update available, so it falls to end users to not use the affected controller, learn how to mitigate the issue (delete the dll), or developers blocking the file,

use some kind of compatibility layer for controllers which have this kind of issue with modern operating systems.

You're a linux oriented dev, arent you :p

[refractionpcsx2]

He's windows, but I agree with him. It shouldn't be on us to make somebody elses shitty software not crash. If your controller has shitty software, find a 3rd party driver or buy a better controller.

[Squall-Leonhart]

I don't disagree, its the same stance i'm taking with EZFRD64.DLL related crashes in X360CE.

The afflicted file is actually blacklisted by kernel anticheats anyway,

I'm sure someone will encounter this when looking for EZFRD64.dll crashes, the user workaround is to delete the file from C:\Windows\USB Vibration\

I'll keep my eye out for a replacement dll, but I'm not keeping my hopes up since the one known to be fixed is built to target a specific mayflash adapter.

[Arktis4]

I have the same problem with my favorite gamepad (EXEQ BattleGear), which I have been using since 2009. The program crashes on vibration test and when trying to run the game. I've been using PCSX2 for almost 10 years and never had any problem with this gamepad. Only on 64-bit builds PCSX2 started to conflict with it. Controller doesn't conflict with other emulators, and vibration works in them. I will be very grateful if you can fix this bug in new builds. This gamepad is perfect for me and its vibration is especially good. I wouldn't want to lose it. Thanks!

[stenzek]

The "fix" is to not use this broken driver. Hot-patching stuff that isn't even our code (like dolphin does) is likely to break in the future, and frankly, not our problem.

Controller doesn't conflict with other emulators, and vibration works in them.

Obviously they're not 64-bit then.