Hello Nikolay, On Wed, Jul 10, 2013 at 1:06 AM, Nikolay Sivov <bungleh...@gmail.com> wrote: > This could be some a different bug, and putting exception handler around it > is not necessary a right solution.
Good catch, I think you are right. I found ImmLockIMC()/ImmUnLockIMC()/etc are called even after ImmDestroyContext(), the latter frees the input method context if the call successes, but the former try to access the IMC. I have a test case show that in some case native ImmDestroyContext() fails but builtin ImmDestroyContext() success: https://testbot.winehq.org/JobDetails.pl?Key=26499&log_206=1#k206 That is why Office die on Wine but live on Windows, ImmDestroyContext() fails so following ImmLockIMC()/ImmUnLockIMC()/ImmGetIMCCSize() are safe, but on Wine ImmDestroyContext() success and free the memory of the IMC, and... Boom! --- snip --- Call imm32.ImmDestroyContext(08a29b28) ret=3927e447 Ret imm32.ImmDestroyContext() retval=00000001 ret=3927e447 /* success, free the IMC (hIMC == 0x08a29b28) */ Call imm32.ImmLockIMC(08a29b28) ret=09ea2c54 /* would die sooner or later ... */ Ret imm32.ImmLockIMC() retval=08a29b2c ret=09ea2c54 ... Call imm32.ImmGetIMCCSize(00000008) ret=09ea3545 /* 0x00000008 comes from hIMC->IMC.hPrivate, unfortunately hIMC is freed... */ --- snip --- I need more tests to figure out what is the necessary and sufficient conditions to make ImmDestroyContext fails. Thanks for the help! -- Regards, Qian Hong - http://www.winehq.org