Determining which w3wp process goes to which SharePoint service
SharePoint runs its service applications on IIS application pools, which in turn creates multiple w3wp processes running on your servers. When looking at Task Manager, you will see a long list of w3wp processes. Similar to
As you can see in my example above, most of my w3wp processes are using unique accounts, so I can quickly look at this list and know what process belongs to which service account. Per Microsoft’s recommendations for installing SharePoint, using a unique account per service is preferred, and this is one of the benefits.
If we didn’t use a unique account per service, this list would show all the w3wp processes using the same account. Exceptionally uninformative.
What happens if one w3wp processor is pinning the processors? Or if one is taking up apparently large amount of RAM? How do we determine which process belongs to which application pool and which application pool belongs to which SharePoint service application or SharePoint site?
Unfortunately there is easy direct method of finding this out. We utilize a few different tools to get it done.
First, let’s get the PID for each process. This is simple through Task Manager.
- Select the View menu, then select Choose columns.
- Check off PID.
- Click OK.
Your process list will now have a PID column.
Now we need to match up the PIDs to the IIS application pools. Open a command prompt window and go to c:\windows\system32\inetsrv by typing in
cd c:\windows\system32\inetsrv
Next type in
appcmd list wp
This will return a list of all application pools running, with their PIDs.
You’ll see in the list the name of each application pool and their PID. The name will match up to the name in IIS Application Pools. Some of these names should be obvious, as they are similar to your web applications. There are a bunch that are uniquely named using a GUID. These ones are the service applications.
Now let’s find out what GUID belongs to which service application.
Open SharePoint 2010 Management Shell (Start > All Programs > Microsoft SharePoint 2010 Products), and type in
Get-SPServiceApplicationPool | select Id, Name
This will return all service applications and which GUID they are using.
This GUID will match the application pool GUID that we previously saw.
TA DA!
You may also notice that not all of the service applications are being represented in the Task Manager. This is because the services themselves are asleep, and are not running. For example, my Word Automation service isn’t listed in the Task Manager, and since I haven’t used it, it isn’t running. If I were to go in and use it, it would then start up.
5 Comments
Trackbacks/Pingbacks
- SharePoint Daily » Blog Archive » Successful Records Management in SP2010; Microsoft-Amazon Cloud Deathmatch; Microsoft too Secretive - [...] Determining Which w3wp Process Goes to Which SharePoint Service (SharePoint 365) SharePoint runs its service applications on IIS application ...
- Successful Records Management in SP2010; Microsoft-Amazon Cloud Deathmatch; Microsoft too Secretive - SharePoint Daily - Bamboo Nation - [...] Determining Which w3wp Process Goes to Which SharePoint Service (SharePoint 365)SharePoint runs its service applications on IIS application pools, ...





Has anyone written a PowerShell cmdlet that replicates the function of IISAPP.exe? That would be pretty much ideal.
Hi Eric,
I looked, haven’t seen anything yet. I am working on writing a cmdlet which can do all this post does, in one easy command. I’ll post here when I get it done.
Thanks,
David
I’ve used that in the past as well, but i have found an even easier way. While you were in Task Manager selecting the PID column, also select the command line column. The command line for each w3wp worker process will include all the information you need to determine which site the worker process belongs too.
Thanks for the tip. This works great for identifying which web sites are running, as the application pools are named to match. This doesn’t work for service applications as the application pools are named with GUIDs.
Thanks David, this little trick helped me track down which app pool was eating up server resources