Nynaeve
April 19th, 2008, 17:13
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:
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:
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.
To start a remote server, use the following:
Code:
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:
Code:
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.