SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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

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

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 and-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).

share|improve this answer

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.

share|improve this answer
    
No, this is not true, see my answer. – Evariste Jan 14 at 12:39

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.