On one of my computers I have started to suffer again the strange case of a prompt to repair Visual Studio 2010 when launching the VBA editor of any Office application. I already posted about this back in 2012 when I learned that a cause for that issue was having an external hard drive connected to the computer while you installed Visual Studio. When the drive was disconnected, the issue appeared. Since I did use an external hard drive as source for the setups of Visual Studio, that was certainly the case. Since then, I never have an external hard drive connected while I install Visual Studio, I copy the setups to the desktop, disconnect the drive and proceed to install.

So, what is causing the issue now, out of the blue? I am reading again the post How to work around the issue when opening Office applications repairs Visual Studio where Heath Stewart explains the issue and the workaround, and again, the cause is the presence of a drive unit that was present while Visual Studio was installed and sometime later that drive letter is no longer available. In my new cause these days, it was caused because the computer is an office laptop, and my company partitions the hard drive in two units, “C:” for apps and “D:” for data. Since that is plainly useless (the hard drive is the same so if broken you lose both partitions and most data goes anyway to the “Desktop” or “My Documents” locations, which are on “C:”), a couple of days ago I removed the empty “D:” partition and joined the space to the “C:” partition (which was almost full). Alas, since the “D:” unit was removed the issue with the VS 2010 prompt to repair appeared.

The post of Heath Stewart explains how to find the offending component filtering by “Warning” kind, “MsiInstaller” source and “1001” event id. But it you filter instead by “1004” event id, you will get the offending missing unit (“D:” in my case).

I have been unable to fix the issue yet with the instructions of the post, so I have had to uninstall VS 2010. I am now gettting a prompt to repair Visual Studio 2013…oh my…, you see, the installers of Visual Studio are so crappy that if you are a developer of extensions for Visual Studio and get a new computer you know you have to spend a lot of hours installing VS 2005, SP1, VS 2008, SP1, VS 2010, SP1, VS 2012, VS 2013, tons of patches and updates, etc. and when you think it’s done, some day you discover that you need to uninstall all of them (or to format the hard drive to start again) as I did in 2012 and it seems that I will have to do this next week again…

Another error that can happen loading an add-in that I have found today is the following (with an unhelpful error message as usual):

Error Message: <Unknown error>
Error number: 8013101b

This error happens if you have compiled the add-in with a CLR version higher than the one supported by the Visual Studio IDE where you are trying to load it. For example, if you compile the add-in using Visual Studio 2010, 2012 or 2013 using CLR 4.0 and you try to load it in Visual Studio 2005 or 2008, which only support CLR 2.0.

Remember that the CLR is not the same than the .NET Framework. The correspondence is as follows:

• .NET Framework 1.0 use CLR 1.0
• .NET Framework 1.1 use CLR 1.1
• .NET Framework 2.0, 3.0 and 3.5 use CLR 2.0
• .NET Framework 4.0, 4.5 and 4.5.1 use CLR 4.0

And there is no such thing as CLR 3.0, CLR 3.5, CLR 4.5 or CLR 4.5.1. While .NET Framework 3.0 and 3.5 just installed new libraries without touching the CLR 2.0, .NET Framework 4.5 and 4.5.1 do touch the CLR 4.0 (a kind of in-place replacement) but keeping it backwards compatible and maintaining the version 4.0.

This means that for example, the problem doesn’t happen if you compile the add-in with VS 2013 using .NET Framework 4.5.1 (uses CLR 4.0) and you try to load it in VS 2010 (supports CLR 4.0). A problem can happen if you use some assembly of .NET Framework 4.5 or 4.5.1 because it would be missing on a machine with only VS 2010 and .NET Framework 4.0 but that would be a different issue, not a 8013101b error.

I have updated my article about troubleshooting add-ins with this new error number:

HOWTO: Troubleshooting Visual Studio and Office add-ins
http://www.mztools.com/articles/2007/mz2007009.aspx

I found a couple of days ago a bug that I hadn’t seen before: when you create an add-in with Visual Studio 2013 (you need to install the VS 2013 SDK), hit F5 to debug it, which launches a second VS 2013 instance and close this instance (even without loading the add-in), you get:

An unhandled exception of type ‘System.Runtime.InteropServices.InvalidComObjectException’ occurred in mscorlib.dll
Additional information: COM object that has been separated from its underlying RCW cannot be used.

This exception happens in System.Threading.Tasks.AsyncCausalityTracer.TraceSynchronousWorkCompletion(System.Threading.Tasks.CausalityTraceLevel, System.Threading.Tasks.CausalitySynchronousWork)

Searching the web I have found that it happens also with packages and DSL designers of the VS 2013 SDK, that is, with any kind of extension. It was reported on Microsoft Connect:

Visual Studio 2013 Domain Specific Language Designer crash on exit.
https://connect.microsoft.com/VisualStudio/feedback/details/813425/visual-studio-2013-domain-specific-language-designer-crash-on-exit

and Ryan Molden (MSFT) acknowledged the bug in this thread of the MSDN VSX forum about packages:

Default VSPackage template in VS2013 SDK Throws Exception when exiting
http://social.msdn.microsoft.com/Forums/vstudio/en-US/06c0c8f3-e616-4c8c-9a62-aa87a6a63edb/default-vspackage-template-in-vs2013-sdk-throws-exception-when-exiting?forum=vsx

It is a bug of the async causality tracing stuff of the CLR 4 modified by the .NET Framework 4.5.1 (and used by VS 2013), because it didn’t happen with the CLR 4 of the .NET Framework 4.5 (used by VS 2012). Notice that it doesn’t depend on the .NET Framework used by your extension (.NET 2.0 in my case).

We will need to live with this bug until the Windows team (which owns the CLR, not the VS team) fixes it. An interesting thing is that I hadn’t seen this problem until I reformatted my laptop with Windows 8.1 a couple of days ago. Previously I was using Windows 7 and in fact I haven’t been able to reproduce the problem today on another laptop with Windows 7.