The 12-Step Recovery Program from a SharePoint Error

In this article, I will share with you my 12-step process that has so far helped me diagnose every SharePoint error I’ve run into. If you have additional diagnosis tricks, please send them to me via email.

1. The three C’s: The three C’s stand for callstack, compilation, and customErrors. These are three attributes you can change to true, @debug=true, and @mode=Off, that allow you to view an exception text right on the web page.
2. Developer Dashboard: The Developer Dashboard is a new addition in SharePoint 2010. It gives you a convenient way to view the details of any particular page rendering down to the database and WCF calls complete with exception traces, warnings, and time durations. You can enable Developer Dashboard by using the following command:

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

1. Event Viewer: The Event Viewer in Windows is an amazing insight into the innards of SharePoint. Some errors will surface only within the Event Viewer. Anecdotally I can tell you that many WCF errors, including those for out-of-the-box WCF services such as those for claims based authentication, seem to merrily log their errors in the Windows Event Log.
2. ULS Viewer: ULS is the unified logging service - which in itself has seen enhancements as compared to the SharePoint 2007 version. You can download this tool fromhttp://code.msdn.microsoft.com/ulsviewer, which lets you view ULS errors at runtime as they occur, and filter using CorrelationIDs.
3. CorrelationIDs: Technically this is a part of the ULS log, but not really. Classically reading ULS logs has been tough. Those multiple log files are quite wide, so you have to scroll around and sift through many such log files, line breaks, etc., to find the error trace you are looking for. Starting with SharePoint 2010, Microsoft gives you a unique ID, a GUID, for each error that occurs. This is the CorrelationID. You can use CorrelationIDs to put together the full error message as it occurred, even across multiple machines. And this can be done easily using the ULS Viewer that I mentioned above.
4. Fiddler: You can download Fiddler from www.fiddlertool.com. Fiddler introduces a proxy for your browser and starts to sniff all local http traffic going back and forth from your machine. It is an invaluable tool for debugging REST-based APIs and client object model calls. Starting with Internet Explorer 9, you have a network monitor built right into your browser, or you can also use Firebug, Chrome extensions, etc.
5. Internet Explorer extensions: Open any SharePoint page, and hit F12. This will bring up the developer extensions for Internet Explorer. Using this you can very easily run small JavaScript commands, change CSS on the fly, and change the DOM of the page entirely if you wish, or even step through JavaScript. In crafting up modern day rich client side applications, I have found this utility to be extremely valuable.
6. IIS 7 trace and logs: Managed code is awesome. And as more and more Microsoft products are whole heartedly adopting the managed code bandwagon, they are reaping amazing benefits from it. One such product is IIS7. With its integrated pipeline and error logging and tracing, it literally tells you what line an exception occurred at - along with a full stack trace, and http error codes. I can’t tell you how much I have found this useful in diagnosing really hard to discover HTTP 401s (HTTP Unauthorized), especially when diagnosing search, reporting services, etc. Security is a good thing, but it can also be a real pain sometimes.
7. WCF Error Tracing: System.ServiceModel comes with a diagnostics element that lets you create listeners to error messages. As messages go across a WCF boundary, errors, or even non-errors, can be logged into a store of your choice. The simplest, of course, is an XML file, which is right out of the box in .NET.
8. .NET Reflector Pro: .NET Reflector is this amazing product that lets you decompile any non-obfuscated .NET assembly and peek into its source code. .NET Reflector Pro takes it to a whole other level - it lets you debug and step through that generated code - as if it was your own code. Amazing! This is extremely useful, and is demonstrated in this video -http://blah.winsmarts.com/2010-9-Ninja_SharePoint_2010_Debugging_with_NET_Reflector_Pro.aspx
9. Ninja debugging skills: No, ninjas do not need debugging. What I mean is that in working with a big product that you didn’t write, such as SharePoint, it helps to develop some advanced debugging skills. I describe some of these black belt techniques in this article here - http://www.code-magazine.com/Article.aspx?quickid=0907041.
10. Call in sick: I haven’t ever had to use this advanced technique, but if all else fails, call in sick, blame it on a coworker, and take the day off. It’s amazing how much some chillaxing can help.