Component Monitor - dlls

I’m a little confused with the dll section on what is needed to go out and what isn’t. Just built a new computer and the only thing installed right now is XP Pro SP2. I was wondering, is there a list of the essential dlls required to make a connection to the net and for IE? There are probably several of them that are not required and could be blocked. I didn’t find anything in the FAQ’s. (which is well done btw) Does such a list exist?

Another thing I was wondering about this area - with the first install there were media type dlls (like audio) that wanted to go out with IE. Since I don’t care about that on the net, I blocked them but it also blocked IE from establishing a connection. Nothing worked except for a re-install of CPF. When I run into this, how can I let IE out while blocking the hitch-hiking dlls at the same time? Thanks.

To tell you the truth I’ve always been a bit confused as well, regarding the Component Monitor. I think it’s alright to allow all DLLs (well, unless they are suspicious), they can’t connect to the net on their own (as far as I know).

Hijacking of the browser which you mention, is another thing. I’ve tried several times to block DLLs but never got it to work so well. Either the rules weren’t remembered, or IE was cut off from the net. But I think it depends on which DLL we talk about. Some of them, as well as some executables (like svchost.exe), should be allowed access, to make Windows work smooth.

Sorry for my info-poor answer, maybe you got out something from it or we’ll just have to wait for an expert to share his/her knowledge here.


If component monitor is turned on when any application tries to make a connection to the outside, the firewall audits all the loaded components and checks each against the list of components already allowed or blocked. Comodo Firewall Pro now validates all the components of an application before granting the Internet access. These components may be dynamic link libraries or ActiveX components that an application is using.

If a component is found to be blocked, the entire application is denied internet access and an alert is generated. If the firewall detects unknown components (those not listed in the firewall database) then the alert will contain a “Show Libraries…” button. Click to review the components and decide whether or not to grant them access.


CPF is probably set for the majority of the people to accommodate the wide range of personal settings vs higher security, which is understandable. I’m not quite as trusting as the app is, when in doubt, I block it and go from there. Causes some frustration but I’m learning through trial and error. Sure was hoping you could have pointed me to a dll list of explanation. I started one of my own with XP Pro SP2 and Office but it’s coming painstakingly slow. There are some I’m not sure about how to set. Do you think there would be an interest if I started a new topic about creating one? It would be for those who want a tighter setup and a resource for others who only want to know about a couple. Would something like that interest you?

You too?? Surfing is such a joy! LOL

Think nothing of it, every morsel helps. Thanks for your reply, LeoniAquila.

I’m assuming this is only true if that component is an integral part of the app, is this right? I have IE set to allow with the default settings. (parent - explore.exe) Why does CPF still ask periodically if it’s ok to let IE out? Is this because IE doesn’t actually need explore.exe to establish a connection? Or is it the difference between IE asking vs explore.exe initiating the connection?

I’ve seen this happen. It’s a nice built-in feature. Coming from ZoneAlarm I had no idea just how unsecured that firewall was in regards to out-going connections. The more I tinker with CPF the more I like it, despite some of the ‘trying’ behavior. This is probably due to my lack of understanding in its logic. Thanks for your reply.

Blocking valid .dll files from being involved with an application connecting to the web seems to be a tricky prospect.

One thing I can tell you is that you cannot do it as you go. In other words, if you get a popup related to Component Monitor (ie, a dll or some other such file), and choose to Deny w/Remember to block that component, or else click the Libraries button and Deny there, your application will be blocked.

The only option you have, I think, is to investigate the component in question while not using the related application, selecting to Block that within Component Monitor, Click the “Apply” button at the top, and probably reboot (so change several at once, and then Apply and reboot). But not while you’re using the application (such as the browser).

Here’s where things get tricky, though. Valid dll files are often integrated with the operations of the browser. Thus, if you block them, the whole browser may be blocked. Some you may have success with, others you may not.

I understand that you want tightened security; however, just because a given component is allowed to run with an application that connects to the net does not mean that the component is allowed to connect to the net. That’s kind of like saying that a passenger in the back seat of your car is driving the car. The point of monitoring these components is so you can be alerted if something changes unexpectedly. Malware can inject a new component into a browser, or other application, in an attempt to control that application; much like a hijacker might try to get you to drive your car a certain way at gunpoint. The hijacker isn’t driving/the component isn’t connecting but is trying to get you/the browser to go somewhere or do something you otherwise might not do.

