Diagnosing Problems (updated for the GDR)

NOTE: This article has been updated to apply to the latest Visual Studio 2008 Team System Database Edition GDR and GDR R2 releases.

How to diagnose problems in the Visual Studio 2008 Team System Database Edition GDR (and GDR R2) release is the subject for this blog post. When the product does not behave as expected we might ask you to create a trace of the activity that you are performing and send us the resulting log file.

VSDB ships with build-in tracing functionality. We ship a Registry file (.reg) which contains the settings needed to enable tracing. The "tracing.reg" file is located in the "%ProgramFiles%\Microsoft Visual Studio 9.0\VSTSDB" and contains the Registry values that you need to set in order to enable tracing.


    1:  Windows Registry Editor Version 5.00
    3:  [HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\9.0\VSTSDB\Tracing]
    4:  "LogDir"="%USERPROFILE%\\Application Data\\Microsoft\\VisualStudio\\9.0\\VSTSDB\\Trace"
    5:  "PrefixTime"=dword:00000001
    6:  "PrefixPid"=dword:00000001
    7:  "PrefixThreadId"=dword:00000001
    8:  "TraceSwitch"=dword:00000000
    9:  "TraceToLogFile"=dword:00000000
   10:  "TraceToDebugOutput"=dword:00000001
   11:  "DisplayCallStack"=dword:00000000
   12:  "UniqueLogFile"=dword:00000001
   13:  "EventIdsToTrace"=dword:0001ffff

In most cases all you have to to is change the TraceToLogFile value to 1 and restart the Visual Studio IDE. If you double click on the tracing.reg file or when you execute it through the command line, the file will be opened by the Registry Editor, since the .reg file extension is associate with the regedit.exe "%1".

    1:  c:\>assoc .reg
    2:  .reg=regfile
    4:  c:\>ftype regfile
    5:  regfile=regedit.exe "%1"

NOTE: Be aware the tracing settings are user specific and therefore stored in the HKEY_CURRENT_USER hive in the Registry. So when tracing the activities performed by a service account like Team Build, you need to make sure to enable tracing for the correct user!

Understanding the Registry settings:


LogDir is the place where output of the trace will be created and saved. Make sure that the user has the appropriate rights in the specified location to create files. The LogDir location definition can contain environment variables as part of the string.


Prefix the log message with the time the event was raised.

[Pid=6544;Tid=1;Time=12:19:13]: Verbose: 1: TraceToDebugOutput=True


Prefix the log message with the process ID of the process that raised the event. In our case that is always DEVENV.EXE.

[Pid=6544;Tid=1;Time=12:19:13]: Verbose: 1: TraceToDebugOutput=True


Prefix the log message with the thread ID which raised the event.

[Pid=6544;Tid=1;Time=12:19:13]: Verbose: 1: TraceToDebugOutput=True


This is the trace filter which is being used and can have a value between [0-4].

0 - Off

1 - Trace only error level events

2 - Trace warning and error level events

3 - Trace informational, warning and error level events

4 - Verbose level tracing (includes all other categories)


This entry contains a fully qualified file path to the directory where the log file will be stored.

Default location is "%USERPROFILE%\\Application Data\\Microsoft\\VisualStudio\\9.0\\DBPro\\Trace".


This option has been removed from the GDR release.


This option will send the events to the debug monitor channel and can be displayed using tools like DebugView from SysInternals. Be aware these monitors pick up all events send to OutputDebugString and related functions, so you will receive much more noise, but the good side is that it is very lightweight and instantaneous.


Include the callstack as part of the event. This option should only be used when you are hunting for more detailed information like tracing a crash. This option adds significant overhead and make the log file growth much faster.


If setting is true (1), every session of the Visual Studio IDE will create a new log file, but only if TraceToLogFile value is set to 1 (true). The name of the log file is determined by the underlying tracing algorithm, for example: devenv_10_15_2007_10_15_45.log. If the UniqueLogFile value is 0 (false), the same file will be used by the tracing infrastructure, and the trace output is appended to the previously existing file, for example: devenv.log.  If for some reason, the file is locked and is unusable, or non writable, a new file is created, the new file name will be prefixed which a GUID, for example: 5c764ce2-c319-4ab3-a8b0-799869c1c6a0devenv.log


This is a bitmap that represents a filter to restrict which events get traced.

Sample output:

Sample trace output taken from a trace log file:

[Pid=6544;Tid=1;Time=12:19:13]: Verbose: 1: TraceToDebugOutput=True

[Pid=6544;Tid=1;Time=12:19:13]: Verbose: 1: TraceToLogFile=True

[Pid=6544;Tid=1;Time=12:19:13]: Verbose: 1: TraceToEventLog=False

[Pid=6544;Tid=1;Time=12:19:13]: Verbose: 1: LogDir=C:\Users\gertd\AppData\Roaming\Microsoft\VisualStudio\9.0\DBPro\Trace

[Pid=6544;Tid=1;Time=12:19:13]: Verbose: 1: TraceSwitch=Verbose

[Pid=6544;Tid=1;Time=12:19:13]: Verbose: 1: UniqueLogFile=True

[Pid=6544;Tid=1;Time=12:19:13]: Verbose: 1: DisplayCallStack=False

[Pid=6544;Tid=1;Time=12:19:13]: Information: 64: RegistryManager.DatabaseLockTimeout: 30 seconds.

[Pid=6544;Tid=1;Time=12:19:13]: Information: 64: RegistryManager.DatabaseQueryTimeout: 60 seconds.

[Pid=6544;Tid=1;Time=12:19:13]: Information: 64: RegistryManager.DatabaseLongRunningQueryTimeout: 0 seconds.

This concludes this first blog post on diagnosing problems.