Sounds like it might be a thread priority problem. A lower priority thread can be starved if there is a higher priority thread that does not periodically sleep or suspend waiting for an event. A higher priority thread can also be blocked if it waits for a signal from a starved thread.
Moving the mouse can give a thread a dynamic priority boost which could delay the occurrence of the starvation.
You might try calling
BOOL WINAPI SetProcessPriorityBoost(
HANDLE hProcess,
BOOL DisablePriorityBoost
);
to disable priority boosting to make the underlying problem easier to reproduce.
Also, here is a warning from MSDN about using the high priority setting:
Use HIGH_PRIORITY_CLASS with care. If a thread runs at the highest priority level for extended periods, other threads in the system will not get processor time. If several threads are set at high priority at the same time, the threads lose their effectiveness. The high-priority class should be reserved for threads that must respond to time-critical events. If your application performs one task that requires the high-priority class while the rest of its tasks are normal priority, use
SetPriorityClass to raise the priority class of the application temporarily; then reduce it after the time-critical task has been completed. Another strategy is to create a high-priority process that has all of its threads blocked most of the time, awakening threads only when critical tasks are needed. The important point is that a high-priority thread should execute for a brief time, and only when it has time-critical work to perform.
