After a boot the systray icon is blue with the BOC426 process using 100% of a processor for several minutes. The process then ends with no visible error messages. Restarting BOC results in the same behavior. Uninstall/install did not help. I have reinstalled 4.25.
Hi Jim__ 
Did you shut down 4.25 before you uninstalled it ? Did you check if the CBOClean folder and its contents was removed before you installed 4.26 ?
Greetz, Red.
yes,yes
It is normal that BOClean is blue for some time after booting up, because it examines every single process, thread and dependency at startup. But it is not normal that it does that using 100% cpu :-\ What other security programs are you using ???
Greetz, Red.
4.25 uses 100% CPU at startup so 4.26 doing the same might not be any different (characteristic of the processes on this system perhaps).
The 4.26 process ends at about the same point in time where 4.25 goes idle.
When 4.26 ends, the systray icon is often left behind. The icon was sometime green (but not always).
CFP 3.0.22.349
CMF 2.0.4.20
CAV build version 2.0.11.43 Program updates version 2.0.17.58
Secunia PSI v0.9.0.1
Windows Defender 1.1.1593.0
Well I am stunned here. I can only tell you that BOClean doesn’t use 100% cpu at startup with me. I am sorry I can’t help you, but I think you should wait for Kevin
Greetz, Red.
Red,
Thanks for your help. I have 4.25 installed and it is running without a problem. I will keep watching this thread for suggestions (diagnostic or otherwise).
I’ll go for a suggestion out of curiosity … try it again and when you go to install it and run it, try excluding BOCORE.exe and BOC426.exe in COMODO Memory Firewall’s exclusion settings … it looks like it’s getting stopped when it starts to run and isn’t being released in your case … dunno why … it should, but that’d be MY guess.
Kevin,
I will try adding the exclusions and report back.
Jim
Kevin,
Installed 4.26 last night and added the exclusions to CMF. Everything ran normally last night. Everything seemed OK tonight when I first started the system. BOC did its thing after boot up and then idled. After a bit there must have been an update (download) based on changes to the systray icon. After that BOC426 ran using 50-100 of a processor for awhile. After a minute or so BOC426 ended. Ran the program again and I see the same high processor utilization followed by the program ending. At this point BOC426 doesn’t seem to want to run. BOCore remains, based on process explorer. I will note that BOC426’s systray icon remains behind after after the process ends (a windows quirk I think) and it is often green, not black or blue.
Is there debugging/tracing functions that I can turn on so you can see why BOC426 is ending? I don’t see this behavior with 4.25. I will wait for your next suggestion.
Update:
Started BOC426 and right clicked on the systray icon (several times) while it was processing. When the menu came up a did a check for updates (none found) and a reload/test update. Closed the menu and BOC426 continues to run.
If it misbehaves, IM me and I’ll tell you what to do, though there’s no specific diagnostics for a situation like this - if it should stop like that, we probably won’t know what stopped it - only what was running … but we can hopefully figure it out …
Kevin,
Problem with BOC426 ending returned tonight after the automatic update. I have turned off automatic updates.
IM sent with additional details.
Saw your message, hope things are saner, and I’ll be back on duty tomorrow night once I get me another test machine built on this end to have another go at it …
Kevin,
It’s not automatic updates.
Everything came up normally on starting the system this morning. Watched BOC426 do its initial scan. After that finished, fired up iTunes for a PODCAST and then quit iTunes. All still OK. Started MIRO.EXE. BOC426 went to 50-100% processor for some amount of time and then ended. Each time I started it, the cycle repeated. After shutting down MIRO, started BOC426. BOC426 remained running. Repeated starting and quitting of MIRO did not cause BOC426 to end. After the next reboot, I won’t run MIRO to see if it is at all related.
Note that this is occurring on a dual core machine. When say 50-100% processor I mean 50-100% of one core.
I am leaving automatic updates off.
Update:
I turned automatic updates back on Saturday night. It has not been 24 hours since the last manual update so I am not sure if automatic updates have run (I have changed the frequency to 4 hours to force additional automatic update cycles). I have not run MIRO since powering on the system this morning and BOC426 has now been running normally for several hours. While MIRO doesn’t cause a problem with BOC426 every time it is run, I do believe that every time BOC426 has ended, MIRO has been running.
I changed the Subject of this thread. After running for a week with no problems but never running MIRO I started MIRO. Within a minute of starting MIRO, BOC quit.
Same here, running Win XP SP3. I also have CFP3 (latest), CMF (latest) and Avira AntiVir running.
As soon as I fire up Miro (latest version), BOC426 crashes while the BoC-Systray icon is green.
This is quite reproducible as it crashes always. I think Miro is the culprit but why it is able to crash BOC is beyond me.
Support ticket MDO-294954
I don’t know if you can add that you are seeing this or if you have to submit your own report.
I just know you guys ain’t gonna be happy … MY sorries … don’t think for a second that I don’t care …
Went and downloaded MIRO … dayum! I remember that proggie! Used to be called “Democracy Player” but then I s’pose the media caught up with them. Heh. Gotta explain a philosophy here, since as simply as SONY did a rootkit, there’s an issue with PeeCees … “speed and memory freeing” … Microsoft is doing SO many stupid things in their kernel with later systems - especially Vista - that ANY media player is bound to choke as its CPU time is eaten by “I can has backup now, thx” and other “kernel nonsense” as “security warez bloat out.” 
I suspect that MIRO is actually successfully shutting DOWN BOClean and there’s the problem. Repeat: I SUSPECT!
I can see the need and desire to do so - anything that UNtaxes a bloated demodulator by requesting clock cycles is better … and the more “known CPU users of ANY sort” will get whacked. OR perhaps, MIRO doesn’t like being “probed” in memory. THIS would be a good thing actually even if it complicates things for BOClean. Just wanted to offer folks a vision of how MY mind works … any problem, from sunspots to acne" is MY fault. And I judge reality by that basis. “WHAT did I forget?”
SO … just for laughs and giggles, since I do NOT have an answer to this as yet, and WANT one just like everybody else:
TRY dragging any EXE and DLL files from MIRO into BOClean’s excluder. To make this useful for you and others, let’s try one at a time until it fails to work, then go on to another EXE first, DLL’s once all EXE’s have been exhausted, and let’s see what does it? Sorry I don’t have a better answer, but as Murphy’s law recommends, “works HERE just fine!”
Objective is to stop BOClean from scanning THEIR file … and by excluding things, BOClean will flip out at ANY change to any excluded file in question, so doing so won’t be a security risk. What would HELP me figure out what’s going on here so I can figure it out is seeing if stopping BOClean from “sniffing it” will solve the problem, OR is MIRO coming after BOClean and actually killing it? IF so, hate to say it, then MIRO is malware. If they shut BOClean down to recapture its memory, then what’s to stop MIRO from taking down a server?
But YEAH … MIRO and any problems with BOClean aren’t a detection issue … something’s wrong. Sure DO wanna get to the bottom of THIS! Just don’t know what the answer is as yet.
HALP!
I’m not sure if I understood you completely.
I entered all .exe files from Miro’s folders into BoC’s exclusion list. I didn’t add the .dlls because there is no way that I add 246 files one by one :o. BoC only takes the last one if I want to drag many.
Unfortunately it didn’t help. It crashes as soon as the Miro.exe from the xulrunner directory is started (which seems to be one of the fist parts of Miro to start). The crash message is as follows (translated badly from German):
The command in 0x20202020 points to memory in 0x00000000 The operation "written" could not be performed on that memory. OK / CancelThat memory address 20202020 looks like an adress, a compiler puts into memory to help debugging. (MSVC uses 0xcdcdcdcd IIRC) but that's just a wild guess.
I don’t see a crash for BOC, at least not where I am looking. I will note that BOC425 runs just fine. I verified this by uninstalling BOC 4.26 and then installing BOC 4.25.
Now if MIRO is malware, BOC isn’t going to do a very good job if it can be stopped that easily with no indication that anything is wrong.
If I read Kevin’s post correctly, he hasn’t been able to recreate the failure on one of the test systems yet at least two of us are having a problem. I will note that I have plenty of processor cycles available when BOC is terminating. It terminates after it does some type of scan. If you want to make a diagnostic version of BOC available that would trace what is taking place I am more than willing to install it and provide the trace files.