MJ Registry Watcher

The increase in CPU usage is due to the registry hooking. As soon as any change happens to the registry, a fast sweep is done to ascertain if what changed affects any of our protected keys. This results in CPU spikes whenever a registry change occurs. Have you got something changing the registry all the while (or periodically)?

On my office PC, simply launching or closing any app changes the registry so that MJRW has to do a fast sweep.

However, on that PC (a Pentium IV running at 2.8GHz), MJRW uses about 1 minute CPU per hour of up time.

 

Perfect got even better. Thanks!

 

So basically you mean the change for unprotected part of registry will also trigger a fast sweep, right?

I think I found the the cause of high cpu spike---google web accelerator. By enable/disable it, I could see the big difference from regwatcher's status bar and process explorer. But I still have to use it for the next few weeks . Because of optical fiber broken near Taiwan, the internet connection between north america and east asia like crawl. GWC helps to accelerate the web surfing.

Anyway, thanks for your help.

shek

 

I Just confirmed google web accelerator is the source of cpu spike with regmon. Every few seconds, it has create key and set value requests, assuming open/close key, query/enumerate value wouldn't trigger the fast sweep.

Shek

 

That's right. MJRW registry hook system only triggers on the following events :-

1) Notify the caller if a subkey is added or deleted.
2) Notify the caller of changes to a value of the key. This can include adding or deleting a value, or changing an existing value.

MJRW does not trigger on the following :-

1) Notify the caller of changes to the attributes of the key, such as the security descriptor information.

I am doing some research on a code-optimised version (where I have let the C++ compiler optimise the resultant .exe file). It may achieve a 50% reduction in CPU use, but I have only tested it for an hour so far! I really don't expect it to make any difference. I'll keep you posted.

 

First off, it's important to understand I'm not trying to criticize but to flesh out a couple of things for me in my setups...

First, 1.2.4.9 runs without any crashes, memory leaks, etc. in the 2 PCs I've tried it in. But after reading Shek's CPU utilization concerns, I took a little deeper look at my newer XP laptop at home. The reason I chose to look at this PC is because it seems the level of CPU activity and the running time of the cooling fan are very closely related. When running MJ RegWatcher 1.2.4.7, the fan rarely came on. But when running 1.2.4.9, it now runs more than half the time.

In addition to this simple observation, I also used ProcessExplorer from Sysinternals and looked graphically at the CPU usage. I also attempted to estimate my average CPU utilization using the percentage listed at the bottom of Windows Taskmanager. In both cases, 1.2.4.9 shows up as a bigger load.

With 1.2.4.7 and ProcessExplorer, the CPU graph is fairly flat. With 1.2.4.9, I have noticeable ups and downs on a regular basis. As for the CPU estimates, when running 1.2.4.7 in the background, the PC averaged around 2% or so. With 1.2.4.9, the average grew to approx. 7%-9% or so (this was harder to gauge than with 1.2.4.7.) Enough of an increase to trigger the fan a good deal more.

Seeing these results got me to thinking that even though I've ran RegWatcher for a while, I still have a poor understanding of how to adjust the sweep parameters (throttle timing, number of lines per throttle.) I keep thinking that if I understood this section better, I might be able to help my CPU load myself. I've looked at the help for some ideas on the sweep parameters but specifics on what each item does is not listed (or I totally missed it... which wouldn't be the first time!)

Another item I have noticed is the sweep count itself for 1.2.4.9. Mine has grown dramatically from 1.2.4.7. Is this what I should expect to see?

I'm not home until late tonight so I may not be able to post more specifics but I will do so when I get the chance.

I would appreciate any thoughts...

 

Han, it sounds like something is changing your registry periodically, causing MJRW to do instant sweeps all the while (causing the increase in CPU and sweep count). On my laptop and on two other desktops, nothing constantly changes the registry, so I do not have this problem. Perhaps I should make the registry hooking optional, so that users with apps running that keep changing the registry, can turn it off. Can you identify the process causing the changes? TIA,

 

That would be great! Maybe default it to having the hooking enabled and if it causes any issues, the user could then disable it.

I'll work on it. FWIW, I run things pretty lean. Typically, both at home and at work, I'm at 30 processes or less...

(This is a random screenie.)

 

HAN:

you could use regmon to identify which process keeps on changing the registry.

shek

 

From Han's list, it is probably zlclient (ZoneLabs ZoneAlarm firewall), which, I know, locks its own registry key: perhaps it is also periodically updating it too.

If this is the case, I don't really want to tell people MJRW and ZA are incompatible. I will have to do another version which makes the hooking optional (but on by default).

I must admit, my security nowadays consists only of Windows SP2 Firewall, MJRW, and a monthly virus scan! That's pretty lean, but then again, I don't browse websites or try out software, the likes of which you lot out there try.

If anyone wants to slip anything else into MJRW before I release the next version with optional registry hooking, please let me know here. TIA,

 

While I haven't had the chance to really dig into this, I do think you are on to something regarding ZoneAlarm. While tinkering with Process Explorer, I noticed that the vsmon service from ZA was a fairly active component. So it may very well be the guilty party (Shek, thanks for the Regmon suggestion. That will likely be the best way to sort this out.) (FWIW, I would hate to give ZA up because overall, it has worked out for me very well.)

GE, thanks for looking into this!

 

To help those with CPU utilisation problems, I have done a new version.

MJ Registry Watcher version 1.2.5.1 is available at http://jacobsm.com/mjsoft.htm#rgwtchr and has the following changes :-

Changes 1.2.4.9 to 1.2.5.1
1) Provided a throttle for the fast loop on hooked registry triggers, which is 10 milliseconds by default, to ease CPU usage. It can be set to zero, which disables registry hooking, and continues to use pure polling.
2) Changed alert sound from karate cry to the sound of rhenium wire in a photoflash lamp as it flashes (rhenium vaporises at 10105 øF). The original karate sound is in orgalert.wav

