Posts Tagged ‘ULS’

SP 2010: Developing for performance Part 4 – Logging

January 17th, 2011 by Tobias Zimmergren

Author: Tobias Zimmergren | | @zimmergren


SharePoint 2010 developing for performance article series:
In this series of articles I will briefly introduce you to some key concepts when it comes to developing for performance in our SharePoint 2010 applications.

Related articles in this article series

Part 1 – SP 2010: Developing for performance Part 1 – Developer Dashboard
Part 2 – SP 2010: Developing for performance Part 2 – SPMonitoredScope
Part 3 – SP 2010: Developing for performance Part 3 – Caching in SharePoint 2010
Part 4 – SP 2010: Developing for performance Part 4 – Logging
Part 5 – SP 2010: Developing for performance Part 5 – Disposal patterns and tools
Part 6 – SP 2010: Developing for performance Part 6 – CSS Sprites
Part 7 – SP 2010: Developing for performance Part 7 – Crunching those scripts
Part 8 – SP 2010: Developing for performance Part 8 – Control that ViewState

Part 4 (this article):
In SharePoint 2010 (well, 2007 too for that matter) you need to think about proper logging in your applications to ensure that any problems, issues or other events are lifted to the ULS Logs (Unified Logging System) – that way the administrators can easily view the logs and track down problems with your applications. In this article I will talk a bit about how you can utilize the logging capabilities in SharePoint 2010.

ULS Logs

The ULS Logs are the main place for SharePoint to output it’s diagnostics information. We will take a quick look at how we can read the logs and obviously how we can write custom logging messages to the logs.

Reading the ULS Logs in SharePoint 2010

In order to read the ULS Logs you’ll need access to the SharePointRoot (14LOGS) folder. But to make the life even easier for us Microsoft released a tool called the ULS Viewer which you can download here:

With this tool you can quite easily read through the logs in SharePoint 2010 without any issues.

There’s plenty of resources on the web about how to use the ULS Viewer, so go take a look at any one of them for some usage-instructions.

Download (docx): ULS Viewer documentation

Writing to the ULS Logs from you SharePoint 2010 application

The other side of the logs are of course writing to the logs. This is not a very hard task to do in SharePoint 2010, and I’ll outline the basic steps to do so here.

Normally I create a new class or at least a method to take care of the logging, and it can look like this:

public static void WriteTrace(Exception ex)
    SPDiagnosticsService diagSvc = SPDiagnosticsService.Local;
        new SPDiagnosticsCategory("TOZIT Exception",
        "An exception occurred: {0}",
        new object[] {ex});

You can use the aforementioned code by calling the method like so:

    throw new Exception("Oh no, application malfunctioned! UnAwesomeness!!!");
catch(Exception ex)

It’s not very hard at all – once you’ve done that, you’re all set to kick off your custom applications and just call your custom logging method. Obviously you should create a proper logging class to take care of all your logging in your applications.


Using the ULS Viewer you can easily track down the error messages by filtering on your category (in my case it’s TOZIT Exception)



Event Logs

Even though the ULS Logs takes care of most of the diagnostics logging today, it might be reasonable to output information into the Event Logs sometime.

Writing to the Event Logs from you SharePoint 2010 application

Just as when you’re doing ULS Logging, you can do logging to the Event Logs. It’s just as simple, but you replace the method "WriteTrace" with "WriteEvent" like this:

public static void WriteEvent(Exception ex)
    SPDiagnosticsService diagSvc = SPDiagnosticsService.Local;
        new SPDiagnosticsCategory("TOZIT Exception",
        "Exception occured {0}", new object[] {ex});


You can view the logs in the Event Logs on your SharePoint server as you would read any other logs.


Can I do more?

There’s plenty of cool things to do with the logging mechanism in SharePoint 2010, so you should definitively get your hands dirty playing around with it.

If you for example want to tag the log entries with your company name, clients name or project name – you can easily change that behavior as well. Take a look at my friend Waldek’s post about it here:

Related resources


As a part of the article series focusing on some general guidelines for performance in your applications, logging is a major player. If you master your logs in terms of monitoring and custom application logging you will quickly come to realize how valuable it is.

This is intended as a starting point for you to get familiar with the logging-capabilities in SharePoint 2010.

Author: Tobias Zimmergren | | @zimmergren


In SharePoint 2010, you’ve got some new capabilities for error reporting and logs. One of the most noted features for me as a developer is that whenever you bump into an error message – you’ll be presented with a correlation ID token.

In this article I will try to explain how you can fetch that token from SharePoint, and also provide a small snippet of code to be able to build your own “Log Searcher Web Part” for your administrators.

Correlation ID, what’s that?

In SharePoint 2010, you get a Correlation ID (which is a GUID) attached to your logs/error messages when something happens. This ID can then be used to lookup that specific error from the logs.

This Correlation ID is used per request-session in SharePoint 2010, and if you are in the process of requesting some information from SharePoint and bump into some problems along the way – your Correlation ID will be the best starting point for searching for what went wrong along that request!

You might get an error message like this in SharePoint 2010 (don’t worry, if you haven’t seen one like this one yet – just hang in there, sooner or later you will.. Winking smile)


Search for the log messages based on the Correlation ID token

