Troubleshooting SharePoint 2010 : Tools & Techniques

Troubleshooting is needed to develop and maintain complex systems where the symptoms of a problem can have many possible causes. One such complex system is SharePoint 2010.

Troubleshooting SharePoint requires logical, systematic search for the source of a problem so that it can be solved, and so the SharePoint Farm or Solution can be made operational again. If you are experiencing problems with a SharePoint farm or  solution, you can use below tools and techniques to find the root cause and fix it.

1. Enable Debugging in Web.config.

You can make below changes in web.config of your web application to see the actual exceptionserrors on the page itself . If you want to debug application pages you may need to the changes in web.config at 14TEMPLATELAYOUTS also.

  • Turn on the call stack (CallStack=”true”)
  • Disable custom errors in Visual Studio (<customErrors mode=”Off” />)
  • Enable compilation debugging (<compilation debug=”true”>)

The resulting web.config looks like :

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<configuration>
...
<SharePoint>
<SafeMode MaxControls="200"
CallStack="true"
DirectFileDependencies="10"
TotalFileDependencies="50"
AllowPageLevelTrace="false">
...
</SafeMode>
...
</SharePoint>
<system.web>
...
<customErrors mode="Off" />
...
<compilation debug="true">
...
</compilation>
...
</system.web>
...
</configuration>

2. Visual studio F5 Debugging

It is the most common form of debugging used by developers. Just set a break point in the code and attach to the worker process(w3wp) for your web application.If you have too many web application you can run below command (in command prompt) to find the w3wp Process ID.

%windir%system32inetsrvappcmd.exe list wp

If you want to see the exact set of steps to do Visual Studio debugging, check here

[Note:  To debug Timer jobs and waiting Workflows you need to attach to OWSTIMER process instead on w3wp]

3. Trace(ULS) Logs

 Trace Logs are text files and can be opened with any tool that works with .txt file. The default location of trace logs is  in the LOGS directory of the SharePoint root (also called the 14 Hive) at C:Program FilesCommon FilesMicrosoft SharedWeb Server Extensions14 . The naming format for the trace log files is machinename-YYYYMMDD-HHMM.log, in 24-hour time.

[ Note : By default, a new log file is created every 30 minutes. You can change it using  PowerShell with the Set-SPDiagosticConfig command. For example, to set for every two hours use :  Set-SPDiagnosticConfig Set-SPDiagnosticConfig -LogCutInterval 180]

Trace logs can give you important information to debug a particular issue. The trace logs have the following columns:

  • Timestamp — Date and time of the event
  •  Process — Process that generated the log entry
  •  TID — Thread ID
  •  Area — Area of the event
  •  Category — The category of the Area of the event
  •  Message — Actual error message
  •  Correlation — The correlation ID

Correlation ID

The correlation ID is a globally unique identifier GUID that is assigned to each conversation a user or process has with SharePoint. When an error occurs, an administrator can use the correlation ID to track down all of the events in the trace logs that pertain to the conversation where the problem occurred.

Correlation ID

An error with Correlation ID displayed to user

Every erroreventinformation recorded in the trace logs has a correlation ID. You can open trace log in Notepad or ULS Viewer and search for the Correlation ID. Then you can find the actual problem related to the error.

The correlation IDs can be used to find error details in the trace logs, Windows Event Logs and even the SQL trace. The correlation ID is considered by many administrators to be one of the best new features in SharePoint 2010.

You can also View and filter log events by using Windows PowerShell using Get-SPLogEvent

4. Event Throttling

In SharePoint 2010, You can choose to monitor specifically events which you think are the problem areas. Go to Central Administration>Monitoring>Reporting>Configure diagnostic logging to viewchange the settings.

Using Event Throttling settings you can also control the severity of events captured in the Windows event log and the trace logs. As the severity decreases, the number of events logged will increase.

Also, you have option to ” Restore to default” settings once you are done with troubleshoot. Any event category which is selected appears bold. For example, If BCS is selected to diagnose, below is how it appears when you view the screen second time.

Event Throttling

Event Throttling Screen

[Note : Use the Verbose setting only when needed. For Verbose-level events,  the system will log every action that SharePoint  takes. Verbose-level logging can quickly use drive space and affect drive and server performance. You can use verbose-level logging to record a greater level of detail when you are making critical changes and then re-configure logging to record only higher-level events after you make the change]

Options for Event log

