Related: "Microsoft's Visual Studio 2012 Update 2 Now Available for Download"
I frequently marvel at how amazing Visual Studio is given its enormous size and mass. Not only does it take up a few GBs of disk space, but it's also an application that can treat complex applications like browsers as if they were a combination of a modal window and a chew toy -- to the point where it can easily tap into them and do all sorts of complex debugging tasks. With something as complex as Visual Studio, it only stands to reason that something's going to break every once in a while -- where I'd expect debugging problems with Visual Studio to be a massive nightmare on its own. Interestingly enough, I recently bumped into a couple of experiences that made me realize that Visual Studio actually has some cool tooling and instrumentation that can make debugging problems with this ginormous IDE much easier.
The Dreaded "Microsoft Visual Studio is Busy" Dialog
Although the specifics aren't too important, I recently ran into an issue editing ASP.NET MVC 3 views after downloading Visual Studio 2012 Update 2. Not only did I notice that these views didn't have any syntax highlighting, but I also realized that anytime I'd mouse into some of the code in my view, I could feel or sense Visual Studio becoming non-responsive. I quickly spotted a notification on the bottom-left side of the IDE informing me that Visual Studio was "waiting for a background operation to complete…," which would last for a second or so until I got a full-blown pop-up window telling me the same only to culminate in waiting for roughly a minute or so while watching the dreaded toast of death in my system tray telling me that "Microsoft Visual Studio is Busy."
As a true test of genius, in the sense that the hallmark of stupidity is attempting the same thing over and over to expect different results, I kept banging my head against this problem two or three times before I decided it was time to start killing some plug-ins or looking at some other options. So I removed a couple of plug-ins that I haven't really used in a while and rebooted my computer -- figuring that'd surely fix the problem.
Unfortunately, that didn't work. But I did manage to somehow make Visual Studio cranky enough after all of this (when I deleted some text in one of my Razor sections) to get it to throw a full-blown exception. At this point, Visual Studio told me that something ugly had happened and that it had dropped debug info into something called the Activity Log, see Figure 1.
Sweet Stuff Abounds: The Visual Studio Activity Log
By navigating out to the path specified in Figure 1, I was able to quickly spot that Visual Studio was running into an ugly exception when trying to parse some of the Razor syntax in my view. That, in turn, led me to StackOverflow -- where some sanity finally made its way into the picture since it's always nice to have the exact bug you're experiencing corroborated by someone else out in the interwebs. From there I was able to send a bug report to Microsoft via the ASP.NET team and a simple workaround that involved putting spaces between my curly brackets and that single snippet of text in the BodyClass listed in Figure 1.
Although it was nice quickly find a workaround for this bug, which is solely a problem with Visual Studio -- as ASP.NET has no problems rendering at all, there's no way I would have been able to do so without this cool new instrumentation and functionality in Visual Studio 2012. That, in turn, made me a bit curious about what else I might have been missing in regards to the Activity Log.
But Wait! There's More!
After doing a bit of digging online, I quickly found a blog post indicating that the Activity Log has been around since Visual Studio 2010. In this version, you have to explicitly enable it through a switch passed into the devenv executable itself. I also found documentation for Visual Studio 2012 that stated that the Activity Log keeps a rolling buffer of the last 100 entries, which correlates perfectly with what I'd seen in my own experience and was a huge win in my case.
Curious to see what would happen if I explicitly kicked off Visual Studio 2012 with the /log switch enabled, I was happy to find my ActivityLog.xml file visibly and massively bloated-up in a matter of seconds -- to the point where it had over 900 entries in just two or three minutes. In other words, if you want or need more complex and long-term output from the Activity Log, then it's easy to enable explicitly -- otherwise you'll just get a buffered copy of the last 100 entries. At this point I also noticed a corresponding .xslt file – which means that while you can open the Activity Log up in Notepad, you'll get an easier version of its contents if you open the file in a browser.
It would be ideal if whatever logic or process within Visual Studio that detects long running or stalled threads would spit out information on which bit of code that thread last touched. However, I'm guessing that setting that up isn't exactly trivial. Still, such a feature would be great to have in terms of helping to troubleshoot similar situations where exceptions aren't thrown in the end (as was the case in my particular situation). Until then, the Activity Log remains a very cool feature of Visual Studio especially since it keeps tabs on oodles of startup and environmental information that helps explain why Visual Studio can take so long to load.
