IME crashes when processing a window message sent from another thread
Describes a scenario where an Input Method Editor (IME) crashes while processing a window message sent from another thread, and where the window procedure handling the message calls an
Imm* function such as
An application using an IME crashes under one of these conditions:
- A user interface (UI) thread calls the
TranslateMessagefunction as a part of the message loop.
- Another thread sends a window message to a window owned by the UI thread.
- The window procedure handling the window message sent by the other thread calls an
Imm*function, such as
An IME included with Windows 10 may call the
PeekMessage function when the IME is called by the
TranslateMessage function to process a keyboard input.
PeekMessage will process any pending window messages sent by other threads. This can result in a reentrancy issue when the window procedure processing the sent message calls an
Imm* function and leaves the IME in an unexpected state.
Imm* functions while the IME is processing another window message.
PeekMessage documentation contains the following:
During this call, the system delivers pending and non-queued messages sent to windows owned by the calling thread using the
SendNotifyMessage function. The first queued message matching the specified filter is retrieved. The system may also process internal events. If no filter is specified, messages are processed in this order:
- Sent messages
- Posted messages
- Input (hardware) messages and system internal events
- Sent messages (again)
Sent window messages are non-queued messages. The message filter specified when calling PeekMessage call doesn't apply to sent messages.