Visual Studio 2015 Remote Debugging

When developing with expensive and unusual hardware in a team environment, debugging and testing can quickly become a chore; swapping devices with other developers and making concessions to complete individual components can quickly cripple a projects momentum, and may even lead to integration issues from oversights often made when a full set of hardware isn’t available to all developers for end-to-end debugging. Remote Debugging offers a clean solution to this, and Visual Studio 2015 makes this easy across multitude of different devices.

The application that I encountered that lead me on the quest to setting up a debugging environment was a work project involving a kiosk, which requires a number of external machines to be connected to it to accept and dispense money, print, and conduct cashless payments. I had heard of remote debugging previously, and had a few hesitations and questions:

  • Will it work without domain membership on all computers?
  • Does it use authentication?
  • Can I make it difficult to use the debugging machine for anything beyond debugging?
  • Is it simple to configure and maintain?

The end result was clean and simple to use, with minimal configuration. Note that all computers are using Windows 10, build 10586 or higher, and Visual Studio 2015 Update 1.

Development Hardware on Remote Debugging enabled computer.

Client Preparation

Firstly, the client should be prepared. This includes installing the debugging tools, securing the client machine, and configuring options to ease use and maintainability. I used this MSDN article (Set Up the Remote Tools on the Device) to get started.

  1. Install the Remote Debugging Tools, obtainable from Microsoft’s download site. You may need to restart afterwards.
  2. On the first run, you will need to configure some preferences. If you aren’t presented with the following window upon attempting to run the program, don’t worry – just enable a firewall exception on the nominated port which we will cover later.
  3. Set up a user account with a password if you don’t already have one, which can be used to access the file share which will hold the debugable application, and connect to the remote debugging tools.
  4. Set up a Windows share, with full permissions for the nominated user. VS2015-remote-debugging-08Remember to set full access in both the security and sharing pages. VS2015-remote-debugging-09I use hidden shares, as denoted by the ‘$’ following the share name. VS2015-remote-debugging-07
  5. Set a static IP address. In a domain environment, I prefer to achieve the same outcome via the DHCP server with a reservation instead. This isn’t strictly necessary, but simplifies things.
  6. Run the remote debugging utility from the start menu if it is not already running. VS2015-remote-debugging-03Permissions, authentication type, and port must now be set. Within the utility, click Tools, ‘Options’ to open the Options dialogue.VS2015-remote-debugging-04
  7. Set the default port of 4020, Windows Authentication, and add the desired user as the debug user in permissions.VS2015-remote-debugging-05
  8. Note the computer name if not a domain member, for remote authentication later.

Make Machine more Appliance-Like (Optional)

  1. Disable power saving, and update power preferences. I like to use the high-performance profile, set the power and sleep buttons to shutdown, disable sleep, and ensure the screen never turns off.
  2. Set up auto login. This can be done in accordance with this TechNet article about Setting up a kiosk.
    1. Open ‘RegEdit.exe’.
    2. Locate ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon’.
    3. Set ‘AutoAdminLogon’ to ‘1’.
    4. Set ‘DefaultUserName’ to the desired username.
    5. Set ‘DefaultPassword’ to the desired password. Note that if either the username or password key is missing, you can simply add a string value at this location.
  3. Replace the shell with the debug client. This can be done in accordance with this superuser question (
    1. Open ‘RegEdit.exe’.
    2. Locate ‘HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\Winlogon’.
    3. Set ‘Shell’ to the full path of the executable you wish to run. In my case, this was ‘C:\Program Files\Microsoft Visual Studio 14.0\Common7\IDE\Remote Debugger\x64\msvsmon.exe’.
    4. Restart. (Press Ctrl+Shift+Escape to bring up task manager if needed, when explorer isn’t running. From here you can start new tasks like ‘regedit’ or ‘explorer’).

Configure Solution

It’s now necessary to configure the solution to utilise this remote debugging agent. This can be done by modifying the local build configuration rather than making a new build configuration, but this will make it difficult to debug locally, and will prove to be more of a hindrance in a team environment.

  1. Connect to the windows share, and remember the credentials. You may need to connect to the \\COMPUTER and authenticating, before connecting to \\COMPUTER\MYSHARE$. If the remote debug machine is not a domain member, log in with COMPUTER\USERNAME.
  2. Open the solutions configuration manager. This can be found on the tool bar at the top of visual studio or in the solution properties.VS2015-remote-debugging-11
  3. Add a new Solution Configuration, and name it appropriately. You may wish to copy settings from your current profile. It’s likely that you will want to also create project configurations; tick the box.VS2015-remote-debugging-12
  4. Set the Active Solution Platform if desired, or adjust the project platforms against the profile.VS2015-remote-debugging-13
  5. Open the project properties for executable projects, and navigate to the ‘Build’ tab. Here you will need to ensure the ‘Configuration’ is set to the new one you have created, and set the output path to your share.VS2015-remote-debugging-14
  6. In the project properties, navigate to the ‘Debug’ tab and tick “Use remote machine”, and set the field to the IP address of the target computer.VS2015-remote-debugging-15
  7. Save All.

You should now be able to select the solution build configuration from the upper toolbar, and start debugging as usual. You may be re-prompted for authentication, log in as you would a windows file share, and remember credentials.