Tutorial :best technique for launching a windbg user-mode remote debugging session


What is your favorite technique for launching a windbg user-mode remote debugging session? Why is do you prefer this technique over other techniques? (pros/cons)

There are at least four different ways to do user-mode remote debug using windbg, as documented in the "Remote Debugging" section of the debugging tools for windows help file.

  1. run app on target then attach to it from the host windbg
  2. have the host windbg use remote.exe to launch the app on the target
  3. have the "smart client" host windbg launch the app on the target via a process server that is running on the target
  4. run a windbg instance on the target machine using the option "-server" to automatically start a server, then connect to the server from a 2nd machine.


Option 1 is my favourite because it is the simplest. I get to launch the app in the normal way without worry about getting WinDbg to set the right working directory, pass any command line arguments, etc.

Fortunately I've not run into any cases where this hasn't worked!


I tend to use option 4 (-server) because it is the only one that doesn't "pop" when you break into the kernel debugger long enough for the TCP connection to timeout. But this is more complex and not fully satisfying. So I'm looking for "best practices".


There is no "the best" solution. Each of the possibilities has advantages and disadvantages and it's good to understand all of them. It depends on several factors like:

  • where are the symbols located
  • which PC has access to the Internet to download the OS symbols
  • what amount of data may you copy to the server (clients often accept better if it's just a single Exe)
  • what's the bandwidth between client and server
  • do you need other commands that just CDB/WinDbg, e.g. access to CMD, then consider remote.exe
  • who's available on the server side, a debugging expert whom you can easily tell a lot of cryptic commands or a normal user who barely knows how to start a command prompt
  • are both sides in a private network, so you need a "man in the middle" server to be able to access each other (or port forwarding as an alternative, which IT guys don't want and it may take days to get it set up)

From those 4 options, don't forget that clients often want to see exactly what you do, so they require an RDP session, Teamviewer or similar. That's something they understand.

Note:If u also have question or solution just comment us below or mail us on toontricks1994@gmail.com
Next Post »