Remotely Debug a Running Process with Visual Studio .Net.
Here goes my attempt to explain the process of remotely debugging any application written with C#, VB/Visual Basic or C++. In order to do this, all you will need is Visual Studio .Net Pro & an application with source code available to debug. (VS.Net 2008 Express will do c++ but you still need pro for C# or VB...)
Microsoft's Remote Debugging Monitor
The Remote Debugging Monitor is basically a server that Visual Studio connects to for, well, remotely debugging code... This will need to be running on the remote machine that the process you want to debug is on.
If you have Visual Studio installed on the remote machine. You can start the Remote Debugging Monitor from the start menu by going to: Microsoft Visual Studio -> Visual Studio Tools -> Visual Studio Remote Debugger.
Otherwise, you can copy the needed files to the remote machine & start it over there.
The files you will need are located in the Visual Studio file in the "Common\IDE\Remote Debugger" file.
So copy these files over to the remote machine and start msvmon.exe.
- mcee.dll
- msvb7.dll
- msvsmon.exe
- msvsmon.exe.config
- symsrv.dll
- vjscompee.dll
Getting your project Ready
Now open your project with Visual Studio & put all of your breakpoints in. If you need some time to allow you to connect before a break point will be hit, put in a sleep. I gave myself 25 seconds. (System.Threading.Thread.Sleep(25000);)
It doesn't matter how you start your program on the remote machine but it does matter that your .pdb file is in the same location as the .exe when it's run. The .pdb file contains the information about the code in relation to the breakpoints. So copy your projects .pdb file to the same location of your .exe. It can be found in the projects folder under:\bin\Debug.
Attaching Visual Studio to the remote process
Go to the machine you have Visual Studio running on & go to "Debug -> Attach to Process..." on the task bar. Make sure the Qualifier is the name of the remote computer you are attaching to and that you can connect & view the running processes. If you have problems check out: http://support.microsoft.com/kb/910448
Now start the process on the remote machine, click on it in the Attach to Process window, and click Attach. As soon as the process hits a Break Point, assuming you left yourself enough time to attach before the break. All of the code should appear in your debugger and you'll be able to step through & debug as normal.
Reasoning
I was writing an application using WMI to remotely install an enterprise network capture agent on several hundred servers. I ran into a problem where certain operations or lines of code, didn't have enough security privileges. What I found out is that even if you are an admin on the machine, depending on where your code starts & how it is started, each line is subject to Code Access Security. There are ways around this, (another article to come...) but it turns out that my app was failing because I was trying to gain access to an environment variable. Being able to remotely debug this process made it much easier to find out my error.
Thanks for reading and please leave a comment to let everyone know how this helped you out.

1 comments:
Can anyone recommend the top performing Network Monitoring system for a small IT service company like mine? Does anyone use Kaseya.com or GFI.com? How do they compare to these guys I found recently: N-able N-central software deployment
? What is your best take in cost vs performance among those three? I need a good advice please... Thanks in advance!
Post a Comment