Hi, folks! I’d like to take a second to CONFIRM that this is indeed an insect in the excluder. Work is underway for a new version of BOClean as a result of this, though I’m not sure yet whether we’ll make it a 4.26 or a 4.30 in order to include some new stuff or not as yet. We were all collectively hoping NOT to have to release a new BOClean until we’d had a chance to play with the public release of Vista SP1 given how very well BOClean 4.25 had been working for quite a while now. 
But wanted to explain the technical reasons behind this manifestation because it might end up resulting in an outcome which I’ve been trying to avoid for a few years now - namely, the obsolescence of Win95, Win98 and WinME support … something I’ve been trying to avoid facing for quite some time. It’s MOST inevitable, but I’ve been doing everything I can to hold it off for as long as possible as there are STILL so many using Win9x!
For now, I think we can solve this without turning BOClean into “Win2000 or later required” though I’m looking at other issues with respect to handling corrupted downloads which may affect this. Not quite sure as yet since this is a reproduceable and solid problem. MY apologies to all for it happening.
For those interested in why though, here’s the deal. The excluder makes use of an “explorer screen” in order to display the program icons and such. In order to retrieve a “file save” from this screen as to what is removed, one has to call Windows functions that are inconsistent across various versions, and not so long ago, these have changed in their absolute values. Once upon a time, Windows “API’s” had a base value of 1 or 0 (a throwback to MS-BASIC “option base 1” or the default of “option base 0” … Explorer screens in more recent versions have an “option base -1” and that flies in the face of the old boolean logic of “TRUE=1” and “FALSE=0” … so, so simple doing boolean. Leave it to Microsoft to define “False !=0” or in other words, “anything can happen day.” 
Anyhoo … you’re RIGHT … there IS a problem, and code for that has already been fixed to deal with the changes in recent times as to how that window is handled by various Windows OS’ and patches. As a result of this though, BOClean is being re-evaluated and reworked, and those issues with how it was handling bad updates is even more important to a new version than this particular issue even though this was the “trigger point” for a new build.
COMODO continues to honor MY values of “BOClean is too important to foist betas and ‘we dunno if it’s ready yetware’” upon the public - it’s always been MY philosophy not to release “not ready for prime time testware” upon the public. So let’s just say, “so noted, you guys ARE correct - proveable problem here, and I’ve already fixed it in code” … I’m still on the other strangenesses and finding solutions for that right now and as soon as we have the rest of the questions and possible solutions solved, there will be a new version of BOClean which will fix this for ya! 
Can’t say right now how long it’ll take to get the new version done, but THIS is resulting in a new build … I’d just like to have a ■■■■■ at a few of the other weirdnesses reported on other fronts first and try to reproduce THOSE as well in hopes of nailing more than two issues with a “next version” release … but wanted to let everyone know … yeah … this one’s real! 