One of the oldest mechanisms for remote Windows debugging is the venerable remote.exe, which ships with the DTW package. Remote.exe essentially just pipes console input/output over a the network, which means that you can only use it for the console debuggers (cdb, kd). This mechanism has the server end of the remote debugging session do all of the “hard work”, with the client acting as just a dumb user interface.
To start a remote server, use the following:
remote.exe /s "command-line" instance-name
where “command-line” is the debugger command line (for instance, “cdb notepad.exe”), and instance-name is a unique identifier (you can pick anything) that allows the remote client to select what program to connect to.
To connect to a remote server, you can use this command:
remote.exe /c computer-name instance-name
where computer-name is the name of the computer running the remote server, and instance-name matches the value you passed to remote.exe /S. To quit the remote client, you can send the special string “@K” (and hit enter) on its own line, which will terminate the remote session (but will leave the remote server running). Likewise, you can enter the “@K” command on the server end of the console to quit the server and terminate the redirected process.
That’s all there is to it. You can actually use remote.exe to control console programs other than cdb/kd remotely, as it doesn’t really have any special intelligence about interacting with the program you are running under remote.exe.
The remote.exe method is the most lightweight of all of the remote debugging options available to you, but it’s also the most limited (and it doesn’t have any concept of security, either). You might find it useful in scenarios where you are very limited on bandwidth, but for most cases you are much better off using one of the other remote debugging mechanisms.
Update: Pavel Lebedinsky points out that you can set a security descriptor on the remote.exe pipe via “/u” and “/ud” (though this will require that you have either local accounts with the same password as a remote user, or a trust relationship [e.g. domain] with the remote computer). This does allow for some form of access control, though it is generally convenient only if both computers are on the same domain from what I can tell.
Typically my problem is the reverse, i.e. I want everything, or at the very least symbol downloads, to be done by the client.
There are actually a couple of options that will allow the client to do the “heavy lifting” (including symbol access, which is nice if you have internal symbols that you don’t want to make available to a debugger running on a customer system) which I’ll talk about in a day or two. They are bandwidth and latency sensitive however.
[…] If you are using the NTSD over KD remoting technique, this is usually less of a concern, since you are usually operating over a serial or 1394 cable physically connecting the two computers. For plain -server and -remote debugging, or remote.exe debugging, however, this problem is more serious as these methods are typically used over networks. […]
[…] Most of the debugging mechanisms I have gone through so far will also support kernel debugging, though I have not focused on this fact. You can use remote.exe for controlling KD remotely, and -server/-remote for controlling one KD through another KD or WinDbg. Both of these mechanisms can be used to control a kernel debugger remotely (keep in mind that you still need a separate computer to run kd.exe on from the target computer of course), however, they do not allow the same flexibility as dbgsrv.exe does. This means no client-side symbol access, and no client-side debugger extensions. […]
> it doesn’t have any concept of security, either…
remote.exe does have some security options to control who can connect to the pipe (/u etc).
Thanks. Updated the post accordingly. It seems like this is going to be a bother to use unless you are on the same (or a trusted) domain.
I was pretty much unaware of these many debugging tools and there usages ,Thanx for sharing them .Its really s nice blog keep it up .