Category Archives: The strange case of…

The strange case of error “Subscript out of range” in Data View starting VB 6

I am writing this little post mainly for myself in the future and the other two users that seem to have experienced this in the past. I already saw this in the past but until today I didn’t find out how to fix it:

If you get a msgbox error with the title “Data View” and the text “Subscript out of range” starting Visual Basic 6.0, it means that your commandbars are corrupted and need resetting:

– Right-click on any toolbar and select “Customize…” menu entry.

– For each toolbar in the list, click the “Reset…” button.

How did I find this fix? After using SysInternals Process Monitor for a while, I only discovered that Data View is actually a kind of hidden add-in. It doesn’t appear in the Add-In Manager, but it has a Connect class, a toolwindow, etc. The clue was that right-clicking on the treeview of its toolwindow, another error “91 : object variable or with block variable not set” happened and the toolwindow was crashed. And what happens typically when you right-click a treeview node? A commandbar is shown! If the commandbar is not shown, it means that there is a problem with the commandbar subsystem (quite typical of VB6), so I tried resetting the commandbars as explained above and bingo!

The strange case of error 80131515 loading a Visual Studio add-in

This morning I got an error 80131515 loading my MZ-Tools add-in that I had never seen before, and it was not mentioned in my article HOWTO: Troubleshooting Visual Studio and Office add-ins, so I searched the web.

It happens that after installing the add-in through the setup on a virtual machine on Windows Azure, I downloaded a new build from my web (just the dll, not a new setup), replacing the existing dll. And this error appears when you download a dll in such way, so it is “blocked” by the OS preventing its execution for security reasons. The solution is to right-click the dll file to show its Properties window, and in the General tab, Security zone, click the “Unblock” button.

The strange case of “LoaderLock was detected” with a COM add-in written in .NET

Since some days ago, I was getting the following error when closing Visual Basic 6.0 from the Visual Studio debugger (I am developing a .NET-based version of MZ-Tools for the 64-bit VBA editor of Office, and VB6 will get it too):

LoaderLock was detected
Message: Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain or image initialization function since doing so can cause the application to hang.

This is a warning of the Managed Debugging Assistants (MDA) of Visual Studio.

Today I decided to investigate. Soon it was clear that it was caused by the test-runner add-in that I created to run integration tests within VB 6.0. Since the error was caused during shutdown, I removed initializations (and the corresponding cleanups) to isolate the problem and I discovered that the problem was in this method:

internal List<string> GetAddinProgIds()
   List<string> colAddinProgIds;

   colAddinProgIds = new List<string>();

   foreach (AddIn objAddIn in m_objVBE.Addins)
   return colAddinProgIds;

That method gets the registered add-ins of the VBE object (to load them in a combobox and select an add-in to run its test suites).

I soon realized that maybe I should release properly some COM object and certainly the problem was fixed:

internal List<string> GetAddinProgIds()
   List<string> colAddinProgIds;
   Addins colAddins;

   colAddinProgIds = new List<string>();

   colAddins = m_objVBE.Addins;
   foreach (AddIn objAddIn in colAddins)

   // The following statement is to prevent the following error:
   // LoaderLock was detected
   // Message: Attempting managed execution inside OS Loader lock. Do not attempt to run managed code inside a DllMain
   // or image initialization function since doing so can cause the application to hang.

   colAddins = null;

   return colAddinProgIds;

The strange case of “Set property ‘System.Windows.ResourceDictionary.DeferrableContent’ threw an exception.”

In the recent days, each time that I clicked the New Project button of the Visual Studio 2012 IDE, I got this exception:

“Set property ‘System.Windows.ResourceDictionary.DeferrableContent’ threw an exception.”

I have been clueless about this problem until today. When a problem happens in Visual Studio, the recommended approach is to launch it in “Safe mode”, because maybe an extension (add-in, package, etc.) is causing it. As a previous step, what I did today is to take a look at the Add-In Manager and I noticed that I had an add-in (a test runner that I created to perform integration tests of my MZ-Tools add-in) marked to load on startup. I unmarked it and then the problem disappeared. Why was this add-in causing this problem?

After some isolation, it happened that this add-in was setting an event handler for the AppDomain.AssemblyResolve event (to locate required assemblies) and a silenced NullReferenceException was happening in the event handler. The following minimal add-in reproduces the issue:

