There are several ways to have a better debugging experience with SharePoint. This will help you deal with "Unexpected Error" screens. Here are a few tips that can be used to make development easier. Some of these tips are not appropriate for a production environment.

Turn ON friendly errors thru web.config

The generic error page with the standard "Unkown error occured" message on the generic yellow & blue page is not very helpful.  Sometimes there is a bit more detailed, but you still don't get a lot of info.

To avoid this when developing SharePoint sites and get the familiar ASP.NET yellow screen of death (YSOD) open the web.config and make these two changes.

Search for <customErrors mode="On" /> and change it to <customErrors mode="Off" />

Find and change the value of “CallStack” to true.

   1: <SafeMode

   2: MaxControls="200"

   3: CallStack="true"

   4: DirectFileDependencies="10"

   5: TotalFileDependencies="50"

   6: AllowPageLevelTrace="true">

Finally, don't forget the set debug="true" in the web.config or it won't matter whether you put the assembly in GAC. Without this change breadpoints will be shown but will not be used. If you want to enable generation of debug symbols for just in time compilation find

<compilation batch="false" debug="false"> and change it to <compilation batch="false" debug="true">.

Attach the debugger to right “w3wp.exe”

When you try to attach to the "w3wp.exe" process to debug an assembly,its chance that you may see multiple instances of it. Either you can attach to all "w3wp.exe" but its not recommended.

Please note that developing with assembles in the BIN, the web.confg set to full trust, then deployed to the GAC is not good programming practice.  It sounds like it would be easier to debug.  It is better practice to make your  development machine closer to your production.  On your machine do not place the DLL in the GAC with the PDB files.


Well, open up command prompt and run the “iisapp.vbs” (Found at %windir%/system32/iisapp.vbs) script with no parameters. It will show you list of the currently running application pools and the associated PIDs.

To verify that you are attached to the correct instance of "w3wp.exe", open the Modules window by pressing CTRL-ALT-U. If your assembly is listed, you picked the right w3wp.exe.

If your DLL is placed in the GAC you do not need to copy the PDB files.  If you configure Visual Studio correctly debugging in the GAC acts the same as the BIN. 

Configure your VS 2005 for this:

Open Tools > Options > Debugging.

You will see option “Enable Just My Code (Managed Only)” with couple of sub options. Just UNCHECK it, and click ok.

Well you can now debug your code without placing PDB files in GAC. Only your DLL in GAC.

Using Windows Event – Logs

   1: //Log exceptions to the Windwos Event - Logs using System.Diagnostics

   2: try

   3: {

   4:     //Do something

   5: }

   6: catch (Exception ex)

   7: {

   8:     SPSecurity.RunWithElevatedPrivileges(delegate

   9:     {

  10:         System.Diagnostics.EventLog.WriteEntry("My WebPart", 

  11:                                                "Exception in Render: " + ex.Message + " Inner Excpetion: " + ex.InnerException + " Call Stack: " + ex.StackTrace, 

  12:                                                 EventLogEntryType.Error);

  13:     });

  14: }

Beside this you can also use Trace.write or Debug.write

Use SharePoint Log Files

Include “Micrsoft.Office.Server.dll” in your reference from “%12 hive%\ISAPI” folder and log errors in it.

   1: //Log exceptions to the default SharePoint log file.

   2: try

   3: {

   4:     //Do something

   5: }

   6: catch (Exception ex)

   7: {

   8:     Microsoft.Office.Server.Diagnostics.PortalLog.LogString("Exception Occurred: {0} || {1}", ex.Message, ex.StackTrace);

   9: }

Now you can log your errors into SharePoint’s log files found in the 12 hive / Logs folder. Make sure you have Diagnostics logging features set correctly. You can change the settings under 'Logging and Reporting' in the operations tab from Central Admin. Under 'Event Throttling' you can change the verbosity. If possible just set all of the categories to verbose since it can be difficult to identify the categories which you may need to change when a problem occurs.

Follow recommendations by MS for your coding:

• Always use try , catch. finally
• Dispose SharePoint objects properly

Make sure you dispose the SPSite, SPWeb objects. If you are not using “using” make sure to dispose your objects in “finally” section.

Always follow the best practice guidelines given my MS.

http://msdn2.microsoft.com/en-us/library/aa973248.aspx

Use the Query String Tricks

When you are developing WebParts, if anything goes wrong and you get an error page, you can trick the URL to put your page in webpart maintenance mode.

For this put “contents=1 “ in your url

e.g. http://<<servername>>/default.aspx?contents=1

Some other parameters that can be useful are:

When testing any WebParts in production environment, its better to add them with "Personal Mode" and after testing you can add them in "Shared Mode"

Use the SharePoint's "Bugs" template

This is useful in production environment. You can have some admin area with SharePoint inbuilt "Bug Tracking Modules" feature. Where all your custom codes  of WebParts, Features, Event Receivers, Workflows etc. can log any errors. You can even go for your own custom list (with base type Tasks or Issues) for this. This provides a flexible way to track any error for administrator then to go and read event logs or any other log files. This also allows alert email and workflow to solve the issue with support team.