Driver deadlock

[michael-fadely]

Describe the bug
With a virtual Xbox 360 controller enabled, programs that poll controller input will be unable to launch. They deadlock attempting to open a handle to the device. This happens with feeder applications as well.

It also prevents any real devices from connecting to or disconnecting from my system.

To Reproduce
I've been unable to consistently reproduce it. It happens fairly frequently, but with no specific steps that I could identify. If applications begin failing to launch with a feeder and Xbox 360 endpoint, however:

1. Launch an application that polls for controller input (a game, Uplay, Steam, Battle.net).
2. The application will stall or fail to launch.
3. Attempt to disable the device with Device Manager/etc, and it will also stall.
4. When the feeder is killed, the Xbox 360 endpoint device will enter an error state, displayed in Device Manager.

Expected behavior
Some kind of error handling or error logging. ViGEmClient has error logging, but it doesn't appear to encounter any errors when this deadlock occurs.

Screenshots

I attempted to disable the device, Device Manager stalled, and both the Game Controllers dialog and Battle.net immediately launched. Opening another instance of Device Manager reveals that the device is still enabled:

System details (please complete the following information):

• OS: Windows 10 Pro 1903
• Feeder software: ds4wizard
• Driver Version: 1.14.3.0

Additional context
It very well could be something I'm doing with my feeder, but I've been unable to figure it out.

[nefarius]

Thanks for the report but could you please monitor the situation with the latest driver version as well? What you run is very outdated.

[michael-fadely]

...Wow, that IS really old! I missed the latest stable release somehow. Will do!

[michael-fadely]

Same issue with latest stable. I will do some experimenting to see if I can narrow down the issue.

[MtDewFella]

I have been getting the same problem, wasn't sure if it was steam, glosc or vigem, I assume it's vigem since trying to disable it causes driver manager to freeze up, only fix I have found is to reboot the pc, oddly it never happens during play only after (not all the time only some times)

[nefarius]

Dammit 😅

[MtDewFella]

I completely uninstalled vigem and glosc, and reinstalled vigem first then glosc and so far I have had no issues, the last time I installed I just installed glosc like normal, which installed vigem (or was supposed to) but when I first used glosc that time I got the couldn't initialize vigem error, I then installed vigem without uninstalling anything, perhaps that caused the issue, I will keep and eye on it

Edit: I can also disable and enable vigem in device manager without issue now

[nefarius]

Any news @michael-fadely ?

[michael-fadely]

Still exhibiting the exact same behavior, unfortunately. Just having the virtual Xbox 360 device present when attempting to launch an application that uses XInput will sometimes cause this deadlock and require a hard reboot to allow any other physical devices to connect to, or disconnect from, the system.

[michael-fadely]

Could this be due to my program's multi-threading? I am using ViGEmClient. I call vigem_alloc and vigem_connect (as well as free and disconnect) on the main thread, but vigem_target_add, vigem_target_x360_register_notification, etc. are called on a secondary thread.

[michael-fadely]

In my program, everything appears to continue working. I simply unplug the DualShock 4 and it calls vigem_remove_target seemingly without error. I will implement some more robust error checking in this instance to be certain.

[Corrodias]

This seems very similar to a problem I'm experiencing. I'm using DS4Windows, on Windows 10 1909 and the latest version of the driver. After about 3 days of uptime, during which I leave a controller connected by USB at all times, Monster Hunter World will stall on its black startup screen and not proceed to the dev logo, but Special K's overlay is drawn, and Chrome can still start a new, GPU-accelerated video, so it's not a video driver failure. Attempting to "stop" and "start" DS4Windows may appear to work but results in a CPU-spinning thread. Attempting to reboot Windows causes it to hang on "Restarting" for several minutes, then BSOD.

I have not yet narrowed this down to being caused by ViGEmBus. It does seem like a likely culprit, especially after reading this thread. The next time this happens, I'll try disabling the device to see if it hangs, like it does for MtDewFella, and I'll try uninstalling it after the reboot. I will also attempt to get an xperf trace on the shutdown process that includes stacks.

If ViGEmBus does wind up being the culprit, is there anything else I can do to help diagnose this? It seems reliably reproducible for me; I just have to wait 3 days each time.

[Corrodias]

In fact, if it's going to do it again, today's the day. I have about 7 or 8 hours before I'm going to commence playing games, at which time I'll be doing the trace and so on if it did deadlock. If you have any advice or suggestions on helping diagnose this, providing them now would be timely.

[nefarius]

Make sure kernel memory dumps are enabled and keep the dump file somewhere. It shouldn't be shared publicly but is the best start to get the culprit.