Hope that makes sense. And yes, if you want to make the effort to start a thread to discuss such aspects of increased/tightened security, I’m sure there will be users chip in on that; it would likely be of benefit to a lot of folks. Doing so in a way non-specific to CFP, I would suggest starting a topic in this board:
On the other hand, if you wanted to do so as specifically relates to CFP, then perhaps a topic in this board:


No. CFP operates on the principal that if you respond with Deny to a popup alert, the application in question must have been hijacked or is in some way a threat; in other words, the system must be compromised. Thus, it will block the application in question (ie, the browser) from connecting (and thus, all the components or other applications that were part of that attempt). If you do not select “Remember” the block will be for that session only; normally stopping/restarting the application will clear the block (although for some, such as an OLE alert, it seems that a reboot is generally required).

CFP may periodically ask about IE for a number of reasons. My top guess would be that it relates to Alert Frequency level (Security/Advanced/Miscellaneous). The AF level is somewhat confusing because it is actually about level of detail in application rules - you’ll see what I mean if you move the slider around. Each popup alert contains the full scope of detailed information (which helps with the confusion), but the only detail relevant is that which is in conjunction with the existing rule for that application. In other words, the detail in the existing application monitor rule for that application must match the level of detail associated with the current Alert Frequency level; if the AF level has more detail than the Application rule, an alert will be generated.

Without seeing the alerts or logs, I can’t really say; this guess is based on experience only.


Little Mac so your saying its not necessarily the end of the world if you allow certain components as long as everything else is set and working you are protected, is that right?

Another well explaining respond from you Little Mac, thanks. This truly is a tricky part of the Comodo Firewall concept.

It would. This topic is interesting, and I think many of those who come to this forum with a little more knowledge (like yourself I believe) than the very “average Joe”, are interested in the Component Monitor. I no longer care for blocking any DLLs, I’m too lazy to pick them out and click block. Instead I only use well-known applications (often open source) I’m totally confident with.


IMO, that is correct. There are tons of components related to various applications (some are shared); you can drive yourself crazy trying to track all those down; the point of Application Behavior Analysis and Component Monitor is to monitor these inner workings of Windows, and alert you if something is suspicious.

In essence, CFP worries about the details, so we don’t have to. Now, as Lilypad has indicated a personal level of trust lower than that of CFP; and this is not uncommon. A lot of people don’t trust MS products and the components that make up those products (and certainly there is a history there); CFP on the other hand looks at “trust” only from the standpoint, “can we verify what this component is, is it legit and unchanged?” That’s as regards the encrypted Safelist; if it’s on the safelist, you won’t see alerts for it provided all the other checks are good.


Great! Letting me know where it should be posted is a big help. I was wondering about that. Your detailed explanation cleared some things up; it is much appreciated. Thanks, Little Mac.

There’s something else I was wondering about, why does CPF resets all the dlls to allow after an installation? I had some blocked that belonged to XP and later installed office. The next day, I noticed the ones that were blocked changed to allow (all of them). Is there a persistent setting that can be applied some where? Or a way to load a block profile list, perhaps? Or was that a fluke and it wasn’t supposed to happen?

Splendid! Glad you’re on board with the idea.

I’m glad to see there’s an interest for the dll list and I’m looking forward to working on it. However, next week I’m going on a trip and realistically I probably won’t be able to start it till around the week of the 16th. If anyone is rebuilding their drive and would like to start before me, I’ll jump in to help when I get back. If not, that’s ok too. Just wanted to let you know since you won’t hear from me next week.

In the meanwhile, to give you an idea what I was thinking and if you wouldn’t mind letting me know, which group is better to post in, when the project starts based on content; that would be great. (Either Security or Feedback as Little Mac suggested) Here’s an example of the format I used with my own list.

Allow\block = 100% confident in this decision
allow?\block? = possibly, not 100% sure
?? = no idea, clueless
if = conditional
NOTE = Additional information or comment
Owned by = Name of app that installed the dll
Used by = Name of app(s) that utilizes the shared dll
Lib = Short for Library

activeds.dll - Active Directory service - related to network security (allow)
NOTE: not related to ‘actived.exe’ - a spyware component
Owned by: XP
Used by:

apphelp.dll - component of application-compatibility (block?)
Owned by: XP
Used by:

adsldpc.dll - (??) [clueless]
Owned by: XP
Used by:

actxprxy.dll - Component of ActiveX (block - if)
NOTE: Only if you surf with (all) ActiveX turned off most of the time. Some shared work-space and client\server type apps may need this to be fully functional
Owned by: XP
Used by: IE, …,

Any other ideas you would like to see added?

