How to workaround issue where launching Outlook triggers a repair of VS 2005

Recently, I helped investigate this Visual Studio 2005 issue reported on the Microsoft Connect site that I wanted to describe here in case anyone reading this blog runs into a similar issue.  To summarize that bug report, a couple of customers had installed VS 2005, and they started to notice that a repair would be triggered for VS when they launched Microsoft Outlook.

How to reproduce this issue

In the cases that I investigated, the customers had large-capacity USB hard drives connected to their systems.  The repair would occur if they disconnected or powered off their USB hard drive, and it would not occur if the USB hard drive was connected.

How to workaround this issue

There are a few possible workarounds for this type of repair:

1.  Uninstall VS, then re-install it with the external hard drive disconnected

2.  Leave the external hard drive connected when starting Outlook

3.  Use the following steps to remove a couple of registry values from the system:

  • Click on the Start menu, choose Run, type cmd and click OK
  • Run this command:  reg delete "HKCR\CLSID\{AC0714F6-3D04-11D1-AE7D-00A0C90F26F4}\InprocServer32" /v InprocServer32 /f
  • Run this command:  reg delete "HKCR\CLSID\{AC0714F7-3D04-11D1-AE7D-00A0C90F26F4}\InprocServer32" /v InprocServer32 /f 

Option 3 (deleting the registry values) is the least invasive, and there will not be any functional side effects in VS 2005 or in Outlook if you choose to do this.  The values that are listed above are only used by Windows Installer to advertise features, but VS 2005 installs all features locally and does not support advertising, so those registry values do not serve any practical purpose anyway.

More information about the root cause

To track down the exact cause of this repair, I had the customers send me some information from their application event logs in order to narrow this down.  As I described in this blog post, when Windows Installer triggers a repair of an MSI, it will log a pair of warnings in the application event log with a source named MsiInstaller.  The first warning will provide the component GUID for the component in the MSI that triggered the health check, and the second warning will provide the component GUID for the component in the MSI that Windows Installer detected was broken and in need of repair.

There is a component in the VS 2005 product that has been incorrectly authored to try to use the drive with the largest amount of free space (the TARGETDIR property in Windows Installer) as a destination location.  In these cases, this drive resolved to the USB hard drive, and when that drive was disconnected or powered off, a repair will be triggered in cases where a health check is initiated by the system.

As I described in this blog post, COM objects that are advertised in the Class table of an MSI will cause Windows Installer to perform a health check for the feature(s) that advertise them each time an instance of the COM object is instantiated.  The VS 2005 MSI advertises a couple of COM objects that are related to VBA add-in development, and Microsoft Outlook will try to instantiate those COM objects when it is launched in some cases.  In these cases, a health check of the VS 2005 product will occur, and the incorrectly authored component will be reported as broken if the USB hard drive is not available.

Fortunately, there are a couple of changes in VS 2008 setup that will prevent this scenario from happening in the future:

  • The VBA add-in COM objects are no longer advertised via the Class table of the VS 2008 MSI
  • The component that uses TARGETDIR as a destination location has been removed from the VS 2008 MSI