How to be a Debugging Ninja!
How many times have you had someone come up to you with a problem that they couldn’t describe?
And if they could describe it, you can’t reproduce the problem on your machine.
And even if you know where the problem might be (thanks to an error code or the like), you have no idea what conditions are causing it to occur?
And say those initial conditions have to do with the mouse moving or the application repainting, and thus even switching between the app and the debugger causes the problem to go away?
Man, you’d need some stealthy way of debugging the application from behind without even being at the computer!
Time to bust out some ninja remote debugging skills.
Step 1 – Start!
For Visual Studio, this is usually under:
C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\Remote Debugger\x86\msvsmon.exe
Substitute in your version of VS and your target architecture.
Run this program on their machine. You can do this by either having it installed on their box or what I usually do is use a network share and just run it directly:
\\mymachine\C$\Program Files\Microsoft ...\msvsmon.exe
Step 2 – Configure!
Go Tools -> Options. You should get a dialog like this:
Choose No Authentication. Note the warning about no authentication: do this only if you are on a private network and at your own risk.
Step 3 – Attach!
Now on your machine, with the project opened in Visual Studio, go Debug -> Attach to Process. Choose Remote, enter the machine name for Qualifier and click Refresh.
The dialog on the clients machine should state that you have connected and you should see the list of processes on that machine:
Choose the process you want to attach to and click Attach
Step 4 – Debug! Ninja Attack!!
You can now place break points in your source code (assuming it and your symbols are the same version as the clients machine). A good way to test if things are working is to try Debug -> Break All and see where you end up.
Note the advantage you have now: you can observe the program state using break points with When Hit conditions, you can stop when you hit certain error conditions or when exceptions are thrown and all without changing the state of the program.
This is a great way to either find hard to reproduce problems that only occur on someone else’s machines or problems that are “finicky” like mouse movement, keyboard hooks or program repaints.
Effective use of remote debugging will increase your amazingness substantially as you will be able to fix problems that no one else can. Imagine, you could be as amazing as I am...