Level Definition
None No logging occurs.
Critical This message type indicates a serious error that has caused a major failure in the solution.
Error This message type indicates an urgent condition. All error events should be investigated.
Warning This message type indicates a potential problem or issue that might require attention. Warning messages should be reviewed and tracked for patterns over time.
Information Information messages do not require any action, but they can provide valuable data for monitoring the state of your solution.
Verbose This event log level corresponds to lengthy events or messages.

Options for Trace log

Level Definition
None No trace logs are written.
Unexpected This level is used to log messages about events that cause solutions to stop processing. When set to log at this level, the log will only include events at this level.
Monitorable This level is used to log messages about any unrecoverable events that limit the solution’s functionality but do not stop the application. When set to log at this level, the log will also include critical errors (Unexpected level).
High This level is used to log any events that are unexpected but which do not stall the processing of a solution. When set to log at this level, the log will include warnings, errors (Monitorable level) and critical errors (Unexpected level).
Medium When set to this level, the trace log includes everything except Verbose messages. This level is used to log all high-level information about operations that were performed. At this level, there is enough detail logged to construct the data flow and sequence of operations. This level of logging could be used by administrators or support professionals to troubleshoot issues.
Verbose When set to log at this level, the log includes messages at all other levels. Almost all actions that are performed are logged when you use this level. Verbose tracing produces many log messages. This level is typically used only for debugging in a development environment.

5. Developer Dashboard

SharePoint 2010 introduces a new developer dashboard that allows you to see all the calls made on a page on the page itself. Those calls can be ones that SharePoint is making or they can be your custom code. By looking at the call stack, response times, and utilization, you can quickly uncover where your code is performing poorly and try to fix it.

Using Developer Dashboard you can track down whether the problem is bad  code, bad database calls the code makes, or coding errors that cause excessive CPU, disk, or memory utilization.  It gives you information for below counters:

  • Thread execution time
  • Number, duration, call stack information and query text of each SQL Server query generated by the page
  • Number, duration, and call stack information of each WCF call
  • URL or timer job name
  • Current user
  • Execution start time
  • Any of the preceding statistics for code enclosed by SPMonitoredScope
Developer Dashboard in SharePoint 2010

Developer Dashboard on a SharePoint 2010 page

You can turn on the Developer Dashboard on Demand using any one of below ways. After getting enabled, the Developer Dashboard appears  on any page that use the default master page or any page using a custom master page with the Dashboard control is included.

PowerShell:

$contentService =[Microsoft.SharePoint.Administration.SPWebService]::ContentService
$dashboardSetting = $contentService.DeveloperDashboardSettings
$dashboardSetting.DisplayLevel = [Microsoft.SharePoint.Administration.SPDeveloperDashboardLevel]::OnDemand
$dashboardSetting.TraceEnabled = $true;
$dashboardSetting.Update()

Stsadm

stsadm -o setproperty -pn developer-dashboard -pv ondemand

Object Model

SPWebService cs = SPWebService.ContentService;
cs.DeveloperDashboardSettings.DisplayLevel = SPDeveloperDashboardLevel.OnDemand;
cs.DeveloperDashboardSettings.Update();
SPMonitoredScope

By default, the developer dashboard display some information about custom code, but the information is about the calls the code is making, not the source code itself. For example, if you ’ ve added web part to the page, and you accidentally put in some poor code that takes a long time to render. If you looked at the developer dashboard, you would see the time it took to add your web part to the page and how long the pre – rendering or rendering for your web part took. However, you wouldn ’ t see how long your code took to run, unless you calculated this off the total rendering time of the page and how long it took SharePoint to do its operations.

To add your own monitored code sections to the developer dashboard, you need to implement the SPMonitoredScope class in your custom code. You can wrap all your custom code that runs in SharePoint using the SPMonitoredScope class.

using(new SPMonitoredScope("Scope Name")){
//your custom code here
}

SPMonitoredScope  can be used to determine :

  • Excessive resource usage.
  • Performance Issues.
  • Interaction between components.

SPMonitoredScope is part of the Microsoft.SharePoint.Utilities namespace. It can be initialized in two different ways via constructor:

  • SPMonitoredScope(String) :  Using a string in the constructor , which is the name of your new scope.
  • SPMonitoredScope(String, UInt32, ISPScopedPerformanceMonitor[]) : Using a string which  the name of the scope, an integer that is the maximum execution time  in milliseconds for the monitored scope, and a parameter array of objects that implement  ISPScopedPerformanceMonitor interface .If the maximum execution time  exceeds, the border around the developer dashboard UI turns red and SharePoint increases the trace level for the code.

