Problems with BOClean Excluder when updating Comodo Firewall Pro

In order to minimize CFP log entries involving Comodo BOClean inspecting parts of CFP, I have followed a recommendation to put the various CFP executables in BOClean’s Excluder list. As advertised, this does minimize the log entries and normally is o.k., but when Comodo Firewall Pro updates, at the required system restart, BOClean alerts that three (or so) of CFP’s components have changed: at this point, however, the system becomes pretty much unusable, because the BOClean alert windows are unresponsive. Eventually, after a very long time, the Excluder window opens and I can very laboriously remove the items in it one-by-one: the labor is greatly increased by the insistence of BOClean of remaining on top, which means that one has to slide windows around all over the place to get the necessary removals accomplished.

I believe these matters are BOClean issues, not CFP ones; and they are not associated with CMF (which I also run), as far as I can see from one quick test. For now I will leave CFP out of BOClean’s Excluder. However, I believe several things might help: first, a much smaller alert window in the first place, as well as one that does not insist on being on top; second, something to limit or avoid the heavy cpu use of BOC425.exe while this alert is displayed: it seems to consume 50% or more of the cpu resource (per Process Explorer); or even a mechanism whereby the various Comodo products would not randomly interfere with each other.

It is a real nuisance to have CFP look with suspicion on BOClean while the latter is casting doubt on the former. There must be some way for the Comodo products to recognize each other as safe and to cooperate with one another, rather than fighting in the alley all the time.

Hey pudelein :slight_smile:

I don’t if the Dev Team is aware of this, but maybe it is good idea to pm Kevin :slight_smile:

Greetz, Red.

I’m looking into this, as I’m hoping to get a new version out as soon as possible in order to deal with a few other issues which have arisen lately … “adventures” with removing stuff from the excluder and having it store the wrong data depending on how things were clicked is already solved for the next BOClean - in other words, if you remove something from the excluder, the CORRECT removal will occur. So if that’s part of your grief, already fixed for the next release.

As to the Firewall, they do replace files from time to time over there. Hopefully an explanation of why the excluder works the way it does and what you might want to (or NOT want to) exclude might help since I don’t see your particular issue being solved without a major redesign of BOClean’s excluder (a separate utility) and/or a change to how the firewall works … and sadly, I can’t see any upsides to either proggie changing the behavior.

Lemme explain …

ANY security program that’s going to have a real sniff at what’s running must intrude into its memory space to check out all which is resident (including nasties which might be “injected”) and therefore, we’re NOT going to make BOClean stop sniffing at everything that’s running, including even other COMODO products. And the firewall folks aren’t going to do likewise either … ALL of us would be remiss if we allowed an anomoly slide without warning simply because “oh, we’re all in the same Army and if that’s COMODO, we should ignore it.” Simple fact is, the “givers of nasties” EXPECT that some security software will have an ignore function which is not absolute to sneak past the guards. :frowning:

The excluder’s simple PRESENCE is a danger to BOClean … any rogue program could add itself to the list of excluded, telling BOClean to never detect it. Not a good idea. This is why the excluder, it’s data encryption and its separate nature from BOClean has always been so strict about any changes … you’d be amazed at how many times that excluder has saved my personal but from a file infector detection which was an “unknown” all these years because one of the files excluded got hit, and the alarm went off from the excluder itself fired off, but not a peep out of anything, not even Boclean! THAT was our warning to dig deeper on our lab rats.

So … what we have here is a situation where BOClean accurately detects modifications to those proggies you’ve told BOClean to ignore. And it fires off indicating that things have changed. So, works as intended with adverse results. Dunno where the advice to exclude the firewall came from since compatibility between ALL COMODO products is actually pretty good. So I s’pose the question (since I would strongly advise the firewall folks here NOT to give BOClean a “free pass” either if it’s acting funny) would be should we weaken BOClean? Or how bad is that logging issue? Perhaps there’s a way to reduce the “logging noise” of the firewall, but too busy myself to know the answer there. But for now, given the intent of the design of BOClean’s excluder, that it’s going to fire off and complain if the firewall exclusions really DO change … that’s what folks pay us to do. And I guess, same for the firewall.

So let’s just say … I need to get a new BOClean version out, and dang soon! Since I’m in code mode and have been a for several weeks now that change requests for BOClean have been frozen “internally” I will see if I can figure out a bit of a SMOOTHER way in which it is all handled, but I’m not going to change the design - I don’t see any SAFE way to say “oh, COMODO FIREWALL … ignore anything out of place there” … I see that as a major potential risk. But let’s see if I can find a way to make it all go a little bit smoother. That might be possible. :slight_smile:


