I have the same version of Comodo firewall, on WinXP Pro, and am having the same problem with cfp.exe accessing msctf.dll almost continuously (which is why I’m on this thread). I hope you can figure out what’s wrong. I don’t think I have the skills to create the stack traces you’re talking about.
Hi, yes I waited but procmon didn’t resolve any more symbols. Have just re-tried it and I waited 5 minutes but results are identical. Have attached procmon Configure Symbols dialog, for reference.
I also went ahead and downloaded a (209 MB) complete set of symbols from http://www.microsoft.com/whdc/devtools/debugging/symbolpkg.mspx but the stack trace results are still the same.
[attachment deleted by admin]
Probably duplicate for this one:
https://forums.comodo.com/empty-t64133.0.html
There are “workarounds” listed there.
Evidently, the “workaround” is to turn off my language services! I can’t do that - we use the second language constantly. I hope the devs will fix this soon.
Same problem here. Disabling ctfmon/advanced text services is not an option; we need to know what language we are typing on.
OK, consider this +1 for fixing the CFP bug and I’ll work around it in the meantime. Thanks.
I have the same problem, under WinXP Pro and all updates for Comodo IS. I hope the devs can pay some attention to this since I can’t do without the Language Bar, but I really don’t like seeing my drive be hammered like this. If it’s been a problem for years, and no doubt for many users, wouldn’t it get some priority to be fixed?
Thx
Arbie
Note: It’s not going to “hammer” anything. The file would be cached by the OS, so no disk access would be required at all.
Not sure here the creation of this file fails so it tries it over and over again to create it…
Don’t think that will end up in cache, but your the expert on the matter 
I’m having this problem too. XP Pro SP3 32-bit, Comodo 5.5.195786.1383 with Firewall and D+ both set to Safe Mode.
Procmon shows the same accesses to msctf.dll (ctfmon) as shown in the screenshot in the top post. I can hear the HDD grinding a lot and the machine gets very slow sometimes. Killing ctfmon.exe temporarily solves the problem, but any program with a text entry field starts it up again. Disabling text services isn’t a solution because I need the Language Bar.
Please do something about this. I’ve tried adding firewall and D+ policy to fully allow ctfmon and msctf.dll, but nothing helps. Even setting firewall and D+ to Disabled mode doesn’t stop the phenomenon. The only thing that stops it is killing cfp.exe.
Also, the language bar itself seems to be broken by this. I can’t restore (float) the language bar, only keep it minimized on the taskbar. Clicking on the language bar controls gives no response. I can still control it with keyboard shortcuts but the appearance of the bar doesn’t change (it displays the default language no matter what mode I change to with the keyboard).
I have these input methods installed:
US keyboard (American Windows default)
United States-International
Chinese (Simplified) - Microsoft Pinyin IME 3.0
Japanese Microsoft IME Standard 2002 ver. 8.1
Japanese Microsoft Natural Input 2002 ver. 8.1
I just started using Comodo a few weeks ago. I never had these problems before then, so I doubt the strange language bar behavior is a bug with the input methods.
Is there any progress on this bug? There have been a few patches since the last activity in this thread but Comodo is still hammering away at msctf.dll all the time and occasionally hangs with 50% CPU usage. Killing ctfmon.exe briefly brings relief. Disabling the Windows language bar is not an option.
Still suffering from this problem.
Hello? Comodo?
I’d advise checking with CIS 6.0 and reporting in Beta bugs if you can. More chance of getting it fixed during the beta process.
Best wishes
Mouse