[Taken From Sahil Malik Books] - I want to share a little trick with you. When you're writing code for SharePoint, and your custom code runs into an error, by default SharePoint will log that error and it will present the user with a generic error through the browser. In order to view the actual error message through the browser, you will need to make three changes to your web.config:

 
1. Change the SharePoint\SafeMode\@CallStack attribute to true.
2. Change System.Web\CustomErrors\@Mode attribute to Off.
3. Change System.Web\Compilation\Debug mode to true.
Making these changes will allow you to both attach to W3WP.exe and run your code in debug mode,
and to view actual error messages through the browser. Note that you should not make these changes in
production environments. Finally even this is not an exact science! Whenever I run into an error in
SharePoint programming, I usually look at the following four places in sequence:
1. The browser window, assuming I have made the above-mentioned web.config changes.
2. The ULS logs available at 14\Logs. You may need to tweak the logging level in central
administration to view your actual error message. Also, you should try out this fantastic tool at
3. The event log, especially for WCF-related errors.
4. The IIS log and tracing facilities.
 
If all these steps fail, I use the techniques described in this article http://www.codemagazine.
com/Article.aspx?quickid=0907041
 
If even that fails, I call in sick and let my co-workers deal
with it. Luckily that hasn't happened yet.
In addition to logging, SharePoint now comes with a database called WSS_Logging. This database
contains a tonne of usage and log data, and Microsoft now actually invites you to read this database, and
run reports against it.

 

Add new comment