adminfoo.net

UPDATE (2005/10/10): Mark Russinovich has a few things to say about registry cleaners. I've added a few comments at the end of the article in an attempt to interpret.

It's time for a little adminfoo debunking. I've noticed a bit more hype lately about various 'registry cleaner' utilities, and I have this to say about them: bunk!

First, a short explanation of what the registry is. If you remember the old days of Windows 3.1, you may recall the old *.ini files (unix people should be thinking of *.conf files). These were text files which held configuration data for a program - things like where program data might be found, or user preferences such as window size and placement, etc. As Windows evolved, the decision was made to centralize all of these *.ini files into one central repository. And so the registry was born. It is now several files, but essentially it is accessed like a single database. Registry keys hold values and data.

The basic registry cleaner parses the whole registry looking for keys which point to things (files or other registry entries) which are not there. Some cleaners claim to do more, "healing" broken entries (I would be especially wary of these!). Bottom line is, if you have an actual bad registry entry (as opposed to just an extra one), you already know it because something is throwing errors. But folks, it's been a long time since I've seen a system error which could be traced back to a bad registry entry.

Let's take a few registry cleaner vendor claims and examine them (claims in italic; response in normal text):

• 
  
• ...your registry gets stuffed with corrupt and orphaned entries. Many invalid records remain in the registry long after the corresponding applications were removed. This slows down your computer and can cause errors in other installed programs. A large registry is no slower than a small one, since Windows does not have to read the registry sequentially until it hits the right key and value. The registry is mapped, acting more like a database than a large file, so the program can go right to the key it needs and retreive a value. Notice how no registry cleaner product ever advertises actual measurements of speed gains? Finally, the difference between a 'large' registry and a 'small' one might be all of 20 mb (or 60 mb in really extreme cases). On today's computers that's a negligible amount of space.
  
• 
  
• ...and can cause errors in other installed programs. Programs keep registry entries within their own keys and rarely if ever reference keys written by other programs. Today's programming best practices include building an uninstall routine which removes these entries when the program is removed. While it's fair to say that many older programs don't do this, and even many modern programs don't do it as well as they should, it's also true that registry keys, values, and data left behind by uninstalled/abandoned programs are simply never referenced. They take up very little space on your system.
  
• 
  
• Advanced "Deep" registry clean. There are thousands of programs out there - many of which can write thousands of combinations of registry keys/values/data. Do the math and you quickly discover millions of possible combinations, few of which are publicly documented by the program's makers. The idea that some omnipotent registry cleaning tool is aware of what all these programs "should" have entered in the registry, and will properly remove or correct each individual entry, seems silly to me.
  
• 
  
• Problems with the Windows registry are a common cause of Windows crashes and error messages. Not in my experience, or the experience of any of the professionals I asked about this. Ask yourself: when was the last time you had a problem with Windows and you were sure that problem was traceable to a registry entry?
  
• 
  
• For example, a registry key pointing to a non-existing file is invalid and must be deleted. Statements like this appeal to the neat freak in all of us. But again, there's very little actual need to do this, since the entry will simply never be referenced, and the key or value takes up only a few bytes on your hard disk. It's like saying all unused files MUST be deleted from your system: sure they aren't doing anything anymore, but if they aren't hurting anything and you have gigabytes to spare, what's the point?

... there's a lot more in this vein. But really all registry cleaners make the same tired, unprovable claims over and over again. Bottom line: most users have no need for this class of utility, and should not be fiddling with the registry anyway. Make changes to software via the software's provided interface, and let the software and the system handle the registry! This is snake-oil, folks, and you shouldn't be buying it unless you've got money to burn.

Troubleshooting pros will occasionally make setting changes directly in the registry. But it's like taking the back off of your TV set: don't do it unless you know what you're doing. Even if you do know what you're doing, you should always back up the registry before making any changes. If you insist on using a registry cleaner placebo, you'd be very wise to backup your registry first.

In closing I will contradict myself just a bit. Some folks do have a legitimate need for registry cleaners. Typically these are programmers and QA staff developing new software. In their dev and test routines they may install and uninstall the same software hundreds of times, and each time they need to be sure to remove all artifacts of the prior install, including registry entries. In this case, a registry cleaner may be justified - though most of the folks I know will write a script which specifically strips out the registry entries used by the program they are testing.

That's my rant. I'd love to be proven wrong, so if you can find measurable evidence of a registry cleaner doing any real good in the world, hit the comment link!

UPDATE (2005/10/10): I read Mark Russinovich's recent comments on Registry Junk with great interest. As you may know, Mark is the leading light behind the supremely respected sysinternals.com, so he's like E.F. Hutton in my book. When he speaks, I listen!

When I first started reading his article, I thought: yay, Mark and I agree! But actually he presents a more nuanced picture, going deep into a special situation I hadn't considered before: uninstallers that leave bogus keys in HKEY_USER registry key/value sets. However I beleive the situation Mark describes is pretty rare (especially in on-the-job situations), and leads to actual problems a vanishingly small amount of the time. Mark ends up concluding that "Registry cleaners will continue to have a place in the anal-sysadmin’s tool chest". Hmm! I've been called anal before ... but even after taking Mark's comments to heart, I still conclude that Registry cleaners are uncalled for 98% of the time they are used. Your mileage may vary.

If adminfoo seems a little windows-centric, that's because, well, it is. It's not meant to be, but I don't have much choice in the matter, since I spend about half of my waking hours thinking about Windows. It's not a prejudice issue ... and to prove it (again!) I bring this note about backups on Linux.

One of the sexiest things about Netapp is those cool snapshot pseudo-backups. This article shows how to create a poor-man's functional snapshot on Linux, basically by the smart use of rsync, cp, and mv commands. It is well thought out, and finds an exciting strength in the *nix way of running a filesystem. As the author leads you through his excellent backup strategy for Linux, he also provides a thoughtful grounding on some Linux file management basics. An excellent return to first principles for gurus, and a wonderful and practical walk through for Linux newbs.

Highly recommended. (Oh, and if you'd like more *nix articles here, why not sign up and submit them?)

MS has released a 90-page Antivirus Defense-in-Depth Guide which is well worth a read. Although you'll already be familiar with many of the concepts outlined in the Guide, it brings everything together in a nice framework overview, and may well expose a few specific tips/tricks you hadn't been aware of. If nothing else, print out chapter 4 (Outbreak Control and Recovery) and keep it at your desk to use as a plan of attack when outbreaks do occur.

In related news, Jeffrey Lee Parson (pictured on the right) has pled guilty to releasing one strain of the MSBlast malware that was so troublesome last year, and will be sentenced in November.