Debugging Deployed ASP.NET Applications
Applies to: 
Visual Studio 
Visual Studio for Mac
Note
This article applies to Visual Studio 2017. If you're looking for the latest Visual Studio documentation, see Visual Studio documentation. We recommend upgrading to the latest version of Visual Studio. Download it here
To use Visual Studio to debug a deployed application, you must attach to the ASP.NET worker process and make sure that the debugger has access to symbols for the application. You must also locate and open the source files for the application. For more information, see Specify Symbol (.pdb) and Source Files, How to: Find the Name of the ASP.NET Process, and System Requirements.
Warning
If you attach to the ASP.NET worker process for debugging and hit a breakpoint, all managed code in the worker process halts. Halting all managed code in the worker process can cause a work stoppage for all users on the server. Before you debug on a production server, consider the potential impact on production work.
The process for attaching to the ASP.NET worker process is the same as attaching to any other remote process. When you are attached, if you do not have the correct project open, a dialog box appears when the application breaks. This dialog box asks for the location of the source files for the application. The file name that you specify in the dialog box must match the file name specified in the debug symbols on the Web server. For more information, see Attach to Running Processes. To set up remote debugging on IIS, see Remote Debugging ASP.NET on a Remote IIS Computer.
Note
Many ASP.NET Web applications reference DLLs that contain business logic or other useful code. Such a reference copies the DLL from your local computer to the \bin folder of the Web application's virtual directory when you deploy your app. When you are debugging, remember that your Web application is referencing that copy of the DLL and not the copy on your local computer.