So if you’ve gotten such an error message and want to find out more information about the actual error and don’t have the time to go around poking in the logs and searching – there’s a few methods you can do this rather easily, as described below.

Using PowerShell to lookup a log message based on Correlation ID token

One of the quick-n-awesome ways to do this is to simply hook up a PowerShell console (SharePoint 2010 Management Shell) and then just write the following command (replace the <GUID> with the Correlation Id):

get-splogevent | ?{$_Correlation -eq "<GUID>" }

This will give you the details about your specific error like this in the console:


You might want to be more precise and get more specific details out of your query, then you can try something like this:

get-splogevent | ?{$_.Correlation -eq "<GUID>"} | select Area, Category, Level, EventID, Message | Format-List

This will give you the details about your specific error like this with some juicy details:


Finally if you would want these messages to be put into a text or log file instead, you could just add the classic “> C:Awesome.log” after the command like this:

get-splogevent | ?{$_.Correlation -eq "<GUID>"} | select Area, Category, Level, EventID, Message | Format-List > C:Awesome.log


On MSDN they have an overvoew of using SP-GetLogEvent which I would recommend!

Using SQL queries to find log message based on Correlation ID token

You can utilize the SQL logs database to fetch the specific error message based on Correlation id as well. In your logging DB (usually called WSS_Logging, but can be called something else if you’ve changed it) there is a view called ULSTraceLog which you can query with a simple SQL query and fetch the results.

I’ve created a query to fetch the items from the logging database like this:

 select 	[RowCreatedTime],  [ProcessName],  [Area],  
 		[Category],  EventID,  [Message] 
 from  [WSS_UsageApplication].[dbo].[ULSTraceLog] 
 where  CorrelationId=< pre>'B4BBAC41-27C7-4B3A-AE33-4192B6C1E2C5'

This will render your results in the SQL Query window like this:


This can of course be implemented in a Web Part for your convenience as well (I’ve created a bunch of diag. and logging web parts that I’ve got deployed to Central Admin) that could look like this (this way you don’t need physical access to the ULS logs all the time, but can do a quick lookup from the web part):


Get the current Correlation ID by using code

I got this piece of code from my good friend Wictor’s blog post. Thanks Wictor – this made my Logging-project more satisfying!

With the following code you can fetch the current Correlation Id of a request.

Create a method (in my case called GetCurrentCorrelationToken()) to wrap up the functionality of returning the current token like this:

 public  class  CorrelationId 
     [DllImport ("advapi32.dll")]
     public  static  extern  uint  EventActivityIdControl(uint  controlCode,ref  Guid  activityId);
     public  const  uint  EVENT_ACTIVITY_CTRL_GET_ID = 1;

     public  static  Guid  GetCurrentCorrelationToken()
         Guid  g = Guid .Empty;
         EventActivityIdControl(EVENT_ACTIVITY_CTRL_GET_ID, ref  g);
         return  g;

Then from wherever in your code you can simply call it by using this approach:

 protected  void  Button1_Click(object  sender, EventArgs  e)
     Label1.Text = CorrelationId .GetCurrentCorrelationToken().ToString();

(Normally you might want this in a try/catch statement or something like that)



This article should give you (administrator and developer) an insight in how you easily can track the specific errors your users encounter in their/your application(s). If a user gets an error message in SharePoint 2010, they’ll also see the Correlation ID.

If you can train your users to write down that Correlation ID along with a few simple steps on how the error might have been occurring, you’re going to have a much easier way to find the details about that specific error than ever before.


Author: Tobias Zimmergren | | @zimmergren


If you are a SharePoint developer, you often need to dig into the logs in the 12-hive in order to find out why things are behaving the way they are.

You and me both know that this can be a pain in the buttocks if you don’t have an appropriate tool to read the logs with.
I’ve been trying out around 10 different log viewers, including SharePoint-specific log viewers, in order to save some time reading the logs.

What I found out, was that the tool called SPTraceView that you an find on, is the by far most complete SharePoint logs parsing tool I’ve tried.

Bear in mind though, that there’s plenty of good tools out there – and this is the one that I find to be most suitable for my needs. Your requirements may differ.

Why SPTraceView for me?

The reasons as to why I chose SPTraceView are as follows:

  • Balloon notifications when new events occur (e.g. an exception is thrown and shown in the logs)
  • Filtering
    • Filter based on Monitoring Level
      • Critical Event
      • Unexpected
      • Exception
      • Warning Event
      • Assert
      • Unassigned
      • High
      • Medium
      • Information Event
      • Monitorable
      • Verbose
    • Filter based on Process
    • Filter based on Message
    • Filter based on Product
    • Filter based on Category
  • Big "View Events" button to quickly parse and view the logs, applying all the filters you’ve configured
  • Farm event logging / Cross-server logging
    • You have the option to use SPTraceView across multiple servers in your farm (!)

An example

The plain-text logfiles in SharePoint looks something like this


Viewing the SharePoint ULS logs with SPTraceView

If I make a simple configuration like this:


And if I now click the big "View Events" button (you really can’t miss it!) – it’ll look something like this:


Summary and Download

I urge you to check out this tool if you’re (like me) diving into the logs every now and then, but find it unbearable to read plain-text and don’t find that any of the other tools really fit the blueprint of what you need.

With that said, go to and get it now!