Uninstall does not remove registry entry - how to find the reason

Question

I have built a setup project (vdproj from Visual Studio 2010) for a product. When uninstalling on my test machine, it does not remove everything it should. Specifically, it doesn't delete some registry entries it created in the installation.

A similar project DOES the cleanup; I compared the projects and found no error, so I assume that windows installer believes to have a good reason for this. I need to make him forget the reason, so that I get a clean test base for my product without reinstalling windows.

So I tried a manual cleanup: - uninstall -> registry entries are not deleted - regedit -> cleanup manually - install -> registry entries are created by my MSI - uninstall -> registry entries still not deleted.

I think there is a (probably obsolete) reference somewhere in the installer database that says: the component that contains these entries is still used by this feature, so you cannot delete them. Perhaps I have duplicate component keys, because I copied a setup project, so that I get this confusion.

I think I might be able to find the component and feature ID to which my registry keys belong, but how can I fix this in the installer database? Where Do I have to look? Are there any tools that could help me? It's Windows 7 Ultimate.

PhilDW · Answer 1 · 2016-10-18T21:00:29.950

Mixed up component ids could cause that, yes. You can run a vbscript like this to identify all the component ids and their product owners, make it a vbs file. The other reason might be that you once marked it permanent. That is a system setting on the object, not just a project setting at build time, so if it was ever installed with permanent true it will remain installed.

When this writes the guids and owners and paths to a file, if it's a registry path it will start with 2 digits to denote a registry location.

Option Explicit
Public installer, fullmsg, comp, a, prod, fso, pname, ploc, pid, psorce

Set fso = CreateObject("Scripting.FileSystemObject")
Set a = fso.CreateTextFile("comps.txt", True)

' Connect to Windows Installer object
Set installer = CreateObject("WindowsInstaller.Installer")

a.writeline ("MSI Components")

on error resume next

For Each comp In installer.components

   a.writeline (comp & " is used by the product:")

   for each prod in Installer.ComponentClients (comp) 

      pid = installer.componentpath (prod, comp) 

      pname = installer.productinfo (prod, "InstalledProductName")

      a.Writeline ("     " & pname & " " & prod & "and is installed at " & pid)

   Next

Next

score 0 · Answer 2 · edited May 23 '17 at 10:27

Phil has already provided a really good answer with the debugging info required. Just want to add that I tend to just give the problematic component a new GUID and then try it again.

You should only do this if the setup in question has not gone live yet and exist only on your test computers.

(If this works it is because the new GUID thinks it "owns" the registry key, and removes it on uninstall. GUID changes such as these cause missing files and settings after upgrades - and changing the GUID in this case is just a hack you can use if the setup isn't used by anyone but you yet - otherwise it should never be done).

Here is another answer describing the issue of component GUIDs. When they should be changed, why and what the consequence will be: Change my component GUID in wix?

Uninstall does not remove registry entry - how to find the reason

2 Answers2