Windows 7 is a “stable” (in the sense of “constant”, “long-term”) system which I like to use for various desktop-based workflows. If you know how to administer it, it is a reliable platform, with many professional features. Recently, however, certain MSI-based installations started to fail on my system. I am not sure how it happened, but I obviously reached an inconsistent state. For example, I was not able to remove, repair, or install the .NET framework 4.5. Also Windows update was affected and could not install .NET updates properly anymore. There are various “FixIt” tools available from Microsoft for addressing similar issues. However, neither Windows Install Clean Up (see Wikipedia entry) nor a specialized .NET install FixIt tool helped.

The first insight I had is that MSI installations actually leave proper log files behind, containing quite some detail. In %USERPROFILE%\AppData\Local\Temp\Microsoft .NET Framework 4.5.1 Setup_20140917_191645234.html I found that

MSI (D:\4113948000d14764646c\netfx_Full_GDR_x64.msi) Installation failed.
Msi Log: Microsoft .NET Framework 4.5.1 Setup_20140917_191645234-MSI_netfx_Full_GDR_x64.msi.txt

In said ....20140917_191645234-MSI_netfx_Full_GDR_x64.msi.txt I found an issue which looked problematic:

MSI (s) (4C:80) [19:19:19:653]: Product: Microsoft .NET Framework 4.5.1 -- Error 1402.
Could not open key:
UNKNOWN\Components\D30312665D61E0E44A85EEBAFAF27C86\BE4EBED704B66673BB53C5BB3C58AD73.
System error 5.
Verify that you have sufficient access to that key, or contact your support personnel.

I ran regedit.exe with administrator privileges and found that, indeed, said key existed, whereas the UNKNOWN in above’s error message really is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\. Said key indeed had weird permissions set — precisely none. It had no owner and absolutely no access control list (ACL) specifications. I figured that this is improper, and assumed that other keys below Components might be affected, by whichever cause.

Likewise, I tried to recursively change (or “normalize”) the permissions of all keys in Components. So, first of all, I added ownership to the group of Administrators to Components and selected Replace owner on subcontainers and objects. This is important as a first step, because without having defined the ownership, setting ACLs is impossible. I then added “full control” permissions for the Administrators group while selecting Replace all child object permissions with inheritable permissions from this object. In the first run, this actually errored by saying that not all children could be re-configured. The second attempt succeeded. It is annoying, but the number of repetitions required to normalize the permissions of the entire tree might actually depend on the depth of the hierarchy. In this Components directory, two runs were sufficient.

Again, I have no idea how that inconsistent state was reached, but this ACL normalization actually fixed the issue.

And before someone flames at Windows for reaching this inconsistent software installation state: one has to appreciate that one is in equally deep trouble once one manually tampers with package-related files in a Linux system without making the package manager aware of the changes. Such a situation might lead to daunting debugging sessions, often followed by the insight that a complete rewind is the best solution. What I want to say is that it is likely that I myself produced that erroneous state, without realizing.