public class Connect : IDTExtensibility2
   private DTE2 _applicationObject;
   private AddIn _addInInstance;
   private AppDomain _appDomain;

   public void OnConnection(object application, ext_ConnectMode connectMode, object addInInst, ref Array custom)
      _applicationObject = (DTE2)application;
      _addInInstance = (AddIn)addInInst;

      switch (connectMode)
         case ext_ConnectMode.ext_cm_Startup:
            // OnStartupComplete will be called

         case ext_ConnectMode.ext_cm_AfterStartup:

   public void OnStartupComplete(ref Array custom)

   private void InitializeAddIn()
      _appDomain = AppDomain.CurrentDomain;
      _appDomain.AssemblyResolve += AppDomain_AssemblyResolve;

   public void OnDisconnection(ext_DisconnectMode disconnectMode, ref Array custom)
      _appDomain.AssemblyResolve -= AppDomain_AssemblyResolve;

   public void OnAddInsUpdate(ref Array custom)

   public void OnBeginShutdown(ref Array custom)

   private Assembly AppDomain_AssemblyResolve(object sender, ResolveEventArgs args)
      Assembly objAssembly = null;
      AssemblyName objAssemblyName = null;

      // Force a NullReferenceException
      if (objAssemblyName.Name == "")

      return objAssembly;

The strange case of the add-in initialized twice

As I commented in my last post, I have developed my own integration test infrastructure to test my MZ-Tools add-in. As part of it, there is an add-in that is the test runner, that when loaded loads in turn the MZ-Tools add-in if not loaded, locates its friend assembly that contains the integration tests, loads it, gets the test suites, gets the test methods, shows them in a treeview and executes the ones that I select.

This worked fine if the test runner add-in was not marked to load on startup and I had to load it with the Add-in Manager. But when the test runner add-in was marked to load on startup, the MZ-Tools add-in was initialized twice, giving an exception because some code didn’t expect to run twice (duplicated key).

The code of the MZ-Tools initialization is similar to the one that I wrote in my article HOWTO: Use correctly the OnConnection method of a Visual Studio add-in and that I constantly recommend in the MSDN VSX Forums:

AddIn _objAddIn;

void IDTExtensibility2.OnConnection(object objApplication, ext_ConnectMode eConnectMode, object objAddInInst, ref System.Array r_objCustom)
   _objDTE = (EnvDTE.DTE)objApplication;
   _objAddIn = (AddIn)objAddInInst;

   switch (eConnectMode)
      case ext_ConnectMode.ext_cm_Startup:

         // IDTExtensibility2.OnStartupComplete will be called

      case ext_ConnectMode.ext_cm_AfterStartup:


void IDTExtensibility2.OnStartupComplete(ref System.Array r_objCustom)

private void Initialize()

This pattern assumes that:

1) If an add-in is loaded on startup:

  • The OnConnection method will be called with the ext_ConnectMode.ext_cm_Startup flag.
  • The OnStartupComplete method will be called later TOO, when the Visual Studio IDE has completed its initialization.

2) If an add-in is loaded through the Add-In Manager:

  • The OnConnection method will be called with the
    ext_ConnectMode.ext_cm_AfterStartup flag.
  • The OnStartupComplete method will NOT be called (because the Visual Studio IDE was already initialized when you used the Add-In Manager to load the add-in).

But in my case, the Initialize method was being called twice. How was that?

It happens that there is a subtle behavior here: when an add-in marked to load on startup loads in turn another add-in (using EnvDTE.AddIn.Connect = true), in the second add-in the OnConnection method is called with the ext_ConnectMode.ext_cm_AfterStartup flag, AND the OnStartupComplete is called too!!! (because the Visual Studio IDE was not initialized when the first add-in was loaded on startup). So, the Initialize method is called twice.

I was about to report this as a bug, but I have thought that maybe the behavior is correct after all, that is, when VS has finished its initialization it calls OnStartupComplete for all add-ins that are loaded in that moment, independently of whether they were marked to load on startup or they were loaded by another add-in marked to load on startup. And what is really misleading is the MSDN documentation about the OnStartupComplete method:

(OnStartupComplete) “Occurs whenever an add-in, which is set to load when Visual Studio starts, loads.”

That implies that if add-in is not set to load on startup, its OnStartupComplete method will not be called.

The Remarks section is correct, though, since it does not relate the OnStartupComplete call to whether the add-in was set to load on startup or not:

“On occasion, OnConnection does not occur correctly, such as when an add-in is loaded, but a component required by an add-in has not yet loaded. This is unusually due to the fact that Visual Studio has not yet started completely. Using OnStartupComplete guarantees that the Visual Studio integrated development environment (IDE) has completed the startup process.”

As you realize, this is a subtlety that your add-in won’t experience unless is loaded by another add-in when Visual Studio is started.

The strange case of error “Unable to register DLL/OCX:RegSvr32 failed with exit code 0x5”

In the past years, I have received some bug reports (less than 10 out of dozens of thousands of installations) reporting that the setup of MZ-Tools 3.0 for VBA / VB6 was failing with this error:

“Unable to register DLL/OCX:RegSvr32 failed with exit code 0x5”

