Don’t you love when Visual Studio severely crashes? I really hate those moments because I am always afraid that if it is a problem of VS and not a problem in my code, I am in trouble…

Some time ago I explained The strange case of Visual Studio 2008 severely crashing loading an add-in that was caused by Visual Studio commandbars. Fortunately the cause of this problem and a workaround was known.

I also opened a bug report at Microsoft Connect due to Application of custom attribute crashes VS 2008 (VB) still with SP1 applied. This causes a crash in the VB 2008 compiler. While Microsoft closed the report as “not reproducible” I am glad that they have reopened it recently and they sent me some “dumping” tools to install on my computer and send them back more information to get a clue about the problem since it is not reproducible with a few lines of code. Hopefully this one can be fixed because it is preventing me to migrate to VS 2008.

Yesterday I got a new severe crash while debugging my MZ-Tools add-in. The crash was something like:

Problem signature
Problem Event Name: APPCRASH
Application Name: devenv.exe
…
Fault Module Name: kernel32.dll
Fault Module Version: 6.0.6001.18000
Fault Module Timestamp: 4791a76d
Exception Code: e053534f
Exception Offset: 000442eb

Searching the web I only found a similar issue but it didn’t explain the cause or fix. The line of code crashing in my code was just setting the value of a class field, which seemed quite innocent. On Windows Vista the dialog didn’t offer the chance of sending it to MS but today on a Windows XP machine the dialog allowed me to send the bug report. But more importantly, after more careful debugging I realized that my code was calling the method of a class that called another method, and then other, and then other, and 10 calls later it was calling again the original method, causing an circular dependency that eventually crashed Visual Studio. For example this code reproduces the problem:

public void OnConnection(object application, ext_ConnectMode connectMode, object addInInst, ref Array custom)
{
   switch (connectMode)
   {
      case ext_ConnectMode.ext_cm_Startup:
      case ext_ConnectMode.ext_cm_AfterStartup:
         f1();
         break;
   }
}
void f1()
{
   f2();
}
void f2()
{
   f1();
}

While the fault was in my code (I have already fixed it), I wondered if Visual Studio could show better information, such as an StackOverflowException or OutOfMemoryException or similar  (that would give me a hint about a circular dependency) rather than a crash in the kernel32.dll module. And guess what? I did a test and VS.NET 2003 shows a more friendly message with the StackOverflow exception indicating a too deep recursion. Somehow something was changed in VS 2005 and now Visual Studio behaves much worse crashing completely. So I have opened a bug report at Microsoft Connect (you are invited to vote to get it fixed):

Add-in causing stack overflow causes “Microsoft Visual Studio has encountered a problem and needs to close”
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=414301

It happens that I had seen this very same problem in my code a couple of years ago but I had totally forgotten that such crashes in VS are sometimes produced by circular dependencies of methods in the code. I hope this helps other people (and me) when searching on the web a crash in a VS add-in in
Exception Offset 000442eb of Kernel32.dll.

Tired of the strange case of sporadic COMException 0x800A01A8 calling CommandBarButton.Delete from a Visual Studio add-in, but very annoying, I decided to take a closer look and solve it. First, I noticed that my MZ-Tools add-in only calls CommandBarButton.Delete for buttons that places on VS built-in toolbars. For buttons that places on its own toolbar, I don’t call CommandBarButton.Delete since I will destroy the toolbar anyway and that will remove its buttons (which is also faster). So, if your add-in doesn’t add buttons to built-in toolbars of VS chances are that you’ll never experience this COMException. Alas, my add-in adds buttons to VS built-in toolbars that must be removed. For these, I took the following approach:

• Rather than calling CommandBarButton.Delete when the add-in is unloaded, and I remove the command calling Command.Delete (which also automatically deletes all CommandBarButtons created from that command) and I create it again.
• As you may know, in general add-ins should not delete commands when unloaded because:
  • Command keyboard bindings are lost. To solve this, before deleting the command I get the command keyboard bindings (Command.Bindings) and I restore them when re-creating the command.
  • If the user has created a button from that command on some other toolbar of her choice (see “Addition of a button of the add-in to a toolbar not belonging to it” case in my article HOWTO: Handling buttons and toolbars user customizations from a Visual Studio add-in), that button will be lost when the add-in is unloaded. There is no solution to this case, but I can live with that. Hopefully my users don’t need to create buttons from my add-in on other toolbars (I strive for providing good button/toolbar customization inside the add-in).

