BOC 4.26 quits When MIRO is Run

[Guest]

[weaker]

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.

[Jim__]

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.

[Kevin McAleavey]

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! 

[weaker]

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 .  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 / Cancel

That 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.

[Jim__]

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.

[Kevin McAleavey]

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 .  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):That memory address 20202020 looks like an adress, a compiler puts into memory to helb debugging. (MSVC uses 0xcdcdcdcd IIRC) but that's just a wild guess.

20202020 is definitely not a memory address which BOClean will use, and we don't have "debug data" inside it as that would slow things down. I don't expect Miro would be in there either. And while BOClean does have a kernel driver of its own, it only accepts a callback from the system itself and relays information to the main BOClean program. The kernel driver does no "calling" itself. I'm leaning at the moment towards wondering if some OTHER kernel driver for something else (possibly one of the COMODO proggies or MIRO itself) might be doing that branch to doom ... memory address of 00000000 is absolutely invalid - question of where it's getting popped from is the big mystery but that's already more info than I already had. Replied to the IM ... am headed out for the night.

[Kevin McAleavey]

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.

 As I just posted before, I'm quite keen on getting to the bottom of this, and you're right ... I can only fix that which I see myself and can then trace to its cause. Just wanted to toss out that "back in the day" BOClean did have termination protection, but there are severe limits to how many "kernel hooks" there are available (used to be 8 of them, but thanks to Microsoft getting into "defending" there are now usually only three) and once that number is exhausted, no more are available. An antivirus requires one of those, and a firewall DEFINITELY requires one of those. Add just ONE more "security-type" proggie, and all gone. 

 So when we came over to COMODO with BOClean, it was decided that it would be best for anti-termination to be done in COMODO's award winning firewall just as we encouraged people to use "Process Guard" to do that in the old days so that BOClean itself wouldn't become a security liability. Just wanted to let everyone know why we did that ...

[SiberLynx]

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 .  BoC only takes the last one if I want to drag many.
.....
 The crash message ...... memory address 20202020 ....

Greetings all,

First I came here to confirm the statement somewhere above that all BOCleanes until v4.25 worked fine with all Miros starting from Democracy Player era until Miro including v1.2.1
All that was on XP SP2.
I don't want to mislead anybody but I was under impression that BOC 4.26 + Miro v1.2.1 + SP2 combo was working fine together. Again, please do not rely on that information or just dismiss it if anybody have such set currently.

What I can confirm that the combo BOC 4.26 + Miro v1.2.3.0 + SP3 is cruel and coldblooded BOC murderer.
There are No crashes as weaker described though.

Actually I came here to post a bit different message which was:
"I am not going to drag 246(!!!) dlls into Excluder one by one.
I'd rather let BOClean die peacefully; then do whatever I want in Miro and then restart Boclean"

Now I see that weaker said almost the same because, yes there "is a way" - one by one.    That's why I said  "not going to"

Is it possible to change that and as a matter of fact removing from Excluder procedure as well?

The latter should be done one by one as well despite strangely enough you can highlight all or a group of items using Ctrl.

~Edited I removed my remark here because could not reproduce 3 times in a row what I was reporting as a bug (separate to current issue). Till next time or I hope I was wrong, which is good in this context 

My regards

[weaker]

I'm running SP3. So perhaps there is something new in SP3.

[Jim__]

I started seeing the problem before I installed SP3. SP3 hasn't made any visible difference with respect to this issue.

[Kevin McAleavey]

 Built another machine earlier today with MIRO and am currently loading it up with other goodies. I already see that MIRO has over 300 dependencies! So there's definitely an overload there, though BOClean is designed to reallocate if necessary. A memory monitor external to BOClean is a good suspect, but then again the kids at Mozilla went and made very very long filenames. So I have a few theories to go with already since I haven't been able to reproduce it here as yet. However, MIRO definitely has a few qualities to it that'd make me more than twitchy if I was in charge of the project. 

DEFINITELY not an SP3 issue ... the whole reason for 4.26 in the first place was compatibility with Vista SP1 as well as XP SP3, and "corporate developers" get the REAL goods in their hands before many others. No, the issue is with Miro and I'm currently working on getting around it. Might take a few days though. There's also something weird in SP3 with respect to German (since "foreign" versions of Windows are unicode ONLY, and BOClean is ANSI in order to be compatible with ALL versions of windows and converts that) but I'm not so sure that's relevant either. I don't see THAT being an issue either since in the end, Microsoft is a USA company and will return USA results as long as you program it to ...

 Hang in there, might be a couple of days before I have an answer ... I am the one and only one person who controls the BOClean code, and I have other things that need to be done as well ... but been burning the midnight coils (heh) for many days on this since it's apparently quite real, and I really DO believe in "mine canaries." If someone has a problem, then OTHERS will as well. Want to find out why and find a way to fix it. It's not my job to come to the forums, but it's also been my own tradition that upon any new release, I want to personally see how it goes for my OWN satisfaction (or need to get back at it) ... but I *will* figure this out as soon as I can see the problem myself ... and that's what I'm working on now ...

