Whether you are a SharePoint 2007(MOSS) developer or an administrator, you probably have seen a MOSS error page with the error message: “unknown error” or “unexpected error”, where these error messages do not give enough information about what happened, more logging is taking place behind the scenes. In order to troubleshoot the underlying error, you may like to follow the following steps:

1-    Disable the user friendly error pages

This will stop MOSS 2007 verbose error pages and throw the exception text to the browser instead. I consider this to be the most important step as this will give you an idea of what is really happening or where to look for more details. This can be done by modifying some configuration values in the SharePoint Site “web.config” file on the server, by default, a SharePoint site that runs on port 80 will have its “web.config” file at:

C:\intepub\wwwroot\wss\VirtualDirectories\80

a.       Open the web.config  file and locate the “customErrors” tag

b.      Modify the Tag’s “Mode” attribute to “Off” (case sensitive) so it would look like:

 <customErrors Mode=”Off”…

c.       Also, locate the “SafeMode” tag and modify the Tag’s “CallStack” attribute to “True” so it would look like:

<SafeMode CallStack=”True”…

d.      To get a more detailed stack trace, locate the “compilation” tag and modify the Tag’s “debug” attribute to “True” so it would look like:

<compilation debug="True"…

2-    Windows Event Logs

It is always good to have a quick look in the Event Logs. Although it is not a very common place to find MOSS-specific errors, but it still can contain a more generic errors such as a WSS service error or a lost connection to the SQL Database Server. You can view the events logs by going to:

Start Menu>> Run, then write eventvwr, and browse to the “Application” Logs

3-    Debug   custom  SharePoint  code

If you have a custom code (e.g. custom webpart) on the SharePoint page, you may want to debug your code to make sure that it is not what causing the problems, you can debug your code from Visual studio by attaching the Visual Studio Debugger to a process called w3wp.exe.

1.       From Visual Studio click on “Debug” then “Attach To Process”

2.       Choose w3wp.exe process

3.       Run the page on the MOSS and watch your breakpoints gets hit

If you have more than one w3wp.exe process, you may either attach the debugger to all the processes to make sure that the process that is responsible of executing your specific SharePoint site code will be attached , or you attach to the right process by its Process Id, you can get the running process information on IIS 7.0 by running the command “Appcmd list wp” on the server, this will list all the pools and their process ids , follow this link for more information. For IIS 6.0, see http://www.microsoft.com/technet/prodtechnol/WindowsServer2003/Library/IIS/2228ff79-0838-4143-8680-e38c452dc243.mspx?mfr=true

Note that if you are running a workflow in SharePoint, attaching the debugger to the w3wp.exe may crash Visual Studio and force it to close. The way to avoid this is to attach the debugger to Workflow Code Only, This can be done in the “Attach To Process” Dialog window, make sure to select "Attach to: Workflow Code".

To make the debugging experience much easier to initiate, Jonathan Dibble from Microsoft Consulting Services created a neat “Debugger Feature” that can be installed and activated on a SharePoint site, this feature enables a developer to attach to the right process directly.

4-    SharePoint Trace Logs

WSS 3.0 and MOSS events are written to log files, by default; these files can be found at this directory: 

C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS

If the log files are not there, you can check the log files location that can be found in MOSS Central Administration >> Operations >> Logging and Reporting >> Diagnostic Logging.

SharePoint Log files are large and hard to read sometimes, I normally open them using Office Excel to benefit from its organizing and formatting features (e.g. conditional formatting), also, you may like to check SPLogViewer which is an open source feature that simplifies reading log files.

Although there are much more ways to troubleshoot SharePoint and  Web Applications in general, these four steps are considered your first aid to quickly examine an error, find what is causing it, plan what to do next or may be solve it.