Registry Cleaner Experiment: Synopsis | BASeCamp Programming Blog

The Registry Cleaner Experiment

Registry Cleaners are purported as curing all sorts of computer problems. People swear by them; people adamantly defend them when they are attacked. But what is the truth? In order to investigate, I have been mulling over a number of methods since I first came up with the idea for an official test for a while. It’s difficult to come with one that adequately answers the various refutations that are given in the defense of Registry Cleaners when they are shown to not perform as well as they claim.

I have decided on two Operating Systems, and several forms of testing methodologies, which I will cover over time. The first step is to decide what registry Cleaners to test. In order to determine this I chose Registry cleaners that I had seen recommended or defended against my allegations. The list of Registry Cleaning utilities I have compiled so far are:

CCleaner

CCleaner is an interesting middle-ground piece of software in these terms. I look forward to experimenting with this one particularly since I actually use it on occasion. However if my experiments determine it to not provide any added value over the windows built-in tool, I will dump it in a heartbeat. I will certainly be focussing on the “Registry” portion of the product in this series.

Easeus CleanGenius 2013

This tool is a Freeware tool who’s marketing page can be seen here. It makes a number of claims of improving system efficiency and performance. We shall see how well those claims stack up after experimentation.

IoBit Advanced System Care 6 Free Edition

This can be found here currently. There isn’t a whole lot to say about this that I haven’t covered already.

In addition to the above I did a quick google search to try to find some “top Registry Cleaners”. I ended up on this page. As I was copy-pasting the links to the listed products- I noticed that all links are in fact affiliate links, which means that if a visitor was to purchase the software, the referrer would “get a cut”. This rather calls into question the objectivity of the page rating the products, I would suppose. These are the products from that page that I will attempt to test:

At a fundamental level, I have a very strong opinion on “tune up” suites like this, and it is extremely negative. I’ve always felt that the Suites are often “all hat and no cattle” that is they work very hard to impress those with reasonable PC competence into thinking they are doing something, but it would take a dedicated individual to prove that they aren’t doing anything useful. The amount of “whizbang” and skinning and lack of accurate technical information on the product has always caused me to consider them something of Snake Oil. I hope to prove, with evidence and scientific, reproducible experiments using the software, that much of this software does not have any noticable positive effect and that due to various technical considerations, they can actually have negative consequences.

So far I’ve only been able to think up one particularly useful test, and that is by running the tools on as clean a system installation as possible. To that end, I will be using VMWare and it’s “snapshot” feature to take a snapshot of each OS immediately after initial installation, and then run the above tools and analyze their discoveries and the relevance and accuracy of the claims and implications of what it finds, as well as the results of removing those entries.

The Default Environment will thus be:

Windows XP SP3 With VMWare Tools installed
Windows 7 (x86) SP1 with VMWare Tools installed

If I can conceive of a reasonable test or way to “emulate” a well-used system in each case without actually well-using the Virtual Machine environments, I may update my results to reflect the second test as well.

Speaking more generally on the concept, one of the most common and typical claims by Registry Cleaner vendors as well as die-hard Registry Cleaner users alike is that it “It speeds up my PC”. I even have a friend who uses Registry Cleaners and even uses them in his own tech work. This has, to be honest, given me some pause. I tried to explain the issues but they stuck to their story about it improving things- though admitting that they had no evidence to support such a claim. (Then again, they are also a Young-Earth Creationist so maybe the whole “ignoring evidence” thing is second-nature?) unnecessary jabs aside, I think they may represent a case of Registry Cleaner Vendors managing to “game the system” by polluting the Tech sector with so many misconceptions about the Registry and Registry Cleaners and what they do that nobody really knows what to believe.

The claim that it makes systems faster often tries to steep itself in technical information about why, but that information never holds up to greater scrutiny. In most cases it seems to boil down to “it feels faster after I run it” but that is purely anecdotal and I’ve yet to see any hard, reproducible evidence of the same; those that have provided specific test cases and cited the result was a speed improvement, the experiment was not repeatable- in my own independent research and repeating of the experiment I found no quantifiable gains.

One of the things that clouds this particular claim is that every machine is going to be configured different and will have been used differently. What this means is that any anecdotal claim in favour of Registry Cleaner’s will be unfalsifiable, because you cannot create the same environment that they used.

We can, however, jump to a lower level. One of the claims is that it will speed up the PC, and the reason is that it will remove data from the registry. What this particular hypothesis fails to realize is that the Registry structures are not accessed linearly, but are an optimized tree structure. Deleting keys has pretty much no impact on accessing data in the registry. It will increase the speed of any tool that for whatever reason looks through the entire registry. So far, we have concluded that running a Registry Cleaner to delete keys and data can speed up registry cleaners. Not exactly the kind of goal we really need. No other common software enumerates and examines such a large section of the registry key-by key, value by value.

