I discussed this problem with our user mode guru and the conclusion is sad: the only way how to avoid this kind of problems is to not use journaling hook. We also used journaling hook in the past in some app and had to remove it because had exactly the same problems (I didn’t know it because work on different projects). Please note the problem doesn’t lie in MEW code; it is OS design which allows any app to lock system when journaling hook is used.
It means part of MEW kernel would have to be rewritten to avoid problem and I’m affraid it can’t be expected sooner than in MEW X. So the only current option for affected users is to find an app which causes lockup. Unfortunately, we haven’t found a better solution that what I already described. Any thread which owns window, visible or invisible, and doesn’t process messages for some time causes this problem. Such an app is poorly written but unfortunately, it isn’t uncommon and can occur even in app which isn’t aware about it. From MSDN docs for SleepEx() which may seem unrelated but actually isn’t (emphasis is mine):
You have to be careful when using SleepEx and code that directly or indirectly creates windows. If a thread creates any windows, it must process messages. Message broadcasts are sent to all windows in the system. If you have a thread that uses SleepEx with infinite delay, the system will deadlock. Two examples of code that indirectly creates windows are DDE and COM CoInitialize. Therefore, if you have a thread that creates windows, use MsgWaitForMultipleObjects or MsgWaitForMultipleObjectsEx, rather than SleepEx.[/quote:2eh1tyhd]
It also means a thread which creates a window shouldn’t access network because of possible delays. Many apps do, including Windows Explorer.