Sometimes you can’t run a debugger in a local environment and you have to remotely debug your deployed code. This can be a tricky process and if there is a missed step along the way, can prove to be a pretty annoying troubleshooting process.
NOTE: In order to run a remote debugging session successfully, you’re going to need locally the exact same code base that you’re running on the server.
First you’re going to want to RDP into the machine your code is deployed on. Go to the link below, download and install the remote debugging monitor.
For our configuration we chose to not run the debugger as a service while going through the install wizard.
Here you might run into your first pitfall. While the remote debugging configuration wizard and Visual Studio are more than capable of making the correct firewall adjustments some third party software or your own configurations could be set up in a way where VS2010 or the Wizard miss a setting. Guides to setting up your firewall for remote debugging can be found at the following links depending on your operating system.
Up until now this is pretty standard with most tutorials you’ll find on the subject. When you launch the remote debugger monitor and attempt a connection via the “Attach to process” option in the Visual Studio “Tools” menu. With the ‘transport’ option set to default and the qualifier set to the name of your remote debugging process (likely userName@machineName) you’ll most likely receive an authentication error.
If you don’t get an error and you’re able to connect to the remote computer for debugging you may stop reading here. You are likely on the same domain as the remote server and have passed authentication.
However, since most of us are on site with the client and are rarely if ever are on the same domain as the remote server we won’t pass authentication. This is because even though you might be signed into the required Administrator security level on both machines and possibly logged into the same user name, the hand shake that takes place between the local machine and remote server doesn’t think it’s the same user and will reject the request.
So what we have to do at this point is fool the remote debugger monitor into thinking we are the same user by setting up user accounts on both systems that can host this process.
The following steps should be performed on both machines identically.
- Start Button –> Right-Click on Computer –> Manage.
- Click Local Users and Groups –> Click on Users –> Right-Click and ‘Add User’
- Add the user name and password
- Uncheck the “User must change password on next login”
- Check Password never expires (not required, more for convenience)
- Click Local Users and Groups –> Click on Groups –> Click on Administrators –> Right-Click and ‘Add to Group’
- Click on “Add”
- Under locations make sure the computer name is selected. (NOTE:Use the computer name of whatever machine you’re on. For example, my local machine name: SCHWIRZ, the remote machine:DEV_SVR)
- Type the user name you just created and click “Check Names”. If the user validates click “OK”
- Click “Apply” –> Click “OK”
Now, on the remote machine when you start the remote debugger monitor you’re going to want to run it as the user you had just set up. Just Right-Click and click on ‘Run as’. Select “The following user:” option and click on the user from the drop down list.
On you’re local machine you’re going to want to run Visual Studio as the the user you just created. Open up your project and attempt to connect to the process again. This should now pass authentication and you can select the server process you want to attach to and debug.