Paul Galvin's (old) SharePoint space [SharePoint

Just another site

Yet Another Event Receiver Debug Trick

I’m sure I’m not the first person to come up with this.  However, I haven’t noticed anyone publish a trick like this since I started paying close attention to the community last July.  So, I thought I’d post it this quick and easy debug tip.

I’m working on an event receiver that started to generate this error in the 12 hive:

Error loading and running event receiver Conchango.xyzzyEventReceiver in xyzzy, Version=, Culture=neutral, PublicKeyToken=blahbalhbalh. Additional information is below.  : Object reference not set to an instance of an object.    

I didn’t know where I had introduced this bug because I had done too many things in one of my code/deploy/test cycles. 

I tried this solution to get my pdb in there with hopes that SharePoint’s 12 hive would show the stack trace, but no luck.  I don’t know if it’s possible and if someone does, please let me know 🙂

I know it’s possible to write your own log messages to the 12 hive.  Frankly, I wanted something a little less scary and quicker to implement.

It occurred to me that I could at least get some basic trace information by catching and re-throwing generic exceptions like this:

  try {
  catch (Exception e)
    throw new Exception("Dispatcher, UpdateEditionDate(): Exception: [" + e.ToString() + "].");

This showed up in the 12 hive thusly:

Error loading and running event receiver Conchango.xyzzyEventReceiver in xyzzy, Version=, Culture=neutral, PublicKeyToken=blahblahblah. Additional information is below.  : Dispatcher, UpdateEditionDate(): Exception: [System.NullReferenceException: Object reference not set to an instance of an object.     at Conchango.xyzzyManagementEventReceiver.UpdateEditionDate(SPItemEventProperties properties)     at Conchango.xyzzyManagementEventReceiver.Dispatcher(SPItemEventProperties properties, String eventDescription)].

That gave me all the detail I needed to track down that particular problem and I expect to use it a lot going forward.


Subscribe to my blog!


3 responses to “Yet Another Event Receiver Debug Trick

  1. Charles February 28, 2008 at 7:23 pm

    Better yet, incorporate a logging library like Enterprise Library or log4net and your life will be even easier.

  2. Paul February 28, 2008 at 7:48 pm

    Noname, I think even better is to put the log messages into a custom list.

  3. Anders September 29, 2008 at 9:26 am

    I have had alot of luck lately debugging this kind of issues with a combination of SPTraceView and DebugView
    Debugview alone is very usefull as well. You can pipe out output using System.Diagnostics.Debug.WriteLine().
    You dont even have to remove them when you release build, since the output only is triggered in debug build mode.
    SPTraceView is a tool created by  Hristo Pavlov.
    At its default setting it will show you ULS trace events as they happen. And it catches also the ULS trace events that *doesnt* make it to the diagnostics log!
    But that i disable as soon as i run the util. Whats much better is that you can pipe output to show up in DebugView.
    It also has alot of nice features for filtering on event levels, services etc.
    oh and nice seeing you in the bar at SPBP 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: