How to work around the issue when opening Office applications repairs Visual Studio

How to work around the issue when opening Office applications repairs Visual Studio

  • Comments 27

Microsoft Visual Studio 2010 Beta 1 customers have been reporting that when they start Outlook or any of the Office applications, VS2010 is repaired. This issue can also happen for VS2005 and VS2008, and for any products using Visual Basic for Applications (VBA).

Besides being an annoyance and potentially taking a while to complete, the repair attempt can prompt for source. Picking the right source may not always be obvious from the dialog caption especially if it is truncated. And all the while Outlook or whichever application you started is probably waiting to finish starting up.

Even if you successfully complete the repair operation, this issue may continue each time you start the same application.

How to work around this issue

Windows Installer logs an event that describes the requested feature and which product it is repairing. For this simple workaround, you need to find the latest event log entry. Using information in that event log entry, you’ll remove and re-add a feature and all its components into directory that should always be available.

  1. Click on Start
  2. Click on Run
  3. Type “eventvwr” (without quotes) and click OK. If you are prompted to elevated on Vista or newer, click Continue.
  4. Expand Windows Logs and click Application
  5. Find the recent warning where the Source is MsiInstaller. In Vista and newer,
    1. Click Filter Current Log… in the right action pane
    2. Check Warning
    3. Type “MsiInstaller” (without quotes) in the Event sources edit control
    4. Type “1001” (without quotes) in the event IDs edit control
    5. Click OK

You should see a message similar to the follow,

Detection of product '{316EE0C1-DB94-30BA-95E6-F4959035EE4B}', feature 'VB_for_VS_7_Ent_28_x86_enu' failed during request for component '{DD68FEE8-C369-11D1-A173-00A0C90AB50F}'

I've also attached an event viewer filter you can unzip and import as a custom view.

Keep the log viewer open with the recent warning of type 1001 and open an elevated command prompt.

  • On XP as an administrator,
    1. Click on Start
    2. Click on Run
    3. Type “cmd” (without quotes) and click OK
  • On Vista and newer.
    1. Click on Start
    2. Type “Command Prompt” (without quotes)
    3. Right click on Command Prompt and click Run as administrator. If you are prompted to elevated, click Continue.

You’ll now use the information in the warning message to run two commands consecutively. The first command removes the feature, and the second command reinstalls it locally. The reason you need to do this for this simple workaround is explained in detail below. Use the GUID after “product” along with the feature name as shown in the corresponding example below.

start /wait msiexec.exe /i {316EE0C1-DB94-30BA-95E6-F4959035EE4B} /L*vx "%TEMP%\1.remove.log" REMOVE=VB_for_VS_7_Ent_28_x86_enu
start /wait msiexec.exe /i {316EE0C1-DB94-30BA-95E6-F4959035EE4B} /L*vx "%TEMP%\2.addlocal.log" ADDLOCAL=VB_for_VS_7_Ent_28_x86_enu TARGETDIR="%ProgramFiles%\Microsoft Visual Studio 10.0"


You will likely be prompted for your installation media when running the second command, so be sure to have your installation DVD loaded or ISO mounted. If you installed from the web or your media is not available, you will be prompted to download the media from the web.

How to avoid this issue

If you have any external drives connected to your machine, consider disconnecting them when installing Visual Studio or make sure that they are plugged in when starting applications like Outlook if you have any add-ins for those applications installed.

Description of the issue

Some components in Visual Studio are authored to support advertised installations. By default, advertised components will not be installed until they are needed. For COM servers, Windows Installer writes encoded data to the server library registry value like InProcServer32. This information contains information about the product and feature that will install the component. Windows Installer will always trigger a health check when advertised data is present for COM objects since, inherently, the COM server path isn’t registered.

Even though the feature that installs these components is typically installed locally, Windows Installer still writes this encoded data to the registry. This isn’t normally a problem unless the components to be advertised also install to TARGETDIR or a descendant of TARGETDIR that is not otherwise redirected.

Because TARGETDIR must be the root directory of any Windows Installer package, technically every directory is a descendant of TARGETDIR; however, directories like ProgramFilesFolder are automatically redirected to their corresponding directories like C:\Program Files. Custom actions can also redirect directories, and this is typical in Visual Studio. If TARGETDIR itself isn’t redirected, it defaults to ROOTDRIVE which is the fixed drive with the most free space available, and “fixed drive” doesn’t necessarily mean its an internal drive. External drives these days are growing more common. Any descendants of TARGETDIR are also located relative to ROOTDRIVE then.

So if you have an external drive with a lot of free space connected when you installed Visual Studio, a number of components may have gotten installed there. Even if you do not see any files mysteriously appear after installing Visual Studio, components may still have gotten registered to the other drive. This can actually happen for any Windows Installer products.

