I've said this before- but it's been a while, but this is how I've always seen it and why there even is a market for registry cleaning in the first place.
The registry was originally designed to replace the INI files that were strewn about the disk like nobodies business in windows 3.x.
It stores the <exact> same information as would be stored in an INI file (excepting the HKEY_DYN_DATA and performance data keys, which are dynamically generated and don't even exist in the registry at all).
However- with windows 3.x- there was no such product as an "INI file cleaner" you could use file utilities to round up older INI files but you could never be sure that they weren't used by anything.
At the time it was a rite of passage to learn how to edit INI files- it was rather simple to do and posed very little danger. for example, a text editor I used with windows 3.1 - PFE (Programmers File Editor) stored it's settings in an INI file. You could open that file, and edit it as you please. however, you could be absolutely certain that no matter how much you munged up "PFE.INI" the only application that would be affected was PFE.
The idea to migrate to a central settings database was due to the fact that at the time, INI files were far less then convenient for the tasks of system standardization and group policies- if all the settings were stored in a central database, there would only be one place to look for the settings- you wouldn't have to actually retrace the steps of the application to find out which of the three INI files it was using in order to edit the right one. a common symptom was that people would be told via instructions to edit an INI file for an application in C:\windows, only to find that nothing changed, because there was an INI file in the applications directory as well.
In order to better organize the settings, they settled on a heirarchal arrangement of keys and values, placed into Hives (so named because one of the developers hated bees or something).
Truly, the registry already existed in windows 3.1; it was basically used for what is now stored in HKEY_CLASSES_ROOT; file associations and registered OLE components. for windows 95 they expanded it and made it a central feature of the operating system with it's own set of API functions as well as supporting multiple data types.
The unintended result was to make the registry a large, monolithic database holding a vast quantity of different information- you could edit a good number of the settings without ill effect, but editing others could make it necessary to reinstall windows 95 entirely.
Being that it was no longer simply text files you could open, the registry was somewhat of a mystery to people- and in fact it still is. Many people, even today, refer to the registry as "windows brain" which is a rather vulgar interpretation as well as an ill-thought out analogy- it's basically a collection of settings, used by any number of applications, that happens to be centralized in a single database. It was this sort of misundestanding of the registry and exactly what it was that was preyed upon by the eventual release of commercial "registry cleaner" products. to make matters worse these registry cleaners were and often still are a part of some sort of all-in-one solution including disk defragmentation, disk checking, disk cleanup, and so forth, making it seem like cleaning the registry is as important as those other operations.
The first registry cleaner ever made was made by microsoft- it was exclusively created for cleaning out obsolete and non-existent registered ActiveX components. and it worked fine. Perhaps it was the release of this particular tool and the gigantic furor it caused (which, in those days, meant about 20 people had heard about it) was what eventually made other companies realize that they would be entering a lucrative market by making a tool that does the exact same thing as "regclean" did but at a higher price point.
HKEY_CLASSES_ROOT is the only hive that should <EVER> be "checked" by any sort of registry cleaner. but many cleaners check other areas in the registry.
a prime example. some time ago I ran ccleaner. next time I went to work on my evaluation library, it refused to start. apparently, CCleaner decided that my applications key in hkey_current_user/software/ was obsolete, and deleted it.
What makes this even more silly is the fact that my program did nothing wrong- it's registry key and the data stored within just happened to fit some sort of pattern that CCleaner recognized and chose it for deletion. This was because it had a number of entries that would CCleaner decided were filenames (but were in fact Expressions) and then found that those files (which weren't filenames to begin with) didn't exist, therefore meaning that the program had been deleted from disk manually, so it decided that the entire key was a waste of space.
It wasn't just that it happened to my application and I spent a futile 4 hours looking for some sort of subtle bug in my code only to discover that it was a ccleaner registry clean I had run over a month earlier that caused it that aggravated me, but rather the fact that it couldn't possibly be an isolated incident. Other programs keep all sorts of data in the registry and no registry cleaner can make the assertion that "this value is a filename" or "this value is a file path" even with the best sort of analysis. Such pattern recognition can be made better but it can never be made perfect; just as an AV will occasionally pick up a false positive so too will the pattern recognition of a registry cleaner will misidentify a value,as it did for me. (note I'm speaking in terms of everything but HKEY_CLASSES_ROOT "cleaning" which is rather well-defined in terms of what each value is).
For me, I literally had to include extra code that took account of the otherwise impossible scenario where the registry key A contains data that implies that registry key B exists, but registry key B doesn't actually exist. Without running ccleaner, such an eventually would never happen, but since I cannot guarantee that all my applications will run on PCs that don't run the CCleaner registry component, I had to add a good page of code just to handle that set of eventualities.
Of course, there will be just as many incidents of "miracle cures" of a system as there will be catastrophic failures, but when then again- people have won millions and billions of dollars through playing the lottery, that doesn't mean everybody comes out a winner. And of course those slot machine tickets mock you on purpose, putting two lemons or two sevens for the first two scratch slots only to deliver you a plum or something for the third one. Why must they taunt us! what cruel and heartless *censored* conceived of such devious lottery ticket design?
there's a saying I just invented:
Some people have a problem, and they say "I know, I'll use a registry cleaner".
Now they have two problems.
