Hello, my name is Sahil, and I am a worsening SharePointoholic. SharePoint is built on ASP.NET 2.0 - pretty much like human beings are made up of carbon and water. There is a lot in SharePoint that isn’t in ASP.NET. Not only is SharePoint a complex ASP.NET 2.0 application, it also has numerous concepts for things such as profiles, role providers, authorization etc., that are different from ASP.NET.

In addition, underneath the hood there is lots of COM, legacy database models, technologies that have come and gone, that are in some way, shape or form being used inside the depths of SharePoint. In addition, SharePoint uses the latest technologies such as WF, WCF and claims based authentication, which forms the bones and flesh of this amazing product.

The good news here is that all of this put together makes it the ultimate Microsoft product - something that benefits from everything Microsoft does. The bad news, of course, is that diagnosing an error sometimes is not as simple as looking at exception text and searching for it on Bing.com.

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 from http://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.

Summary

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 across multiple machines even. And this can be done easily using ULSViewer.

This list is not complete. SharePoint is a complex product, and in working with it I continue to discover new tricks and new techniques all the time. I hope you found these techniques useful. If you have more to contribute, I would love to hear from you at www.winsmarts.com.

Until next time, Happy SharePointing.