Now if you start a product like Outlook that might have add-ins installed that use Visual Studio Tools for Office system Runtime (VSTOR) or Visual Basic for Applications (VBA), creating COM objects they install triggers a repair. This happens because Windows Installer requires the COM server path and this, in turn, triggers a health check. Since the component installation directory – TARGETDIR or a descendant when the component was installed – is no longer available, a repair begins but will ultimately fail in this case since the installation directory is unavailable.

Other problems may manifest. For example, if a file within the same feature is missing for unrelated reasons, Windows Installer installer may prompt for source to replace that file.

So if you had an external drive connected when you installed Visual Studio, make sure you keep it connected when starting applications like Outlook if you have add-ins installed – or at least if you’re experiencing this issue. Better yet for VS 2010 Beta 1, disconnect it when installing Beta 1 unless you intend to install Beta 1 to that drive but remember to keep it connected. On a related note, keep in mind that disk space on your Windows system drive is still consumed by Windows Installer, .NET Framework, and a few other components.

We are working to identify all possible components that may cause this issue for future releases, including VS2010.

Leave a Comment
  • Please add 1 and 7 and type the answer here:
  • Post
  • Ralph, there should be one more event log entry paired with the one shown above. What does that one state? Like that one, Source = MsiInstaller and the same component code - {DD68FEE8-C369-11D1-A173-00A0C90AB50F} - should be referenced.

  • The other event entry is:

    Detection of product '{211E0526-66B6-31BF-930A-A3738EC9290C}', feature 'VCsh_for_VS_7_Pro_810_x86_enu', component '{A5854250-7B92-4A50-935F-6A486589F87D}' failed.  The resource 'C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\en\' does not exist.

    There are no subdirectories under C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\

  • Ralph, this is a known issue with Beta 1. Please create the "en" subdirectory and this issue should be resolved for beta 1.

  • At least in my case the problems all seem to be that some directories aren't being created by the Beta 1 install. It doesn't appear that the msiexec commands are needed.

    The missing directories are:

    C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\EN\

    C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\EN\


    Based on your previous comments, I created

    C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PublicAssemblies\EN\

    I then got:

    >> Detection of product '{211E0526-66B6-31BF-930A-A3738EC9290C}', feature 'VCsh_for_VS_7_Pro_810_x86_enu' failed during request for component '{DD68FEE8-C369-11D1-A173-00A0C90AB50F}'

    >> Detection of product '{211E0526-66B6-31BF-930A-A3738EC9290C}', feature 'VCsh_for_VS_7_Pro_810_x86_enu', component '{F5686A3B-40B1-40CF-8B60-88D08F50A38A}' failed.  The resource 'C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\EN\' does not exist

    So I created

    C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\EN\

    Then I got:

    >> Detection of product '{211E0526-66B6-31BF-930A-A3738EC9290C}', feature 'VCsh_for_VS_7_Pro_810_x86_enu' failed during request for component '{DD68FEE8-C369-11D1-A173-00A0C90AB50F}'

    >> Detection of product '{211E0526-66B6-31BF-930A-A3738EC9290C}', feature 'Language_Tools_for_VS_7_Pro_x86_enu', component '{DC255EAE-9ABC-423E-83BD-FC084680B004}' failed.  The resource 'C:\WINDOWS\Microsoft.NET\Framework\URTInstallPath_GAC\' does not exist.

    So I tried:

    >> start /wait msiexec.exe /i {211E0526-66B6-31BF-930A-A3738EC9290C} /L*vx "%TEMP%\1.remove.log" REMOVE=Language_Tools_for_VS_7_Pro_x86_enu

    >> start /wait msiexec.exe /i {211E0526-66B6-31BF-930A-A3738EC9290C} /L*vx "%TEMP%\2.addlocal.log" ADDLOCAL=Language_Tools_for_VS_7_Pro_x86_enu TARGETDIR="%ProgramFiles%Microsoft Visual Studio 10.0"

    This completely broke VS10 - it wouldn't start at all, so I uninstalled VS10 and reinstalled it, keeping the \EN directories I had previously added but not doing any of the msiexec commands and tried creating:


    This seems to have fixed everything.

  • Ralph, the missing directories are described in Do you still have the logs you created when you invoked msiexec? I would like to take a look and see why Dev10 didn't function correctly. ZIP and post the logs to a server and use the Contact link to send me the URLs. Thank you.

  • Not working for me

    Office 2007 VS 2008

    error from event viewer

    Detection of product '{6721AC10-3743-38F1-B178-C0EC6C9A4108}', feature 'VB_for_VS_7_Ent_28_x86_enu' failed during request for component '{DD68FEE8-C369-11D1-A173-00A0C90AB50F}'

    Ran these:

    start /wait msiexec.exe /i {6721AC10-3743-38F1-B178-C0EC6C9A4108} /L*vx "%TEMP%\1.remove.log" REMOVE=VB_for_VS_7_Ent_28_x86_enu

    start /wait msiexec.exe /i {6721AC10-3743-38F1-B178-C0EC6C9A4108} /L*vx "%TEMP%\2.addlocal.log" ADDLOCAL=VB_for_VS_7_Ent_28_x86_enu TARGETDIR="%ProgramFiles%\Microsoft Visual Studio 9.0"

    Install completes: (from event viewer)

    Windows Installer reconfigured the product. Product Name: Microsoft Visual Studio Team System 2008 Development Edition - ENU. Product Version: 9.0.30729. Product Language: 1033. Reconfiguration success or error status: 0.

    upon restarting all begins again.


  • Heath, may I ask if people developing Windows Installer have any sanity and respect for users left in their heads?

    Whose idea was that horrible auto-repair feature?

    An example which you can easily try:

    I install StuffIt, I decide that I do not need one of its services (ArcNameService) and I kill the process, delete the .exe file, and remove its registry entry.

    Later on, when I call up a context menu Windows Installer starts, stealing focus from me trying to "repair" this intentional "damage" to the application it is auto-repairing.

    Now don't get me wrong -- I would appreciate if it asked me "The application XYZ files are corrupted or missing, would you like to repair them?", if it did that without stealing the focus, and if it asked me only once and remembered my choice. Even better if there was a global policy to disable this completely.

    But no! It keeps popping its progress dialog and I keep canceling it, it is really annoying up to a point that I finally completely uninstall the application which I wanted to use and decide not to buy it.

    This may well be an error in the way Windows Installer service is used in that particular application (it is probably starting the repair from the context menu shell extension which IMO is a big no-no), but I really don't care -- Microsoft should make sure that such powerfull options do not get abused by the developers.

    Problem with the repair idea is that when there is a program damage the changes are pretty high that the installation source is missing or damaged as well, so there is no point in repeatedly trying to repair the damage without giving the user an option to break out of this vicious circle.

    As for the bloat, it is bloated, there is no point in denying it. What is the purpose of keeping cache of the installation if the application doesn't use auto-repair? It is one thing to keep a list of UNDOs to unwind the system to the previous state but keeping this small bit of information glued together to the whole setup which can often take as much as 1GB in size (Adobe Acrobat 9 for example) is IMO just a very poor design begging to be ridiculed and called out upon.

    Even those .msp files are a joke -- in most cases they do not contain differential patches, they have whole files inside. Last time I checked the meaning of the word "patch" replacing ripped pants with new pants didn't count as patching. Providing such "patches" is pointless -- in most cases it is much more efficient to uninstall the program, slipstream a patch, and install from new source.

    Finally, VC redist MSI shipped with several popular applications and games spilling its files all over C: root is an unforgivable sin.

  • Russell, could you enable the logging policy (, stop the Windows Installer service (net stop msiserver), and reproduce this? Use the Contact link to send me the URL to the log and please include a bit of context so I realize the email pertains to this thread.

  • January 29, 2011, and this still happens :/

    VS 2010 Pro. I'm removing the VB portion and reinstalling without the external hooked up.

    Don't you think maybe windows installer should notice it's a removable drive?

    On the plus side: your article is beautifully written and finally explained to me what the heck was going on. Thanks

  • VS2013: The procedure described here did not help in my case; however when looking at Event ID 1004 I saw this:

    Detection of product '{9C593464-7F2F-37B3-89F8-7E894E3B09EA}', feature 'Visual_Studio_Professional_x86_enu', component '{E3FF99AA-78B9-4A06-8A74-869E9F65E1FE}' failed.  The resource 'C:\Windows\Microsoft.NET\Framework\URTInstallPath_GAC\' does not exist.

    After adding the missing subfolder "URTInstallPath_GAC" the problem was gone.

  • Hello,

    I am seeing this problem after installing Visual Studio Community Edition 2013 - Update 4. My Office installation 2010. My Visio and Project which are 2007 are not affected. System is Windows 7 64-bit with latest patches applied.

    Trying to use the solution listed above with my specific GUID results in the following Error:

    The Installer has encountered an unexpected error intalling this package. This may indicate a problem with this package. The error code is 2711.

    Any help would be appreciated.

    - One thing more: When I installed VSCE-2013, I did have my external drive connected which is now disconnected.

  • @Vinay, you'll need to plug your external drive back in. If you don't want to long term, xcopy the contents to a temporary directory, detach the drive, then create a virtual drive in place with the same drive letter and copy the contents back in. That would work around the problem. To fix it, you'd need to uninstall VS and re-install it without the drive attached.

Page 2 of 2 (27 items) 12