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

[FanJ]

Hi,

Although I myself (still being on W98SE :-[ ) cannot run PG, I would like to quote Kevin (BOClean) to inform users of both ProcessGuard and BOClean.

This quote comes from the BOClean-update-notice at 1-March-2005.
(FILEDATE: 03/01/05 - 10:09:55 (US EDT) (15:09:55 GMT/UTC)).

=== begin quote ===

NOTE: A discrepency in the number of "unique items" will be noticed - 28 obsolete entries of BOClean 4.11 and earlier legacy were removed prior to this update as BOClean 4.12 no longer requires these unnecessary entries which may result in conflicts with a program called "Process Guard" as a result of the unnecessary disk reads of INI files.

=== end quotes ===

As from my part, I posted this only for your info.

Cheers, Jan.

[nick s]

Hi FanJ,

Thanks for spotting that. The CPU usage spikes are down to ~3% and steady so far.

Nick

[FanJ]

You're welcome Nick ! :)

Actually, I saw your posting in Mercurie's thread here (http://www.wilderssecurity.com/showthread.php?t=68885) and instead of going off-topic there, I thought it better to post it here so all would be informed ;)

Most warmest regards, Jan.

[Howard]

Unfortunately, this does not fix the problem I am experiencing with BOClean and Process Guard, BOClean spiking at 50% CPU/ten seconds and rising. The current versions of these two programmes will not coexist/run on my machine without excessive CPU activity. The changes made to ini file reading in BOClean are not, as I understand it, a solution to the problem but are intended, until the problem can be examined in more detail and depth, to secure some alleviation which in my case they have not. It should be pointed out that the problem is grounded in the interaction of the current versions of BOClean and Process Guard and while the excessive CPU activity registers under BOClean, it is not necessarily the case that BOClean is the source of the problem. Whatever the cause, it is beyond my understanding and I currently have to disable BOClean from monitoring continuously or disable Process Guard - I do the former, but not happily.

[Infinity]

I surely can understand that Howard, that is bad news. the problem doesn't exist when you disable PG? or put pg in the exclude? or the whole folder from pg in the excluder?

Probably you did this, just a question though


Inf.

[Howard]

-{ Quote: "I surely can understand that Howard, that is bad news. the problem doesn't exist when you disable PG? or put pg in the exclude? or the whole folder from pg in the excluder?

Probably you did this, just a question though


Inf." }-

The only thing that seems to work reliably is disabling Process Guard :(
Kevin has been great and has embarrassed me with the amount of time he is spending trying to sort this out, especially as I was one of the small group of people who had serious problems with the initial release of 4.12. Now I am one of an even smaller group that has problems with BOClean and Process Guard. Terribly difficult having to choose between two great programmes both of which feel essential to me.

[Infinity]

true, I wished I could help you out...beyound my limits I must say.

Inf.

[Howard]

-{ Quote: "true, I wished I could help you out...beyound my limits I must say.

Inf." }-

Way beyond my limits too, but I appreciate your kind thoughts, it is what helps make these forums such a good place to learn.

[nick s]

-{ Quote: "Way beyond my limits too, but I appreciate your kind thoughts, it is what helps make these forums such a good place to learn." }-The fixes so far have not changed anything here either. For what it's worth, the CPU spikes on my systems top out and remain steady. Might not mean anything either, but on my P4 systems, the spikes top out at ~30% while on my Athlon 64 system the spikes top out at ~15%.

Nick

[Pilli]

Hi All, Not sure if this has been tried but ProcessGuard has three other files that may need excluding as they are protected and not in the PG folder
*\windows\sytem32\drivers\procguard.sys
*\windows\system32\pghash.dat
*\windows\system32\pguard.dat
Where * = drive letter and of course "Windows" may not be your windows folders so substitute your folder name,

HTH Pilli :)

[Howard]

-{ Quote: "The fixes so far have not changed anything here either. For what it's worth, the CPU spikes on my systems top out and remain steady. Might not mean anything either, but on my P4 systems, the spikes top out at ~30% while on my Athlon 64 system the spikes top out at ~15%.

Nick" }-

BOClean hits 50-70% on my P4 and, if I let it run long enough, will use up to one third of all CPU time - it really isn't usable with PG here.

[Jason_R0]

I suspect that BOClean may be calling an API function a few thousand times a second which ProcessGuard would be adding "time" to, by checking to see if its ok. The solution is either to optimize BOClean so that it doesn't call API calls unecessarily or to optimize ProcessGuard further.

[BlueZannetti]

-{ Quote: "I suspect that BOClean may be calling an API function a few thousand times a second which ProcessGuard would be adding "time" to, by checking to see if its ok. The solution is either to optimize BOClean so that it doesn't call API calls unecessarily or to optimize ProcessGuard further." }-
If that were the case, it is hard for me to understand the results in the image below. I'd assume that this would yield a static machine/configuration/active process dependent spiking.

For the image shown, I simply double clicked the tray icon to bring up the BOClean menu, and then immediately closed that menu. Obviously this doesn't just open and close the menu, a number of things get reset/checked, etc.. In the image shown, BOClean had been running all night on a freshly rebooted system. CPU utilization had been spiking to the ~30% level for BOClean and dropped to ~ 5% after the open/close operation.

The same basic result is obtained if you simply shutdown BOClean, restart it, monitor for a short time, then open/close the BOClean menu. In that case, the spike dropped from ~ 10.5% immediately after the restart to ~5% after the open/close operation. In all cases, as mentioned above, the CPU utilization will start to drift up as time passes. On one of my other home machines - same basic set-up but without PG running - the BOClean spike is ~5% or lower and constant.

Blue

[Don Pelotas]

I'm seeing the exact same thing as BlueZannetti, the spikes drops from 23% to 2% if i open/close the menu.

[Jason_R0]

Thanks for the graph Blue, definately seems like a problem with BOClean then, kind of weird in a way because it is like a "memory leak" for the CPU in a way. :)

[BlueZannetti]

I guess the other reasonably important thing to add is that I don't see any impact on performance, so I'm quite far away from even contemplating making a choice between PG and BOClean. I'm also assuming that what we see here is real, and that there is not some background artifact at work skewing the results.

I believe that users of both applications who are concerned about this should step back and base any decisions regarding actions to take on the current stability of there system (rock solid in my case) and subjective assessments of whether there is an observable system response impact (none in my case).

Blue

[BlueZannetti]

-{ Quote: "Thanks for the graph Blue, definately seems like a problem with BOClean then, kind of weird in a way because it is like a "memory leak" for the CPU in a way. :)" }-I considered an actual memory leak, but I don't see any direct evidence of a leak with the application. But I know what you mean, a memory leak in the sense that it would seem to be surveying RAM that should no longer be scanned - or something like that.

Blue

[FanJ]

On my W98SE machine (of course I cannot run PG there) the CPU usage by BOClean is very low, as I see it in TaskInfo.
Indeed when I open the BOClean menu (its icon goes red then) and close its menu again, then its usage rises for a little while very high during the time BOClean checks memory. After that it is normal again.
My machine: P 3, 600 mhz, 512 MB RAM.

Is there any other pattern to discover on the machines of those who see that high usage?
Like for example any other security program?
Like for example NOD32:
I myself have excluded the BOClean files/directory in NOD32-AMON.
As for the files: bocsec.exe , boc412.exe , BOC412.XVU
Those files and folders are there both in long file names and in short file names.
And NOD32KUI and NOD32KRN are excluded in BOClean.


PS: was the new BOClean freshly installed after uninstalling the previous one?
I don't know whether that makes a different.

Well, only wild guesses...

[nick s]

Disabling PG from the tray icon has the same effect. When I reenable PG, BOClean's spikes return to the previous level. In terms of system performance, there is no noticeable impact and I have never considered disabling either app.

Nick

[Jason_R0]

Hi Nick, what you and Blue are showing are 2 different performance problems. The one you show is how PG affects performance by controlling the flow of BOCleans API calls, this could possibly be improved in BOClean to use less api calls (not quite sure how it is designed but it most likely could be improved). What Blue is showing is a sign of another issue when BOClean has been left running for a long while and CPU usage increases out of control only with ProcessGuard on the system. Both things should be looked into I think.

[Howard]

Recent correspondence from Kevin on this matter suggests BOClean should not be using more than single figure CPU % when the machine is quiet. I am experiencing 50-70% when the machine is quiet and while opening and closing BOClean's menu has a quiescent effect on CPU activity, this is superficial and temporary on my machine, bringing a brief relief before excessive CPU activty is resumed. And yes, this was a clean install after unistalling 4.11

[nick s]

-{ Quote: "Hi Nick, what you and Blue are showing are 2 different performance problems. The one you show is how PG affects performance by controlling the flow of BOCleans API calls, this could possibly be improved in BOClean to use less api calls (not quite sure how it is designed but it most likely could be improved). What Blue is showing is a sign of another issue when BOClean has been left running for a long while and CPU usage increases out of control only with ProcessGuard on the system. Both things should be looked into I think." }-Thanks for the clarification :). I see the distinction now.

Nick

[Atomas31]

Hi,

I also have the same problem with Boclean taking up to 80% of my CPU at almost 10 seconds??? I have PG too...

Look at my screenshot of Boclean CPU usage???


Atomas31

[jon_fl]

Any remedies to the problem besides opening and closing BOCLEAN? Has anybody heard if BOCLEAN has addressed the issue?

[Howard]

-{ Quote: "Any remedies to the problem besides opening and closing BOCLEAN? Has anybody heard if BOCLEAN has addressed the issue?" }-

I am not aware of any remedy at present, other than not running BOClean or disabling PG. I have been corresponding with Kevin about this and he is fully aware of the problem, although only a handful have communicated it to him. Last I heard he was having difficulties reproducing the problem.

[no13]

Hia...
Off topic request: what utility are you showing in those screen shots??

[Infinity]

That would be Process Explorer, a very handy very informative task manager with a lot of tools and freebie :)

[Pilli]

Hi Infinity, I think no 13 was asking what screen capture program was being used :)

