Moving onwards to the more modern remote debugging services available, the next option available for remote debugging with the DTW package is -server\/-remote.\u00c2\u00a0\u00c2\u00a0 This remote debugging mechanism is one that you may find yourself using fairly frequently.\u00c2\u00a0 Its advantages are rich functionality\u00c2\u00a0and integration with the WinDbg GUI (as a remote client), and reasonably low bandwidth usage, though not quite as lightweight as the previous options.<\/p>\n
This mechanism allows you to connect one (or more) debugger clients to a debugger server.\u00c2\u00a0 This can allow for a limited set of collaboration between multiple people debugging the same problem.\u00c2\u00a0 Unlike the other mechanism discussed thus far, -server\/-remote utilizes a more advanced protocol that while leaving most of the “hard work” (including symbol management)\u00c2\u00a0to the debugger server, allows things like the various WinDbg debuggee status windows to work and receive useful information (i.e. not just command window text).\u00c2\u00a0 So, when using this protocol with WinDbg as the client, you can utilize the memory \/ disassembly \/ register windows (and soforth).\u00c2\u00a0 Note that you can use any of WinDbg\/ntsd\/cdb\/kd as either a client or server with this protocol.\u00c2\u00a0 It can be used for any debugging type that is supported by these debuggers, including dump file debugging.<\/p>\n
The protocol also provides for varying forms of security.\u00c2\u00a0 You can use simple plain text password authentication, or if you want true security, SSL over named pipes or TCP.\u00c2\u00a0 The protocol can operate over several underlying transports; tcp, com (serial port), 1394, or named pipes (note that this is the transport used to communicate between the debugger server and debugger client, not related to the medium that is used to connect to the target in kd).<\/p>\n
When using -server\/-remote, it is important to ensure that both the debug client and debug server are from the same DTW package; otherwise, unexpected results may occur (typically resulting in the connection failing silently).\u00c2\u00a0<\/p>\n
There are many different ways to activate this remote debugging mechanism; you can start a debugger with -server to create a debugger server, or with -remote to act as a debugger client.\u00c2\u00a0 Alternatively, you can use the .server command to create a debugger server out of an existing debugging session.\u00c2\u00a0 If you are using WinDbg, you can use File->Connect to Remote Session (Shortcut: Ctrl-R) to connect to a remote debugging server instead of using the -remote command line parameter.<\/p>\n
To\u00c2\u00a0use this debugging mechanism, you will need to create a connection string to be used by the debugger server and then the debugger client.\u00c2\u00a0 The general format of a connection string is “transport:transport-parameters”.\u00c2\u00a0 For our examples, I will use tcp as the transport; this is likely to be the most common you’ll use in the real world.\u00c2\u00a0 You can look up the usage of the other transports in the documentation if you are curious.<\/p>\n
A simple connection string to use if you want to create a tcp server that listens on port 12345 would be “tcp:port=12345”.\u00c2\u00a0 The client connection string corresponding to this would be “tcp:port=12345,server=ip_or_hostname_of_server”.\u00c2\u00a0 (Note that if you are using the DTW 6.6.3.5 package, then it is required that you specify port= before server= in the client connection string or the connection will fail, due to a parser bug in the debugger).\u00c2\u00a0 If you use the “.server tcp:port=12345” command, you’ll see something like this:<\/p>\n
0:001> .server tcp:port=12345
\nServer started.\u00c2\u00a0 Client can connect with any of these command lines
\n0: -remote tcp:Port=12345,Server=COMPUTERNAME<\/p>\n
Then, you can connect to it using WinDbg and specifying either “tcp:port=12345,server=localhost” (assuming you are running on the same computer) to either the Ctrl-R\/Connect to Remote Session dialog or the -remote parameter:<\/p>\n
Microsoft (R) Windows Debugger\u00c2\u00a0 Version 6.6.0007.5
\nCopyright (c) Microsoft Corporation. All rights reserved.<\/p>\n
Server started.\u00c2\u00a0 Client can connect with any of these command lines
\n0: -remote tcp:Port=12345,Server=COMPUTERNAME
\nCOMPUTERNAME\\User (tcp 127.0.0.1:2025) connected at Mon Jul 24 01:33:20 2006<\/p>\n
On the server, you’ll see a notice that someone has\u00c2\u00a0connected:<\/p>\n
COMPUTERNAME\\User\u00c2\u00a0(tcp 127.0.0.1:2025) connected at Mon Jul 24 01:33:20 2006<\/p>\n
Henceforth, all output will be sent to all clients and the local server text output.\u00c2\u00a0 Additionally, clients will be able to use the debuggee status\u00c2\u00a0UI windows (e.g. disassembly) as well as viewing command output text.\u00c2\u00a0 After all this is setup, then you can continue to debug as if you were on the server computer (keep in mind, however, that symbol paths are relative to the server<\/em> and not the client computer).\u00c2\u00a0 If you connect multiple clients to the same session, then each additional client will be updated as any debugger client changes the state of the debugging session.<\/p>\n That’s a quick overview of -server and -remote.\u00c2\u00a0 However, there’s a\u00c2\u00a0bit more to this particular remote debugger mechanism than what I have talked about so far.\u00c2\u00a0 I’ll elaborate on some other features and usage cases of -server and -remote in the next post in this series.<\/p>\n","protected":false},"excerpt":{"rendered":" Moving onwards to the more modern remote debugging services available, the next option available for remote debugging with the DTW package is -server\/-remote.\u00c2\u00a0\u00c2\u00a0 This remote debugging mechanism is one that you may find yourself using fairly frequently.\u00c2\u00a0 Its advantages are rich functionality\u00c2\u00a0and integration with the WinDbg GUI (as a remote client), and reasonably low bandwidth […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[2,5],"tags":[],"_links":{"self":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/31"}],"collection":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=31"}],"version-history":[{"count":1,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/31\/revisions"}],"predecessor-version":[{"id":668,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/31\/revisions\/668"}],"wp:attachment":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=31"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=31"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=31"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}