I don’t have an answer to this strange case, but after 4+ years getting reports from users, I will write about it just in case someone can post a solution.

When using a temporary user interface (not a permanent one), add-ins typically add CommandBarButtons to commandbars using Command.AddControl when loaded. When the add-in is unloaded, it must remove its buttons calling CommandBarButton.Delete. You can see a sample in the following article of mine: HOWTO: Adding buttons, commandbars and toolbars to Visual Studio .NET from an add-in

The problem is that sometimes you get COMException 0x800A01A8 when calling CommandBarButton.Delete. There are some facts about this problem:

• It happens very sporadically (I have received less than 20 user reports in all these years).
• When I ask the users if the problem is reproducible, they always answer that no, that the add-in unloads fine next time.

So the occurrence is really really tiny and it is not a bug in the code of the add-in since it works fine almost always, but nonetheless I would like to erradicate it.

Searching the Web, it seems that this problem appears more commonly with add-ins for Office, but no forum seems to deal with Visual Studio add-ins or provides an answer.

A couple of years ago I posted in the MSDN Forum:

To Microsoft: Sporadic COM exceptions adding/removing commandbars and buttons from Visual Studio add-ins
http://social.microsoft.com/Forums/en-US/vsx/thread/8fff7d90-7867-4608-a8b6-ba9362d91411/

In that post I exposed three reproducible cases of COM Exceptions, but I mentioned that there were more COM exceptions. Reviewing the user reports in my e-mail system, I think that in fact there is only a non-reproducible COMException 0x800A01A8 and it happens always calling CommandBarButton.Delete.

Craig Skibo (former member of the Visual Studio extensibility team) answered to that post but since I posted 3 reproducible cases and 1 non-reproducible case the discussion was a bit messed and in the part that dealed with CommandBarButton.Delete he argued that buttons created with Command.AddControl shouldn’t be destroyed calling CommandBarButton.Delete, but IMHO he is wrong or his workarounds are not really workarounds.

So, at this point I don’t know it I should ignore that exception because I am not sure if the COM exception is caused because the button is not already there (it would be OK to ignore the exception) or if I would get a duplicated button the next time that the add-in is loaded (in this case I would like to notify the previous exception to know why I am getting a duplicated button).

Anyone is experiencing this problem? You can either post a comment or contact me by e-mail.

Finally, wouldn’t be nice to be able to debug the code of Microsoft.VisualStudio.CommandBars.dll when the exception is thrown? Or better yet, a managed IDE where the menus and toolbars are no longer based on Office COM-based commandbars?

Update (February 3, 2009). See More on the The strange case of sporadic COMException 0x800A01A8 calling CommandBarButton.Delete from a Visual Studio add-in (solved)

(Or why it is a bad idea for an add-in to add add-in file paths to Visual Studio)

When Visual Studio 2005 introduced XML-based add-ins, which used an .AddIn file rather than COM registration), rather than providing just two fixed folders to place such files (one for all users, other for the current user), Microsoft provided five (5!!) folders, listed in the Tools, Options menu, Environment, Add-in/Macros Security section.

Not only that, Visual Studio allows to add more folders using the Add… button or programmatically writing to the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\AutomationOptions\LookInFolders” registry key (VS 2005).

Not only that, you will have a difficult time expanding VS-proprietary placeholders like %VSAPPDATA%, %VSCOMMONAPPDATA% or %VSMYDOCUMENTS%, if your add-in setup wants to use one of those folders.

Not only that, Visual Studio 2008 added a sixth folder, %ALLUSERSDOCUMENTS%\Microsoft\MSEnvShared\Addins.

Not only that, Visual Studio 2008 actually fails to look for XML files in that new folder (see HOWTO: Using the Process Monitor (ProcMon) tool to diagnose Visual Studio add-ins problems)