Here are some classes that implements ISPScopedPerformanceMonitor and can be used in second overloaded constructor of SPMonitoredScope:

  • SPCriticalTraceCounter : It can be used to trace critical events and asserts.
  • SPExecutionTimeCounter : It can be used to track execution time for your scope. You can use properties such as ElapsedTime , StartTime , EndTime ,MaximumValue , and ValueIsExcessive to track usage and whether you are exceeding your allocated execution time.
  • SPRequestUsageCounter: It can be used to track the number of SPRequest objects used by your code. In its constructor, you can pass an integer that is maximum number of SPRequest objects to use and then you can check  whether you have exceeded that value and the logging level is increased in the dashboard.
  • SPSqlQueryCounter: It can be used tracks the number of SQL queries for your scope. The text, call stack, and duration are tracked.

Below is an example that uses SPRequestUsageCounter and SPSqlQueryCounter . It monitors and logs execution time, number of SPRequests, and the number of SharePoint SQL Server queries (including the query text) that are performed by the external function.

using (new SPMonitoredScope("Scope Name",1500,new SPRequestUsageCounter(4),new SPSqlQueryCounter()))
{
callToExternalCode();
}

In above codeif callToExternalCode() function takes  more than 1500ms and  allocate  more than 4 SPRequests, the trace level for this scope will be escalated to “high” . The counter will also appear red in the dashboard.

It is important to note that :

  1. SPMonitoredScope  work only with Farm solution, and not in a Sandbox solution.
  2. SPMonitoredScope logs only calls to SharePoint databases
  3. SPMonitoredScope  statics  appears on the Developer Dashboard only for the code that executes on WFEs.  For the Code that executes on application servers, the statistics  are logged in the ULS logs of the server that the code is running on.

6. Other Useful Tools for Troubleshooting

SPDisposeCheck

We have to call the Dispose() method on  SPSite and SPWeb objects otherwise we get memory leaks in your application. SPDisposeCheck can scan your code and identify where objects that are not disposed.

Internet ExplorerChromeFirefox  Developer Tools

The latest browsers (Internet Explorer 9 , Chrome, Firefox) includes tools to debug the  HTML, script, and Cascading Style Sheets (CSS) . IE 89 also includes a JavaScript profiler that shows you the performance of your script code. With these tools, you can track down any issues in your client – side code. Here are useful Chrome extensions for web developers.

For more details check here : IE Developer tools Chrome developer tools  Firefox Firebug

Visual Round Trip Analyzer

The Visual Round Trip Analyzer (VRTA) visualizes how long it takes a client to talk to a server — information that you can then use to understand if you are making excessive round trips, if your code is slowing down the pages (for example, because of loading many small JavaScript or CSS files), or if there are network issues causing any problems between your application and the server.

FiddlerHTTPWatch

Fiddler and HTTPWatch are a web debugging proxy that logs all HTTP traffic between your computer and the Internet. They allows you to inspect all HTTP traffic and view your incoming and outgoing data. It is an essential tool to help you understand what server variables are coming back from your server, what the payload is, how many calls your client – side code took, and other factors that provide insight into your applications.

7. Troubleshooting few common problems in SharePoint Solutions  : http://msdn.microsoft.com/en-us/library/ee231594.aspx

8. Troubleshooting SharePoint Packaging and Deployment : http://msdn.microsoft.com/en-us/library/ee330922.aspx

4 Responses to “Troubleshooting SharePoint 2010 : Tools & Techniques”
  1. Megren says:

    Very nice Article Amit,

    I like it :)

  2. Arfeen says:

    Developers dashboard,SPMonitoredScope and Event Throttling are very useful
    Thanks

  3. Sudhanshu sharma says:

    Sir,
    This article is best actually the way u have written/shared this really praise worthy.
    keep posting :)

  4. Kevin C says:

    Amit, Awesome site. You are my SP guru & hero! Thanks for the great posts

Leave a Reply

Subscribe

Get every post delivered to your inbox via FeedBurner :

© 2010-2013 Extreme Sharepoint | The content is copyrighted to Amit Kumawat and may not be reproduced on other websites.