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

For eg, this one:


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?


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

  • If something running in OWSTIMER causes an event, then the event receiver will run under OWSTIMER.
    – lgaud
    Commented Mar 13, 2013 at 14:02

3 Answers 3


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

  • so when mentioned "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." .. So for example if a user update an item using UI (using the edit form), and i have an async event receiver (ItemUpdated), then the itemupdated event receiver will run under a seperate W3WP , so it i will run based of the login user identity ? is this correct ? and let say inside my event receiver i wrote the following properties.Web.CurrentUser then i will get the login username and not the sysem account username ??
    – John John
    Commented Jan 16, 2017 at 18:45
  • The async ER will run in a new thread of the same W3WP process, under the identity of the original user.
    – Evariste
    Commented Jan 16, 2017 at 20:57

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.


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.

  • No, this is not true, see my answer.
    – Evariste
    Commented Jan 14, 2016 at 12:39

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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