Registry Junk: A Windows Fact of Life

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_MACHINESOFTWAREMicrosoftWindows NTCurrent-VersionProfileList, 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