Click here to Skip to main content
15,395,257 members
Articles / .NET
Technical Blog
Posted 16 Jan 2011


45 bookmarked

Remote debugging with Visual Studio 2010

Rate me:
Please Sign up or sign in to vote.
4.79/5 (20 votes)
16 Jan 2011CPOL4 min read
Remote debugging with Visual Studio 2010

I've recently needed to remotely debug a .NET desktop application with Visual Studio 2010. After having read the MSDN documentation on this subject, I still missed some information. I hope that this post will fill some of these gaps and will help you configure and run the remote debugging tools.

Let’s first start with a definition of parts involved in the debugging process:

  • host – is a machine on which Visual Studio is installed and on which you control the debugging process
  • remote computer – is a machine on which the debuggee is run

Since the debugging process is wholly controlled from the host, there must be a listener on the remote computer that executes commands sent from Visual Studio. This listener is called Remote Debugging Monitor (msvsmon.exe). There are two possible ways to install it – you can either download and run the setup package from Microsoft or copy all the necessary files from C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\Remote Debugger (path on my 64-bit Win7). A caveat here: If your host is x86 machine, then you have no choice but x86 package for your remote computer – there is no way you can debug a 64-bit process in a 32-bit debugger. Though you can debug 32-bit process in a 64-bit debugger.

Next step (the most boring and error prone in my opinion) is a network setup. Ideally Visual Studio and Remote Debugging Monitor should take care of the Windows Firewall settings after you run them with the elevated privileges, but life is life and you might need to get your hands dirty. Fortunately the manual configuration process is pretty well explained on MSDN sites for WinXP, Vista and Win7. The next important thing is security. You can either perform debugging in “NoAuthentication” mode (which is of course less secure) or in Windows Authentication mode. Unfortunately Windows Authentication mode requires the same account to be setup on the host and the remote computer – both usernames and passwords must be the same. If it’s a problem for you, then you are left with the “NoAuthentication” mode in which you take a risk of allowing all people to access your debugging monitor.

Having finished the configuration part, we may finally start the debugging process. Begin with starting msvsmon.exe (Remote Debugging Monitor) on the remote computer – it will communicate with Visual Studio running on the host. Let’s assume that our application is named RemoteControl.exe and is written in C#. First, we need to deploy it on the remote computer, for example into the C:\Users\concept\Desktop\RemoteControl folder (remember to copy also all the pdb files and the assemblies required by the main application). We can now either start the application under the debugger or attach the debugger to the already running process. Let’s start with the first scenario. If you have access to the application solution folder and to all the project files, then you can start the remote debugging by modifying the start project properties page:

If you don’t have access to the application solution, then you need to use the application EXE file. From File menu choose Open->Project/Solution… and find the EXE file for your application. Select the newly opened project and choose properties. Fill the page with following values:

Attaching to the already started process is fairly simple: From the Debug menu, choose Attach to process…. If you are debugging in the Windows Authentication mode, set the Transport box to Default. In Qualifier field, type name of your Remote Debugging Monitor session. Usually it is your user name + @ + the remote computer name, for example Sebastian@REMOTE-PC (the session name is also displayed in the listbox after you start the msvsmon.exe).

Finally, a few words about the debugging process. Unfortunately the debugging symbol configuration differs depending on the chosen debugging engine (native, managed, mixed). When using managed debugging engine symbols must be accessible on the remote computer (so you need to deploy your application with all pdb files and set_NT_SYMBOL_PATH variable on the remote computer for .NET Framework debugging symbols). When using native debugging engine symbols are loaded from the host machine (so you must include the directory with all pdb files for your application into the Visual Studio symbols search path – Tools->Options->Debugging->Symbols). Interestingly, source files are always loaded from the host machine (in case that you don’t use any kind of source server). To summarize: remember to always choose the managed engine for your .NET applications that don’t have any interop parts. The native engine requires much more information (like symbols for all native libraries) and provides you with capabilities that are usually not necessary in debugging pure .NET application.

I haven’t touched the subject of the web applications remote debugging and running Remote Debugging Monitor as a service. Leave a comment if you wish such a post to appear in the future. :)

Filed under: CodeProject, Debugging, Visual Studio


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Sebastian Solnica
Software Developer (Senior)
Poland Poland
Interested in tracing, debugging and performance tuning of the .NET applications.

My twitter: @lowleveldesign
My website:

Comments and Discussions

GeneralWorked like charm Pin
Torsten Tiedt30-Sep-13 3:22
MemberTorsten Tiedt30-Sep-13 3:22 
QuestionCan't start debugging Pin
BMW74028-May-12 4:36
MemberBMW74028-May-12 4:36 
AnswerRe: Can't start debugging Pin
BMW74030-May-12 2:52
MemberBMW74030-May-12 2:52 
QuestionUser Accounts and Remote Debugging Pin
Scientific Mitch23-May-12 10:57
MemberScientific Mitch23-May-12 10:57 
AnswerRe: User Accounts and Remote Debugging Pin
Lyubov Zvereva7-Nov-12 0:28
MemberLyubov Zvereva7-Nov-12 0:28 
GeneralRe: User Accounts and Remote Debugging Pin
Lyubov Zvereva7-Nov-12 23:31
MemberLyubov Zvereva7-Nov-12 23:31 
QuestionUnable to initiate DCOM communication Pin
Andrew Phillips21-Mar-12 12:21
MemberAndrew Phillips21-Mar-12 12:21 
I am trying to get the remote debugger working using Windows Authentication. (Using no authentication with a managed application does not seem to allow setting breakpoints.) The systems are in different domains so I have had to set up local users on both systems.

I have done all that the documentation says to do (and more) and I still get the error (see below). I have turned off firewalls on both systems, set up users (with admin privileges) on both systems with the same name and password, run dcomcnfg and allowed Remote Access, Remote Launch and Remote Activation to ANONYMOUS LOGON and Everyone (using Edit Limits button in DCOM Securtity).

I have checked the Windows Authemtication is working by opening a file share in both directions. I also rebooted both machines (as the MSDN help says) and checked the event logs in event viewer on both systems and there are no Kerberos or other security errors or warnings.

The only complication that I can think of is that the host system is running under VMware on the target system, but this is through "Bridged" networking so Windows should be oblivious to this.

Nothing I try gets rid of the DCOM error. Any ideas would be appreciated.

Microsoft Visual Studio
Error while trying to run project: Unable to start debugging.

The Microsoft Visual Studio Remote Debugging Monitor on the remote computer cannot connect to the local computer. Unable to initiate DCOM communication. Please see Help for assistance.
OK Help
Andrew Phillips
andrew @

AnswerRe: Unable to initiate DCOM communication Pin
Andrew Phillips21-Mar-12 16:42
MemberAndrew Phillips21-Mar-12 16:42 
GeneralMy vote of 2 Pin
oren.shnitzer25-Jan-12 5:11
Memberoren.shnitzer25-Jan-12 5:11 
QuestionCannot get the debugger to hit the breakpoint ! Pin
d_lina6-Dec-11 0:00
Memberd_lina6-Dec-11 0:00 
AnswerRe: Cannot get the debugger to hit the breakpoint ! Pin
Member 38224758-Dec-11 15:30
MemberMember 38224758-Dec-11 15:30 
AnswerRe: Cannot get the debugger to hit the breakpoint ! Pin
Andrew Phillips21-Mar-12 12:01
MemberAndrew Phillips21-Mar-12 12:01 
AnswerRe: Cannot get the debugger to hit the breakpoint ! Pin
hans.sch15-Jul-13 21:32
Memberhans.sch15-Jul-13 21:32 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.