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.
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 …
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. :-TD 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.
[size=6pt]~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 :)[/size]
My regards
I’m running SP3. So perhaps there is something new in SP3.
I started seeing the problem before I installed SP3. SP3 hasn’t made any visible difference with respect to this issue.
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 …
Nice that you are already working on it
Just write if you need some help e.g. a test carried out.
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
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
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 ■■■■■ 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.
The problem I have is a little different as I do not run MIRO. But BOC 4.26 quits when starting Adobe Premiere Elements 4.0 (with Premiere Elelments 3.0 BOC keeps alive).
My opinion is, that Premiere Elements 4.0 does have a quite large paging activity during loading. Could this be one part of reason for BOC to die?
My solution is to restart BOC again after I have closed Premiere Elements.
I am running XP SP2, CFP 3.0.22.349 and Avast.
Hi Kevin,
great that you found the problem. It seems to be a wonder that Miro manages to work somehow 
I will test that unsigned version to confirm that it’s fixed. But I wonder because I have 2 Gigs of RAM…
I will second weaker’s comment. I am running on a 2GB machine also. Sounds like this even worse on a system with less memory.
No problem if you want to send a “test” code file. Anything we can do to help.
In my day job I have seen the results of coding being “sent out” and I am not impressed. Who knows who might have been coding what in MIRO. You have obviously spent a great deal of time tracing what is happening. I am not sure how easy it would be to pass this on to MIRO as they obviously aren’t intending their program to be a test of Windows fault handling.
By the way, I encounter the same type of BoC crash (0x20202020) with the VLC player 0.86f playing a DVD (with menus). Perhaps Miro and VLC both use the same video decoding module that poses a problem to BoClean?
@Jim__
Do you also see that behaviour? VLC home is here: Official download of VLC media player, the best Open Source player - VideoLAN in case you don’t know VLC.
@Weaker,
No problem playing either DVDs or or other video files with VLC. I am running the same version that you report.
Interesting. I have two new things to report. When BoC was crashed (with 0x20202020) by VLC playing the same files as in Miro this led to a very interesting effect when I shutdown the system a few hours later:
Windows complained about that an app is not responding and has its countdown and the “kill now” button. That function that crashed was named nsAppShellEventWindow which seems to belong to NSClean’s BOClean
The second thing is: After I shuffeled around data on my harddisks, Miro was unable to find the location where its videos were and defaulted to a (nonexistant, because my Win is German) “My Documents/My Videos” path. But BoC did not crash!! This leads to the conclusion that Kevin was on the right track to follow with difficult filename handling.
HTH
weaker
Hey guys! Apologies for being sidetracked … got handed a “critical mission” by Melih and had to put this aside whilst doing some other things, including an official “hajj” to New Jersey earlier this week. Heh. Bottom line though is YOUR probloem got solved in code last week, but have been too busy to “come out and play” this week.
Glad to see that you had the opportunity to see that it isn’t BOClean once WE were out of the way! And for anyone who cares, the “nsAppShellEventWindow” thingy is actually MIRO’s doing. The lower-case “ns” function names actually were a universal naming convention of “NetScape” from which that function derives. When “NSClean” was originally born back in 1995, the “NS” also meant “NetScape” since we were the very first “Privacy Software (Corp)” which dealt with cleaning up the original Netscape and elminating traces of “internet records” … but that’s where the “NS” angle ends. This is the MIRO program’s “main window” which receives “PostMessage()” results from the underlying player once it’s talked to the kernel … I saw that crash often myself in the research into this “WTF?” Heh.
But that was MIRO being broken, and unable to take itself down completely, leaving that as one of MANY “hung DLL’s” when Miro bites the bag. LOTS of old Netscape code in MIRO! This is one of the problems with “open source” in that someone else posts BAD code in hopes that someone ELSE can fix it, people download it, write their own code around it and never FIX it. I’ll just leave the reality there since it’s not germaine to what happened here.
The REAL problem which caused the BOClean “whoopsie” on Miro is that MIRO ran the system completely out of memory! When THIS happens, Windows will try to find all the memory it can, based upon what the kernel’s internal tables think are not allocated anymore … “garbage collection” was what it was called in the “old days.” But WHAT IF the tables have been turned to garbage themselves as a result of “shooting buckshot” in memory by a badly programmed program? If WINDOWS was told the memory was freed, then it WAS … only problem is that the way MIRO is working, it was trashing memory in the kernel itself!
BOClean uses PSAPI functions, as well as WDF in order to have a shot at detecting rootkits. The actual crash wassn’t happening in BOClean itself, but rather in the Microsoft PSAPI libraries which suddenly had no memory available to pull a database of memory allocation (which BOClean needs in order to find where to look) and having the rug pulled out from under the kernel was the cause of this problem as MIRO blew up windows itself!
Anyhoo, solved that last week. BOClean now holds the memory for what it calls under PSAPI now and will NOT allow it to be “garbage-collected” by an errant kernel. That was the solution. I still have a few other “last program installed gets blamed for all the others” and have also fixed the alert on a bad download, explanation of “module not found” and better 'try this" results, and have one LAST complaint involving services which were excluded but are STILL being detected yet to be recoded.
Once I have THAT done (and hope to find some time over the weekend coming) then I will offer you guys a “test build” to play with to replace your existing BOC426.exe to test it out with. Stay tuned, but I’ve EARNED a few days off … will be back to ya’s all with some HAPPINESS! =)
Edit: added information as to the origin of “ns” and its relationship to “NSClean” …
You definitely deserved your break. Take your time. Devote it to your family. No hurries here.