Almost two weeks ago something strange started to happen on my laptop: the next version of MZ-Tools that I am working on was taking almost 10 seconds to load, while usually loads in 1 or 2 seconds. Since I was working on some other complex tasks (unit testing of add-ins, satellite DLL for custom pictures in international versions of Visual Studio, etc.), I didn’t devote time to troubleshoot this but as days passed finally three days ago I started to investigate.

At first I thought it was caused by some changes in the source code, such as handling the AppDomain.AssemblyResolve event to return the satellite DLL assembly, a required technique in international versions of Visual Studio (as I will blog about in a few days). But this was not the problem.

An intriguing thing was that the problem didn’t reproduce on another two computers of mine, nor on another partition of the same laptop with Windows 7 64-bit instead of Windows 7 32-bit. I created another user account on the partition where the problem reproduced and it happened too. So, it was not something user-specific but something machine-specific to the main partition and OS of my laptop (I was glad that this was the case and not a problem of the add-in).

I isolated the problem to the point where I measured that a single DTE.CommandBars.Add call to add a toolbar was taking 2 seconds (no surprise then that the whole add-in was taking 10 seconds). So I thought it could be some problem with the multiple products that install .NET / Visual Studio components, such as the own Visual Studio versions, their service packs, their security updates, but also Microsoft SQL Server (which installs .NET stuff) and Microsoft Office (which installs Visual Studio Tools for Applications). All that complicated with the fact that to do tests with international versions of Visual Studio I had both the English and Spanish versions installed.

So, I started to uninstall products, testing the load time after each uninstallation: the security packs, the service packs, SQL Server, Office, etc. etc. I even uninstalled the whole Visual Studio versions and reinstalled just one, to no avail: the add-in took still 2 seconds just to create a toolbar.

When I was resigned to format the partition and start from scratch hoping that that would solve the problem and maybe reinstalling products I could find the culprit, I did one last thing: to use Process Monitor to diagnose the problem. And I noticed a lot of disk access to the C:\Users\Carlos\AppData\Local\Microsoft\Windows\Temporary Internet Files location such as:

?FusionBindError!Category=NativeImage!exe=devenv.exe!name=EnvDTE80, Version=8.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a

And when I saw the “FusionBind” term I remembered: a couple of weeks ago I needed to use the Assembly Bind Log Viewer (fuslogvw.exe) to diagnose the problems locating the satellite dll assembly in international versions of Visual Studio. I opened that tool and bingo! the trace was activated. As soon as I deactivated (note: you need to launch it with admin rights) the problem was solved. Somehow I forgot some day to turn it off.

Now I have a lot of products to reinstall, but I am happy that I didn’t have to reformat…  🙂