Which process do event receivers run under?

Question

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.

Answer 1

An event receiver runs in the same process as the code that triggered it. This can be anything running SharePoint code:

• If the action (adding an item, updating an item...) is performed by an end-user, from the browser UI, the code that actually performs the operation runs under W3WP (the IIS application pool process, i.e. the one that runs the Web application).
• If the action is done by a job, it's under OWSTIMER.exe (the SharePoint timer service).
• If you add an item through PowerShell, the process is PowerShell.exe. The event receiver DLL is loaded in PowerShell.exe.
• If you add an item from a custom .exe (built on top of server Object Model), the ER will run in that exe.

In all cases, sync events run in the same thread as the one that triggered the event, while async events run in a separate thread.

And the same goes for feature ER: the ER code runs in the process that actually activated the feature. W3WP most of the time, but could also be PowerShell.exe if you activate the feature from PowerShell, or even devenv.exe if you deploy/activate from Visual Studio (a bad idea IMO).

Answer 2

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.

Answer 3

In SharePoint 2013 event receiver runs only in w3wp process, it does not matter that the event is Synchronous or Asynchronous. I have tested it on my development environment.