[weaker]

Nice that you are already working on it :-)
Just write if you need some help e.g. a test carried out.

[Jim__]

Kevin,
Thanks for the effort. Since we know it is a MIRO thing, I can detour by running BOC after I end MIRO. What is of greater interest is if some MALWARE could cause the same thing. I am sure that is why you are interested in pursuing this as well. Best of luck and let us know if you need information since we seem to be able to reproduce this.
Jim

[SiberLynx]

Hi Kevin,

I join the company to thank you for addressing the problem.
No rush with this I think. We can wait.
It would be nice though even before solving main issue to implement some changes just to mentioned procedures of including/removing group of files when working with Excluder.

My regards

[Kevin McAleavey]

 Thanks, guys!

I can confirm now that I've REPRODUCED the problem, and it's a corker! Back when PSC did BOClean, we had machines for testing that were designed specifically as "least common denominator" ... OLD stuff running OLD OS, designed to be "minimum quality" since the weakest machine would break before anything "neato swifto" ... my old lab rat chassis died a couple of months ago and COMODO got me a recent vintage HP box and that as well as my trusty old 64 bit AMD machine were sufficient for testing.

What I *didn't* know was that the main machine came with TWO gigs of memory, not just one or 512 meg. 2 gigs, no problem. 1 gig unstable, 0,5 gig, blew chunks. Miro has to be the most bloated program I've ever seen before, and THERE'S the problem! 

Having said that, I won't offer my true opinions of what I've just played with since it'd only get ME and COMODO in trouble for going into it. I'll just offer that to MY mind, only ONE instance of a library is sufficient - whole point of having DLL's in the FIRST place was to load ONE copy and let every other program which needed it SHARE just one copy. I'll just leave it as ... MIRO is the problem. I'm too busy to research and resolve their problems. And I use Firefox, and was already used to the inefficiencies of XUL. Bottom line, Miro is crashing Windows ITSELF! And then doing one UGLY recovery a step short from a BSOD!

 Errors I was seeing were the most unique one in the world, which ONLY results in BSOD - the infamous 0XC0000027! This error is extremely rare, and is known as "STATUS_UNWIND" error ... which means "WBEM_MC_ADAP_DUPLICATE_PROPERTY" from a KERNEL failure, and that in turn means that memory is SO corrupted, only a memory HARDWARE failure can screw it up THIS badly! For "old timers" ... "parity error."

 For those concerned about malware doing something like this, malware would never WORK! Heh. But MIRO is literally using a gun and "buckshoting memory" and the failure mode is in the Windows kernel itself. MIRO is hosing the PSAPI Microsoft library, creating memory GHOSTS (to the point where Miro itself is loading MULTIPLE copies of DLL's it's already loaded before) until it kills memory and steps on other programs! THERE's the problem.

 Once again, NO offense intended towards "mozilla" and I speak ONLY for myself in what I sat here for the past couple of days analyszing and absorbing, and MY opinion expressed here is SOLELY my own! But YIPE! 

 So OK ... decided to write a few workarounds since if Mozilla can do this to code and have BOClean die because WINDOWS did, have written some workarounds to ignore bad results, check again and again until there's a GOOD result, and was AMAZED to see green flashes on BOClean's traybar with the new code to see just how *MANY* kernel bombings Miro does! Wowsers.

HAVE a workaround, looks good so far, and will burn the weekend ahead testing it to be SURE it's "the fix for that." But I has faith, and for now ... THANKS for pointing that out ... Miro is actually taking out the kernel and performance monitor (PSAPI) and THAT is what's crashing ... but BOClean now needs to PROTECT Windows there to ensure it doesn't splash on OUR shoes ... done. Some testing, some other changes based on other complaints, and looks like either a new version or a "patch" ... dunno what we're doing as yet, but will want you guys to test the "fixed" before I go the other steps ... hang in there ... I've finally SEEN the problem, and I'm not amused.

 So lemme put it this way ... I THINK I have a workaround for what they've done and will offer you guys a "test copy" (it won't be SIGNED though) as soon as I code up some of the other things I want to tackle such as error messages that cause confusion and redoing how memory is allocated, then I'll contact ya's and get you a replacement BOC426 for now until we can decide what to do and if what works for me works for you.

[Tags:]