We just upgraded our install to use InstallShield 2008, and just rebuilt.
When our application gets installed on Vista, everything that the installer writes to HKEY_CLASSES_ROOT (which is mostly a LOT of COM dll registration) appears to be completely locked down in the registry. As an administrator on the machine, I can see all the keys, but when I click on one and it tries to get values, I get an Access Denied error. All previously existing keys in the registry are fine. HKEY_LOCAL_MACHINE is also fine.
In fact, as an administrator, I cannot even change the permissions on the keys that it installed.
When our install was on a previous version of installshield, this never occurred.
well, after more research, I have discovered that something removed ALL permissions from HKEY_CLASSES_ROOT (but not from sub keys) on my machine that i'm testing with. Now the bigger question - what removed the permissions?
I'll continue testing and see if I can find out what did it.
I hope you aren't using the LockPermissions table! 🙂
Windows Installer's permissions pattern is so badly broken I don't know where to start. The two main problems is let's say some object ( directory or registry key ) as a bunch of permission assigments and you want to make a change. MSI will replace all of the assignments with your new assignment and not preserve any of the originals.
To make it worse, it doesn't understand permission propogation ( inheritance ).
I once received a CD from a software vendor that was labeled 7.5A with insturctions "DESTROY THE 7.5 MEDIA".
Why? Because they put LockPermissions on HKEY_CLASSES_ROOT and it destroyed the system so badly that you had to be very smart in the registry to restore the state or otherwise just reimage the machine.
thats good to know. fortunately, we are not using the LockPermissions table. There is one row in it, and it looks like its coming from a merge module, but it is referencing a folder.
