Categories
Microsoft Windows Installer, Application Compatibility and Deployments

Problems with Orphaned Registry Keys in Visual Studio 2010 Installation

I was talking to one of my friend Ninaada, who was facing a strange issue while installing Visual Studio 2010. It sounded a little wierd for me, as he said that, most of the applications in the Visual Studio Suite did not respond after the upgrade. Do have a look at this and let us know your suggestions in the comment box!

He explains,

“Visual Studio 2010 has been released recently and I downloaded the iso image of the Ultimate edition DVD from my MSDN account. Eager to try it, I installed it by removing the Release Candidate of the same, which I had installed earlier. The RC was removed without any issues whatsoever. But after installing VS 2010, strangely, Visual Studio 2008 Pro started showing weird problems. At first, the designer view for ASP.Net project stopped working, it would just stop responding. I could not click anywhere in the window & had to close the IDE using the Task Manager.

Since I was not much into ASP.Net, and design view was working fine in VS 2010. This error was due to the fact that some .dll file required for rendering was replaced by VS 2010 installer with a newer version of the same dll & which was not compatible with VS 2008. Since it was fine in VS 2010, I did not bother much about it.

But situation started worsening after a few days. I had installed XNA Game studio which is an add-on to VS 2008 to create games in C#. VS 2008 not only stopped opening/creating the XNA projects, but also started to fail to open any C# project! I searched over the Internet to see whether anybody else had encountered the same problem. I did not get any such cases, and hence I decided to re-install both VS 2008 & VS 2010. I first removed VS 2010 and started removing the other components it had installed with it. I could remove almost all of them except for one or two. I had to remove the remaining components using the MS Installer Clean-up Utility which is available for download here. It appeared that I had successfully removed VS 2010. Then I re-installed VS 2008 which went well without any issue.

Then came the bigger problem. I tried Installing VS 2010 back again, which used to fail repeatedly. It was trying to install VC++ 10.0 Runtime without any success. VC++ Runtime is a prerequisite for installing VS 2010. I tried installing it separately by downloading from the MS website, which would actually install, but would not be detected as installed by VS 2010 Installer, which tried to install it again & would fail. Then I looked into the installation log of VS 2010 which was in my “Temp” folder located in C:\Users\Username\AppData\Local\Temp\ . There, I found that the installer was returning error code 1603, which meant “fatal error during installation”. I digged further and I got error code 1402, which meant that a particular Registry Key was not accessible to the installer. The error message in the log file read something like Error 1402. Could not open key:  UNKNOWN\Components\06A0D925C8932A8379FE28AFAF97A860\B45568A682984E035AC37D33679831D4. Verify that you have sufficient access to that key, or contact your support personnel.

So, I came to know that the installer has some problems accessing a particular key in the registry. I searched in the net & got a link on how to solve such type of registry inaccessible problems. As you can see, that particular Registry key had been “Orphaned”.

Issues with Orphaned Registry Keys in Visual Studio 2010

What happened here was that when VS 2010 was uninstalled, the uninstaller instead of removing those registry keys, had actually, Orphaned them. In the sense, that those Keys don’t belong to any particular user, & hence when the setup tries to create the key, it encounters another key with the same name & cannot modify the existing one since it doesn’t have any owner, rendering it inaccessible to any user/process. As indicated in this earlier link, I changed the permissions for that key & thought Installation would be successful this time. But, this time, another key problem came up! Again I changed the permissions.

Again a problem! After doing this exercise for many times, I got fed-up & used a software called Registry Mechanic to clean the registry. It found 1000+ issues in the registry, of which most of them where this orphan registry keys. It removed all of them & finally, I could Install VS 2010! And as of now, XNA projects are successfully opening in VS 2008, but the design view issue still persists, which is enough for me as of now.”

What are your thoughts on this issue?

Categories
FAQ Microsoft Windows Installer, Application Compatibility and Deployments

Windows Installer FAQ – Part 4

instAs you guys are aware, I am writing a series of posts which covers some key discussions, topics and FAQs in the stream of MSI Windows Installer and application packaging. In this fourth part, we will look at some questions on MSI properties and key scenarios which can easily achieved by using the properties appropriately.

