DirectInput8 EnumDevices sometimes painfully slow

Question

Sometimes (in about 50% of runs), EnumDevices takes 5-10 seconds to return. Normally it is almost instant. I couldn't find any other reports of this kind of behaviour.

When things are this slow, it's ok to profile by watching stdout :) This:

std::cout << "A";
directInput8Interface->EnumDevices(DI8DEVCLASS_GAMECTRL, MyCallback, NULL, DIEDFL_ATTACHEDONLY);
std::cout << "C";

...

BOOL CALLBACK MyCallback(LPCDIDEVICEINSTANCE, LPVOID)
{
    std::cout << "B";
    return DIENUM_CONTINUE;
}

Seems to hang at a random point through enumerating devices - sometimes it'll be before the callback is called at all, sometimes after a couple, and sometimes it will be after the last call to it.

This is clearly a simplified chunk of code; I'm actually using the OIS input library ( http://sourceforge.net/projects/wgois/ ), so for context, please see the full source here:

http://wgois.svn.sourceforge.net/viewvc/wgois/ois/trunk/src/win32/Win32InputManager.cpp?revision=39&view=markup

There doesn't seem to be anything particularly fruity going on there though, but possibly something in their initialisation could be the cause - I don't know enough about DI8 to spot it.

Any ideas about why it could be so slow will be greatly appreciated!

EDIT:

I've managed to catch the hang in an etl trace file and analysed it in Windows Performance Analyzer. It looks like EnumDevices eventually calls through to DInput8.dll!fGetProductStringFromDevice, which calls HIDUSB.SYS!HumCallUSB, which calls KeWaitForSingleObject and waits. 9 times out of 10 (literally - there are 10 samples in the trace) this returns very quickly (324us each), with the readying callstack containing usbport.sys!USBPORT_Core_iCompleteDoneTransfer followed by HIDUSB.SYS!HumCallUsbComplete, which looks quite normal.

But 1 time in 10, this takes almost exactly 5 seconds to return. On the readying callstack is ntkrnlmp.exe!KiTimerExpiration instead of the HIDUSB.SYS function. I guess all this indicates that the HIDUSB.SYS driver is querying devices asynchronously with a timeout of 5 seconds, and sometimes it fails and hits this timeout.

I don't know whether this failure is associated with any one device in particular (I do have a few USB HIDs) or if it's random - it's hard to test because it doesn't always happen. Again, any information anyone can give me will be appreciated, though I don't hold out any hope for Microsoft fixing this any time soon given the odd situation DirectInput is in!

Perhaps I'll just have to start initialising input earlier, asynchronously, and accept that sometimes there'll be a 5 second delay before user input can happen.

Answer 1

I was running into this too, largely as an end user, but it's been annoying the hell out of me for years. I didn't realize it was this issue until I ran into it on an open source project and was able to debug it.

Turns out it was my USB Headphone DAC (The Objective DAC from Massdrop), it installs the driver: wdma_usb.inf_amd64_134cb113911feba4\wdma_usb.inf for Device Instance ID USB\VID_262A&PID_1048&MI_01\7&F217D4F&0&0001 and then shows up in Device Manager under Sound, video and game controllers as: ODAC-revB USB DAC and, under Human Interface Devices as: USB Input Device and HID-compliant consumer control device.

I have no idea what the HID entries do but... When they are enabled and this DAC is set as the Audio Output device both IDirectInput8_CreateDevice and EnumDevices are painfully slow. Disabling the "USB Input Device" entry seems to cause no negative effects and completely solves my issue.

Changing the Audio output from the DAC to anything else also weirdly solved the issue.

This was so bad that it made the Gamepad Configuration dialog joy.cpl unusable, hanging and eventually crashing.

I was wanting this to just be a comment but I don't have enough rep for it, and this is pretty much the only place on the internet that describes this problem though so hopefully this helps someone else one day!

Answer 2

I had the same issue. I have a Corsair K65 LUX RGB keyboard. I updated CUE and it seems to have fixed the issue

Answer 3

Got same issue when having my Corsair K55 Keyboard. Changing the keyboard of USB port fixes the issue for a while, but then it comes back later on. So it seems to be a buggy drivers issue.

Answer 4

As DaFox has pointed out, a likely cause appears to be certain device drivers being enabled. I contacted JDS Labs support (who sell one device which happens to install one such driver) and they kindly pointed out that the root cause is actually a bug within Windows (not the installed driver), and they actually provide the solution on their troubleshooting page. See Games hang or experience loading delays, which explicitly mentions VID_262. Disabling this driver fixes the issue without apparent side effects (under the condition that that is the only driver triggering the bug). As for what exactly is going wrong within Windows, here there be dragons.

So I guess the go-to solution (for users) is to scrape all the troubleshooting and FAQ pages for all devices which you have ever connected to your system and see if there is a mention of delays/lag caused by a driver.

As a software developer, you will probably want to benchmark the execution time of the affected code and kindly tell the user there is something wrong with their system configuration and where to look for how to fix it in case it is unreasonably long.