Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Some MSDN articles say that synchronous event receivers run under w3wp.exe, and asynchronous event receivers run under owstimer.exe.

For eg, this one:

http://blogs.technet.com/b/speschka/archive/2009/12/25/debugging-event-receivers-in-sharepoint-2010.aspx

First of all, I was not aware of this change in 2010, and I have been attaching event receivers to w3wp.exe in order to debug them like since forever.

So this was contrary to my experience, so I decided to try this out myself, to confirm it.

So I created a simple event receiver, specifically mentioned <Synchronization>Asynchronous</Synchronization>

in my elements.xml, stopped the sharepoint timer service to kill the owstimer.exe process, attached the event receiver to the w3wp.exe, and I was able to debug all the asynchronous event receivers without any problem. Same was the case even when owstimer.exe was up and running.

So what is the deal here? Am I missing something? Or is MSDN wrong here?

EDIT

Further experiments confirm that asynchronous event receivers fire in a different thread by default. But they are still running under the w3wp.exe process.

share|improve this question
    
If something running in OWSTIMER causes an event, then the event receiver will run under OWSTIMER. –  lgaud Mar 13 '13 at 14:02

1 Answer 1

SharePoint 2010 RTM'd in April 2010. That article is from December 2009, when it was in beta. We're now into SP1, so it wouldn't surprise me if they changed the dispatcher to use w3wp.exe instead of owstimer.exe.

Personally, if you know that it runs under either of the two, debug either until you hit breakpoints. I don't reckon it's that much of a deal.

HOWEVER, if you think about it, feature event receivers typically work in the context of the site in which a feature was enabled. You'll have to do stuff like elevate permissions to do certain things, and this reverts the process identity to the app pool. If the thread was under owstimer.exe, you wouldn't have that luxury, as timer jobs would probably run under a different identity.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.