Share-n-dipity

SharePoint serendipity is the effect by which one accidentally discovers something fortunate, especially while looking for something else entirely. In this case, it is the occassional musings, observations, and Ouija board readings about the phabulously

Debugging Event Receivers in SharePoint 2010

Debugging Event Receivers in SharePoint 2010

  • Comments 8
  • Likes

Well folks, it's been a while since I've added to the blog, and ironically I find myself on Christmas morning finally chasing down a little "bugger" that was causing me considerable grief yesterday afternoon.  So Merry Christmas, and here are a couple of tips that may save you some time when you are trying to debug event receivers in SharePoint 2010.

The first issue that remains troublesome, even with Visual Studio 2010, is debugging the activation of your feature.  For example, in my case I have a feature and it contains an event receiver.  For my particular scenario I wanted to bind my event receiver to a specific list, so I had an event receiver for my feature and in the activation callout I did the binding.  Of course, when there are problems in there, how do we debug that?  VS 2010 just tries to push out the solution, deploy it, activate it, and activate features.  Well I found the simplest way to do that is to use our new friend PowerShell.  I let VS 2010 do it's thing, and then I open up a PowerShell window.  In PowerShell, I use the Enable-SPFeature cmdlet to go ahead and activate my feature.  Before I execute that cmdlet, in VS 2010 I use the Tools...Attach to Process menu to select the PowerShell window I have open.  Then when I execute the PowerShell command VS will hit the breakpoint in my Feature Activated event and I can step through my code.  Not completely straightforward, but once you get the pattern down it proves to be quite useful.

The second issue that was really driving me crazy was debugging the event receiver itself.  In SharePoint 2007 I would just attach to the w3wp.exe process for my web application and I was good to go - I'd hit my breakpoint and debug away.  In SharePoint 2010 I was having no such luck.  I was trying all sorts of things but could not get my debugger to step through the code.  What was also strange is that the data my app would write to the event log was completely out of whack with my latest compiled version of the event receiver - it was from a build I had already changed some time ago.  Two age old tricks finally gave me the clues I needed to solve this puzzle:  1) adding a System.Debugger.Break(); as the first line in my code and 2) rebooting the machine.  The next time my receiver fired, the Debugger.Break() line forces one of those dialogs we've all seen before to appear - the one that says you've hit an unhandled exception, what do you want to use to debug it?  When that dialog comes up, it also says which process the problem occurred.  Well, it turns out that code is now running in the OWSTIMER.EXE process, no longer the w3wp.exe.  Aha!  I hate it when that happens.  That not only explains why I couldn't hit my break points, it also explains why the event log data my code was writing seemed dated; it was, there was an old version of my assembly in memory with owstimer.

So, I removed Debugger.Break() statement from my code, and now my process works like this:

  1. Compile
  2. Deploy
  3. net stop sptimerv4
  4. net start sptimerv4
  5. Run my code and hit my breakpoint

I'm actually adding the net stop and net start commands as post-build steps to my solution, so it will all work seamlessly moving forward.  Hope this helps you if you get stranded in this same scenario.

Happy Holidays!

Comments
  • Thank you very much for the stop and start sptimerv4 suggestion.

    It allowed me to finally debug my EventReceiver

    Marco

  • Not sure why your blog describes debugging a feature event receiver as being so cumbersome. Might be because SharePoint 2010 was still in beta when you wrote this article. Now with the RTM of SharePoint 2010 debugging the event receiver of a feature has become as become as easy as simply having Visual Studio 2010 attach to the SPUCWorkerProcess.exe process via Debug -> Attach to Process and activating the feature through Site Actions -> Site Settings.

  • Thanks, dude!

    You've just saved me a lot of time.

  • How do you do this in a non-dev box?

    I've created an event receiver.  I log using ULS logger on 'ItemAdded' event handler.  Works fantastic in DEV environment.  I can see all the logs.

    In PROD, I don't see the logs.  What could be wrong?

  • Hi,

    Here you can find some useful VS 2010 extensions that may help debugging event receivers as well. For example menu items and deployment steps to restart OWSTIMER and to attach debugger to OWSTIMER.

    Hope it helps.

    Peter

  • Unfortunately, there is a lot about what Steve has written which I don’t really understand. The first part appears to suggest you can debug a feature receiver by attaching to SharePoint Management Shell and executing Enable-SPFeature to hit a break point in the Feature Activated event. But the second part suggests it actually requires a different approach: “Compile, Deploy, net stop sptimerv4, net start sptimerv4, run my code and hit my breakpoint” – presumably via the F5 key in VS2010. Neither of these approaches worked for me. And I don’t really get what the net stop and start commands are for.

    In order to operate under the Farm account I’ve tried to devise a method for debugging a feature receiver using SharePoint Management Shell, rather Visual Studio 2010, to install, deploy, activate and trigger break points in the feature receiver; but only with limited success. When trying to repeat the build, run, test sequence, on second and subsequent times around problems occur when attempting to reactivate the feature via Enable-SPFeature.

    For example:

    - break occurs in assembly, but source code not found when WS2010 is opened,

    - or source code opens in WS2010 automatically, but is an earlier version,

    - An error occurs: “Failed to load receiver assembly …etc” even though gacutil.exe –l “solution” shows assembly is actually present in the GAC.

    Usually the only way out it to reboot the server – so here’s hoping someone can come up with a more rigorous and foolproof method than mine below…

    1. Using Visual Studio 2010, build solution then Package to obtain new solution.dll and solution.wsp

    … Feature receiver code contains System.Diagnostics.Debugger.Break() statements

    2. Then using SharePoint Management Shell to install, deploy and activate/deactivate the feature:

    • Install:

    Add-SPSolution –LiteralPath "path\solution.wsp"

    … installs solution in SharePoint 2010

    • Deploy:

    Install-SPSolution –Identity solution.wsp –GACDeployment

    …tasklist /m solution.dll - shows it is attached to OWSTIMER.EXE

    … gacutil.exe –l “solution” -  shows solution.dll is in GAC

    • IIS: Iisreset /noforce

    • Activate:

    Enable-SPFeature “featurename” –URL “url”

    … breaks SharePoint Management Shell at System.Diagnostics.Debugger.Break() in FeatureActivated()

    … VS2010 Debug > Terminate-All to stop debugging and close SharePoint Management Shell window- sometimes have to use Task Manager to terminate the shell process

    • Deactivate:

    Disable-SPFeature “featurename” –URL “url”

    … breaks SharePoint Management Shell at System.Diagnostics.Debugger.Break() in FeatureDeactivating()

  • Thx, for me that helps, the breakpoints didn`t work at all, but after searchitn around a lot and getting mad about this i handled it by writing everything i need to know into txt files, and with net stop and start the canges will be updated.

    Jo

  • Thanks , It helped me when I was trying to debug but was not successing. Service start and stop worked correctly.

Your comment has been posted.   Close
Thank you, your comment requires moderation so it may take a while to appear.   Close
Leave a Comment