Scareware? No thanks

Sometimes it feels like I am a lone singer in the darkness. It is always nice to know that I am really singing with the choir. I have been rattling on for quite a while about social engineering and greyware – that is to say software that is essentially useless and misleads the user into installing it. Some people use the phrase “potentially unwanted software” instead which is thought to be less legally actionable but I will never learn and will continue to say what I think.

Anyway, according to the dear old BBC, my former employer and Washington state are taking joint legal action against both Branch Software and Alpha Red, two companies owned by the extravagantly named James Reed McCreary IV. The most problematic of these “potentially unwanted softwares” was one called Registry Cleaner XP which is not the old programmers tool popular back in the late 90s but a rather different application that seems to be sold from this website - Please don’t install it unless you think that my opinion and that of my former colleagues is a nonsense. I do not recommend this software. The state of Washington suggests that the fine should be $2000 for each false warning made by this software. Since it is not unusual for this software to pop up over 200 warnings over the course of 24 hours and we are talking of thousands of systems, the fine c ould mount up rather quickly indeed.

Let us think for a moment though. What could a registry cleaner actually do? Well, we need to consider what the registry is – this is the XP version. If you are interested in what is different in Vista and Server 2008, please let me know. By the way, no trade secrets here. All of this information has been revealed in one form or another over the years.

The registry is a database of entries on a huge range of different things. Let us look at the sections.

HKEY_CLASSES_ROOT relates to COM objects and who would have thought that there were so many of them? File associations, Class IDs, interface IDs for COM components that can be remotely instantiated and such like are stored here. So, how could you have duff entries in here? For developers, it is pretty simple – developing new COM components all the time meant that there were a lot of dead entries in here unless the developer took good care to clean up the box. Visual Basic 6 was a bit of a devil for bloating this section of the registry. It allowed you to extend a COM interface which technically speaking you really shouldn’t be able to do and it fudged the mechanics by using interface forwarding which was completely undocumented last time that I looked. There were two results of this. The first was that you could change the interface of a COM component and the clients that expected the old interface would still work on that machine but probably not on a client system which is not actually that much use for a developer tool. The second was that you ended up with a great many registry entries pointing at other registry entries. The sensible thing to do was to break compatibility, get new GUIDs and compile the client and the server into a clean version but that left a lot of dead entries. There was a little utility written by a support tech that went through the class IDs and interface IDs and deleted the ones that didn’t point to a valid file. This stopped being useful with hosted components where the reference was not to a simple DLL or EXE but instructions to MTX.EXE or these days SVCHOST to instantiate the component. Running this tool would probably break a modern operating system pretty badly but it was the bee’s knees in 1998. So, that was the only registry cleaner that ever had a good excuse for existence in my opinion. Could you get dead entries on a normal end user XP box? Well, if they deleted an application that was a COM server or had a file association without uninstalling it, then yes, it would happen but to be honest, a handful of redundant references would have little effect on performance. The only time that I see broken references like this on a consumer system is where malicious browser helper objects have been whacked out by an antivirus product and it has been sloppy about the cleanup. So, no need for cleaning in this bit of the registry.

HKEY_CURRENT_USER is a phantasm. It just points to a specific user in HKEY_USERS. RegEdit is a habitual liar. Just because you can see it is no reason to think it exists and just because you can’t doesn’t mean that it doesn’t exist. So, no need for a registry cleaner there.

HKEY_LOCAL_MACHINE is the home of some interesting things. All the driver settings live here and the settings for a great many third party components and Windows settings. You could have dead entries in here if software was deleted without removing its settings but that wouldn’t have a great deal of effect on performance as there is not a linear search algorithm for these things. Dead entries just use a bit of space. It would be pretty dangerous to clean up entries without knowing what they represented and there wouldn’t be much point. Removing driver settings, security settings and so on would break things badly. No call for a registry cleaner there then. It isn’t that dirty.

HKEY_USERS has a branch for each user account and if you look there, you will see some well known SIDs (security IDs) and some less well known ones that probably represent real users. There will be user specific software settings. Actually, a lot of these settings will never be used for anything. I have a guest account on the system where I am writing this. It is disabled which is the best thing to do with a guest account. If I don’t know you well enough to give you an account of your own, you have no business running code on this box. Looking at the guest account, it has settings for the AV product installed, my Creative Zen, iTunes and all sorts of things that get installed for all users by default. Switching quickly to the admin account gives a last login date for the GUEST account of never. No-one has ever used those settings and they never will. My ASP.NET account doesn’t use those settings either. It exists solely to run ASP.NET code in a very limited environment. Now, something could usefully clean up some of those entries but no tool that I know does that. Oh well, it is just some memory bloat. The one place where it would be of some use, no registry cleaner reaches. Oh well.

HKEY_CURRENT_CONFIG is just another phantom pointing at specific entries in HKEY_CURRENT_USER.

If you want to keep your system nice and spry, here is my advice:
1. Add memory. These days, if you are not hard against your address space limits then you are running on 64 bit.
2. Do not load things that you do not need. Autoruns from Sysinternals as was is a fine tool for seeing how much junk loads each time that you start up. It is amazing what you can remove without ever missing it.
3. Defrag your hard drive once in a while.
4. Stay malware free.

That is what I do and this machine is used every day and still runs pretty darn sweet. The OS was installed in 2004. Remember when the OS had to be reinstalled every few months? No need for that and, in my opinion, no need for registry cleaner tools.

Signing off,

Mark Long, Digital Looking Glass Ltd