Thanks for your reply! I agree with all you say about needing BOClean to be “hypersensitive”, particularly with respect to excluded item changes. However, when such changes occur, as at a CFP update, it would be nice if corrective action could be taken without all the obstacles I have faced at two CFP updates. As I mentioned, the insistence of BOClean to have its alert window on top is a significant obstacle to fixing things, since that window totally covers the Excluder window: maybe the alert window could be made smaller (much smaller). As to altering CFP’s logging behavior, that would be an even nicer thing to have; BOClean is not the only program to be logged by Defense+ unnecessarily, Tiny Watcher is another.

Glad to hear that an update of BOClean is imminent. I will look forward to seeing it.

As the professor would say in “Futurama,” … “Good news, everyone!” Heh. Took the last two days, but your worries have been resolved in the new code for the next release - a bit more sanity. Your situation was a rare one until recently and the truth of the matter is that I had no idea that the handling of your situation was hosed for many versions. It’s been fixed now. What WILL happen though is that after delivering the alert, the next release of BOClean will continue to sniff before “releasing” that window for further action until it’s done doing its startup thing. There will be an hourglass over the alert until it’s done. Once done though, when you click on the excluder, the alert window will go to the background now and when you’re done with the (also fixed) excluder, it’ll clear up and close when you’re finished. That should do the trick - just wanted to explain why it’s going to do what it will do in the next release.

But should be much happier … :slight_smile:


Your fix for my BOClean issue sounds good to me! I will be looking forward to getting it! Any idea when the new version will fly?

Snap. Just cost me 4 hours after I updated a video player. Mine was worse because at startup I already had a slowdown problem as Bofiend, whoops, I mean BOClean, fought for CPU time with BCwipe and AVG. That was already a 2 or 3 minute wait with no useful response form the keyboard or mouse. Coffee time.

When the alert problem occurred and that gigantic window came up (honest, its big enough to list the Doomsday book,) I was able eventually to get to the excluder window - fter a long enough wait to drink 3 cups of coffee INCLUDING popping out to my local equivalent of Waitrose equivalent to get some sugar. But then it wouldn’t remove the offending program so I could add the new version!

So next startup…Aaargh!!!

I then temporarily disabled BO***** , 3 more cups of coffee and a game of darts, and tried to just run the excluder manually. But that wouldn’t take. Just seemed to revert to the removed version of my player and complained as soon as I relaunched it. Bizar.

I am farily patient as a rule, but this one nearly had my CPU in pieces on the pavement 4 floors down. Finally I gave up and booted into safe mode and deleted the little ■■■■■■. Die you evil piece of ****!!!

While you’re on Kevin, is there any way you could get BOClean to check the CPU temperature when it goes on its little tantrums? It really needs another CPU all for itself! Or, if it really does need to compute the sqaure root of infinity 3 trillion times, when we are upgrading an app, could we just have a say second button on the excluder that instead of saying Remove says Re-scan this app? Then you wouldn’t have the hassle of a re-write, debug, realease, re-debug, etc.

Now, blissful calm has descended. Thoughts of nuking Greater Manchester have passed into history, and I await patiently for an update, secure in the knowledge that even if Ebola hits my Celeron in BOClean’s absence, at least I won’t see that frigging alert on the next reboot!

Tired, …bed.

I’m hijacking the thread, in order not to start a new one :stuck_out_tongue:

I have excluded cfp.exe from BOClean, but on CFP Defense+ events I stil get:
BOC426.exe interprocess memory cfp.exe/cfpupd.exe/…

What do I do?

edit://Ok I followed this tip and everythink ok now :slight_smile:;msg111955#msg111955

Needless to say, not normal … apparently AVG and BCWipe are having a happy fizzies party and we’re not invited. Have you moved on to 4.26 which is a LOT more forgiving of this?

I hope you understand that BOClean complaining about any changes to the original file(s) is a necessity since when a file is excluded, BOClean will NOT respond to it at all. Therefore it’s necessary to ensure that the file has not caught the “sniffles” from a file infector or has been otherwise “messed with.” About all I can offer that will preclude the insanity is bear in mind what you’d excluded when upgrading and remove the file(s) ahead of time - not much I can do when the tripwire is kicked on a change and your other programs won’t allow us CPU time because they’re hogging it all. Normally, all this is quite painless. :frowning:

Sorry for the headache there!