Registry cleaners have always been popular, but I never paid much attention to them. I originally thought that there might be valid reasons for their existence, but over time I changed my mind. But recently I've come to recognize that even today they can help maintain registry hygiene.
It used to be common for developers to write their own application installation routines to avoid paying hundreds of dollars for commercial setup toolkits. Their focus in coding installers was the installation part of setup because coding uninstallers is in some sense an admission that the software you've developed might not be useful or robust enough to become a permanent fixture on end-user systems. As a result, software uninstalls were often incomplete, leaving behind registry and file system detritus. A few hundred kilobytes of unused keys and values causes no noticeable performance impact on system operation, but I figured it was natural for a registry cleaner to be an essential part of running a tight ship for the anal-retentive systems administrator.
Installer technology has come a long way and today there are dozens of reliable
freeware and low-cost installation toolkits available both for old-style and
Windows Installer Package (.msi)-based setup. I previously believed that meant
the end of registry scrap and any reason for the existence of registry cleaners.
However, one of the Regmon troubleshooting examples Dave Solomon and I present
in our Windows Internals seminars made me realize that it's common for even
best-of-breed uninstallers that have earned the Windows logo from Microsoft
to leave our registries littered with traces of applications deleted long ago.
The troubleshooting example that triggered my realization is one in which a user discovered that Microsoft Internet Explorer (IE) would hang on startup unless he'd used his ISP's dialer to establish an Internet connection before opening IE. The user captured a Regmon trace of the hang and found references to his previous ISP's dialer in the RAS Phonebook key under the HKEY_ CURRENT_USER area of the registry. After deleting the stale values, the new ISP's dialer began launching like it was supposed to when IE opened.
Some research on my part suggests that the user had manually configured a RAS
phonebook entry, and when he changed ISPs had forgotten to update the entry.
But the fact that the problematic key in the example was in the per-user part
of the registry got me thinking. If the user's old dialer had created the phonebook
entry automatically, then been uninstalled from a different account, the user
would've been left with a broken IE configuration. That's because uninstallers
typically delete their application's systemwide settings from the HKEY_LOCAL_MACHINE
part of the registry and any per-user settings of the user running the uninstaller
from HKEY_CURRENT_USER. But what happens to the per-user settings of the other
users that used the application? You guessed it: Registry junk gets created,
and perhaps also file system junk in the application's Application Data folder
in the \Documents and Settings directories of other users. An uninstall is
thorough only if the user performing it is the only one that used the software.
Uninstallers that want to be as meticulous as possible could use the LoadUserProfile
Windows API to load each profile stored on the system, as listed in HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows
NT\Current-Version\ProfileList, and look for their application settings in other
profiles. The problem with that approach is that registry permissions would
likely prevent a user from deleting keys in other users' profiles. Even if permissions
aren't an issue, domain users with roaming profiles carry application settings
with them to other computers, so profiles that need to be updated might not
be locally accessible.
So it appears that registry junk is a Windows fact of life and that registry
cleaners will continue to have a place in the meticulous system administrator's
tool chest, at least until we're all running Microsoft .NET applications that
store their per-user settings in XML files . . . and then, of course, we'll need
XML cleaners.
—Mark Russinovich
End of Article
Register
