SharePoint Applied: SharePoint 2007 Ninja Debugging

One of the challenges of working as an on-demand consultant is that I frequently get called into projects where the SharePoint installation is a bit sick, and it is in production. All the usual tricks have been tried, and the Infrastructure Ogre won't let me install Visual Studio on the production systems to truly be able to debug the problem. Yet another

problem of being an on-demand consultant is that the clock starts ticking even before I've understood the problem description.

Here are some examples of problems I hear:

My SharePoint is slow. This description is about as good as saying it may rain next week. This tells me nothing about where it is slow, at what times, and what the definition of slow is.

I am getting a random exception every now and then, and SharePoint says “unexpected error has occurred.” I think you will agree that “random” is not to be used when describing specifics of a problem, but it frequently is.

It works in the development environment, but we have no idea why it blows up in production, and we really can't diagnose because of restricted access to production.

Did I mention that SharePoint is a big and complex product with a lot of moving parts? So that makes it a little bit more challenging to diagnose the above, than, say for instance, an ASP.NET app. But luckily the same concepts apply. Also, SharePoint production installations are usually comprised of multiple servers so it is incredibly difficult sometimes to identify the source of the problem by bouncing electrons off of your installation. A typical request on a corporate network may go through a couple of firewalls, a load balancer, a few security appliances, and finally one of the Web front ends may render the actual content, which is reverse URL rewritten over a Forefront server before it comes back to the browser. Good luck finding where the “slowness” in your SharePoint farm is coming from. As a SharePoint consultant, the boundaries of my responsibility end at proving that the SharePoint farm itself was slow or not slow, and thereby rectifying the problem if it is indeed in SharePoint, or having a “blame-storming” session and finding out what needs to be fixed.

In this article, I'll demonstrate a debugging technique I have used frequently on production environments where I need to diagnose a problem with minimal or zero downtime to the application. The process is ridiculously simple, and the data collected using this mechanism is invaluable.

Here are the steps:

1. Setup a simple database.
2. Throw an ASPX into the 80 directory.
3. Make some changes to the web.config file.
4. Use the website normally and reproduce the error.

So let's get started.

Setup a Simple Database

Technically, you could use any database structure with this technique. If you wish to write a custom database structure, perhaps something more optimized for large amounts of data to be collected over time, all you'd have to do is write a custom logging provider. But since I'm the laziest guy you'll ever meet or hear about, I'll use the aspnetdb that comes as a part of Microsoft.NET 2.0.

In order to set up the database, run the following command on the command line.

This command will bring up a wizard. Go through the wizard to set up such a database on any available database server other than SQL Express. While I could have used SQL Express, it is just a whole lot easier to talk to a server-based SQL product when working with SharePoint. While you are at it, also go ahead and set up a SQL Authentication user that can work with such a database.

By: Sahil Malik

Sahil Malik is a Microsoft MVP, INETA speaker, a .NET author, consultant, and trainer, and a well-rounded overweight geek. He has a passion for SharePoint, data access, and application architecture.

Sahil loves interacting with fellow geeks in real time. His talks are full of humor and practical nuggets. His talks tend to get very highly charged, fast moving, and highly interactive.

You should check out his blog at http://blah.winsmarts.com

sahilmalik@gmail.com