imsc12.ime causes mmc.exe to freeze?

I had suffered from this annoying problem for a long time – Every time I opened the compmgmt.msc file, and tried to check the system log (or application log, or any other log loged by Event Log), I could open the event property windows normally by double click on a log entry. But as soon as I closed the event property window, the whole application got frozen. That is, I can move the main windows, maximize it, minimize or restore it, but the content of the window became blank. Soon after that, the title bar of mmc told me that the application stoped responding.

I couldn’t figure what’s happening until one time, I used SystemInternals’ process explorer – I love this tools – I found that there’s a new thread being spawned when I opened the event property window. Yet when I closed the window, the thread didn’t terminate. Just a desperate move in order to solve this problem, I killed the thread using procexp. Magically, the mmc window restored to its normal state!

I tried to reproduce this scenario, some time it works, other times it failed.

Yesterday, when I got an error, I check the log and got stucked, again! When I fired process explorer and trying to kill the stuck thread, this time, the worst thing happened, process explorer got stuck!

Finally, I would have to solve the whold problem. I launched visual studio, and created a new project, and attach to mmc.exe process. I waited for all the symbols got loaded and paused the process.

There they were! In the thread window, there were four threads, I repeated the resume and pause for some time. Everytime the process pauses at the same thread. So I can assume this thread was busy doing something. The call stack show that this thread is doing somthing with the IME engine – I’m working on an simplified Chinese platform.

There was another thread with a paused flag, I switched to this thread, call stack show it was paused in a WaitForSingleObject function call. It must be the main thread. A peek at The bottom line of the calling stack confirmed this.

So, could it be the IME engine causes this frozen?

I investigated the loaded modules of the process, and the imsc12.ime seemes suspicious. It was the module sit on top of the call stack of the busy thread.

I opened the c:\windows\system32\ folder and found the file. In the security property of the file, I denied everyone from accessing this file. After that, I opened the compmgmt.msc and double clicked on an event. With cautious and anxiety, I closed the window… IT WENT WELL! THE PROBLEM GOT SOLVED!

ps, I searched the net with all the possible keywords combination. It seemed nobody else ever had this problem.

An ugly implementation

Recently, I’ve been working on an CPropertySheet based application. It has multiple property page. Along with every property page, there’s a working thread behind the scene. I use a timer and a critical section kernel object to syncronize the working thread and the GUI update.

I tested the code with just one page, it works fine. But when I add the second page to the property sheet, the code ends up with an assert error on the SetTimer function call with the OnInitDialog funciton of the PropertySheet.

I was confused by this odd – it takes me a whole day to figure out what happened to the second property page. Finally I realized that the page would not be created till the user clicked the tab and activate the hiding page. So in OnInitDialog function, all propertypages’ m_hwnd is NULL – except for the first page, it has been activated automatically – that lead to the ASSERT error.

To solve this problem, I use a loop to activate the pages within the OnInitDialog function of propertysheet and then SetTimer. It works, but what an ugly implementation! If anyone has a neat approach, pls let me know.