PG and BOClean : quote from Kevin 1-March-2005

Howard,

I'm sure you've alerted Kevin to this thread or perhaps he's noticed it himself. As my screen shot above suggests, I've suffered the same problem although I tend to focus on these things only when a clear impact on usage follows, and this problem hasn't crossed that threshold for me yet. I'm sure many other PG users are in a similar boat, it's not a major problem, but it is present. Hopefully the test build will be released to the BOClean community at large when it is locked. It is nice to hear your woes may be at an end!

Blue

 

Hi Blue, it is Kevin's intention to release a new beta to be tested, but it will be more refined and sophisticated than the test build that is making me smile again. (The test build confirms, by the way, that ProcessGuard is by no means innocent in this, although the whys and wherefores are beyond my limited grasp; I'm just glad to have my favourite anti-Trojan back on continuous guard). And in case I haven't already and he isn't, I will ensure Kevin is aware of this thread

 

Howard,

Thanks.

Maybe we're dealing with the domain of unintended consequences. I know that Kevin has been clear regarding his opinion of mucking with things at a kernel level (see here), particularly within individual AV/AT type applications in which a cascade of these pertubations could certainly have undesired consequences. Regardless of "fault" in this case, it does seem that it may illustrate his general point, as well as his caution that if you're going to do it, go via a single path (e.g. PG vs. a collection of applications many of which practice this finesse).

Blue

 

