How to remove HKCU registry keys when uninstalling software?

Question

When my software is installed, via an MSI, it creates some registry keys within HKLM. When people are using the software their individual preferences are saved to HKCU. When the software is uninstalled the HKLM and HKCU registry keys are deleted, but I'm thinking that it's only the HKCU keys for the user who is running the uninstall that will be deleted. Is this correct? If so, how do I ensure the HKCU subkeys for other people who have used my software on the same machine are deleted?

UPDATE: The 'individual preferences' that are saved in my case aren't really settings that the user has chosen, but rather data that the application has stored while running for that user. So it's not really data that the user would want to keep. It seems right to delete it on uninstall since it won't have any use if the application is reinstalled. So I guess the best suggestion so far is Ed's: don't use the registry, although that's not really solving the original question.

Answer 1

It can't be done, only entries for the current user are removed.

You can use ActiveSetup to work around this, however it's pretty much undocumented aside from that link and unsupported by Microsoft. So if you do use it, don't rely on it ;)

The idea behind not removing user data during uninstall is a rather controversial topic with some rather interesting history... I remember old versions of Office used to save documents underneath the installation directory, the number complaints we used to receive when after an upgrade users would delete the old Office folder and lose their documents was enormous. More recently the complaint is people losing their custom Normal.dot template.

As someone involved with business software, my view is that if people rely on your software as part of their office workflow and take the time to customize settings, don't remove settings during uninstall.

From another point of view, if you uninstall a game that you've sunk hours/days/weeks into playing - would you want your savegames deleted? Your custom config files? What about a game on a shared family computer, someone uninstalls a game to free up disk space, unaware that another family member plays it regularly. Do you want to deal with those kind of complaints from your customers?

Answer 2

Short answer is you don't. The installer is suppposed to remove entries it creates and nothing else. If your app creates per-user settings at runtime, those are not owned by the installation routine.

If you really really really want to do this, you can create a custom action and force the uninstall to run as administrator so you can access all user hives. Be warned - this is completely nonstandard behavior and can it can take a significant amount of time & system resources to mount & unmount all of the user hives. And if your uninstaller isn't careful, you can damage things in the system-level hives and make your system unbootable.

As I mention in the comment to sascha's reply, Windows Installer Best Practices say (said?) to leave custom user settings on uninstall. That way if the user reinstalls your software, their settings are available.

Answer 3

If you really want to be able to eliminate user data, store the user data on the file system. Somewhere like "Documents and Settings\username\Application Data\Your Organization\Your Application". That data would be trivial to remove on uninstall, with an entry in the RemoveFile table.

The Windows Installer development team specifically addressed this on their blog. See "Rule 26". http://blogs.msdn.com/windows_installer_team/archive/2006/05/12/595950.aspx

Update:

Many years ago I wrote code that does what you describe with the registry, and quickly came to regret it. It was a pain, but more than that, it had an issue related to privileges. The short version is that the Installer service doesn't run with all the privileges that Admin has. They're not just disabled, they're absent from the security token of the process. Notably this includes the privilege needed to load and unload registry hives (se_restore_privilege as I recall). That caused the code to break for silent install and uninstall, even if the invoking user was Admin, and I couldn't just disallow silent install and uninstall.

Another issue that hasn't come up yet is Active Directory. I'm not certain, but I'm thinking that what you describe is going to have serious additional hoops to jump through in an AD environment.

In general, I try very hard to avoid having installs or uninstalls touch the HKCU hive. I've found doing that to be a consistent source of significant pain for minimal benefit.