Troubleshooting Extensions with the Activity Log
One of the most powerful tools for troubleshooting issues that involve Visual Studio extensions is often overlooked, even though it has been around for quite some time (since VS 2005). Anyone wondering what Visual Studio is doing with their VS Package, Extension, MEF Component, or pkgdef file should ask the IDE for an activity log. In this article, I will show you not only how to generate an activity log file for Visual Studio, but also highlight some of the things you can find in it.
It’s important to note that this applies not only to the Visual Studio 2010 IDE, but also to applications built using the Visual Studio 2010 Shell (Isolated) (or Integrated). All of the examples will assume the case of Visual Studio running under 32-bit Windows 7. For other cases, substitute the appropriate file locations and names and registry root key.
Creating the Activity Log
This is as easy as it sounds. Here is the magic incantation required to generate a visual studio activity log file:
In this case, I’ve started a command prompt and navigated to the folder where the Visual Studio executable is installed before typing “devenv /log”.
The same command could also be given:
- from the Visual Studio Command Prompt (2010)
- using the full path to the executable (“C:Program FilesMicrosoft Visual Studio 10.0Common7IDEdevenv.exe“) from either a command prompt under Start – Accessories or in the Start – Run dialog
- on Windows 7, just by hitting the Windows key and typing “devenv /log” in the search box.
Finding the Activity Log
If “/log” is specified without adding an output path, the file is written to
%APPDATA% resolves to “C:UsersuserAppDataRoaming”
In previous releases of Visual Studio, there was a required parameter to /log that specified the full path for the output file. In VS 2010, this path is optional. You might find it useful to direct the log file to an easier to find location, such as the desktop:
devenv /log c:usersuserdesktopactivitylog.xml
Reading the Activity Log
Once you have reached the point in Visual Studio that you are trying to troubleshoot, it’s a good idea to close Visual Studio. Otherwise, it will continue to write to the log while you are trying to read it.
Notice that the log file is generated as XML. When Visual Studio starts writing the log, it also writes a corresponding XSL file next to the XML file that makes it easy to read in Internet Explorer. Go ahead and browse to the file’s location and double-click on it.
At the top of the file is a summary of how many lines of “infos” (sic), “warnings”, and “errors” are listed. Below that are the actual log items, which have up to 7 columns of information.
|#||sequential item number|
|Type||blank for information, “Warning” (highlighted in yellow), or “Error” (highlighted in red)|
|Description||the activity, which may optionally include a registry or file path|
|GUID||associated GUID, typically for a VS Package|
|Hr||HRESULT value that may be useful for troubleshooting|
|Source||module writing the log item|
|Time (UTC)||timestamp for the item in UTC (not local) time|
Activity Log Items
The activity log is full of more information than can adequately be addressed in any detail by a single blog post. However, several activities are worth noting:
- Version of Visual Studio and .NET Framework
- Configuration and state information about the pkgdef cache
- If the pkgdef cache is found to be out-of-date, each discovered pkgdef file is listed, as it is parsed and loaded
- Each VS Package that is loaded, including success and failure
- Each VS Extensions loaded through the Extension Manager and whether it is enabled
- Each MEF Component loaded and whether it came from the cache
- Each category exported by the Profile manager
Those are the basics for creating, finding, and reading the Visual Studio Activity Log. Hopefully, this will give you a powerful tool for troubleshooting issues with VS Packages, VS Extensions, MEF Components, and pkgdef files. Try running Visual Studio with /log and see what useful insights you gain into what Visual Studio is doing.
Bill is a relative newcomer to Microsoft, but has many years of software industry experience working on IDEs and vertical applications. For Visual Studio 2010, he was a key contributor to PkgDef Management.