{"id":38,"date":"2006-08-03T12:30:08","date_gmt":"2006-08-03T17:30:08","guid":{"rendered":"http:\/\/www.nynaeve.net\/?p=38"},"modified":"2019-12-13T17:41:40","modified_gmt":"2019-12-13T22:41:40","slug":"remote-debugging-review","status":"publish","type":"post","link":"http:\/\/www.nynaeve.net\/?p=38","title":{"rendered":"Remote debugging review"},"content":{"rendered":"<p>Over the past week or two, I&#8217;ve written about some of the various remote debugging options available to you through the <a title=\"DTW homepage\" href=\"http:\/\/www.microsoft.com\/whdc\/devtools\/debugging\/default.mspx\">Debugging Tools for Windows<\/a> (DTW) package.\u00c2\u00a0 I&#8217;ve covered most of the major debugging mechanisms available at this point and given brief descriptions of their strengths and weaknesses.<\/p>\n<p>Here&#8217;s an indexed listing of the posts on this topic so far:<\/p>\n<ol>\n<li><a title=\"Permanent Link to Overview of WinDbg remote debugging\" href=\"http:\/\/www.nynaeve.net\/?p=15\" rel=\"bookmark\">Overview of WinDbg remote debugging<\/a><\/li>\n<li><a title=\"Permanent Link to Remote debugging with remote.exe\" href=\"http:\/\/www.nynaeve.net\/?p=19\" rel=\"bookmark\">Remote debugging with remote.exe<\/a><\/li>\n<li><a title=\"Permanent Link to Remote debugging with KD and NTSD\" href=\"http:\/\/www.nynaeve.net\/?p=30\" rel=\"bookmark\">Remote debugging with KD and NTSD<\/a><\/li>\n<li><a title=\"Permanent Link to Remote debugging with -server and -remote\" href=\"http:\/\/www.nynaeve.net\/?p=31\" rel=\"bookmark\">Remote debugging with -server and -remote<\/a><\/li>\n<li><a title=\"Permanent Link to Reverse debugging -server and -remote\" href=\"http:\/\/www.nynaeve.net\/?p=32\" rel=\"bookmark\">Reverse debugging -server and -remote<\/a><\/li>\n<li><a title=\"Permanent Link to Securing -server and -remote remote debugging sessions\" href=\"http:\/\/www.nynaeve.net\/?p=33\" rel=\"bookmark\">Securing -server and -remote remote debugging sessions<\/a><\/li>\n<li><a title=\"Permanent Link to Remote debugging with process servers (dbgsrv)\" href=\"http:\/\/www.nynaeve.net\/?p=35\" rel=\"bookmark\">Remote debugging with process servers (dbgsrv)<\/a><\/li>\n<li><a title=\"Permanent Link to Activating process servers and connecting to them\" href=\"http:\/\/www.nynaeve.net\/?p=36\" rel=\"bookmark\">Activating process servers and connecting to them<\/a><\/li>\n<li><a title=\"Permanent Link to Remote debugging with kdsrv.exe\" href=\"http:\/\/www.nynaeve.net\/?p=37\" rel=\"bookmark\">Remote debugging with kdsrv.exe<\/a><\/li>\n<li><a title=\"Permanent Link to Remote debugging review\" href=\"http:\/\/www.nynaeve.net\/?p=38\" rel=\"bookmark\">Remote debugging review<\/a><\/li>\n<\/ol>\n<p>At this point, you should be able to use all of the above remoting mechanisms in their basic usage cases.\u00c2\u00a0 There are a couple of obscure features that I did not cover, such as doing -server\/-remote over serial ports, but between my posts and the documentation you should be able to figure out what to do if you ever find a use for such estorica (let me know if you do!).\u00c2\u00a0 What remains to be told is some general advice on which remoting mechanism is the best for a particular problem.<\/p>\n<p>In general, the most important factors in choosing a remoting mechanism are:<\/p>\n<ul>\n<li>Available bandwidth and latency between your computer and the remote system.\u00c2\u00a0 Some remoting mechanisms, like dbgsrv, perform very poorly without a high bandwidth, low latency link.<\/li>\n<li>Whether symbol access needs to be done on the client or the debugging target.\u00c2\u00a0 This consideration is important if you are debugging a problem on a customer site.<\/li>\n<li>What types of targets you need to support.\u00c2\u00a0 Some mechanisms, such as process servers, do not support all target types (for instance, lack of dump file debugging support).<\/li>\n<li>Whether you need special support for working through a firewall (i.e. reverse connection support).<\/li>\n<li>Ease of use with respect to setting up the remoting session.<\/li>\n<\/ul>\n<p>These are the general factors I use to decide which remoting mechanism to use.\u00c2\u00a0 For example, in ideal cases, such as debugging a problem on a LAN or on a virtual machine hosted on the same computer, I will almost always use a process server for remote debugging, simply because it lets me keep my own WinDbg workspace settings and symbol access without having to set up anything on the target computer.\u00c2\u00a0 Over the Internet, process servers are usually too slow, so I am often forced to fall back to -server\/-remote style remoting.<\/p>\n<p>Taking into account the guidelines I mentioned above, here are the major scenarios that I find useful for each particular remoting mechanism:<\/p>\n<ul>\n<li>Process servers and smart clients (dbgsrv).\u00c2\u00a0 This is the remote debugging mechanism of choice for remotely debugging things on virtual machines, on a LAN or other fast connection, or even <a title=\"Introduction to x64 debugging, part 1\" href=\"http:\/\/www.nynaeve.net\/?p=8\">on the same computer<\/a>\u00c2\u00a0(which can come in handy for certain Wow64 debugging scenarios, or cross-session debugging under Terminal Server prior to Windows XP).\u00c2\u00a0 Process server debugging is also useful for debugging early-start system services remotely, where the intrastructure to do symbol access (which touches many system components, for things like authentication support) is not yet available &#8211; for this scenario, you can use the &#8220;-cs <em>command-line<\/em>&#8221; parameter with dbgsrv to start a target process suspended when you launch dbgsrv, which is handy for using Image File Execution Options to have dbgsrv act as a debugger for early start services.\u00c2\u00a0 This can be more reliable than -server and -remote if you are trying to do symbol access, as if you are debugging certain services, you might deadlock the debugger and lose the debugging session if the debugger has to talk to the service you are debugging in order to complete a network symbol access request.<\/li>\n<li>-server and -remote.\u00c2\u00a0 If I am doing debugging over the Internet, I&#8217;ll usually use this mechanism as it&#8217;s relatively quick even over lower quality connections.\u00c2\u00a0 This mechanism is also useful for collaborating with a debugging session (for instance, if you want to show someone how to perform a particular debugging task), as you can have multiple users connect to the same debugging session.\u00c2\u00a0 Additionally, -server\/-remote are handy if you have a large dump file on a customer site and you want to debug it remotely instead of copying it to your computer, but would like to do so from the context of your local computer so that you have easier access to source code and\/or documentation.\u00c2\u00a0 Finally, -server\/-remote support remote kernel debugging where process servers do not.<\/li>\n<li>KdSrv.exe.\u00c2\u00a0 If you need to do remote kernel debugging over a LAN, this is the mechanism of choice.\u00c2\u00a0 Be aware that kernel debugging is even more latency and bandwidth\u00c2\u00a0sensitive\u00c2\u00a0than process servers, making this mechanism useless unless you have a very fast, LAN-like connection to\u00c2\u00a0the target.\u00c2\u00a0 If these conditions hold true, KdSrv.exe provides the main benefits that a process server does for user mode debugging; local symbol access, local debugger extensions, and allowing the debugger to use your workspace settings on the local computer as opposed to setting up your UI on a remote system.<\/li>\n<li>NTSD through KD.\u00c2\u00a0 This is useful in a couple of specialized scenarios, such as debugging very early start processes or performing user mode debugging in conjunction with the kernel debugger.\u00c2\u00a0 While controlling NTSD through KD is much less convenient than through a conventional remote debugging session, you won&#8217;t have to worry about your session going away or getting disconnected while the remote system is frozen in the kernel debugger.\u00c2\u00a0 In particular, this is useful for doing things like debugging things that make calls to the LSA from kernel mode, or other situations where kernel mode code you are debugging is extensively interacting with user mode code.<\/li>\n<li>Remote.exe.\u00c2\u00a0 I have never really found a situation that\u00c2\u00a0justifies the use of this\u00c2\u00a0as a preferred remoting mechanism, as its capabilities are far eclipsed by the other remoting services available and the benefits (low network utilization) are relatively minimal compared to -server\/-remote in today&#8217;s world of cable modem and xDSL connections.<\/li>\n<\/ul>\n<p>If you are debugging a problem on a customer site, you will likely find reverse connection debugging highly useful.\u00c2\u00a0 All of the modern remote debugging mechanisms support reverse connections except NTSD over KD, for obvious reasons.<\/p>\n<p>Another consideration to take into account when selecting which mechanism to use is that you can mix and match multiple remoting mechanisms within a\u00c2\u00a0debugging session\u00c2\u00a0if it makes sense to do so.\u00c2\u00a0 For instance, you can start a process server, connect to it with ntsd, and launch a -server\/-remote style server with &#8220;.server&#8221; that you then connect to with WinDbg.\u00c2\u00a0 This capability is usually not terribly useful, but there are a couple of instances where it can come in handy.<\/p>\n<p>That&#8217;s all for this series on remote debugging.\u00c2\u00a0 I may come back and revisit this topic again in the future, but for the moment, I&#8217;ll be focusing on some different subjects for upcoming posts.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Over the past week or two, I&#8217;ve written about some of the various remote debugging options available to you through the Debugging Tools for Windows (DTW) package.\u00c2\u00a0 I&#8217;ve covered most of the major debugging mechanisms available at this point and given brief descriptions of their strengths and weaknesses. Here&#8217;s an indexed listing of the posts [&hellip;]<\/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\/38"}],"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=38"}],"version-history":[{"count":1,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/38\/revisions"}],"predecessor-version":[{"id":660,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/38\/revisions\/660"}],"wp:attachment":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=38"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=38"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=38"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}