May 23, 2014, 6:00 AM — As is the custom, the code which works perfectly in your local environment rarely works as perfectly in your remote test environment. Some issues can only be reproduced on the different hardware running as a different service account etc. To find out exactly what’s happening in that environment, you need to set up remote debugging.
Remote debugging in Visual Studio allows you to step through code, set breakpoints, review objects, inspect the stack, and catch errors on a remote server just as if you were running the code locally. While generally dog slow, this capability is invaluable when mysterious problems crop up in another environment.
Microsoft has made the setup of this magical feature pretty simple, but there are a few gotcha’s that always cause me headaches. To get started, you need to install the Visual Studio Remote Tools on the server you want to debug remotely. Once you install the service, you’ll find a link to the remote tools configuration wizard in the start menu on the server. Running that will allow you to specify the account for the service to run under, or if you prefer, set up the monitoring tool to run as a user account instead of a service. After you complete the wizard you can start the Remote Debugger Monitor by running the program from the server’s start menu. That’s it for the server side in most cases.
Next you need to connect to the server from visual studio so you can attach to the w3wp process. Before you do that however, here are two important items to note:
You must have the same version of the code on the server as you have locally, so make sure you publish your solution before trying to debug it.
You must publish the Debug version of the code to the server. If you publish the Release version, the .pdb files which contain all of the debug symbols will not be included and you won’t be able to debug remotely.
With the latest debug code pushed up to the server, you should be able to connect up and attach to the process to begin debugging. From Visual Studio, go to Debug -> Attach to process. In the Qualifier field, type the IP or the hostname of the server you want to connect to (the port should default to 4018 automatically), then press the Refresh button at the bottom. If you’re successful in reaching the server, you’ll see a list of running processes.
If you don’t see the w3wp.exe process in the list, be sure you’ve checked the “Show processes from all users” box. If you still don’t see it, navigate to the application in a web browser to kick off the process, then refresh again.
Once you find the w3wp.exe process, highlight it and click the “Attach” button. Your local client and the server will sync up the symbol files, which can take a minute, and then you should be connected to the remote debugger. You’re now free to set breakpoints in your local code which will be hit from the remote execution.
Once you set a breakpoint, open a web browser and navigate to the application on the remote server. When you do, you should hit your breakpoint just as you would if you had launched the program locally.