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 24

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.

Attachment: Filter.zip
Leave a Comment
  • Please add 5 and 1 and type the answer here:
  • Post
  • It's due to exactly this kind of bug that Windows Installer really bites.  That and all of the disk space that it uses.  I understand that complex applications like Office and Visual Studio need complex installers and are so fragile that they require repair support.  But I appreciate every app I install that supports unzip and run.

  • In the couple seconds it takes to cancel the vs2010 install dialog and then close access, over 7000 errors are reported. List list offered by event viewer cuts off what is probably the relevant entry at the start of the list so I can't look at it. All 7000 entries are like this:

    The description for Event ID ( 1 ) in Source ( nview_info ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. You may be able to use the /AUXSOURCE= flag to retrieve this description; see Help and Support for details. The following information is part of the event: NVIEW :  MSACCESS: Shared heap exhausted or damaged, process ID 1054, total alloc:3b198...

    So what can I do to get rid of this? I don't think any external drive was running when I installed vs2010, unless the installer regarded a printer as a disk?

  • rusti, this appears to be coming from another application. Do you have Microsoft Access or something named "NVIEW" running? It might help to close that. Generally, closing applications during installations is recommended.

  • Hello.  In the first step of this process I get: The installer has encountered an unexpected error installing this package...The error code is 2711.

  • You're right, that nview issue does not seem to be related to the vs2010 installer issue. Today and yesterday the nview errors are not there; I'm sure it'll reappear and I'll check out running taskd the next time it does. Today, not distracted by the thousands of nview errors, I found the MsiInstaller warning. The fix you posted did work - thank you.

  • but only if I installed VS2010 that this issue will appear, vs2008 is fine. and it can't be solved as you said for me. every time I installed the component , event log will generate same warning( if reinstall could solve, why first time fail?) , I even had re-installed my OS, it doesn't help at all, (I use win7) , it seems the fail rate is 100%(for me), the only way is uninstall vs2010......

    I'm really suffering from this issue, is there any way to disable this feature? in fact , I don't use it at all.

    I tried disable the add-on from excel option, but it doesn't help.

  • I am unable to even begin unistalling this app. It asks for a file that does not exist:

    Setup is looking for file TFSObjectModel-x86_ENU.exe

    Please locate this file or insert Microsoft Visual Studio Team System 2010 Please locate this file or insert Microsoft Visual Studio Team System 2010

    Team Suite Beta 1 – ENU disk 1 now Team Suite Beta 1 - ENU disk 1 now

    I do not have a disk, this was an install directly from the MS website.

    How to I roll it back to the previous version since I am not able to unistall it? None of my projects will open in Blend now, I need to roll this back. Help.

  • Removable devices aren't the only thing that may cause this issue. In fact, reliance on ROOTDRIVE is poor form, as it simply finds the volume with the most free space.

    This assumption can change as volumes fill or may be completely wrong from the get-go (e.g. my Windows volume is kept small)

  • John, you need to have permissions to run an elevated command prompt and run the commands elevated. Do you have administrative privileges on your machine?

  • Scott, it's true the workaround will not work 100% of the time. It depends on a number of factors, but it should usually work. What do the event log errors say exactly? Can you paste the content here (please be sure not to post any personally-identifiable information).

  • Franchesca, look under your VS installation folder for a sub-folder bearing the name of the product: like "Microsoft Visual Studio 2010 Processional Beta 1 - ENU". In there should be a file named baseline.dat. Look for that file name and find a property near it like DownloadUrl. Copy and paste that into your browser and download the file. When prompted for that file, point to the download location.

  • Thanks for this blog!

    A recurring theme in comments to many posts here, is the "bloat factor".  It seems as if Microsoft is assuming we all live in a world of "one large C:" so that space is cheap.

    In practice, it may be better to keep C: deliberately small, and reserve it for frequently-used/paged code, active temp locations etc. so that no matter how full the entire drive may be, disk head travel is constrained within a few cylinders most of the time.

    A non-relocatable Installer (plus other subtrees within the OS subtree) really messes this up.  for every one active code file, there may be 3 "dead" copies that are never used unless an (un)install is being done, and the heads have to keep stepping over this junk.  

    It's like living in a house with one big room, where you have to walk around the car every time you move between sink and fridge.  How efficient a kitchen would that be?  

    We optimize CPU and RAM use, where we'd never accept dead material locked in RAM or a CPU stalled waiting for a peripheral.  So why do we tolerate Installer bloat?

    Even when large apps are deliberately installed off C: to free space there, Installer can bloat up with the pre-install material for that app.

    It's really gross, and one solution may be to make Installer (or better yet, *all* dead-bloat cold-storage locations, such as SoftwareDistribution, $...$, ie7upd, ServicePackFiles, Config.msi etc.) a relocatable shell folder subtree.  

    I've been doing this since Win95, using a small-ish location at the far end of the disk for "cold storage" (pre-install material, C: partition image, data auto-backups).  

    I disable any auto-groping services that would normally go there (e.g. System Restore), so head travel to that material is reduced, write traffic is less, and survivability is better.

  • Chris, I wouldn't call the Installer "dead-bloat". Another reoccuring theme on this blog is if you delete files from it you'll be in a bad state. But I do agree that while hard disks may be cheap these days, replacing them is not - especially the system drive. Enterprises and home users both incur costs of backup, replacement, and reinstallation.

    But small system partitions should still be avoided because it's no just the "dead-bloat" files that go there. .NET does for several reasons and if you don't redirect Program Files - or more specifically Common Files (files installed to that location typically don't let you redirect through the install UI) - they end up on the system drive by default.

    I would also recommend if you have more than one physical drive you locate your pagefile on a separate drive, perhaps even in its own partition. Depending on disk I/O load this may increase throughput slightly - considering, of course, that the pagefile drive isn't slower than your system drive.

  • I don't think external drives being connected is the problem. I uninstalled VS, then disconnected my external drive, disconnected from my local network and reinstalled it and am still getting the same error when opening Excel macro editor.

  • I haven't been able to resolve this problem. I'm on XP SP3 with the current VS 2010 Beta 1 opening the VBA editor in Excel 2003 SP3.

    I have an external hard drive but it was disconnected during the original VS install and during this exercise. I was also disconnected from my local network and the internet.

    The warning I'm getting in the event log is:

    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}'

    I ran these commands:

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

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

    ProgramFiles%Microsoft Visual Studio 10.0"

    After the remove and before the addlocal the error did not occur but VS 2010 wouldn't open my projects. Once I did the addlocal VS works but the error on opening the VBA editor returned.

    I also tried removing the VS tools for office and reinstalling them but it didn't help. When the tools were uninstalled, the error was still there opening the VBA editor.

Page 1 of 2 (24 items) 12