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.
However, there is a way to get this functionality with the kernel debugger as you would with the user mode debuggers when using dbgsrv.exe. Enter kdsrv.exe, the kernel debugger server. Kdsrv.exe is an analogue of dbgsrv.exe and fullfills the same basic functional requirements; it allows multiple debugger clients to connect to it and begin kernel debugging sessions on resources that are connected to the computer running kdsrv.exe. Like dbgsrv.exe, kdsrv.exe is used with one debugger client per debugging session, and also like dbgsrv.exe, kdsrv.exe does not start any debugging sessions on its own and leaves that up to clients that connect remotely. It also allows for secured connections and reverse connections, just like dbgsrv.exe (using the same connection string values).
Kdsrv.exe allows the same rich experience as dbgsrv.exe when it comes to doing remote kernel debugging. It allows you do perform symbol access and debugger extension calls on the local debugger client and not from a kd.exe instance running on the remote system. It also has many of the same limitations of dbgsrv.exe, such as no support for remote dump file debugging.
To activate a kdsrv.exe server, use the same syntax that I described with with “Activating process servers and connecting to them“. The command options are identical to dbgsrv.exe with respect to specifying a connection string and starting the server (some of the little-used other command line options to dbgsrv.exe that relate to starting a process along with the debugger server are not supported by kdsrv.exe). For example, you could use:
kdsrv.exe -t tcp:port=port,password=secret
You’ll get an error message box if you give kdsrv.exe an unacceptable command line, otherwise, it will simply run in the background.
Connecting to a kdsrv.exe instance uses a slightly more complex connection string syntax, which is an adaptation of the one used by smart clients with -premote.
The client connection string is given in the format:
kdsrv:server=@{tcp:port=port,server=server-ip,password=password},trans=@{kd-string}
(Password is optional.)
The “kd-string” value is what you would normally pass to kd.exe or windbg.exe to start a kd session. It specifies a remote resource to connect to that resides on the machine running kdsrv.exe. For instance, you might use “com:port=comport,baudrate=baudrate” to direct kdsrv.exe to connect the kernel debugger over a com port connection using the specified baud rate.
To activate a kdsrv.exe client, use a command line formatted as follows;
debugger -k connection-string
, where “connection-string” is the “kdsrv:…” string discussed above. Here are some examples of starting a server and connecting to it:
Starting the kdsrv instance:
kdsrv.exe -t tcp:port=1234,password=secret
Connecting kd:
kd.exe -k kdsrv:server=@{tcp:port=1234,server=127.0.0.1,
password=secret},trans=@{com:port=com1,baudrate=115200}
After that, you should be set to go.
You can use a variety of different underlying debugger targets with kdsrv.exe, including serial (com), 1394, and serial-over-named pipe (virtual machine) targets.