Comodo is turning internet browsing much slower (Dll injection problem)

I am using comodo for months and recently (after a comodo update) my internet browsing turned too much slow. It takes much time to open a single webpage. To read and post in this forum, I had to turn off comodo.

I’m using Firefox and share a 600k DSL internet connection router for 3 PCs. The curious part is that uTorrent and Emule are working ok, with good speed, only internet browsing is affected.

Just to help, I have no application blocked and have created a trusted network zone for my network.

I like comodo very much, but I’ll have to try another one if this ploblem could not be solved. I’m sure it must be some kind of configuration matter.

So please, if anyone could help!

Please see my reply at,6323.msg46785.html#msg46785. It works for me. :wink:

Disabling DLL check doe speed things up, it is noticeable.

It also reduces your security because that is a very popular exploit.
Make sure you have the latest version, it’s a known issue with older versions.

Well, my problems seems to be more regarding comodo and utorrent.

When I turn off comodo or utorrent, my internet browsing is ok!

When both programs are running, even Internet Explorer get too much slow, so I don’t think is something regarding firefox.

OK now your more on point, known issue regarding p2p and comodo, disable “do protocol analysis” & dll injection, and it would speed things up.

Well Drob, I’ll try this and see what happens.

But I don’t get why this is happening now, I am using comodo and utorrent together for quite some time and just now I got this problem. I never changed any configuration and both were working fine until some time ago.

Also I’m worried about Quwen said, that this Dll-thing is a important part of protection.

I’m using comodo to feel more secure, this procedure won’t turn me vulnerable?

Thanks for the help!

as long as your protected by proper rules your OK. dll injection protects you from Trojans or other baddies already on your PC, something a good Av would let you know before hand, in that meaning you are slightly more vulnerable, some suggestions were made the you should disable dll for few weeks while it learns your machine then turn it back on,i am still new to it so didn’t see that change yet but will be smarter in two weeks lol

That was my suggestion. Monitor Dll Injections (MDI) has not caused the cpu issue since that method (with the exception if Component Monitor is On mode). Also have to reboot.


I’d advise using something like Process Explorer to see exactly where the CPU usage is hitting when you’re experiencing the slowdown.

If it belongs to either Firefox or utorrent, you may edit that Application Monitor rule, under the Miscellaneous tab, select “Skip advanced security checks.” OK and reboot.

If it belongs to CFP, then I would recommend filing a ticket with Support, before I would recommend turning off any aspect of ABA. There is a very small chance these days that your antivirus or antispyware is going to catch something doing a dll injection (or anything, for that matter… the malwares are becoming more difficult every day…). The only exception I would make to that rule is if you are actively running a HIPS type program that specifically protects against these types of behaviors.


Just disabling DLL Injections returned my internet browsing to normal as Drob said. Didn’t even need to change the protocol analysis.

I’m using Avast Anti Spyware, I wonder if this could protect me while Comodo learns my system?

After that maybe I could turn on again…

I’ll try the other sugestions too! And just to make sure, my slowdown is only in internet browsing, not in the computer itself.

Thanks everyone!

I installed Process Explorer and don’t seems to have spikes in CPU usage… just the pages that take ages to load.

The CPU usage shifts between firefox and cpf, but using about 20 or 30% CPU…

Is that with DLL injection monitoring turned on?

For me it is a combination of running emule for few hours, with dll injections on, then cpu spikes (and slow loadings) for comodo whenever there are more busy/complex web sites. the reason for disabling protocol analysis is due to many many alerts of denied connections due to protocol analysis, disabling advanced checks didn’t solve it unfortunately.

Yes, with dll injection on.

I didn’t see any huge CPU spikes, but I didn’t stayed very long watching, just a few moments to see if I could see any spike and what process was consuming CPU. After this I turn it off again, otherwise I can’t load any site.

During the night I turned it on, so when I come home I’ll check again for CPU spikes.

Just thinking out loud…

If you turn off Advanced Checks for an application (ie, application rule, Miscellaneous tab, “Skip advanced security checks”), that completely disables all ABA (application behavior analysis) for that application. If that doesn’t resolve the issue, then surely we can safely say it’s not the application in question (such as the browser).

If, however, we can disable an aspect of ABA globally (such as Monitor DLL Injections), and this works, then we know that it was being impacted by some application. After, all, we turned it off for one app, but that didn’t work; we turn if off for ALL apps, that works.

What if, one at a time, you disable active security applications (such as antivirus, antispyware), and check each time to see if that makes a difference (with ALL ABA turned on). Then try it one at a time with all other applications in the App Monitor (by skipping the advanced checks).


Note: I’m not categorically stating that there isn’t anything “glitchy” with MDI; just based on how it’s designed to function, there may be something else in the equation.

What’s also strange is if Component Monitor is On mode, it eats up even more cpu.

That could make sense, since it’s then watching not only for allowed applications, changes to the applications’ signatures, and then also all components of the application (and we all know what the component monitor looks like…).

The thing I don’t get is why some systems and not others… for instance, I don’t have that issue and never have. I’ve had others, but not that. ;D Given that all systems are different, I’m wondering what the common link is, and if it can be traced to a specific common application (or type of application).

In all your checking into it, soyabeaner, did you go thru the process I mentioned, to try to eliminate application possibilities?


That’s not what you posted before (:TNG). That was my theory at first, but you rejected it. :stuck_out_tongue: :


MDI is not an issue for me anymore. It’s down to Component Monitor On vs Learn mode when browsing web sites. cmdagent.exe should be around 0% like it is in Learn mode. When I used to have the MDI problem, disabling other MDI or advanced security checks - either one of them worked. Here’s another thing to note: I don’t have any other real-time security like AS or AV running so I highly doubt it’s about software conflict. I tried Paul’s method of installing CFP prior to Nod32 (had to uninstall both).

I can see how you’d think that, but that wasn’t really what I was trying to say. Let me try to clarify (which may cause even more confusion…) ~

As in my post you quoted, that’s my understanding of how it works.

How that relates to my post here:

My current train of thought is that some other application (besides the browser) is causing the slowdown; possibly an AV, who knows. IF another unknown application is interfering with the browser function, that application’s components may be being utilized by the browser. Thus, CFP would not only have to analyze all the direct components, but indirect as well, when the browser is connected/connecting.

This could explain why you noticed the video codecs coming up on your component alerts when you were browsing. Even if it doesn’t cause CPU usage, it could (given individual system speed, RAM, etc) conceivably cause slowdowns.


PS: If you think I’m crazy/off my rocker anyway, well, you could be right… ;D