I'm trying to decide wether to dig up one of my old registry cleaner rants or make a new one.
basically programs mucking about in the registry is a bad idea- they try to mechanically understand what is stored there and determine wether they should delete it. The only section in the registry where that is possible is HKEY_CLASSES_ROOT, which stores registration information about OLE and ActiveX Objects- sometimes programs can be deleted/uninstalled and leave their registration info. Basically if the file doesn't exist the key can be deleted. (CCleaner's registry cleaner portion does this)
the other keys- the ones used by programs to store data - could be anything. A prime example is a registry value that specifies, say, a filename. Most registry cleaners simply look to see if the file exists and delete the key if it doesn't exist- but what they fail to understand is that might not be the purpose of the key- it might specify a file to create, for example.
In either case, a registry cleaners will never result in anything but miniscule gains in performance; and oftentimes can result in missing functionality or broken programs- sometimes issues so great that only a reinstall of windows can assure the issue is resolved.
If you've used it your probably safe- it's constant usage (say, once a day) of the registry cleaners that make them prone to mistakes. That's not to say you should even use them in moderation, they are notorious troublemakers.
on top of the occasional disk cleanup and defragmenter, a chkdsk once every month or so can't hurt, either. (in fact, it's best to run a chkdsk before you defragment anyway.
Another one...
this has been discussed to DEATH in the forum.
the reason they are useless is there is no way to differentiate "bad data" from good data within the registry, which is why a lot of runs of these so called "Cleaners" their internal hueristics might decide that certain data values are invalid- for example, many flag filenames in the registry that don't exist. What if the path points to a disconnected network drive? The cleaner will flag it and delete it, and the next time the app is run it will perform unexpectedly, possibly crashing.
Additionally although verifying the existence of COM server DLL,OCX, and EXE file is a simple directory lookup some configurations might have some of the registered com components on removable drive. run the cleaner while it's unplugged and it will delete the otherwise perfectly valid entries.
This situation compounds when it tries to verify component categories and CLSID's between the versions of the same component.
It boils down to this- Registry cleaners, regardless of the amount of hueristic data can not foresee how, or what applications store in the registry and thus it is a fools errand to try to define some standard.
This isn't even factoring in the use of the term "corrupt". If a registry is corrupted- windows won't boot. you cannot have a few "corrupted entries" unless specific applications purposely wrote those values to the registry. I've found most "corruption" as flagged by these so called registry cleaners is a REG_BINARY type that an application uses. Of course the proposed fix is the delete the entry, rendering that application unusable.
I've said it once and I'll say it again- the fact that registry cleaners even have a market is simply because of the instilled preconception by users that it holds anything more then mere data. It's a data repository, and nothing more; basically a giant conglomeration of Heirarchal INI files, really.
Why was there never a "INI file cleaner"? the same reason there shouldn't be one now- there is no way to objectively decide wether a foreign program's data is valid or not- but there wasn't- for the sole reason that people understood INI files, Now, there is a cloud of confusion over the registry. I've heard people refer to it as the "brain" of windows, which is like calling a acountants paper his brain- completely false. The reason registry cleaner's exist at all is because people think they are useful, when in fact the only purpose they serve is a placebo to the user who actually believes there is a such thing as a "registry issue". There isn't.
The only reason the registry even exists is thanks to OLE and COM, which used the windows 3.1 registry to save OLE registration information. Later versions removed the registry size limit (to some degree) and improved the node/key heirarchy. The registry's main purpose is to store COM/OLE registration, File association, and other system specific information, and as I said, no program can pass judgement on what another program considers to be valid. So what if a string looks like a filename? Without knowing how the application loading that string uses it the cleaner program has no business flagging it as "corrupt" or "file missing" or anything of the sort.
ONE change- a registry cleaner has only one, very specific use case- the removal of orphaned CLSID entries during the development of a COM component. Now I'm going to go out on a limb and say the average user really doesn't develop COM components. However- this use is PURELY cosmetic- a larger registry instills absolutely no time penalty of any sort, and the symptoms that people often diagnose as a "corrupt registry" or "registry issues" are 100% caused by malware. Warranted, the malware installs itself via registry keys in the Winlogon notify, RUN, and various plugin keys for the shell, but that doesn't make the entries invalid anyway- they are perfectly legal, which is why a spyware app is required to properly remove the entries, since it can flag the DLL's in question as malicious and thusly knows via it's database exactly how to go about removing it.
And an entire thread about it here:
http://www.computerhope.com/forum/index.php/topic,77609.0.htmlAnd another one:
the registry is composed of two files. SYSTEM.DAT and NTUSER.DAT, (with others loaded if "switch users" functionality is enabled)
each Hive is stored in a separate file- there are really only two hives, HKEY_USERS and HKEY_LOCAL_MACHINE. (HKEY_CLASSES_ROOT is just a reference to keys elsewhere in the registry, be them in the system or user hives).
HKEY_CURRENT_USER, of course, is just another alias to the HKEY_USERS key that holds the current users registry data.
registry cleaners work by deleted what they deem to be unused registry entries. the problem lies in determining just what an "unused entry" or obsolete entry is. most will scan the HKEY_CLASSES_ROOT alias for references to COM objects whose executables no longer exist, and delete those entries.
the same steps are taken with other entries; (non-existent files, executables, etc).
each entry is not a file or folder, of course- there are registry keys and registry values. registry keys can hold any number of other keys and values as well as a default value (which shows up in the values pane).
As an example- take ProgID lookup for object names such as "Word.Application".
First, the Com Loader needs to get the CLSID of the concrete class to instantiate. to do so, it searches for Word.Application as a key under HKEY_CLASSES_ROOT (which we've already established as an alias to elsewhere in the registry). finding this, it retrieves the CLSID, and performs a similar lookup, and looks inside and sees the InProcServer32 (or other COM key) and finds the path to the DLL/EXE, which it subsequently loads and uses.
If anything along this line is messed up due to some heuristical bug in the registry cleaner- for example, if it references a DLL file name that it deems "invalid" because it doesn't end with EXE,OCX, or DLL... then the entire Component will not load. Word would still start, and re-add the appropriate entries; but any attempt to automate word via OLE would fail miserably.
There is however the additional question of the HKEY_CLASSES_ROOT key, where values CAN be determined to be invalid. the HKEY_CLASSES_ROOT key stores, as well as information about file extensions, information about registered COM components. Since each CLSID entry has a InprocServer32 or a similar key (I cannot remember the name for the out of process server exe) the validity can be determined simply by checking if the file exists.
or can it? What if the file is on a removable drive that is not plugged in or a network drive that is not mapped? Basically, the value is valid when it's used, but not at the time of running the program. So what happens? you plug in your flash drive and try to run one of the programs on it, and you get an error- and unless you know exactly what the registry cleaner program has removed and how do use the command line tool regsvr32 you'll likely need to reinstall.
And that's just MY posts... the topics I grabbed those from have a lot of other relevant posts in them too.
