{"id":30,"date":"2006-07-20T07:00:12","date_gmt":"2006-07-20T12:00:12","guid":{"rendered":"http:\/\/www.nynaeve.net\/?p=30"},"modified":"2019-12-13T17:43:35","modified_gmt":"2019-12-13T22:43:35","slug":"remote-debugging-with-kd-and-ntsd","status":"publish","type":"post","link":"http:\/\/www.nynaeve.net\/?p=30","title":{"rendered":"Remote debugging with KD and NTSD"},"content":{"rendered":"

Besides remote.exe<\/a>, the next remote debugging option available is controlling NTSD through the kernel debugger.\u00c2\u00a0 This technique has also fallen by the wayside in recent days like remote.exe, but there are still some circumstances under which it is useful.<\/p>\n

This remote debugging technique is based upon controlling NTSD through the kernel debugger connection.\u00c2\u00a0 As a crude form of remote debugging, this option\u00c2\u00a0allows you to control NTSD on the target computer from a different computer over a serial\/1394\/USB debugger cable.\u00c2\u00a0 This is useful in situations where you are debugging a user mode process in conjunction with the kernel debugger, and want to hide many of the kernel-debugger-specific overhead that is typically associated with doing user mode debugging from the kernel debugger – for instance, having to deal with whether a particular piece of code or data\u00c2\u00a0is paged out or not.<\/p>\n

Under the hood, this mechanism works by having NTSD use DbgPrint and DbgPrompt instead of console output and console input, respectively.\u00c2\u00a0 Additionally, all other dependencies upon CSRSS by NTSD for debugging are disabled, so that NTSD can be used for debugging CSRSS (the Win32 subsystem).\u00c2\u00a0 The kernel debugger displays DbgPrint outputs and allows input through DbgPrompt, which allows you to control the user mode debugger through the kernel debugger.\u00c2\u00a0 One consequence of this is that the entire system is going to be frozen while you are inputting commands to NTSD, which can have implications for debugging RPC or network related programs, as connections may time out or go away while you are providing input to NTSD, since the networking stack will be frozen and be unable to acknowledge packets.<\/p>\n

To activate this mechanism, you can start ntsd with the “-d” parameter (in addition to the usual parameters to specify what you are debugging) which “sends all debugger output to kernel debugger via DbgPrint” according to the documentation.\u00c2\u00a0 You must have the kernel debugger active in order for this option to be effective.\u00c2\u00a0 After you initially continue execution from NTSD (if applicable, depending on if you use “-g” or not), then you will need to cause a breakpoint exception (or other exception) in the process being debugged by NTSD through the kernel debugger (or another program) in order to return control back to NTSD.\u00c2\u00a0 The “.sleep” command is also mildly useful here, as effectively a “delayed breakin” type command that allows you to instruct the NTSD instance to continue execution and break back in to the kernel debugger with a prompt after a certain period of time.\u00c2\u00a0 This is necessary because there is no way to directly transfer control back to NTSD after you are done doing something in the kernel debugger.<\/p>\n

Like remote.exe, this mechanism simply redirects input\/output, although this time through the kernel debugger connection and not a pipe.\u00c2\u00a0 The main reasons to use this mechanism over remote.exe (or the other options) are for debugging certain situations that make it difficult or impossible to use a conventional user mode debugger, for instance, debugging CSRSS.exe.\u00c2\u00a0 Since the user interface I\/O is redirected only, things like symbol processing are performed on the NTSD instance and not the local kernel debugger user interface.<\/p>\n

Although the kernel debugger connection currently only supports serial cables, 1394, and USB for debugging, you can extent the NTSD-over-KD remoting mechanism\u00c2\u00a0to be useful for computers in remote locations by remoting the KD instance controlling NTSD through a network aware mechanism such as remote.exe, -server, or kdsrv.exe.<\/p>\n

For most purposes, though, I would recommend not using this mechanism.\u00c2\u00a0 The other\u00c2\u00a0remoting mechanisms provide greater flexibility and are easier to user with remote computers.<\/p>\n

This mechanism is, however, a\u00c2\u00a0valuable technique\u00c2\u00a0for certain special situations where you are either debugging the lowest level parts of the user mode NT infrastructure, or where you need to coordinate between a kernel debugger and user mode debugger on the same machine.\u00c2\u00a0 In the latter case, the NTSD-over-KD technique is superior to a network aware remote debugger connection to a NTSD\/CDB\/WinDbg instance running on the computer being kernel debugged because the NTSD-over-KD connection will not time out while you are broken into the kernel debugger like a network connection would.<\/p>\n

That’s all for this installment of the remote debugging series.\u00c2\u00a0 I’ll talk about some of the more modern remoting mechanisms that you are likely to use in every-day debugging next time.<\/p>\n","protected":false},"excerpt":{"rendered":"

Besides remote.exe, the next remote debugging option available is controlling NTSD through the kernel debugger.\u00c2\u00a0 This technique has also fallen by the wayside in recent days like remote.exe, but there are still some circumstances under which it is useful. This remote debugging technique is based upon controlling NTSD through the kernel debugger connection.\u00c2\u00a0 As a […]<\/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\/30"}],"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=30"}],"version-history":[{"count":1,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/30\/revisions"}],"predecessor-version":[{"id":690,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=\/wp\/v2\/posts\/30\/revisions\/690"}],"wp:attachment":[{"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=30"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=30"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.nynaeve.net\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=30"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}