I never discovered the cause (I just recommended to reinstall Office or VB6, depending on the case, or I sent the list of dependencies), but in the last weeks the problem has happened to two users of Microsoft Office 2013 using a clean installation. I already suspected that the problem was related to the file MSADDNDR.DLL (in the folder C:\Program Files (x86)\Common Files\designer), the reference used by add-ins for VB6 and for the VBA editor.

So I decided to investigate, and lo and behold, it happens that Office 2013 doesn’t install that file, it just installs the MSADDNDR.OLB object library file. I even used the orca.exe tool of the Microsoft Windows SDK to open the .msi files of the Office 2013 setup to verify. I guess that somehow some users of VB6 and old versions of Office had this file missing or damaged, what would explain the case completely.

To fix the problem, the new setups of MZ-Tools 3.0 released today install this file:

MZ-Tools 3.0.1206 for VBA with bug fix to support Microsoft Office 2013

Another strange case of error 80131522 loading a Visual Studio add-in

OK, this is a post mainly for me (to be found in the future) because yesterday it was the second time that it happened (and I barely remembered the first one). It is a so subtle scenario that it can only happen if you create lots of add-ins for multiple versions of Visual  Studio (I need to do this for the MZ-Tools Articles Series about developing Visual Studio add-ins) and some day you do not clean up properly.

So, yesterday this is what happened:

  • I created an add-in named MyAddIn1 in Visual Studio 2005 (I tend to use this IDE for the samples of articles to ensure that I use .NET Framework 2.0).
  • I edited the file MyAddIn1 – For Testing.AddIn in the “C:\Users\<user>\Documents\Visual Studio 2005\Addins” folder to add <HostApplication> entries for Visual Studio 2008 (9.0), 2010 (10.0) and 2012 (11.0).
  • I copied the file MyAddIn1 – For Testing.AddIn to the AddIns folders of those IDEs.
  • I loaded the add-in using the Add-In Manager (the add-in was marked not to load on startup) and it loaded correctly in VS 2005, 2008 and 2010, but I got error 80131522 in VS 2012. What???

I was well aware that the usual cause for that cryptic error is when the namespace and class name of the “Connect” class in the code don’t match the value of the FullClassName tag of the .AddIn file, as I explained in this article:

HOWTO: Troubleshooting Visual Studio and Office add-ins

But this was not the case, because the .Addin file was exactly the same (copied to four folders) and in fact the add-in loaded correctly in three IDEs. So, I used ProcMon to see if I noticed something strange:

HOWTO: Using the Process Monitor (ProcMon) tool to diagnose Visual Studio add-ins problems

I certainly I found that the first appearance of MyAddin1.dll was being loaded from the folder “C:\Users\<user>\Documents\Visual Studio 2012\Projects\MyAddin1\MyAddin1\bin”, not from the “C:\Users\Carlos\Documents\Visual Studio 2005\Projects\MyAddin1\MyAddIn1\bin”. So, there was a second add-in dll named MyAddIn1.dll (from the past) that was being loaded before the MyAddIn1.dll created with the steps above. This dll used a different namespace for the Connect class (even subtly “MyAddin1” vs “MyAddIn1”, notice the different case of just one letter) and therefore the error 80131522.

The only thing that remained unexplained yesterday was why this old MyAddIn1.dll was loaded at all if I replaced its “MyAddIn1 – For Testing.AddIn” file by the new one pointing to the folder “C:\Users\<user>\Documents\Visual Studio 2005\Projects\MyAddin1\MyAddin1\bin” (I remembered the Windows Explorer prompt to confirm replacement) and today I have found the explanation: this old add-in created a permanent CommandBarButton, so its underlying MyAddIn1.dll file was loaded. As soon as I removed that button, the new add-in loaded fine.

Bottom line: the error 80131522 can happen if a wrong add-in dll (with the same name) is loaded. The ProcMon tool should help to find the folder where an add-in dll is being loaded from.

The strange case of projects not being rebuilt

Yesterday while writing code for the next article about creating add-ins for the VBA editor of Office using Visual Studio .NET I noticed that when I used this approach to debug it, the add-in project was not being rebuilt when I changed some code and hit F5 to debug:

  • In the Solution Explorer of the Visual Studio project, right-click the solution
    node and click the “Add”, “Existing Project…” menu entry.
  • Select the path to Excel.exe, for example “C:\Program
    Files\Microsoft Office\Office14\EXCEL.EXE”.
  • Right-click the EXCEL.EXE node and click the “Set as Startup Project” menu
  • Right-click the EXCEL.EXE node and click the Properties menu entry.
  • In the Debugger Type field, change its value from “Auto” to “Managed (v2.0)”.
  • Click the “Debug”, “Start Debugging” menu.
  • Excel will be launched.
  • Open the VBA editor and load the add-in. The breakpoint should be hit in the
    add-in project.