[BlueZannetti]

-{ Quote: "Hia...
Off topic request: what utility are you showing in those screen shots??" }-
In my case it was Process Explorer (http://www.sysinternals.com/ntw2k/freeware/procexp.shtml) for the window shown and SnagIt (http://www.techsmith.com/products/snagit/defaultb.asp) for the image and added text/arrows.

Blue

[Infinity]

ok, no prbs

:)

[Peter2150]

I just finally read this thead, as I don't use BoClean, but I noticed the same behavior with Webroot Spysweeper. If I turn on all Spysweeper's shields and have the gui minimized I get the same behavior of CPU spikes. IF the gui is open it they go away. I traced to their memory shield, which apparently sweeps ram for spyware. I assume it is doing it about every 30 seconds. When disable the memory shield they go away.

Given all the other stuff I have protecting my computer I just turned off that shield. I will periodically turn it on and let it check my machine, and then turn it back off.

Pete

[Mongol]

That Spysweeper memory shield is a notorious problem. I finally had to disable it because it caused brief hesitations in my Realplayer and would do the same with the DVD player when trying to watch movies, not to mention my screensaver. I believe Webroot is aware of it. Hope to see some program update smoothing it out in the future. :o

[controler]

If I remember correct, Kevin added the feature to tha last build of BoClean to do another memory scan every time you open and close the boClean menu and added the red color. Why wouldn't the CPU spike then?
I am not sure about this without going back and reading but if I remember correct Kevin also added a new kernel mode driver? Maybe not but if so, and PG uses one, I am sure there will be conflicts.

Bruce

[Atomas31]

Hi controller,

You are right, from what Kevin has wrote to me Boclean make "memory calls" into the kernel and it is also monitoring the registry wich could cause conflict with PG and NOD32 at least, that's what Kevin wrote me!!!

My question now is, if Boclean play at the kernel level and monitor the registry can that mean that Boclean should or might conflict with some other software like RegRun and RegDefend????

Atomas31

[BlueZannetti]

Atomas31/controler/Peter2150,

I guess I don't quite understand the time dependent nature of the trends. If it's a conflict, I'd expect seeing issues from the start, and not see a reset to "expected" levels, followed by a slow rise in the spike level.

On a quick test, shutting down the GUI of RegDefend didn't have an impact, and the "problem" doesn't seem a whole lot worse since I installed RegDefend, so that doesn't appear to be a contributing factor.

As you'd expect, since BOClean is a process memory scanner, those spikes scale with the process load in memory. It's as though the scan doesn't quite properly reflect the current state as processes are loaded in/unloaded from memory. Since a simple load/unload of the menu system (and with whatever resetting occurs when that happens) brings the spikes way down, it would seem that a temporary fix would be straightforward (do this "reset" operation on an infrequent but regular basis - like once an hour). Just a suggestion based on the system response I see, there may be pragmatic reasons this wouldn't fly.

Blue

[nick s]

-{ Quote: "...My question now is, if Boclean play at the kernel level and monitor the registry can that mean that Boclean should or might conflict with some other software like RegRun and RegDefend?" }-Hi Atomas31,

In the five years that I have used BOClean, I have never seen BOClean conflict with the registry monitors I have used with it (that includes Greyware Registry Rearguard, RegProt, RegRun and now RegDefend).

Nick

[no13]

Thx guys
I was asking about PE...
Did anyone see Iarsn TaskInfo?
~unfortunately, I have nothing sane or funny to add to this topic.~

[Howard]

Just to keep folk up to date, Kevin has very recently informed me that he will be sending me a custom built BOClean.exe to try out in the next couple of days 8) but that the problem is with ProcessGuard, that the ProcessGuard problem is affecting other software, some even more seriously than BOClean, and that the problem* is leading to a kernel memory leak of some sort and that it is this which is causing the rise in CPU. Most of this is completley beyond me, so please do not ask me for an extended analysis :)