Q16. What are the types of properties and when do you use a Private property?

Properties are global variables that Windows Installer uses during an installation. As MSI is a database type structure, all the properties are saved in a table called PROPERTY table.  There are three types of properties.

PUBLIC: These properties can be changed by the Application packager in a transform / a system administrator can change it through the command line.  These are always in Capital Letters.  These properties are set during installation and it can be overridden in command line. Ex: INSTALLLEVEL, ALLUSERS, INSTALLDIR.

Properties that are set during the User interface dialogs should be public.

PRIVATE: These properties are used internally by the installer and their values must be entered into the database by the author of the installation package or set by the installer during the installation to values determined by the environment. For example, if the installation is run on a Windows platform, the installer sets the WindowsFolder property to the value specified in the Property table. These properties cannot be changed by the System administrator in command line and its always in lower cases. EX: WindowsFolder, SourceDir

RESTRICTED PUBLIC: There are certain conditions where SystemAdmin can exert control over the PUBLIC properties so that a user with an elevated privileges can’t modify or access them so as to maintain secure systems these properties are know as Restricted PUBLIC PROPERTIES. These properties has a limited set of values. For eg: ALLUSERS,REBOOT

The best practice is to set the ALLUSER property  =1 because if the application is to be installed to per machine and a user without admin access try to install that it will prompt an error but in the other cases it will be a peruser installation without any prompts.

Q17. What would you do, when you (do not) want your installer to restart the machine after installation?

The REBOOT property takes care of this.  The REBOOT property can have any of the below values.

REBOOT = Force – Always prompt for a computer restart at the end of the installation. The UI prompts the user to restart at the end. If there is no user interface, the system restarts at the end of the installation

REBOOT=Suppress – Suppress restart prompts at the end of the installation. During installation, Windows Installer prompts the user to restart whenever it encounters ForceReboot set by the application vendor

REBOOT=ReallySuppress – This will suppress all restart prompts that ForceReboot initiates during the installation and also suppress all restart prompts at the end of the installation.

Setting the REBOOTPROMPT property to Suppress (or S) allows Installer to perform a computer restart, if necessary, without prompting the user.

Q18. How can you disable/Hide an application from Add/Remove Programs?

Setting the ARPSYSTEMCOMPONENT property to 1 will hide the application from appearing. Also, ARPNOREMOVE property to 1, will just disable the remove button from Add/remove Programs.

Q19. When would you use REINSTALL property and what is its significance?

REINSTALL is an important property which is used while Application patching and Upgrades.  If you set the REINSTALL property, you must also set the REINSTALLMODE property, to indicate the type of reinstall you want.

When the REINSTALLMODE property is not set, all files currently installed are reinstalled, but only if the file on the computer is an earlier version or is not present. By default, no registry entries are rewritten if REINSTALL is set to ALL, only features already installed are reinstalled Thus, if REINSTALL is set for a product that is yet to be installed, no installation takes place.

 By default the REINSTALLMODE is “omus”.

For eg: Msiexec /p AdbeRdrUpd913_all_incr.msp REINSTALL=ALL REINSTALLMODE=omus

 p – Reinstalls a product only when a file is missing

  •  o – or an older version of a file is installed
  •  e – or an equal or older version of a file is installed
  •  d – or a different version of a file is installed
  •  c – or the stored checksum value doesn’t match the calculated value
  •  a – Forces all files to be reinstalled
  •  u – Rewrites all required user-specific registry entries
  •  m – Rewrites all required computer-specific registry entries
  •  s – Overwrites all existing shortcuts
  • v – This switch forces the installation to ignore the cached MSI package on the machine and recache the new package being run. This should only be used in an upgrade and not with a first-time installation.


Q20.  Which are the Properties that are mandatory for an MSI installation to work?

ProductCode; ProductLanguage; ProductVersion; ProductName;Manufacturer

For Information on ADDLOCAL property, check this article – http://www.msigeek.com/310/installing-specific-features-in-a-msi-package

I would recommend, You read the other parts too – Part 1 , Part 2 , Part 3 , Part 4, Part 5 (Coming Soon)