DirectInput Deadlock

You're talking gibberish [smile]

What call is hanging? Is it definitely hanging inside a D3D function? What input device are you reading (Please tell me it isn't keyboard or mouse)? What cooperative level is your input device set to?

I think its fixed or worked-around. Here's the problem.

To reproduce:
1) Start up the app (compiler auto-focuses the window).
2) Unfocus the window before the app is initialized by clicking on another window or hitting the Windows key.
3) Focus the window just before the game is finished initializing.

If the timing is right, the app will freeze and use no CPU. The app will remain frozen until the window loses focus, at which point the app continues as if nothing happened. Instead of the window losing focus, the ESCAPE key or numpad ENTER key will unfreeze the app. I'm not sure what is special about those keys. Also, the window's registered message proc does NOT receive the key press to unfreeze the app.

The fix/work-around:
Originally, D3D graphics would initialize and call ShowWindow. Then, DirectInputwould initialize.
Now, input is initialized before graphics.

Recalling some info from the article (the one I can't find or maybe the one I dreamed up):
ShowWindow triggers the win32 WM_ACTIVATE msg. This msg is first sent to parent windows.

Some guessing:
Some part of DInput must be locking the child window and then trying to lock the parent window. Meanwhile, the WM_ACTIVATE is locking the parent window and trying to lock the child (to send the WM_ACTIVATE msg?). I still have no idea why ESC or ENTER ends the deadlock.

So what DirectInput function was causing the deadlock? It's likely there's still a bug in your code that you've just managed to step around. Under normal circumstances, DX calls should never deadlock unless it's documented.