*"calls to the system for a function called "GetShortPathName" (which merely asks the system for the actual kernel filename associated with a long filename path, it doesn't DO anything) is being handled improperly by ProcessGuard" :o

[controler]

I guess I am missing something here in this disscussion again , duh me?

"BOClean also performs a "recalibration" every ten seconds which examines registry and system components to ensure that nothing has changed since its last calibration cycle in order to prevent against injections into already running programs."

The only diff here is that in the old version, you could change the calibration
time but the recommended was 10 sec. Since I reformated both my desktop and laptop and do not have PG on my desktop and have not reinstalled PG on laptop yet. I do have BoClean on both.
Even without PG installed, BC will spike 100% for a few sec on closing the menu
and again every 10 sec. This is normal operation.
Are you saying with PG loaded, the 10 sec spikes don't go away but keep growing? Because of a Mem leak?

Bruce

[Peter2150]

I have a whole bunch of stuff running with Process Guard and don't have memory leak or creeping CPU usage issues. Even Spysweeper which is doing the same kind of thing doesn't. I turned of the memory shield of spysweeper as with my other protections I don't need something checking memory every 10 seconds. I guess the same thing would apply to an antitrojan.

[toadbee]

-{ Quote: "... I don't need something checking memory every 10 seconds.." }-

Why not uncheck - "Monitor system continuously" in BoCleans configuration ?

