How to set up remote debugging on a machine without Visual Studio
Taken from: how-to-implement-remote-debugging-in-visual-studio-2005
Let's consider an example to understand this situation clearly. Molly Clark and Adam Barr are both employees at Adventure Works. Adventure Works has a Microsoft Windows NT domain named adventure-works.com. Adam is having trouble with some software that Molly wrote. Molly would like to debug this software on Adam's computer. Molly and Adam follow these steps:
- Adam doesn't have the remote debugger on his computer. To set up the remote debugger, Molly decides to share out the Program Files\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger directory on her computer. She creates a file share called Remote.
- Adam runs \MollyComputerName\Remote\x86\Msvsmon.exe.
- After the remote debugger starts, Adam clicks Permissions on the Tools menu to configure the remote debugger by using the Permissions dialog box. He gives Molly permission to debug.
Note Adam could also configure the remote debugger by passing the /allow option when the remote debugger starts.- Molly starts Visual Studio 2005.
- To open the Attach to Process dialog box, Molly clicks Attach to Process on the Tools menu.
- Molly connects to Adam's computer by entering adventure-works.com\Adam@AdamComputerName in the Qualifier box.
- Under Available Processes, Molly selects the worker process that her application is using and then clicks Attach.
- Molly opens a browser and provides the URL to the remote application. The execution stops where the breakpoint is placed in the application.
Update: Here's the links for 2017 which are not obvious to find either.
Visual Studio Remote Tools Links x64 direct link
Visual Studio Remote Tools Links x86 direct link
certainly there is.
You can install msvsmon without installing visual studio.
I've done this myself on several machines.
the tricky part lays in authorization- the user running VS on your local machine needs special priviliges on the remote machine.
ms has some articles explaining the details- http://msdn.microsoft.com/en-us/library/bt727f1t.aspx,
I'm going to resurrect this because anyone who's tried to do this knows it's a complete pain in the ass every time, and that it changes slightly with every possible combination of host/remote system you can have.
Visual Studio Remote Tools Links:
- Visual Studio 2010 remote debugger. (Working as of 21/Oct/2016)
- Visual Studio 2013 remote tools (working as of 21/Oct/2016)
- Visual Studio 2015 remote tools x86 - Direct download link
- Visual Studio 2015 remote tools x64 - Direct download link
- Visual Studio Tools (Thanks Robo Burned)
- Visual Studio 2017 Remote Tools x64 - Direct download link (Thanks Isaac Baker)
- Visual Studio 2017 Remote Tools x86 - Direct download link (Thanks Isaac Baker)
- Visual Studio 2019 Remote Tools - download link
This is the setup I succeeded with today:
Host (Dev) Machine:
Windows 7 Ultimate SP1 x64. Running Visual Studio 2010, .NET Framework 4.
Remote Machine:
Industrial/Factory Floor PC running Windows Embedded Standard 32-bit. It looks/feels exactly like Windows 7. Running SP1. Visual Studio is not installed. Has the .NET framework 4.
Network:
Both machines are on the same subnet. I access the remote machine via RDP and run my application that way.
Microsoft-Proprietary Follicle-Deterioration Implementation:
Make note of your dev machine's user name and password. For some reason you have to create exactly the same user name and password on the remote machine. Because Microsoft.
How I did it:
I downloaded the Visual Studio 2010 remote debugger from the link provided by @sJhonny. I had to switch off of Visual Studio 2013 in that article and over to 2010. If you care to go over the 2010 article with a fine-tooth comb to find the download, the link is right next to the "No one ever finds this helpful" link at the top. If not, just follow my link above.
Install that on the remote machine and run the configuration wizard. I left the defaults for the wizard:
- "Run the 'Visual Studio ....." was checked off
- Username is LocalSystem and password is blank
- Allow only computers on the local network....
Run the Remote Debugger on the remote system and you'll see
Msvsmon started a new server named 'username@machinename...'
in the interface. So far so good. Run the application on the remote machine. On the dev machine, Ctrl+Alt+P in visual studio will open "Attach to Process" (It's also under the tools menu). I got a popup about my dev machine's firewall not being configured properly and was asked if I wanted to allow the connections etc... Say yes obviously.
Enter the 'username@machinename' combination into the qualifier box... press Refresh and pray a little. Pray a little more a lot harder and you should see a list of the processes running on the remote machine. Select your process and attach to it.
But my breakpoints don't work!? Of course they don't... because using the breakpoints in the same directory as the application on the remote machine would make too much sense. If you were lucky enough, you got warned about a breakpoint cache and got shown a dialog with a path.
The dialog mentions something about it being correct relative to the remote machine. It's lying. It has nothing to do with the remote machine except that it forced you to create a brand new user over there with the same name as your current user because Microsoft. To get your breakpoints to work, follow the path on your dev machine (customizable in Tools>Options>Debugging>Symbols: Cache symbols in this directory) and copy your application's .pdb files over to that directory. You have to copy them over with every new build, unless there's an option to do it automatically; I haven't checked because I have yet to stop celebrating my remote debugging success.
Everything should work now.
I hope that helps someone save the hours of blinding rage I've endured trying to get this to work on different machines over the years.