The new throttle setting is on the Settings submenu. To go back to pure polling, set it to zero. The setting is stored in the config file as usual.

 

New version installed and running. First impression is that it is running with less CPU activity on the PC I mentioned above.

The new flash sound is welcome and kinda cool, but on my PCs, I'll probably keep the "chop". I can be distracted, doing something else and still hear it. I'm not sure I'd hear the quieter flash.

More thoughts to follow...

GE, thanks for your efforts!

 

GE---

the new version does reduce the cpu usage.

From what I understand, for regular polling, the smaller throttle time is, the faster sweep would be. If that's the case, then zero would mean non-stop. However, on the other hand, in current setup, zero for fast sweep throttle turns reg hooking off. So it might lead to some confusion because of the inconsistency, at least for me. Why not have an option to disable the fast sweep directly?

Regards,

shek

 

I have just uploaded a zip file containing some 30 different wav alert sounds - it's at http://www.jacobsm.com/rgwsndz.zip . My personal favourite is Alarm.wav - when this goes off multiple times (like in a Windows update) it sounds superb! It's just 661K in size : let me know your favourite! Regards,

 

I don't use sound, but Drumroll and Ticking are funny each in their own way. Ticking is my favourite.

 

I have updated the alarms archive at http://www.jacobsm.com/rgwsndz.zip - it now contains 33 sounds, the best of which, IMO, is klaxon. It really blasts you into action!

 

How many people out there would like me to change the prefix meanings to include all modes, not just prompt mode? This would allow you to always reject any changes to a key even when running in accept mode, for example. Or to always accept changes to a key even when running in prompt mode.

Currently, there is only one = or ! prefixed key in the custom set, and that is :-
=hkey_local_machine\software\microsoft\windows\currentversion\app management\arpcache
To have this reject changes when MJRW is running in reject mode may be inconvenient. The current system only allows the (normal) changes to this key in accept and prompt modes, but not reject mode.

Hence, I feel this would be an improvement. What do you think? Surely, prefixing a key should mean that is how the key is to be treated in all modes?

 

GE---

I like this new idea.

 

Graphic E,

Definitely.

Thanks....

 

Count me in too!

(BTW, tested out the latest bunch of sounds. oof is interesting... )

 

MJ Registry Watcher 1.2.5.2 has been released at http://www.jacobsm.com/mjsoft.htm#rgwtchr . It has the following changes :-

Changes 1.2.5.1 to 1.2.5.2
1) Made key prefixes apply for all modes, not just Prompt Mode.
2) Added prefix $ so that you can make keys automatically prompt for any changes, whatever mode MJRW is running in.
3) Made alert messages clearer as to why a change is accepted or rejected.
4) Changed alert sound to klaxon.
5) Made alert window display in top to bottom order, with the most recent at the bottom - it makes it easier to read.
6) Corrected a bug with prefixing keys. Now, the prefixing will briefly show MJRW, as it prefixes the key(s).
7) Now keys and filespecs can be double-prefixed, if the first prefix is &. This means that &$%system%.exe and &$%system%.dll can be used to check these every 50 sweeps but always prompt if there's a change, even when running in Accept mode.

 

You've been busy! Several changes.

Thanks!

 

Thank goodness I put a throttle into the fast sweep! I have just discovered that while Opera 9.10 is downloading a file, the registry is constantly being updated, causing MJRW to be constantly fast sweeping for the entirity of the download! Internet Explorer does not have this problem, and does not update the registry while downloading files.

I have also discovered that every time you receive or view a different email message in Outlook Express, the registry gets updated, forcing a fast sweep.

I have only scraped the surface of this "applications repeatedly (and seemingly unnecessarily) updating the registry" subject. Any others out there know of apps the make the registry update all the while?

 

Now I see why my cpu usage is so high. I'm a fan of opera and set the oe to check email every 2 minutes.

btw, as i said before, google web accelerator does keep on updating registry entry.