Answer to fixing MSI uninstall failure causing error 2908 and "UNKNOWN\Components" oprhaned registry keys

Question

The question with failed MSI package uninstalls causing further installation attemts return error 2908 in the MSI logs (msiexec returns 1603) have come up in very many different forums so I just wanted to give my solution to this since we have had it appearing now and then over the years and I have never seen a programmatic solution to it.

The general cause is that the MSI uninstaller creates "orphaned keys" in the registry in the LOCALMACHINE hive under SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components

The typical MSIEXEC log errors looks like this:

MSI (s) (2C:0C) [14:52:21:490]: Note: 1: 1401 2: UNKNOWN\Components\B44598ECC622C01BD780AEC8E234E3E1 3: 5 DEBUG: Error 2908: Could not register component {CE89544B-226C-B10C-7D08-EA8C2E433E1E}. MSI (s) (2C:0C) [14:52:21:523]: Product: Some software 3.7 -- The installer has encountered an unexpected error installing this package. This may indicate a problem with this package. The error code is 2908. The arguments are: {CE89544B-226C-B10C-7D08-EA8C2E433E1E}, ,

As other posts have pointed out you can locate the keys from the MSI log file and edit them with Regedit, do "properties" and "advanced", change their owner from "unable to display current owner" (or similar text) to "Administrators" and finally set the access rights on it, like instructed in this link:

https://kb.acronis.com/content/33458

However, this is cumbersome, you can get hundreds of broken items. Worse, the above manual procedure seems to have issues in Windows 10 and there is no more "Windows Fixit" tool available.

So how to fix this automatically? These "broken" registry keys are hard to change even as an elevated admin resulting in various errors, thus to be sure of success I run it as a service in a SYSTEM account.

I thus created a windows service project in visual studio running as SYSTEM (SID S-1-5-18), then we open the parent key of the offending entries:

RegistryKey hklm = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine, RegistryView.Registry64); RegistryKey regParent = hklm.OpenSubKey( "SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components", RegistryKeyPermissionCheck.ReadWriteSubTree, RegistryRights.FullControl);

I answered my own question I had a few days ago but never wrote here So I thought to write a informative text on the answer I came up with here since lots of people have questions on this one. — Nihopteh
– Nihopteh, Commented Oct 21, 2016 at 13:29

Floern · Accepted Answer · 2017-03-07 16:58:20Z

The corrupt keys can be detected by a securityexception when opening each subkey with

regKey = regParent.OpenSubKey( registryKeyName, RegistryKeyPermissionCheck.Default, RegistryRights.TakeOwnership | RegistryRights.ReadPermissions | RegistryRights.ReadKey))

For me msiexec seems to have added an "Admin user" for the broken keys in question and what is worse, the rule inheritance has completely stopped working for some reason, I think it is this this the reason regedit cannot show the key's owner, which IS actually still SYSTEM, so the keys are not really orphaned in the first place. It does not help removing the RegistryAccessRule for this strange Admin user entry either. The solution is to reapply rules for the users at the regParent since this seem to update and "heal" all child nodes aswell.

It is thus sufficient to do the following:

 security = regParent.GetAccessControl(AccessControlSections.All); security.AddAccessRule(new RegistryAccessRule( new SecurityIdentifier(WellKnownSidType.LocalSystemSid, null), RegistryRights.FullControl, InheritanceFlags.ContainerInherit | InheritanceFlags.ObjectInherit, PropagationFlags.None, // Self+Children AccessControlType.Allow)); security.AddAccessRule(new RegistryAccessRule( new SecurityIdentifier(WellKnownSidType.BuiltinAdministratorsSid, null), RegistryRights.FullControl, InheritanceFlags.ContainerInherit | InheritanceFlags.ObjectInherit, PropagationFlags.None, // Self+Children AccessControlType.Allow)); security.AddAccessRule(new RegistryAccessRule( new SecurityIdentifier(WellKnownSidType.BuiltinUsersSid, null), RegistryRights.ReadPermissions | RegistryRights.ReadKey | RegistryRights.EnumerateSubKeys | RegistryRights.QueryValues, InheritanceFlags.ContainerInherit | InheritanceFlags.ObjectInherit, PropagationFlags.None, // Self+Children AccessControlType.Allow)); regParent.SetAccessControl(security);

This should be enough to make Regedit work and Msiexec change its keys again. You can now repair/remove your broken uninstallation.

In addition I created a simple wrapper application that installs and start the service in the SYSTEM account then uninstall it once it stopped at end of its cleanup process.

Hope this helps someone out there with the same issues as we had here!

Collectives™ on Stack Overflow

Answer to fixing MSI uninstall failure causing error 2908 and "UNKNOWN\Components" oprhaned registry keys

1 Answer 1

Comments

Hot Network Questions

Collectives™ on Stack Overflow

1 Answer 1

Comments

Related