So you’ve developed some custom Event Handlers/Web Parts/Workflows/Feature Receivers/Custom SharePoint Timer Jobs that run within SharePoint, but something smells and you need to do some debugging to find out what went wrong and where so you can fix it. Here’s what you can do to get to the root of your problem.
1) Make sure you’ve enabled debugging in web.config.
SharePoint suppresses the normal ASP.NET exception page with nice user-appropriate messages. To turn those off and enable debugging, there’s three sections in web.config you’ve got to modify.
Modify the CallStack= and AllowPageLevelTrace= attributes of the
Modify the Mode= attribute of
Modify the batch= and debug= attributes of the
After doing this debugging will be on, and the default error pages will be displayed, letting you get closer to your problem and at least see the stack trace.
2) Attach the debugger to the IIS Worker process to hit breakpoints and step through code.
Usually seeing exception messages isn't good enough, there might be some code that has incorrect behavior that doesn't necessarily throw an exception and you want to look into executing code and figure out where this is occuring.
Within code, you can place Trace.WriteLine/Debug.WriteLine statements to try and trace your problem, but you can also attach the debugger to w3wp.exe (The IIS Worker Process) and set breakpoints as you would normally. You do this in Visual Studio under the Debug -> Attach to Process menu. A dialog appears letting you choose the process to debug. Simply choose the appropriate instance of w3wp.exe in the dialog and press ok.
Keep in mind that you should do an IISRESET after you’ve updated your assembly in the GAC, prior to attaching.
3) Attach the debugger to the Windows SharePoint Timer service to debug code that runs as a result of a timed job.
Behavior that occurs on a timed basis, such as SharePoint Workflow, Custom Timer Jobs and ListItem events that occur as a result of sending an e-mail to an e-mail enabled list are spawned by the “Windows SharePoint Services Timer” service.
To debug code that runs in the context of the timer service, you can attach Visual Studio to the Windows SharePoint Services Timer. In the Attach to Process dialog in Visual Studio, find the process named “OWSTIMER.exe” process, select it and press ok. Make sure you check ‘Show processes from all users” to see it.
Accordingly, you must restart the timer service after you’ve updated your assembly in the GAC prior to attaching. You can bounce the timer service at the command line by executing net stop “Windows SharePoint Services Timer” and then net start “Windows SharePoint Services Timer”
Good Luck Debugging!
Sean McLellan, Software Engineer, RDA Corporation
1 comments:
In one of the posts, it says this:
Modify the Mode= attribute of located under to be “off”
Modify the batch= and debug= attributes of the element to be “true”
This makes no sense. What did you mean?
Modify the Mode= attribute of ?????? located under ??? to be “off”
Modify the batch= and debug= attributes of ???? the element to be “true”
Please repost with clarification of the ????.
Post a Comment