[Howard]

-{ Quote: "Even without PG installed, BC will spike 100% for a few sec on closing the menu and again every 10 sec. This is normal operation." }-

Normal operation as described by Kevin is BOClean using less than 10% CPU every ten seconds, not 50-70% CPU every ten seconds which is what I am experiencing.

[Howard]

-{ Quote: "Why not uncheck - "Monitor system continuously" in BoCleans configuration ?" }-

This has the effect of reducing BOClean to running solely at startup and any updating would then have to done manually. This is how I am currently running BOClean ...

[earth1]

My experience also seems to indicate a "plays well with others" issue for Boclean rather than PG. I'm curious to know which other programs have a bad reaction to PG. I would have expected to hear more on the PG forum if the problem was widespread.

My suggestion to Kevin would be release a v4.13 that can adjust the frequency of Boclean's memory scans (2-3 minutes is better than never). Then, take your time trying to address these issues in a new version that's going to get prolonged and thorough testing. The goal should be a scanner with minimal impact on performance even when the system is running at or near full capacity. I think that implies full configurability over Boclean's behaviors and its exclusions. Remember, no security app is an island. :)

[Howard]

-{ Quote: "My experience also seems to indicate a "plays well with others" issue for Boclean rather than PG. I'm curious to know which other programs have a bad reaction to PG. I would have expected to hear more on the PG forum if the problem was widespread." }-

I hear what you say, earth1, but I will leave it for Kevin to decide whether to make that sort of information public - I am definitely not cut out for the role of messenger, even if I have been flirting with the role recently. Certainly I have experienced no problems with ProcessGuard other than that of BOClean. FWIW, I am now running BOClean solely at startup and a-squared Guard real time - CPU is very quiet ;D

[earth1]

-{ Quote: "I hear what you say, earth1, but I will leave it for Kevin to decide whether to make that sort of information public - I am definitely not cut out for the role of messenger, even if I have been flirting with the role recently. Certainly I have experienced no problems with ProcessGuard other than that of BOClean. FWIW, I am now running BOClean solely at startup and a-squared Guard real time - CPU is very quiet ;D" }-Sorry, Howard, I wasn't trying to pump you for information -- merely wondering aloud with the hope of being indirectly helpful. I know (too well) the feeling of certainty that my program's problems must be coming from somewhere else. Most often, I eventually find a solution to my own problem.

I do appreciate the information from Kevin and continue to root for him and for Boclean's ongoing success. The suggestions were meant to be constructive and I hope they haven't come across otherwise.

[Jason_R0]

