W3wp.exe Debugging Visual-studio

[Shane Rouse]

OpenVisual Studio in Administrator Mode, then Debug -> attach to process -> tick the check box "Show processes from all user", select w3wp.exe. Administration mode is required for debugging the source code.

I ran into this same issue today. To resolve the issue, I had to change the application pool to run as 32 bit application since I am debugging in visual studio 2017, which is still a 32 bit application.

In my case, I first launched the application, still could not find w3wp.exe. Then I took the worker process ID from (IIS->Worker Process -> Process Id) and then search by id in the details tab and found it.

In my case, the problem was that I wasn't running Visual Studio as Administrator. My machine had restarted after an update and relaunched all the previously running processes, but had only relaunched VS in non-admin mode. When I restarted VS in admin mode, the w3wp.exe processes were available again for debugging.

In my case, I needed to connect from one Visual Studio to the process which running from another VS studio window.

The problem was next: one VS was launched with Administrator permissions. For resolving that issue you should launch both VS with Admin perm.

Run the remote debugger as an administrator.I followed every suggestion to resolve the issue, but it was not until I ran the remote debugger as an administrator that I was able to see the w3wp process

Be aware that even after jumping through all these hoops (kicking off an instance using a web browser, starting your remote debugging session as an admin, ensuring that "show all users" is checked, etc., ensuring you aren't on a server farm, etc), you may still at times be out of luck.

There are times when the remote process, usually a WCF service in my case, simply will not show up in the list of processes to attach to, and there's nothing that can be done about it. I'm always careful to make my target process readily identifiable by keeping it and only it in a certain App Pool. Sometimes you just can't get there from here. This is undoubtedly the most frustrating thing about remote debugging Microsoft has ever done.

I am using VSTS 2008 + .Net 3.5 + C#. And I developed a custom Forms authentication module for IIS 7.0 and I attach to w3wp.exe to debug this module. During the attach process (I just select Tools -> Attach to Process, no further operation performed on the computer I am debugging -- I just wait for the attach to be completed), I met with the following error, any ideas what is wrong?

The web server process that was being debugged has been terminated by Internet Information Services (IIS). This can be avoided by configuring Application Pool ping settings in IIS. See help for further details.

Setting Ping Enabled to False stops IIS from checking whether the worker process is still running and keeps the worker process alive until you stop your debugged process. Setting Ping Maximum Response Time to a large value allows IIS to continue monitoring the worker process.

You can use Attach to Process to debug running apps on local or remote computers, debug multiple processes simultaneously, debug apps that weren't created in Visual Studio, or debug any app you didn't start from Visual Studio with the debugger attached. For example, if you're running an app without the debugger and hit an exception, you can then attach the debugger to the process running the app and begin debugging.

Starting in Visual Studio 2022 version 17.10 Preview 2, the Attach to Process dialog box has changed. If you need instructions that match the older dialog box, switch to the Visual Studio 2019 view (upper left version selector in the article).

In most local debugging scenarios, you can use Local. Some scenarios might require a different connection type. For more info, see other sections in this article or Common debugging scenarios.

Processes can start and stop in the background while the Attach to Process dialog box is open, so the list of running processes might not always be current. You can select Refresh at any time to see the current list.

You can be attached to multiple apps for debugging, but only one app is active in the debugger at a time. You can set the active app in the Visual Studio Debug Location toolbar or Processes window.

You can also select a remote computer in the Attach to Process dialog box, view a list of available processes running on that computer, and attach to one or more of the processes for debugging. The remote debugger (msvsmon.exe) must be running on the remote computer. For more information, see Remote debugging.

In most scenarios for remote debugging on Windows, you can use Remote (Windows). Some scenarios, such as debugging Linux or a containerized app, require a different connection type. For more info, see other sections in this article or Common debugging scenarios.

The Connection type setting persists between debugging sessions. The Connection target setting persists between debugging sessions only if a successful debugging connection occurred with that target.

If you try to attach to a process owned by an untrusted user account, a security warning dialog box confirmation will appear. For more information, see Security Warning: Attaching to a process owned by an untrusted user can be dangerous. If the following information looks suspicious or you are unsure, do not attach to this process.

In most scenarios, you can use Default. Some scenarios, such as debugging Linux or a containerized app, require a different connection type. For more info, see other sections in this article or Common debugging scenarios.

If you can't connect using the remote computer name, try using the IP and port address (for example, 123.45.678.9:4022). 4024 is the default port for the Visual Studio 2019 remote debugger. For other remote debugger port assignments, see Remote debugger port assignments.

In some cases, when you debug in a Remote Desktop (Terminal Services) session, the Available processes list won't display all available processes. If you are running Visual Studio as a user who has a limited user account, the Available processes list won't show processes that are running in Session 0. Session 0 is used for services and other server processes, including w3wp.exe. You can solve the problem by running Visual Studio under an administrator account or by running Visual Studio from the server console instead of a Remote Desktop session.

If neither of those workarounds is possible, a third option is to attach to the process by running vsjitdebugger.exe -p from the Windows command line. You can determine the process ID using tlist.exe. To obtain tlist.exe, download and install Debugging Tools for Windows, available at WDK and WinDbg downloads.

If you're publishing to Azure App Service (Windows), you'll find the Attach Debugger option under the ... menu under Hosting in the publish profile. Visual Studio attempts to attach the remote debugger to the instance of Azure App Service (Windows) that the profile is publishing to.

Starting in Visual Studio 2019, you can attach the Visual Studio debugger to a process running on a Docker container. For a Linux .NET Core Docker container, see Attach to a process running on a Linux Docker container. For a Windows Docker container, see Attach to a process running on a Windows Docker container.

You can quickly reattach to processes that you were previously attached to by choosing Debug > Reattach to Process (Shift+Alt+P). When you choose this command, the debugger will immediately try to attach to the last processes you attached to by first attempting to match the previous process ID and if that fails, by matching to the previous process name. If no matches are found, or if several processes have the same name, the Attach to Process dialog box will open so you can select the correct process.

To help you determine whether to use Attach to Process and what process to attach to, the following table shows a few common debugging scenarios, with links to more instructions where available. (The list is not exhaustive.)

3a8082e126