Better Debugging with SharePoint

Generally its common complaint with SharePoint “how to debug the code more better way” mostly ending up with frustrated “Unexpected Error” screens.

These are some of the Tips you can follow to get rid of those errors

  1. Using query String Tricks
  2. Turn On Friendly errors in web.config
  3. Attach w3wp.exe
  4. Using Windows Event – Logs
  5. Use SharePoint Logs
  6. Follow recommendations by MS for your coding
  7. Some tools you can use.

Use the Query String Tricks

When you are developing webparts, if anything goes wrong and your page hooks up on error page, you can trick the URL by putting your page in webpart maintenance mode.

Put “contents=1 ” in your url

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

Some other parameters that can be useful are:

Add Web Parts/Browse : ToolPaneView=2
Add Web Parts/Search : ToolPaneView=3
Edit Mode : mode=edit
View Mode : mode=view
Shared Mode : PageView=Shared
Personal Mode : PageView=Personal

Turn ON friendly errors thru web.config

“Unknown error occurred” message on the generic yellowish & blue page? Of course, sometimes they get a bit more detailed, but you still get stuck without enough info.

To avoid this in development in SharePoint sites ; open the web.config and make two tweaks so it gives the familiar ASP.NET yellow screen of death (YSOD) with the true exception and underlying call stack.

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

To see the call stack and trace information. Find

<SafeMode MaxControls=200CallStack=falseDirectFileDependencies=10TotalFileDependencies=50AllowPageLevelTrace=false>

and change the value of “CallStack” to true.

<SafeMode MaxControls=200CallStack=trueDirectFileDependencies=10TotalFileDependencies=50AllowPageLevelTrace=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 or not without it the breakpoints will turn all nice and red, but it won’t stop anywhere. 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>.

Although none of these are appropriate for a production environment, but they all make development much easier.

Attach the debugger to right “w3wp.exe”

If you are developing something on SharePoint and don’t know what’s purpose of “w3wp.exe”, then you should really start learning from scratch.

When you try to attach to the w3wp.exe process and debug an assembly there are multiple instances from which to choose. How do you know which one to pick?

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.

Also to be noted here, Developing with assemblies in BIN with the web.config set to full trust and then deploying them to the GAC at last is not good programming anywhere, even though it sounds more easier to debug. Better is to make your development machine closer to production one. If that means on your machine place your DLL in GAC including with PDB files ? Big answer is NO.

If your DLL is placed in GAC, that doesn’t mean you need to copy PDB files too. Its same as to debug in GAC as in BIN, if your Visual Studio is configured properly.

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

//Log exceptions to the Windwos Event – Logs using System.Diagnostics
try
{
//Do something
}
catch (Exception ex)
{
SPSecurity.RunWithElevatedPrivileges(delegate
{
System.Diagnostics.EventLog.WriteEntry(“My WebPart”, “Exception in Render: “ + ex.Message +
” Inner Excpetion: “ + ex.InnerException +
” Call Stack: “ + ex.StackTrace, EventLogEntryType.Error);

});
}

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.

//Log exceptions to the default SharePoint log file.
try
{
//Do something
}
catch (Exception ex)
{
Microsoft.Office.Server.Diagnostics.PortalLog.LogString(“Exception Occurred: {0} || {1}”, ex.Message, ex.StackTrace);
}

Now you can log your errors into SharePoint’s log files found under

12 hive / Logs folder. But 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. Always make practice of using the “Using” in you code while creating objects
  • Always follow the best practice guidelines given my MS.

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

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

Some Useful tools you can use: