Bug 1777960 Comment 18 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

Adding the signatures for x86. Here is the full list of signatures on which we receive variations of this crash currently:

`TF_Notify`: `msctf.dll` 10.0.22621.1928 x64;
`msctf.dll | icsak.dll | RtlpFreeHeapInternal | free | icsak.dll | CtfHookProcWorker`: `msctf.dll` 10.0.22621.2215 x64;
`IMProcessKeyInput`: `msctf.dll` 10.0.22621.1928 x86;
`msctf.dll | icsak.dll | CtfHookProcWorker`: `msctf.dll` 10.0.22621.2215 x86.

For the record, what we described to the vendor with [:gstoll] is the following. We believe that this crash occurs because ZoneAlarm Anti-Keylogger hooks `TF_Notify(UINT message, WPARAM wParam, LPARAM lParam)` from `msctf.dll` to alter the Microsoft-internal message `0x20000`, but starting with `msctf.dll` 10.0.22621.1928 Microsoft has changed the way the lParam should be used for that message. It was a scalar value before and is now a pointer to data instead. ZoneAlarm always uses the old convention and thus forwards a scalar value, which is dereferenced by `msctf.dll`, causing the crash.
Adding the low-volume signatures for x86. Here is the full list of signatures on which we receive variations of this crash currently:

`TF_Notify`: `msctf.dll` 10.0.22621.1928 x64;
`msctf.dll | icsak.dll | RtlpFreeHeapInternal | free | icsak.dll | CtfHookProcWorker`: `msctf.dll` 10.0.22621.2215 x64;
`IMProcessKeyInput`: `msctf.dll` 10.0.22621.1928 x86;
`msctf.dll | icsak.dll | CtfHookProcWorker`: `msctf.dll` 10.0.22621.2215 x86.

For the record, what we described to the vendor with [:gstoll] is the following. We believe that this crash occurs because ZoneAlarm Anti-Keylogger hooks `TF_Notify(UINT message, WPARAM wParam, LPARAM lParam)` from `msctf.dll` to alter the Microsoft-internal message `0x20000`, but starting with `msctf.dll` 10.0.22621.1928 Microsoft has changed the way the lParam should be used for that message. It was a scalar value before and is now a pointer to data instead. ZoneAlarm always uses the old convention and thus forwards a scalar value, which is dereferenced by `msctf.dll`, causing the crash.

Back to Bug 1777960 Comment 18