This is the behavior I am observing anyway. The setup could not be any simpler really. It doesn't happen every time the thread sleeps. But if Sleep is ever called it's bound to happen after probably less than a minute. Just seems wrong for the thread to never yield. I am not sure what that means for the scheduler.

A SetEventNotification approach is relied on, but it's not clear what that has to do with Acquire. For the record after having Sleep'ed. Any call to Acquire can result in the thread never returning.

Could it be just a bad build of the library? Or is there any reason (legitimate or otherwise) for Direct Input to be doing this?

For readers I found that setting the timeout for MsgWaitForMultipleObjects to even 1 millisecond is effectively equivalent to a Sleep and takes the CPU usage down from ~50% to less than 1 or 2%. Not sure why the documentation samples suggest a 0 timeout presumably so your app doesn't miss a beat; assuming your app is hogging the CPU and has something to do between timeouts (eg. single-threaded)

If you try to Sleep manually rather than using the timeout parameter then dinput8.dll (2009 build) eventually deadlocks on Acquire. My guess is this is a bug. Possibly a driver bug. But if its a physical hole in the scheduler (very possibly) then it should be documented.

Anyway using the timeout parameter, and not using Sleep, so far no deadlocks. But it's only been a short while of monkeying with it this way.

Follow up:

It's also possible that this is symptomatic of calling Unacquire in your loop (http://xboxforums.create.msdn.com/forums/t/108722.aspx)