I remembered that the same happened to me some months ago with the solution of my add-in MZ-Tools 6.0, that contained the main add-in project and other projects for external operations of the MZ-Tools 6.0 SDK: the projects of the external operations were not rebuilt when I debugged the main add-in project.

The reason is that by default, the setting “Only build startup projects and dependencies on Run” that is in the “Tools, “Options…” window, “Projects and Solutions”, “Build and Run” section is checked. Once you uncheck it, the issue is solved.

I have updated the article that I wrote a couple of days ago to reflect this:

HOWTO: Debug an add-in for the VBA editor (32-bit or 64-bit) of Office with Visual Studio .NET.

The strange case of VB6 prompting to repair VS 2010 when MZ-Tools 3.0 is loaded

I have got a new laptop (an Apple MacBook Air 11″) and after installing BootCamp, Windows 7, VB6, VS 2005, 2008 and 2010, yesterday I noticed that when loading MZ-Tools 3.0 for VB6, it prompted to repair Visual Studio 2010. I had received the same or similar issue from 2 or 3 users these last years that I never knew how to solve, so I could only recommend to repair or reinstall Office, VB6 ,etc. Today I have investigated more and it seems that there are multiple causes but one of them documented by Heath Stewart was certainly my case:

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

That is, if there was an external drive connected when you installed Visual Studio, you get the issue when you load some Office application, or some application using VB/VBA. Of course this issue doesn’t happen if you install from the DVD, because the drive (typically D:) will be there always, but it happens if you have an external drive connected, specially if that is the drive where you are installing from!. It happened that other times I copied the setups to the internal hard drive before installing Visual Studio, but since the MacBook Air has only 128 GB of internal hard drive, I installed from an external drive.

That said, the workaround proposed in the post didn’t work for me. I guess that using the variable %ProgramFiles% on my Windows 7 64-bit rather than %ProgramFiles(x86)% didn’t help. Anyway, I got it so messed that finally I had to uninstall completely VS 2005, 2008 and 2010, which is a horrible experience because you have to uninstall lots and lots of separate setups (Visual Studio is by far the worst product regarding uninstallation). Then I started again the installations, but this time copying the media to the internal hard disk (it is a good thing to have USB 3.0 technology). And now I have 27 updates to install from Windows Update, but the issue is solved.

I hope this help others, and myself in the future 😉

The strange case of “Error 1606: Could not access network location VS Developers” installing SP1 of Visual Studio .NET 2003

At the time of this writing there are three Visual Studio versions out there (VS 2005, 2008 and 2010) that support .NET Framework 2.0 and with an extensibility model that allows you to create a single binary add-in dll to target all of them (see HOWTO: Create an add-in that targets several Visual Studio versions with the same add-in DLL using C# or VB.NET). So I wouldn’t support Visual Studio .NET 2003 in a new add-in created today, but my old MZ-Tools 6.0 add-in still supports Visual Studio .NET 2003. On the other hand, the current OS today is Windows 7 64-bit, and, alas, VS.NET 2003 is not supported by Microsoft in that Windows version. Not being supported doesn’t mean that it doesn’t work, specially if you want it only to test an add-in, not for actual development of projects, so I have it installed on Windows 7 64-bit despite all compatibility issues warnings during installation.

Yesterday I wanted to install SP1 of VS.NET 2003, that I noticed that I hadn’t installed, so executed the VS7.1sp1-KB918007-X86.exe setup just by double-clicking it. I got a warning about a security of files from Internet but I authorized its execution. At some point of the installation, I got this error:

“Error 1606: Could not access network location VS Developers (could not create group)”

This problem is caused if you have the User Account Control (UAC) feature of Windows Vista or Windows 7 activated. It happens that this setup was created before Windows Vista and therefore it is not UAC-compliant (it lacks a manifest). So, how does Windows Vista / 7 know if this executable requires admin rights? Windows Vista / 7 knows that most executables that are setups require admin rights, so when the UAC manisfest is missing, it applies some heuristic rules to guess if an executable is a setup or installer. In this case all rules failed, including the most usual one (the name includes the “setup” word) and UAC determined that VS7.1sp1-KB918007-X86.exe was not a setup and didn’t require admin rights, which caused the error above at some point.

Of course the solution is to install VS7.1sp1-KB918007-X86.exe by right-clicking it and selecting the “Run as administrator” menu entry.

Another solution is to rename the setup file name to include the “setup” word, for example VS7.1sp1-KB918007-X86Setup.exe, so that UAC guesses that it is a setup and it prompts for admin consent or admin credentials to elevate privileges.