SPTraceView

Download: Latest version 0.9.7.1, released on 19 June 2008 is available for download here.

SPTraceView is a utility targeted mainly for people that develop and/or test custom SharePoint applications. It could be also useful to administrators to diagnose and troubleshoot their MOSS farm. It analyses in real time the ULS trace messages coming from all MOSS components and can notify you using a balloon-style tray bar messages when something happens.

SPTraceView could be used for example to identify whether web parts, web controls, workflows, event receivers, feature receivers and all other custom and out of the box components work correctly. For example if an SPSite or an SPWeb object is not disposed correctly, SPTraceView will show the SharePoint diagnostic message shown.

As soon as you run it, SPTraceView will start receiving all messages from MOSS and will start checking if any of them match filters defined by you. The default filter matches all messages which severity level is: Critical Event, Unexpected, Exception, Warning Event, Assert or Unassigned. You can configure your settings by choosing “Configure” from the context menu. The configuration form will show up and you will be able to choose the monitored levels and what you want SPTraceView to do when any of the messages match your filter. You can also quickly enable or disable the tracing by using the “Enabled” / “Disabled” menu items from the context menu. This may be handy if you only want to enable it when you are doing specific tests or when you want to disable it when there are too many messages flying around at certain times.

At the moment when a traced message is found to match your flter you can choose between: (i) showing a balloon in the tray bar, (ii) saving the traced message in the SPTraceView’s own log file and (iii) further tracing the message using the .NET System.Diagnostics.Trace class, which can be captured and be shown in a program like Mark Russinovich’s excellent Debug View.

The log file is an XML file that is saved in the same directory where SPTraceView was started from and contains all information from the ULS message.  The log file is displayed in SPTraceView using an XSLT transformation that by default formats it to the following HTML.

The XSLT file is called SPTraceView.xslt and resides in the same directory as the log file. It can be modified to produce a different formatting of the log entries if desired.

Configuring more advanced filters

SPTraceView allows more complex include/exclude filters to be configured from the form below, which is shown by the “More Settings” button. In all of the input boxes, except the process filter, you can use a wildcard. In all places you can provide multiple match strings separated by a semicolon. 

You can narrow down the traced messages by either specifying what to include in the Include filter or what to exclude in the Exclude filter. The single asterisk “*” matches all items and a blank string doesn’t match anything. You could also specify both the Include and the Exclude filters for an item and in this case the Include filter will be applied first to determine whether the message should be included and after that the Exclude Filter will be applied (only if the message has matched the Include filter) to determine whether it actually has to be excluded. So remember that the Include filter is applied before the Exclude filter.

How to use it in a multi-server farm

If you want to intercept the trace messages from more than one server in your farm you will need to have SPTraceView running in each of the servers you want to monitor. The Farm Settings form is used to configure how SPTraceView should act in a farm. The default option is a “Local Machine Viewer” (also called “Stand Alone Viewer”). In this mode SPTraceView will only capture and process the trace messages on the local machine. This is probably what most developers need when they develop in a single server farm or virtual machine.

To configure an instance of SPTraceView to send the traced messages to other SPTraceView clients you should use the “Farm Trace Provider” mode. You will typically configure in this mode the instances of SPTraceView running in all servers in your farm but one. This will be the server where you will be monitoring all the traced messages from the other servers. On this machine you will need to configure SPTraceView to run as “Farm Trace Receiver”.

It is important to know that the filters will be applied locally and only if a trace message matches the local filter it will be transmitted to other SPTraceView clients. So make sure you have the same filter settings in all servers.

Advanced settings are available if you click the “Advanced” button

SPTraceView instances are using the UDP protocol to communicate between each other and the advanced settings form allows you to configure the communication settings. There are two modes of communicating: by using a multicast or a broadcast. If you are not sure what the difference is then use Multicast. To be able to communicate all running SPTraceView instances will have to use the same transport method: multicast or broadcast and must use the same port as well. By default SPTraceView is using port 12361. If you need to change it to a different port, then create a new DWORD registry value called Port under HKEY_CURRENT_USER -> Software -> SharePointInternals -> SPTraceView and specify your custom port number. The multicast IP address cannot be changed and is always 232.153.23.255. Don’t worry it will work for your network as this is an IP address in the special multicast range.

On the advanced form you can also configure the GUID of the farm which messages you want to intercept and view. This could be useful if you have more than one farm installed in the network or if you are running the SPTraceView Trace Receiver on a Vista or Windows XP machine.

Getting updates

SPTraceView has an automatic update functionality which is available if you are running it with account that is a local administrator. At the moment this type of account is actually required to be able to intercept the SharePoint ULS trace log messages. SPTraceView checks for a new version when it is started using port 80 HTTP.

Other similar tools currently available

Some people may ask “Why another tool that handles the SharePoint logs?“. There are indeed other tools out there (see the list below) that provide similar functionality but they are either not working in real time or are too heavy or don’t provide good filtering and alerting functionality or are not fully implemented. If you need more than what SPTraceView provides or something different, then you may want to have a look at some of these tools:

Name: SpsDev.Com ULS Log Reader

Type: Free

Url: http://browse.epmscentral.com/ulsreader

Size: 644 Kb zipped

A tool to read the existing log files on a single machine. You point to where the log files are saved and it loads the log entries in a data grid and allows you to filter and search. It doesn’t work in real time but it looks fast and is small.

Name: SharePoint Log Viewer

Type: Open Source

Url: http://browse.epmscentral.com/SPLogViewer

Size: 10 Kb zipped

The project description is: “Read and filter SharePoint log data from log files”. A very light weight and simple tool that allows you to open one log file at a time from the local machine and displays it in a data grid view. Supports message filtering.

Name: SharePoint Logging Spy

Type: Open Source

Url: http://browse.epmscentral.com/sharepointloggingspy

Size: 22,944 Kb setup kit

According to its documentation: “A MOSS 2007 utility to allow real time diagnostics of multiple servers in a sharepoint farm using a single console view”. However only the Windows event log functionality seems to be working in real time and not the ULS trace. Also the multiple servers log files are accessed via network shares. It’s very heavy weight, not fully implemented and the SharePoint log files are opened directly as files so they will not include all trace events. The SharePointLoggingSpy however gives you other diagnostic settings to monitor, not just the SharePoint log files so you may still find it useful.