Hi, my name is Dmitri Leonov and I am an engineer on the VS debugger team. A couple of months ago with the Visual Studio 2012 Update 1, we shipped debugger improvements some of which were related to symbol and source loading as described in our previous blog post: “Debugger Source Symbol Improvements to Visual Studio 2012”.

In this blog post I would like to take a little closer look at the performance and usability improvements around symbol loading in Visual Studio.

Cancellable symbol load

Symbol loading is truly cancellable now. This is especially useful when a valid symbol path becomes unreachable unexpectedly. Previously this could result in Visual Studio becoming unresponsive – a sometimes frustrating issue, now fixed by these improvements.

Even when the source path is reachable but slow, when you click cancel the download would cancel immediately and the rest of the PDB files would not be downloaded.


 

The Modules window will indicate that symbol load has been cancelled:

 

Recording misses

When a particular symbol file is not found in the given symbol path, that path will not be searched again for that file during the same VS session to improve performance. The Symbol Load Information dialog (accessible through the context menu of the Modules window) indicates the reason why the symbol file was not loaded:

 

If symbols at that path have been updated, you can override this behavior if you restart Visual Studio.

Additional improvements

  • Caching of symbols downloaded from network share (previously caching was done only for symbol servers)
  • Cache limit to 5 versions for a PDB for network share
  • Better handling for invalid cache path. For example if the cache folder you specify cannot be created you will know about the problem:

Summary

Visual Studio Update 1 includes debugger improvements around performance and usability when it comes to symbol loading. Most notably, symbol loading is cancellable, misses are recorded for the given VS session, and caching is done in a smarter way. These improvements were a result of your feedback, so please keep it coming. I would love to read your comments below, and for general debugger questions please use Diagnostics MSDN forum.