-{ Quote: "*"calls to the system for a function called "GetShortPathName" (which merely asks the system for the actual kernel filename associated with a long filename path, it doesn't DO anything) is being handled improperly by ProcessGuard" :o" }-

That actually doesn't make much sense and doesn't tie in to the memory leak idea expressed earlier. Did Kevin give any more description about the problem? Does he mean BOClean calling GetShortPathName is causing PG problems or PG calling that function causing problems?

ProcessGuard only calls that function once when you add a new protection item, and there is no way it could memory leak since all the buffers are static and not dynamic. So if it is in this context it doesn't make any sense.

If he is talking about BOClean calling that function.. then that is a different. I havn't traced that function to see where it goes exactly in kernel mode, but it seems unlikely that this could be the problem.

[Howard]

-{ Quote: "I do appreciate the information from Kevin and continue to root for him and for Boclean's ongoing success. The suggestions were meant to be constructive and I hope they haven't come across otherwise." }-

No problem at all earth1, I thought your post asked the sort of questions I hope I would have asked if the positions were reversed and if I was more knowledgeable than I am about these matters :)

[Howard]

-{ Quote: "If he is talking about BOClean calling that function.. then that is a different. I havn't traced that function to see where it goes exactly in kernel mode, but it seems unlikely that this could be the problem." }-

This, I believe, is what Kevin is referring to, but we are not simply at the edge of my understanding here, but have moved almost to another continent, so I would not dream of commenting on the likelihood or otherwise of the explanation. I shall remain a grateful but agnostic build tester for now :)

[Howard]

Turns out PG's response to GetShortPathName was not the problem. The current test of build of BOClean is running at 2-5% CPU 8) so we can assume Kevin has correctly identified the problem (something to do with PG not liking BOClean's kernel prodding/proprietary kernel fishing - don't ask me to explain, this is all I know). Yesss!!! ;D ;D

[BlueZannetti]

-{ Quote: "Turns out PG's response to GetShortPathName was not the problem. The current test of build of BOClean is running at 2-5% CPU 8) so we can assume Kevin has correctly identified the problem (something to do with PG not liking BOClean's kernel prodding/proprietary kernel fishing - don't ask me to explain, this is all I know). Yesss!!! ;D ;D" }-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

[Howard]

-{ Quote: "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 ;D

[BlueZannetti]

-{ Quote: "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 ;D" }-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 (http://www.wilderssecurity.com/showpost.php?p=119038&postcount=14)), 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

[K McAleavey]

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.

[mercurie]

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? :-\

[controler]

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

[FanJ]

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 ! :D
Please guys: stay friends and talk to each other behind the scenes.
I highly respect you both !

PEACE

Most warmest regards,
Jan.

[BlueZannetti]

-{ Quote: "...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? " }-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 (http://www.wilderssecurity.com/showpost.php?p=389694&postcount=13) 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

[Technodrome]

-{ Quote: "

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"
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

[FanJ]

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

[BlueZannetti]

-{ Quote: "That high CPU usage (after opening/closing its menu) during a few seconds is completely normal for BOClean !" }-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

[Technodrome]

-{ Quote: "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 !!!!!
" }-

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

[mercurie]

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. :)

[azumi21]

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

[Jason_R0]

-{ Quote: "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.
" }-

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.

-{ Quote: "
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.
" }-

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. :)

-{ Quote: "
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 ...


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." }-

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. :)

[FanJ]

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.

[Acadia]

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. 8)

Acadia

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

[controler]

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

[mercurie]

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. :-X :-\

[redwolfe_98]

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

[BlueZannetti]

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

[mercurie]

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

http://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.

[BlueZannetti]

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

http://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

[Peter2150]

I've followed this thread with interest, as I am interested in all security software. I haven't tested Boclean, as the pay, get refund basis is a nuisance, even when folks are as good as Kevin. What has interested me is the Boclean vs PG issue. For the markets sake I am glad Kevin is working on a fix as I have a hard time accepthing the problem is PG. I have tested almost all security stuff out there, and so far everything I've tested plays fine with PG. I also am a Raxco fan, and on their website is a warning there might be problems with offline defrags with Process Guard. I don't have any such problems. Given this I have had a hard time believing that with the Boclean v PG issue that PG is the culprit. As I said I am glad Kevin is working on this issue.

[Don Pelotas]

-{ Quote: "I've followed this thread with interest, as I am interested in all security software. I haven't tested Boclean, as the pay, get refund basis is a nuisance, even when folks are as good as Kevin. What has interested me is the Boclean vs PG issue. For the markets sake I am glad Kevin is working on a fix as I have a hard time accepthing the problem is PG. I have tested almost all security stuff out there, and so far everything I've tested plays fine with PG. I also am a Raxco fan, and on their website is a warning there might be problems with offline defrags with Process Guard. I don't have any such problems. Given this I have had a hard time believing that with the Boclean v PG issue that PG is the culprit. As I said I am glad Kevin is working on this issue." }-
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.

[BlueZannetti]

Posts continuing the discussion of KAV & FD have been split off to their own thread here (http://www.wilderssecurity.com/showthread.php?p=405353#post405353) for anyone wishing to pursue that topic.

Blue