For some reason, I can't login here - I suppose I've expired. ("Bring out your dead! BONK!)

This situation REMAINS in flux - all this talk of memory leaks is incorrect. The PROBLEM is *absolutely* ProcessGuard, but I'm still struggling to figure out WHY it's assigning a "thread stop" on BOClean (not to mention how it can even DO so) charging *us* for the CPU time. Based on the observations by folks, I've pursued numerous dead-ends, using Filemon, the internal PSAPI libraries and other tools which ACCURATELY charge CPU time and other data in the performance libraries to the proper source. Alas, the specific PSAPI tools are on the Win32 SDK and not generally available to non-programmers and thus the CPU time is apparently being charged to BOClean as far as anyone can tell without using debugging tools to get at reality. No biggie.

At FIRST, people were complaining that the excess CPU time was based on BOClean reading INI files ... well, the need to do that went away in 4.10 owing to automatics, but we never removed the entries in 4.11 because that (no longer used) code was carried over from 4.10 and we just didn't want to risk complaints of "unhappy update" if we took it all out. We did a few days ago since 4.12 no longer has any of that old "legacy code" ... and since people swore that was the cause, it was an EASY "WTF" for us to take it out as it was no longer needed - all I had to do was explain the database SHRINKING by 28 entries.

Turns out, that wasn't it. Others offered that it was a "memory leak" ... well ... about a year ago, in another exchange between me and TDS over ProcessGuard issues, I was told that BOClean had "memory leaks" ... spent a several weeks checking it, and as it turns out there was an issue whereby XP itself was doing the memory leaking, when ProcessGuard was present, by not freeing our hook into now-closed processes because Windows never freed the space of our "hook" which was placed by Windows itself and NOT BOClean. Microsoft still hasn't fixed this "lost unload instance" bug. THIS one wasn't PG's fault, though the extra CPU cycles in the kernel increased the chances of it missing this by slightly greater odds.

In listening to others though who said "BOClean has ALL this ACTIVITY on each recalibration" I did the first "test build" that removed all of the "GetShortPathname" calls (which is used as a redundancy check to deal with another not-fixed Microsoft bug - the "double-dot exploit" in filenames to ensure that the filename we grabbed to associate with a process wasn't a dead-end) ... given all the FILEMON activity over that, I expected THIS was what was giving PG fits and moved that past our caching ... put out a "test build" ... nope ... wasn't THAT either. NO difference except for a SLIGHT dropoff in CPU overload. So NOW we've determined that the problem isn't "query data" calls as I'd originally thought. Thus, that info didn't help either.

What we've done THIS time is further cache data, BUT doing "zW" calls to NTDLL.DLL in ring zero directly from ring 3 (used to be impossible, THANK YOU SP2, you've out-competed Madshi by no longer requiring kernel emulation, aren't y'all PROUD of reducing XP's security to lower than Win95?) which allows us to just BYPASS ProcessGuard as far as the spikes on recalibration go.

HOWEVER, we've ALSO learned that PG seems to be hanging up on doing memory scans as well as LoadLibrary calls to verify the existence and validity of certain dependency files - this we CANNOT stop doing, so the ProcessGuard CPU overload still exists when a new process is loaded, a new module is called, or any other situation where we have to dump the cache and check everything again. People REALLLY don't want us to screw with this. Really.

At this point in time, I still haven't identified what we're doing so annoys ProcessGuard as to keep ripping the rug out from under us. The CPU time though is BOClean fighting for its own survival ... WHY I don't know quite yet, and thus it's going to be a while before we solidify a "new build" ... for now though, candy in the form of what we got so far can be handed out to those who MUST have it ... but I want to get to the bottom of this and I've ONLY bought my first vowel here at the moment. If it were *MY* code, it'd be fixed in HOURS ... somebody ELSE'S code however brings out the lawyers to bits-slap me ...

HERE's the problem. I get paid by all of you to reverse-engineer trojans and protect you from them. Wayne and Gavin and all are FRIENDS of mine, but they are ALSO "competitors" and therein lies the problem. Since we've got a 5 version in the works *WAY* down the road from now (and we're not a DAMNED SECOND CLOSER to release than we were this time last year owing to the workload here) and it's going to be truly impressive (and like the original BOClean, an entirely different path dfrom what we do now, and completely out of the realm of what people EXPECT - we don't do file scanning as a basis now, and we're DEFINITELY not doing it in the future - in fact I see MEMORY scanning as being a future dead end too, just like I saw FILE scanning to be worthless back in 1997) and will have some features similar to that of ProcessGuard, but very different.

Therein lies the problem. I *CANNOT* so much as LOOK at a ProcessGuard SCREEN, much less dissect their code legally. Because *I* write the code (with a few others) if I were to even TEST against a competitor on a machine I was at, I could become legally responsible for "theft of intellectual property, patent fraud, 'ripping off'" ... so because it's a competitor legally, I *cannot* so much as RUN ProcessGuard or be near our folks doing my "blind taste test" ... were it NOT for this legal situation, I'd be offering a patch for PG 3.15 and everybody'd be on their merry way. So I'm stuck with treating it as a "black box" ... what can I tweak in MY code so as to not set off ProcessGuard ... the limitation is necessary, but irritating as Hades to me personally.

At this point, I *still* haven't figured out what's going on in ProcessGuard. ALL I can say is I found ONE thing and that's solved the quiescent issue as BOClean sits ... when BOClean goes ACTIVE on something however, the pigginess problem that ProcessGuard is creating will come front and center and that HUGE CPU use will come to bear and so far, there ain't a damned thing I can do about it since *I* didn't write ProcessGuard ...

So for NOW, the complaint that was brought up appears to be solved. I don't know though if I can do anything about the underlying problem when something starts up - I didn't write ProcessGuard and I still haven't figured out what's making it vomit in my pants. Still trying to figure it out, but legally, I'm hamstrung. If ProcessGuard were malware and I was free to treat it as such, I'd have it dissected in minutes at worst. No can do because there be lawyers and laws ...

But I'm *ON* it, and shutting off ProcessGuard proves what the issue is. I'm PRAYING to stumble on a solution that doesn't say "shut it down and use OURS." And I'm still on it until we can figure out WTF ...

I go get some sleep ... too long a night again.

 

Thank You Very Much Kevin. (2/3's of it is way over my head, but that is my problem not yours).

Fellow Creatures,
Very interesting stuff. O.K. In laymens terms what was meant by, "aren't y'all PROUD of reducing XP's security to lower than Win95?) which allows us to just BYPASS ProcessGuard as far as the spikes on recalibration go." Wow, pretty bad, if I am understanding it correctly.

A lot of rumors were put to rest and questions answered in Kevins posting.

I just saw one of the best reasons ever for allowing a Guest to post!

Finally, until the problem is fix (and I better find a thicket of trees to hide in here at the Forest before I say this) solution to the problem if it was me turn off ProcessGuard until the problem is fixed. Do away with it or what ever. Given a choice I would keep BoClean. Other security would have to a back seat given any conflicts that could not be resolved quickly. Now that we certainly know it is ProcessGuard that is in conflict with BoClean not XP in and of itself. What am I missing if anything?

 

Thanks Kevin

Like I said, I never reinstalled PG yet after my reformats.
I only noticed the CPU spike in that last build on opening and minimizing the GUI which was 100 %. And that has not even ever bothered me.
The tiny 10 sec spikes have always been there but they don't bother me.
it is against the law for anyone to reverse engineer PG. This is where I sure hope the DCS people with work with you not against you on this, competitors or not.
One thing I liked about regdefend is that Jason offered users for a tiny fee more to install his software on all home computers.
You have always allowed us to install on both our laptop and our desktop.
Which was old school and should stay that way by ALL software makers.
I bet these people here are getting tired of me saying that LOL
I WON"T.
I will be out of town for threek so I sure won't be able to reinstall Pg to do any testing. Hoping others will work with you and not just complain about things .

Bruce

 

First let me say that I most definitely love both companies, PSC and DCS.
I have bought programs from both companies, for myself and a few others.
It was never ever my intention, by starting this thread, to raise any kind of conflict between the two of you !!!
(and BTW as everybody knows: I run W98SE ...).

If I am allowed to make a wish:
Dear Kevin, Dear Wayne,
Please work together to try to solve this.
Just like Kevin posted: as far as I know you both has always been friends !
Please guys: stay friends and talk to each other behind the scenes.
I highly respect you both !

PEACE

Most warmest regards,
Jan.

 

mercurie,

Personally, I think that conclusion is premature. When you get right down to it, if one were to assign the direct cause to PG, I would think that it would be difficult to rationalize the behavior displayed in the screenshot that I provided above.

To test further, I decided to uninstall/remove PG from my system and reboot. After doing that, I obtained the screenshot shown below. While there may be a number of circumstantial bits of evidence implicating PG, I still believe that it might be a tad early to assign the direct cause of this issue to PG.

Is what I'm seeing at all as severe as the symptoms elicited on Howard's system? No, things seem to settle into a fairly steady 20-30% CPU spike if only ProcessExplorer is running. I don't suffer system issues at this time. But all systems are different. My minor issue may be morph into Howard's on his PC. Or maybe it is a different issue altogether. I simply don't know. But if you accept that what I am seeing is the same issue as Howard's, it would appear inconsistent with a PG-based cause. The fact that adjustments around PG seem to resolve the problem could be still another manifestation of unintended consequences. But if the expectation is that I should be seeing recalibration spikes in the single digits of CPU utilization, I simply don't observe that - even with PG pulled from the system.

Obviously, from what I see, I would encourage Kevin to think about what goes on after the BOClean menu is closed or what occurs during that "internally generated activity" (whatever that is) shown in the screenshot with the current post. Although the BOClean spikes are quite low after each event, they regrow rather quickly to the steady state values quoted above.

Blue

 

I am wondering this myself. The CPU usage goes very high for a couple of seconds after I close the BOClean menu. See Pic.


tECHNODROME

 

That high CPU usage (after opening/closing its menu) during a few seconds is completely normal for BOClean !
It simply is re-checking (or whatever you want to call it) the memory.
I see it too on my W98SE; absolutely nothing wrong with that !!!!!

Geez, I'm using BOClean for years and years (and so do I with TDS-3; perfectly working fine together if I wish to).

 

FanJ & Technodrome,

My comment wasn't directed at the magnitude of that spike per se. I assume that it is doing checking, garbage collection, etc.. Rather, the CPU spiking drops to nil right after that and this behavior persists for a while.

Whatever happened in that process seemed to have dealt with the spiking issue, albeit temporarily. Is this relevant? I have no clue, but one aspect of basic problem solving is performing challenge-response experiments. In this case, the challenge is the series of operations performed when either the GUI menu is open/closed or that periodic internal event occurs and the response is the disappearance of the large spikes. Something happened, I don't know what, but if I were looking for the cause of high CPU spiking, I'd be interested in things that seem to make it higher or lower. These are examples where is is made lower. Maybe PG is simply something that makes it higher. One could speculate (and this is pure speculation) that neither step resolves or causes the problem, but they both interact with the underlying issue.

Again, I'm speaking in gross terms here, about a black box, the inner workings of which I have no information.

Blue

 

Since I am new to BOClean I had no idea if this is normal behavior or not. I just thought it had something to do with this thread. Thanks for pointing this out Jan.


tECHNODROME

 

All,
About 3% CPU normal mode and it hit a high of 62% just briefly and ranged from about 32% to 52% upon closing the menu as FanJ was speaking to. I feel that has been pretty normal over the years. No ProcessGuard on my system. Just thought I would throw my numbers in for anyone who cared.

 

I have PG (user, pg, acc) in the BOClean program excluder.
I get spikes from 5% to 20% max (with everything open - mp3s, browser, IMs etc). It doesn't effect the performance on my machine.


--
2.6 p4
xp pro

 

Well it is quite simple. ProcessGuard provides hooking of certain kernel mode API that BOClean calls directly or indirectly. When your thread calls these API calls, it will eventually end up somewhere in ProcessGuard and then the kernel. So your thread actually runs part of the ProcessGuard code, it is the whole premise of "hooking" and should be simple enough to understand.

This doesn't actually make much sense to me, "doing zw calls to ntdll.dll in ring zero directly from ring 3"? I have no idea what this means.

I'm sure by now you have a fairly good understanding of why BOClean with PG is causing it to use a lot of CPU. You undoubtably call "ReadProcessMemory", etc, when reading the memory space of other processes. This is one of the (many) API which ProcessGuard protects against. If you call this function 1000's of times a second you WILL notice a difference with PG on the system. Why? Because PG uses some resources to protect the system.

The solution isn't that hard for you as the developer of BOClean, simply reduce your API reliance. I don't see why you cannot simply call "ReadProcessMemory" less times with bigger buffers, etc. You should be optimizing this stuff anyhow even for systems without ProcessGuard. If you want some ideas regarding this give me an email or IM.

Alternatively I am sure ProcessGuard could also be optimized a bit more, but in cases like this, you simply need to reduce your call amount with a better design to see the biggest difference, even on systems without protections like PG, which I'm sure all of your customers would appreciate.

 

With all due respect to everyone involved:

I still think that, if there is anything to solve with regard to this, it would be far better for all parties to do that in private...

Jan.

 

Well, all I know is this, whenever in the past there has been some kind of a, for want of a better word I'll say "conflict" between Kevin and DCS, Kevin has always been more willing to come forward and talk about it and try his darndest to get the "other side" to come forward and cooperate for eveyone's benefit. I don't know about y'all, but that says something to me.

Acadia

EDIT: FanJ, I was writing this as you posted yours, did not post this as a disagreement to your post.

 

Myself i love these kinds of disscusions. I always end up learning something. I am not sure how LONG I rememebr it though.

One thing I will point out is, if you are using Filemon to check things out you will find the CPU usage is three times more. At least I do. Anyone else seeing this?
You should see the CPU usage running ghostsurf and Filemon.

Bruce

 

All,
Discussion is good. But FanJ and Acadia your points were not lost with me. I understand it can and could be a difficult and tense situation, such a collabiration between to competitors.

 

i wish that kevin would see this thread.. yes, after you open the boclean menu from the boclean icon in the systray, and then check for an update, after boclean resets itself, the processor usage drops to "normal", but, it will gradually work itself back up.. PG does amplify the problem, but there is still a problem, regardless of PG..

i was intending to simply continue using BOC 4.11, except they quit updating it..

sometimes i see BOC running at 9% cpu, which might not be so bad, but other times i have seen it running at 22% and this is without processguard's being installed.. with processguard installed and running, i have seen BOC's processor usage at 30%..

 

I have pointed Kevin to this thread and he is testing a fix. In my own case I can verify that the proposed fix works for the examples I cited above and one other not contained in this thread that I had observed (which did not involve PG at all).

As you know, PSC takes pains to fully verify that the problem is solved, and no new problems are created with any program fix. This takes time with controlled and limited field-use testing. In my own case that's in progress and I've given Kevin a provisional thumbs-up already.

Be assured, PSC is on the job on this one.

Blue

 

All,
4.11 was starting to give me problems. 4.12 has run very smooth for me.
(I do not have PG)

https://www.wilderssecurity.com/showthread.php?t=49724

Blue,
Thanks for the work here. I had no dought that Kevin was at work on this. None.

 

mercurie,

My pleasure.

Yes, you can count on Kevin and all the folks at PSC to jump on user problems when they crop up, and they are relentless when it comes to getting the fix properly done.

Blue

 

I'm not so sure either, because on my system, as Blue noted in his post, even without PG the spikes were still there. It's good to know that Kevin is working on it.

I use FirstDefense also (and Kaspersky) and on the website there is also warning that there might be problems with FD/Kav, i have since oct/nov not experienced even one (except bootup takes longer than without FD, not a problem a for me) despite using it often when testing.