3 Ways to Locate Exact SharePoint Worker Process ID
At a Glance
- Target Audience
- SharePoint Developers
- Problem Solved
- Attaching debugger to wrong IIS worker process, causing failed SharePoint debugging and breakpoints.
- Use Case
- Debugging custom WSP solutions in SharePoint development environments.
Most developers attach their debugger to every single IIS worker process they see.
It never works well. You cannot just guess your way through SharePoint debugging and expect your environment to stay clean.
The w3wp.exe process is the engine running your ASP.NET applications. It handles the incoming client requests and generates the responses. When you write custom code, you have to debug the solution by attaching to this exact process.
The problem is that a busy server runs multiple processes at the same time. If you do not know which one maps to your specific site, you are flying blind. Stop attaching to everything. Find the actual target.
Here are three specific ways to locate the correct worker process.
1. The Visual Method (IIS Manager)
Open your Run dialog and type inetmgr to launch IIS. Click on your server node in the left pane. Double-click the Worker Processes icon. You will see a clear list of every active application pool and its exact Process ID. It is simple and requires zero guesswork.
2. The Command Line Method (PowerShell)
If you want to move faster, use PowerShell. Open your shell editor and run this exact command:
C:\Windows\System32\inetsrv\[appcmd.exe](https://piyushksingh.com/2015/01/03/check-the-process-id-of-a-site-deployed-on-an-iis-server) list wp | Out-GridView
This pulls the data instantly and drops it into a searchable grid. It is the cleanest way to find what you need.
3. The IDE Method (Visual Studio)
You can wire this directly into Visual Studio by adding an external tool. It takes a few minutes of setup but saves hours over a long period of time. Follow the configuration steps via this Link.
One Hard Rule
You do not need a complex routine to make this work. You just need to follow the proper order of operations.
When you deploy or update a WSP, you must refresh your browser before checking the process ID. If you skip this step, IIS will hand you an old thread. Your debugger will fail to hit the breakpoints.
Do the boring work. Refresh the page. Find the right process. Then start debugging.

