Find the Correct IIS Worker Process for SharePoint Server Debugging

To find the right w3wp.exe process, identify the SharePoint web application's IIS application pool, then map that pool to its current process ID. Do this only in a development or controlled test farm. Attaching a debugger to a production worker process can pause requests and disrupt users.

This procedure applies to on-premises SharePoint Server. You cannot attach to Microsoft's SharePoint Online worker processes.

Before you attach a debugger

You need:

• local administrative access to the SharePoint web server;
• permission to inspect IIS and run Visual Studio as required;
• a controlled development or test window;
• the exact SharePoint URL and IIS application pool;
• symbols and source matching the deployed assembly.

If you are troubleshooting a production incident, collect logs, correlation IDs, ULS data and IIS evidence first. Do not use an interactive debugger as your default production diagnostic.

Method 1: IIS Manager

1. Open IIS Manager on the server handling the request.
2. Select Application Pools and note the pool used by the target SharePoint web application.
3. Select the server node, then open Worker Processes.
4. Match the application-pool name to the displayed process ID.

If the pool is started but no process appears, make one harmless request to the test site and refresh the Worker Processes view. IIS can start a worker process on demand.

Method 2: AppCmd

From an elevated PowerShell window on the IIS server, run:

& "$env:windir\System32\inetsrv\appcmd.exe" list wp

The output maps each active worker-process ID to an application pool. Filter the text or send it to a file if the server hosts many pools.

AppCmd reports the current process. Application-pool recycling can replace that process ID, so check again after a deployment, recycle or crash.

Method 3: PowerShell process inspection

PowerShell can show the current IIS workers:

Get-Process -Name w3wp -ErrorAction SilentlyContinue |
    Select-Object Id, ProcessName, StartTime

This confirms which processes exist but does not reliably identify their application pools by itself. Use IIS Manager or AppCmd for the mapping.

Attach Visual Studio

After confirming the PID:

1. Open the matching solution in Visual Studio.
2. Select Debug > Attach to Process.
3. Show processes from all users if required.
4. Choose the verified w3wp.exe PID.
5. Confirm the expected code type before attaching.
6. Reproduce one controlled request.
7. Detach when the test is complete.

Do not attach to every w3wp.exe process. That broadens the impact and makes it harder to know which application produced the breakpoint.

When breakpoints stay hollow

Check:

• the request reached the same server you are debugging;
• the application pool did not recycle after you recorded the PID;
• the deployed DLL matches the source build;
• matching symbols loaded;
• the assembly is in the expected web application;
• compilation optimisation is not hiding the behaviour you expect;
• the account and request path actually execute the target code.

If the process crashes or recycles, stop and collect the Windows event, IIS and SharePoint evidence. Microsoft's IIS process-crash guidance provides a safer diagnostic path than repeated blind attachment.

Evidence boundary

Matching an application pool to a PID proves only which worker was active at that moment. It does not prove the request reached that worker, the correct assembly loaded or the bug sits inside SharePoint code.

For practical SharePoint Server administration and troubleshooting, join the SharePoint & Teams Admins Space.

Sources

• Microsoft Learn: troubleshoot an IIS application-pool process crash
• Microsoft Learn: SharePoint application pools and memory-limit recycling
• Microsoft Learn: troubleshoot SharePoint solutions in Visual Studio