Crashes the moment a controller connected

[potatoxbe]

On Windows 11, game crashes the moment a controller is connected. If I launch the game with controller already connected, white screen appears then closes. If a controller is connected midway through the menu and gameplay, crashes.

Testing on Xbox Series X controller with the official USB adapter, and Dualshock 4 with the 8bitdo adapter, and connecting the controller directly to USB. Both displays same behaviour. So only works with keyboard. All settings are kept at default. VC redistributable to latest. Any help?

[mendegen]

I'm having exactly this issue on Windows 11 using a Dualsense.

[fklfkl]

I'm having exactly this issue on Windows 11 using a Dualsense.

We debugged the crash on this user's machine, it was a mutex lock in the safetyhook library when applying these particular hooks:

• AllowUncompressedBGM (calls safetyhook::create_mid)
• FixPegasusClopping (calls safetyhook::create_inline)
• PreventDESTSaveCorruption (safetyhook::create_mid)
• FixFullPedalChecks (safetyhook::create_inline)

After disabling those hooks it crashes in ReplaceGameUpdateLoop which also sets up a hook, that's about as far as we were able to get today.

The crash was the std::scoped_lock in allocator.cpp of safetyhook:

std::shared_ptr<Allocator> Allocator::global() {
    static std::weak_ptr<Allocator> global_allocator{};
    static std::mutex global_allocator_mutex{};

    std::scoped_lock lock{global_allocator_mutex}; // crash

    if (auto allocator = global_allocator.lock()) {
        return allocator;
    }

    ...

Possibly related - however these both mention safetyhook::trap_threads which I don't think we saw in the call stacks at any point:

• https://github.com/cursey/safetyhook/issues/79
• https://github.com/cursey/safetyhook/issues/70

We tried to record a trace with TTD.exe but it errored out. I hope to grab a memory dump next time I'm able to debug on that machine

[emoose]

Are they running with the latest VC redist installed? There was a pretty recent change around the std::mutex constructor which caused issues when an older redist was used, the _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR build define is meant to work around that but I'm not sure if it's being applied to all our libraries properly.

[potatoxbe]

I'm on the latest VC redist. Have uninstalled and reinstalled. Still crashing.

[emoose]

Does changing ControllerHotPlug in INI to false make any difference? Maybe an issue with that since you mentioned it crashing if you connected during gameplay, would need to connect controller before launching with that though

[potatoxbe]

Changing ControllerHotPlug to false launches the game without crashes, but it can't detect my controllers. In the controller settings, just shows USB device and default USB device. Doesnt detect my buttons when trying to change button assignment.

[potatoxbe]

I think I know what's wrong. This USB Device detected by the game refers to a wireless USB dongle for a mini keyboard/mouse (https://aliexpress.com/i/1005002288164838.html). When I removed that, my controllers are able to connect without crashes, even with ControllerHotPlug on true.

While I can now play the game with my controller, it is a hassle to remove the USB dongle everytime. Any way around this?

[potatoxbe]

solved this. If I disabled HID game controller in Device Manager for the USB keyboard dongle, everything works flawlessly and I can still use the keyboard.

Though I now have another issue where my Xbox Series controller connected through the official xbox dongle would turn off mid way through a race. Turning it on would turn it off again. Doesn't happen when using other controllers wirelessly, and certainly doesn't happen in other games.

[fklfkl]

Are they running with the latest VC redist installed? There was a pretty recent change around the std::mutex constructor which caused issues when an older redist was used, the _DISABLE_CONSTEXPR_MUTEX_CONSTRUCTOR build define is meant to work around that but I'm not sure if it's being applied to all our libraries properly.

We opened the debugger again and the mutex was not crashing at all anymore - to my knowledge the C++ DLLs were already on the latest version so not entirely sure what went wrong there or what might have changed in between the last debugging session and this one

Instead it was crashing on Game::DInput_EnumJoysticksCallback when trying to pass a particular input device to the game - it was a Mayflash Wii sensor bar, unplugging fixed that and everything is fine now