Most of cases you would have had hard time to figure out error with SharePoint. SharePoint is know to be bad when it comes to providing verbose error and debugging environment. There are few tricks which can save you a lot of time when you are in trouble.
– modify web.config for verbose errors (server)
– installing debugger feature (server)
– configure Diagnostic Logging/ULS (server)
– Change setting on IE (client side)
Modifications to web.config
This are originally taken from Shannon Bray blog post here (all credits to Shannon) http://www.shannonbray.com/2008/07/verbose-errors-in-sharepoint.html
web.config is typically located in the C:\Inetpub\wwwroot\wss\VirtualDirectories\<Port of Website>
You should see several folders here. You need the folder for the port number your site is on. This is often the 80 folder. If you only have two, the 80 and another number, it is definitly the 80. The later would be for your Centeral Admin. There is no need to mess with this one.
Find the web.config and make a copy!!!!! Just incase you make a mistake you don’t know how to fix. Name it something like web.backup.
Open the web.config file in notepad and change the following
First Change:
SafeMode MaxControls=”200″ CallStack=”false” DirectFileDependencies=”10″ TotalFileDependencies=”50″ AllowPageLevelTrace=”false”
to
SafeMode MaxControls=”200″ CallStack=”true” DirectFileDependencies=”10″ TotalFileDependencies=”50″ AllowPageLevelTrace=”false”
The “True” will give you the verbose details beyond the simple error codes.
Second Change:
customErrors mode=”On”
to
customErrors mode=”Off” Save the web.config!!!
Make sure you capitalize just like I did.
Do an IIS reset… re-run your page. You should see the real error.
You should put things back when you are done so that other end users don’t see critical error information.
As a developer, this is often one of the first things I do. Errors are part of the development process and you might as well set this early. Do not leave this on for Production sites. Set the “Off” to “RemoteOnly” or “On”.
Installing the debugger feature
This is snippet taken from the SharePoint Team Blog and the original post can be found at http://blogs.msdn.com/sharepoint/archive/2007/04/10/debugger-feature-for-sharepoint.aspx
While Windows SharePoint Services 3.0 provides an excellent platform for developing Web applications, debugging them can be a bit of a pain. It’s often a case of finding the process ID (PID), attach the debugger, navigate to the error, rinse, and repeat, but programmers love to write code, not navigate through menus. J Fortunately, my good ol’ buddy from Microsoft Consulting Services and developer extraordinaire, Jonathan Dibble, created a nifty “Debugger Feature” that can be installed and activated on a SharePoint site to make the debugging experience much easier to initiate. Jonathan is a brilliant guy, but he’s too shy (for now) to engage the broad SharePoint community, so he has donated his code to Scot Hillier’s SharePoint Features project on CodePlex for all to share and hopefully extend. The blog entry below was jointly written by Jonathan and Scot.
When activated, the Debugger Feature adds an “Attach Debugger” menu item to the Site Actions menu (see picture below). The feature provisions a simple page, which executes the System.Diagnostics.Debugger.Launch statement, causing an exception to be thrown and the debugger to be auto-attached. In some cases, the debugger cannot attach – for example, when the AppPool is running under a different user account. When that happens, the page will at least give you the correct PID, so you can attach the debugger yourself.
Read more details on the post at original blog.
Configure Diagnostic Logging
Unified Logging Service (ULS) writes WSS 3.0 and MOSS events to SharePoint’s Trace Logs, and these are stored in the file system in …\12\LOGS. Collectively this location and its files are commonly referred to as the “ULS Logs” though MSDN calls them the Trace Logs.
According to the MSDN Trace Log docs:
“Developers can program their applications to write custom operations messages to the trace log, the same log that Windows SharePoint Services uses to log developer-oriented information and events. Writing to the same trace log Windows SharePoint Services employs enables third-party developers to view their custom application traces in the larger context of Windows SharePoint Services operations, without having to correlate multiple trace logs. In addition, the trace log provides a central destination for information concerning development processes, such as debugging. This alleviates the need for developers to log their development information in other places, such as the Windows Event Log, which are more commonly used by system administrators.”
Configuration:
Go to your central administration server web site, and open up the Diagnostic logging:
Central Administration -> Operations -> Logging and Reporting -> Diagnostic logging
In the Diagnostic logging page, focus on the following categories:
- Event throttling: how much you log
- Trace Log: where you store the logs
Event Throttling:
- For a Dev/staging server server, you should log all or “medium events”
- For a Production server, only log errors
- The search crawler will take up most of the log space
Trace Log:
- By Default, logs are sent to: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\
- Store the logs on a separate drive so that at worse your drive gets full and your application stops logging, but still functions. It’s a pretty standard practice for SQL server installations for instance.
- Reduce the number of log files. The default is two days worth of logging (96 files x 30 min intervals). See if this is too much for you; it might depend on how much you chose to log in the Event Throttling.
Caution:
SharePoint 2007 by default stores 48 hours worth of logs in a directory buried in your program files folder (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\LOGS\ !). Very few events get logged to the application event log.
Expect each log file to be at least 200 megs (a log file being generated every 30 minutes by default), or 19 GB of space at the minimum being used by SharePoint logs.
Change Setting for IE
By default IE is set to show Friendly HTTP Error messages. By turning this off we can more specific error details.
To configure the settings:
IE -> Tools -> Internet Options… -> Advanced Tab ->
Under Browse section locate and UNCHECK “Show friendly HTTP error messages”
I hope this tips will help you better debug and troubleshoot SharePoint development environment.