The greater issue with “speed” considerations is that the tenet relies on the idea of deleting and removing keys. Most registry Cleaners call these “issues”; others even go so far as to call them registry “Errors”. When I get around to writing the articles about the various other registry cleaners we wil see the differences. The problem is that there is no such thing, objectively, as a “registry issue” or “registry error”; that is, the only registry errors you can really have would be those that prevent your system from loading that registry hive to begin with. registry “Cleaners” however work with already working registry structures, so clearly there cannot be errors. What these registry cleaners label as “Errors” and “issues” are based on simple rules that can often do more harm than good. Most Registry data will belong to other applications and therefore only those Applications will truly know the appropriate data structures. A good example of this would be BASePArser, which actually stores some evaluator configuration data in the registry. Only I- or, more specifically, BASeParser, really knows the appropriate format and what those keys mean and represent, and what is valid or invalid. This is where Registry Cleaners do a faceplant in a cow pat.

Because- just what is a “Registry Issue”? What is a “Registry Error”? From the registry Cleaners I’ve tested, they don’t often agree and those that do agree don’t agree on everything. Some things that count as errors and issues include:

Empty Keys
This seems reasonable on the surface- if a key is empty, why not delete it? Well, because the key itself might not have any values, but it may itself be representative of some critical information. Imagine of a Application decides to use subkeys in a larger key to represent plugins. Each plugin key has the name of the component to load, and it can have optional subkeys and values that provide options. Many registry cleaners would find empty keys in that to be “issues”; but deleting those keys effectively destroys and removes those plugins from the software. This doesn’t help for many people who then blame the broken Application functionality on more registry errors, and keep running that registry cleaner, even though it was the original usage of said cleaner that caused the “corruption” in the first place. And that is really all we can call it- some other application is screwing around with what is essentially the internal persistence structures of another application, and making their own judgements and considerations about what is and is not valid. It’s like some sort of data storage Gestapo making sure every single application that stores data follows some arbitrary ruleset.

Empty keys also have 0 performance impact due to the way the registry works though a set of hashed key structures.
Invalid File Association
This comes with a few other names, but typically revolves around “issues” in HKEY_CLASSES_ROOT or other areas of the registry. Oftentimes the “issue” can claim teh file type or content type is not valid, or that it doesn’t refer to a valid key, or the application it refers to doesn’t exist. In some pre-experiment tests of the above registry cleaners I witnessed cases where the registry cleaner didn’t recognize environment variables and determined that a perfectly valid path was not valid, cases where it didn’t look very hard for other data (certain parts of the association data can “point” to other data keys, and while the Windows Shell knows how to use them, the Registry Cleaner decides they are invalid because it doesn’t follow along. The most typical result from cleaning these issues resulted in broken associations, broken associated icons, and broken DDE features where they are supported by applications. Basically, the Cleaner caused all the types of problems that the vendors insist are the type of thing caused by failing to perform regular “Registry Cleaning”. Resulting in devoted users simply running the Cleaner even more. A viscious spiral.
Missing COM Component
This comes in various other variants as well. Whatever the case the issue typically revolves around a CLSID or COM component and it’s registration information. For the typical user, they don’t know what COM is and they shouldn’t have to. The problem is that registry cleaners will scan all the COM component information and make judgements about what is and is not valid. This data is application specific- COM components are typically registered and unregistered with two functions exported by the component for registration and unregistration of a component, by adding and removing appropriate registry keys. A Registry Cleaner may decide that the DLL reference is invalid (in my case it was registered using an environment variable that pointed to a valid file but that the registry cleaner didn’t recognize and expand so it decided it was invalid).
Missing File
Some registry cleaners will scan other application’s registry data and make guesses about what they are. For example if a path looks like a file it will try to find the file on the local system and if it cannot find it for any reason, ti calls it missing and tags it as a problem to ‘fix’ by deleting the key. There are a number of problems with this approach; the first is that it doesn’t really know if the key or value is supposed to refer to a file anyway, it just thinks it “looks” like a file. It doesn’t even know what the application intends to do with that file path; it may indicate the path to a temporary file that the application deletes on startup and that will thus never exist. The App may be designed to not expect random applications by shady vendors to go deleting it’s keys so may not have th robust error handling for when their temp data key dissappears. So you clean it and the app stops working. And- again, it’s a bit of a coincidence that those types of issues are exactly what Registry Cleaner Vendors ascribe to “corrupted or dirty” registries. The other is that it may actually be a file reference that simply isn’t valid at that moment. For example it may be a file that exists on a network drive or other medium that has since been disconnected; there is no way to know if the application’s actual usage means that the file will not be a valid reference when the application is run again. It might even be that the applications creating and reading registry data runs on a remote drive itself, so by definition if it runs that drive will be present. If you run a registry cleaner in the meantime, it’s registry data will be randomly destroyed because of some random alleged “system tool”.

The only benefit from any such cleaning operation is going to be in used disk space from the registry- and even that isn’t really true because the registry Hive files don’t expand and contract perfectly to fit the data, but they only expand. “compacting” the registry is another activity that registry Cleaners perform, and what that does is shrink all registry files down to the size of the data they contain. That seems reasonable, until you realize that all it does is save you disk space and cause future data to be fragmented from the other parts of the registry hive. So if anything that will reduce performance in the long run for a short-term gain in a few hundred kilobytes of disk space. And then later you need to keep running the tool as your registry expands because it keeps getting fragmented. Not withstanding such a task could be performed by useful utilities like contig. It basically makes a bunch of claims on a flashy dialog or advertisement about how great the tool is and how it will make your PC go so much faster, pairing it up with some ridiculous set of “ratings” of system health based on the tool vendor’s own subjective ideas.

Have something to say about this post? Comment!