Dot Net Mafia

Group site for developer blogs dealing with (usually) Ionic, .NET, SharePoint, Office 365, Mobile Development, and other Microsoft products, as well as some discussion of general programming related concepts.

This Blog



Corey Roth [MVP]

A SharePoint MVP bringing you the latest time saving tips for Ionic, SharePoint, and Office 365.

How to: Remote Debugging a Web Application

After talking to many different developers, I appear to be one of the few ones that have gotten remote debugging to work with a reasonable success rate.  That is why I have decided to post on it today.  Everything I am writing today is based upon my experience in what has worked and may not necessarily be a best practice.  I actually posted about this once in the past, but I think its worth going into more detail.

Preparing Your Server

The first step is to install the remote debugging tools on your server.  To do this, run rdbgsetup.exe contained in the Remote Debugger folder of your Visual Studio 2008 or Visual Studio 2005 installation media.  Be sure and pick the correct processor architecture (x86, x64, or ia64).  To use remote debugging, you can either install a Windows service or run an application.  Although, the service is more convenient if you are going to be debugging a lot, the application is a lot easier to get up and running.

Running the Remote Debugger

Once you have got the remote debugger installed, I typically use remote desktop to log into the server and start the Visual Studio 2008 Remote Debugger.  This really will only work right if the account you are logging into the server with is also the same account you log into on your client machine that is doing the remote debugging.  If its not, there are some complications and you'll legitimately get the error I have posted about here.

One thing to note.  The Visual Studio 2008 Remote Debugger is not backwards compatible with Visual Studio 2005.  Therefore, you need to be sure and install the Remote Debugger from the same version of Visual Studio you are debugging with.  It is ok to have them both installed at the same time, but I don't believe you can have both running at the same time (need to confirm though).

Preparing your environment

When you are ready to start remote debugging, start by compiling your web application.  You then need to copy the DLL and PDB file from your bin/debug folder to the bin folder of the web application on your server.  Not doing this is one of the most common causes for a breakpoint to never be hit when remote debugging.  If the DLL and PDB do not match between the client and the server, the breakpoint will never be hit.

Start Debugging

Once everything is in place, it is time to start debugging.  To do this, click on Debug -> Attach to Process in Visual Studio when you have your web project open.  If everything is good and all the permissions match up, you should be able to type your server name into the Qualifier box and view its processes.  Typically, when I do this, I am a local administrator on both the client and the server.  I think this is more permission than needed though.  I believe there is a Remote Debuggers security group that can be used.

The way you start debugging is by attaching to w3wp.exe.  However, it is more than likely that you will have multiple application pools on your server (especially if you are using SharePoint) which means more than one w3wp.exe process.  To determine which w3wp.exe to use, you can just pick one arbitrarily and then examine the modules window in Visual Studio and look for your DLL.  You can also look at the username on the process and see if it matches the one on the application pool you want, or you can use a cscsript command to get a list of the w3wp.exe processes and which site they match in IIS.

Once you have attached to the correct w3wp.exe, set a breakpoint open a web browser and hit the page you want to debug.  Assuming you set a breakpoint and did everything correctly, the breakpoint wont give you a message that the symbols could not be loaded and the breakpoint cannot be hit.  If you were able to set your breakpoint, open a web browser and hit the page you wanted to debug.  If all goes well, your breakpoint will be hit and you can debug just like it was on your local machine.



Remote Development, Deployment, and Remote Debugging your first SharePoint 2007 Program « Stuff I geek with said:

Pingback from  Remote Development, Deployment, and Remote Debugging your first SharePoint 2007 Program « Stuff I geek with

December 4, 2008 7:10 PM

Paul said:

Also make sure that you select the Default transport (instead of that juicy looking Remote option) and attach to Common Language Runtime instead of Native.  The Native type doesn't load any useful debug symbols so your breakpoints will never be hit if you do that.

December 17, 2009 8:43 PM

Kostadinnm said:

Is that aplicable to SharePoint 2010?!

November 10, 2010 9:56 AM

CoreyRoth said:

@Kostadinnm Yes, it should work in SharePoint 2010 as well.

November 10, 2010 10:07 AM

Javin @ Tibco Tutorials said:

Nice article ,Remote Debugging was the single most feature which convinced me to migrate from Netbeans to Eclipse.



<a href="">How to setup remote debugging in Eclipse </a>

February 27, 2011 2:12 AM

Blog del CIIN said:

Una pregunta habitual cuando se comienza a desarrollar en plataforma SharePoint es la relativa a como

October 26, 2011 4:23 PM

SharePoint 2010: Desarrollo y depuración contra sitios remotos (I)! « Pasi??n por la tecnolog??a… said:

Pingback from  SharePoint 2010: Desarrollo y depuraci&oacute;n contra sitios remotos (I)! &laquo; Pasi??n por la tecnolog??a&#8230;

October 26, 2011 4:26 PM

Brunno said:

I did everything you told in the article and no symbols have been loaded.

December 16, 2011 12:37 PM

Brunno said:

Oh, and when a try to load symbols manually, I receive the following message: A matching symbol file was not found in this folder.

Thanks in advance.

December 16, 2011 12:39 PM

CoreyRoth said:

@Bronno If no symbols are loading.  Start over, recompile and try again.  Usually, the number one reason is that the DLLs don't match exactly between the client and the server.  Either that and Visual Studio is not cooperating and sometimes it just takes multiple attempts. :(

January 5, 2012 3:58 PM

Leave a Comment


About CoreyRoth

Corey Roth is an independent SharePoint consultant specializing in ECM, Apps, and Search.
2018 dotnetmafia.
Powered by Community Server (Non-Commercial Edition), by Telligent Systems