有時（約50％的運行），EnumDevices需要5-10秒才能返回。通常它幾乎是瞬間的。我找不到任何其他這類行爲的報道。DirectInput8枚舉設備有時會痛苦地慢
當事情是這樣慢，這是確定通過觀察標準輸出:)這剖析：
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;
}
似乎在隨機點通過枚舉設備掛起 - 有時它會調用回調之前在所有，有時在一對夫婦之後，有時候會在最後一次通話之後。
這顯然是一個簡化的代碼塊;我實際使用OIS輸入庫（http://sourceforge.net/projects/wgois/），因此對於上下文，請參閱完整的源代碼在這裏：
似乎沒有是什麼特別的水果對那裏發生的，雖然，但可能有些東西在初始化時可能是原因 - 我不知道DI8發現它。
任何想法，爲什麼它可能會這麼慢將不勝感激！
編輯：
我設法抓住懸掛在ETL跟蹤文件，並在Windows性能分析器進行了分析。它看起來像EnumDevices最終通過呼叫DInput8.dll!fGetProductStringFromDevice，其中調用HIDUSB.SYS!HumCallUSB，其中調用KeWaitForSingleObject並等待。 10次中的9次（字面上 - 跟蹤中有10個樣本）非常快速地返回（每個324us），準備好的調用堆棧包含usbport.sys!USBPORT_Core_iCompleteDoneTransfer，然後是HIDUSB.SYS!HumCallUsbComplete，這看起來很正常。
但1次在10，這需要幾乎一模一樣5秒返回。在準備的調用堆棧上是ntkrnlmp.exe!KiTimerExpiration而不是HIDUSB.SYS函數。我猜這一切都表明HIDUSB.SYS驅動程序以5秒的超時異步查詢設備，有時會失敗並且達到此超時時間。
我不知道這是否失敗與特別是任何一個設備（我確實有一些USB的HID）或相關的，如果它是隨機的 - 這是很難測試，因爲它並不總是發生。再次，任何人都可以給我的信息將不勝感激，儘管我不抱希望微軟在任何時候儘快解決DirectInput的問題！
也許我就不得不開始初始化先輸入，異步，並接受，有時還會有之前用戶輸入可能發生延遲5秒。
非常有趣！謝謝！我從來沒有深入到底，也從來沒有在其他機器上發生過，所以我認爲它是壞的設備或其他東西，而且你的報告也是一樣的！很高興知道我不是它唯一影響的人！ –