And not only that (finally), Visual Studio hardcoded “Application Data” in one of the paths (“%ALLUSERSPROFILE%\Application Data\Microsoft\MSEnvShared\Addins”) without taking into account that that folder is localized and in other languages it doesn’t exist with that name on the hard disk. For example, in Spanish, it is should be “%ALLUSERSPROFILE%\Datos de programa\Microsoft\MSEnvShared\AddIns”.

I documented all that in the article INFO: Default .AddIn file locations for Visual Studio add-ins.

Guess what? Yesterday, while writing an utility that scans the add-in file paths, I noticed that on my Spanish computer Visual Studio 2005/2008 listed “%ALLUSERSPROFILE%\Datos de programa\Microsoft\MSEnvShared\AddIns” as one of the add-in file paths in the Tools, Options menu, Environment, Add-in/Macros Security section. Indeed VS 2005 listed 6 folders instead 5, and VS 2008 listed 7 folders instead of 6.

How could that be? At first I thought that the service pack 1 of both IDEs could have “fixed” the problem adding the localized version of that path maintaining the wrong one (with “Application Data” hardcoded). But I quickly discarded that explanation because I had installed SP1 from long time and those folders were not there. Then I remembered that I had installed recently an add-in (I won’t cite its name), and looking into the contents of the “%ALLUSERSPROFILE%\Datos de programa\Microsoft\MSEnvShared\AddIns” folder, there was the .AddIn files of this add-in. So, the setup of this add-in is placing the .AddIn file in that folder, AND it is adding that folder to the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\AutomationOptions\LookInFolders”. In other words, it is trying to “fix” what Microsoft did wrong with that folder. But I think this is a bad idea for this reason: if this add-in is installed on a non-English computer and the user happens to be a developer of add-ins who is unaware of the problem of the hardcoded “Application Data” path, he will see two paths listed:

%ALLUSERSPROFILE%\Application Data\Microsoft\MSEnvShared\Addins
%ALLUSERSPROFILE%\Datos de programa\Microsoft\MSEnvShared\AddIns

And certainly he will use the second one because any non-English developer knows that it is the correct one (using an API call to get the actual localized folder), but when his add-in is installed on another machine, the second path is not in the list of paths that VS scans, and the add-in won’t appear in the Add-In Manager.

Placing the .AddIn file in the first path (%ALLUSERSPROFILE%\Application Data\Microsoft\MSEnvShared\Addins) is also a bad idea because the setup will create that English folder on non-English computers, and then the computers will have those two paths physically on the hard disk.

So, what to do? I’d recommend to use the “%VSCOMMONAPPDATA%\AddIns” folder instead, which is also for all users but it neither mess the list of paths of Visual Studio nor creates English folders on non-English computers. The only drawback is that the folder is actually different each VS version:

For Windows XP:

• VS 2005: “C:\Documents and Settings\All Users\Application Data\Microsoft\VisualStudio\8.0\Addins”

• VS 2008: “C:\Documents and Settings\All Users\Application Data\Microsoft\VisualStudio\9.0\Addins”

For Windows Vista:

• VS 2005: “C:\ProgramData\Microsoft\VisualStudio\8.0\Addins”

• VS 2008: “C:\ProgramData\Microsoft\VisualStudio\9.0\Addins”

To get it programmatically the custom action of your setup that copies the .AddIn file must call the API that returns special folders with the parameter CSIDL_COMMON_APPDATA and then concatenate
“Microsoft\VisualStudio\8.0\Addins” for VS 2005 or “Microsoft\VisualStudio\9.0\Addins” for VS 2008. For example:

• Using the .NET Framework the call is System.Environment.GetFolderPath(System.Environment.SpecialFolder.CommonApplicationData)

• Using the free InnoSetup installer, the PascalScript call is ExpandConstant(‘{commonappdata}’) (see: HOWTO: Create a setup for a Visual Studio 2005 / 2008 add-in using Inno Setup)

• Using the Win32 API, you can use the SHGetFolderLocation, SHGetFolderPath, SHGetSpecialFolderLocation, and SHGetSpecialFolderPath functions.

Being the path different for each VS version you can’t use a single .AddIn file with two hosts inside (HostApplication tags) for VS 2005 and VS 2008, but that’s a minor extra work for the setup of an add-in, and we all know that software is all about our users, not about us the developers…