In my experience it’s not a good idea to block components unless you’ve got reasons to think they’re malicious. As LM said it’s not that they’re connecting themselves, it’s only CFP letting you know in case. Sometimes I blocked some component from the list built by the learn mode and then my browser lost Internet connection, sometimes not. Another time I blocked a component of MATLAB and I could browse but my AV guard went down, maybe it was trying to scan that dll.

I’m also a little bewildered about the component monitor but IMO it’s just another layer of protection and also not the most important one at all. My advice is, just after installing or updating something be prepared to allow and don’t worry about it. Only if you think that the alert is untimely, investigate the dll in case it’s malicious. But otherwise my principle is allowing everything not malicious, I tried to monitor everything like you but I gave up.

I do support Lilypad’s ambitions, but Japo has a good point. Even though I would like to block more things than I block today; it’s not worth the effort to me.


There are three possibilities that I can think of:

  1. You didn’t press the “Apply” button at the top of Component Monitor, after making changes (in which the change would not persist at all).

  2. Your Component Monitor is still set to “Learn” mode, rather than “On.”

  3. The components happen to be shared (not at all uncommon; I would say that most are shared), and the newly-installed application utilizes them; thus you have approved them for the new app. If approved for one, it’s approved for all - global setting…


That helped a lot, it was the second reason you offered. I forgot I read somewhere in the forum that the ‘Learn mode’ sets everything to allow by default. Thank you again, Little Mac.


It seams that the general consensus is to not bother with the dlls. I understand everyone’s reasons but here are my thoughts on why I would consider doing this. Of course, it might be incorrect. When I’m setup with all the apps I want installed, I only want 4 of them to access the net. Eventually, I don’t want to be asked by CPF unless it thinks something has been modified and it’s suspicious. Basically, everything would be setup the way I preferred - as anyone else would like. My thinking is, if everything is blocked (dlls) other than those associated with the 4 apps and ones for communication between the OS and router, then any new apps installed in the future, won’t bother trying to make an invisible connection if the required dll is already blocked. (app would be blocked also) I’ve noticed that even if an app is blocked in App Mon, there are invisible connection attempts anyway. I tested this theory with explorer.exe with all dlls set to allow. I added it to App Mon and blocked it with ‘skip parent check’ selected. My understanding of this setting is any attempt at all by explorer.exe would be automatically blocked and not asked. This is not the case because CPF asked anyway when it wanted to go out through IE by an invisible connection. With this current setting and all the dlls associated with it were set to block, then it shouldn’t ask at all. (In theory anyway) For testing purposes, explorer.exe may not have been a good choice. However, this is the reason why I was considering blocking them. Perhaps I missed some understanding somewhere but for this moment in time, it seams logical. Also in theory, shouldn’t it cut down with the rules making, in regards to blocking?

That sounds nice but when my AV went down unless I allowed a DLL from MATLAB ( ???) I just gave up. However when I’m asked to allow new components and I haven’ t just updated the browser or whatever, I montor those components before allowing. But my rule of thumb is not allowing only if they seem neccessary for Internet to my uneducated understanding, instead blocking only if they don’t seem trustworthy.

My thinking is, if everything is blocked (dlls) other than those associated with the 4 apps and ones for communication between the OS and router, then any new apps installed in the future, won't bother trying to make an invisible connection if the required dll is already blocked.
IF we weren't dealing with Windows, that would probably be true. Unfortunately, the way components are shared between applications behind the scenes, there is a plethora of communication going on that we don't ever see.

It’s important to remember, too, that just because an application is connecting, doesn’t mean the required components are connecting. This is a critical distinction. The backseat passenger is going down the road in the car, yes; but he’s not driving the car, and isn’t in control of reaching the destination (route, speed, etc). In this scenario, that passenger is a normal component (dll, com, sys, etc). If he pulls a gun on the driver, that changes the situation, and gives him control; but that’s a hijacking attempt, and is where you get a different kind of alert - ie, the component has changed, the dll has injected code, etc.

Invisible connections are a different thing as well. That’s when an application calls/starts itself. For instance, if you start your browser from a desktop icon, explorer.exe is the parent (as the Windows shell). If the browser updates and restarts automatically, it is its own parent, and has connected invisibly. That can be controlled under the Miscellaneous tab of the application rule. It seems that Skip Parent may not work quite like we think it should; at times that almost seems to be a temporary setting that won’t work much different from Learn Parent, rather than meaning you don’t care who/what the Parent is, you want the rule to be applied regardless.