Debug ASP.NET application running on remote IIS Server from VS2010

Profile picture for BIDeveloper
BIDeveloper

Just wondered if anyone could point me in the right direction here?

I'm trying to debug a deployed web application and can't seem to get the attach to work. Here's the scenario:

VS2010 installed on my machine - with all source code.

IE8 on my machine browsing to ASP.NET site on production IIS server (FWIW .pdb files on production site.)

When I attach the debugger to the IE session, and continue browsing the site, no breakpoint is ever hit... so effectivly I don't think I'm really debugging the site!??

I'm guessing that I need some kind of remote debugging set up? If that's the case, if anyone knows of any URL to help that would be much appreciated!

Thanks in advance!

Jim

Here's a full step-by-step guide because there is a lot of scattered information and the linked Microsoft article assumes a lot of information.

First let's clarify the terms used throughout the rest of the guide:

diagram

Client is the computer on which you do development
Remote is the computer the code has been deployed to that is running on IIS

  1. Install msvsmon.exe (Microsoft VisualStudio Monitor) on the Remote computer.
    You can find the executable installed with Visual Studio on your Client at the following path:

    <!-- language: lang-none --> <pre><code><b>VS 2010</b>: C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger\x86 <b>VS 2017</b>: C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\Packages\Debugger\X64</code></pre>

    When the tool is up and running, you should see the following application:

    new server

    The Debugging Monitor has created a server that you can connect to remotely. If you're on a Windows machine, the the name is probably <Code><i>User@Remote</i></code>. Remember this name, because you'll need it later. If you want to copy it directly, you can go to Tools > Options and you'll see the server name. You can even change it to something else if you like.

  2. From here you can try the shotgun approach and see if everything works, but depending on your network configuration, there might be some additional hiccups. To attempt to debug remotely, open the project up in Visual Studio. This should be the same exact project that is deployed on IIS.

    In Visual Studio, you'll want to attach to the process on the new server. Go to Tools > Attach to Process or hit <kbd>Ctrl</kbd> + <kbd>Alt</kbd> + <kbd>P</kbd>

    attach to process

  3. In the Attach to Process dialog, change the Qualifier from your current computer's name to the new server name (<code><i>User@Remote</i></code>) and hit enter to see a list of the available processes on the remote computer:

    attach dialog

  4. If everything comes back right away, you're in good hands. It means there were no firewall policies preventing you from connecting with the remote server, and you can skip to Step 6.

    Alternatively, if you got the following message, it means your firewall is blocking the client and remote boxes from communicating.

    Unable to connect to the Microsoft Visual Studio Remote Debugging Monitor named 'User@Remote'. The Visual Studio Remote Debugger on the target computer cannot connect back to this computer. A firewall may be preventing communication via DCOM to the local computer. Please see Help for assistance.

  5. If you weren't able to connect, there could be range of problems depending on your domain policies. For the official firewall setups, you can check out Microsoft's Configure the Windows 7 Firewall for Remote Debugging, but I found it to be lacking in detail.

    If attaching failed, but you still get a message that the user connected like this:

    connected

    Then it means that the problem is not with the outbound rules on the client or the inbound rules on the remote server. It's much more likely the issue is with the inbound rules on the client machine.

    To fix this, on the Client computer, go to Control Panel > Windows Firewall > Advanced Settings which should open up Windows Firewall with Advanced Security. Select Inbound Rules and right click to enter a New Rule:

    new rule

    Give the rule any name. Based off advice in this SO question, instead of exempting particular ports, we'll allow all traffic to go through for any Visual Studio executable. Go to Programs and Services and select the full folder path to the 2010 install of visual studio:
    %ProgramFiles% (x86)\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe

    Then make sure that the rule only applies to computers within the domain (making sure private and public are unchecked).

    visual studio rule

    With any luck, when you go back to attach the process, you should be able to get into the remote machine.

  6. At this point, you should see a list of all the processes on the remote machine. If you wanted to debug a windows application, you'd just pick the name of the process. For ASP.NET, we want to attach to the w3wp.exe (WWW Worker Process). If you don't see it in the list, try kicking off the server by opening up the webpage of the application you'd like to debug. You can do this on localhost or by navigating to the address in IIS from any computer.

    attach dialog connected

    Make sure to attach to the right type of code for your application. You can select between native (C++, etc.) or Managed (VB, C#, etc), or select automatic and let Visual Studio decide.

  7. If you get the following error, I found that reopening Visual Studio and msvsmon.exe with Admin privileges fixed the issue

    Unable to attach to the process. The Visual Studio Remote Debugger (MSVSMON.EXE) has insufficient privileges to debug this process. To debug this process, launch the remote debugger using 'Run as administrator'. If the remote debugger has been configured to run as a service, ensure that it is running under an account that is a member of the Administrators group.

  8. You'll see a security warning that you can accept by clicking Attach:

    security warning

  9. The last issue I ran into was the getting the Debugger Files to load. You need to make sure that the libraries that are being executed exactly match the ones that are currently loaded in visual studio and that they have the correct .pdb files in the solution on the client machine. You can inspect which modules were loaded and where they loaded from by going to Debug > Windows > Modules or hitting <kbd>Ctrl</kbd> + <kbd>Alt</kbd> + <kbd>U</kbd>. For more on loading debugger files, you can also try any of the following resources:

Hopefully it's up and working for you at this point. Now you can catch any calls made into your IIS hosted code and step through them same as you would during development.

Proof of Concept

Further Reading: