How to change the debugger attached to a process

Suppose your application crashes and debugger X is automatically connected because that's how the system happened to be configured. But you would prefer to use debugger Y. After installing debugger Y, how do you switch the debugger from X to Y? If you try to connect debugger Y to the process, you get the error code STATUS_PORT_ALREADY_SET, because only one debugger can be connected to a process at a time. But if you disconnect the old debugger, the application will disappear with it. How do you escape from this Catch-22?

Here's what you do.

  • Attach the ntsd debugger in non-invasive mode: use -pv instead of -p when specifying the process id.
  • The ntsd debugger will suspend all the threads in the process.
  • Now tell debugger X to resume the process and detach from it. (If debugger X is ntsd, then the command for this is qd.)
  • Next, tell debugger Y to attach to the process.
  • Finally, go to the ntsd debugger which you attached in non-invasive mode, and tell it to detach with the qd command.

This trick works because the non-invasive mode of debugging doesn't actually connect to the process as a debugger. It merely suspends all the threads in the process and lets you snoop around its memory. As a result, when you disconnect the original debugger and tell it to resume execution of the application, the application doesn't actually resume because the non-invasive ntsd is keeping it suspended. You then can attach the new debugger to the process and resume your debugging.

In other words, the non-invasive ntsd acts as a bridge, holding the process frozen while one debugger gets out and another one comes in.

Comments (12)
  1. Hans says:

    For me more interesting would be how to select the right debugger for a crashing app, let it be a certain Visual Studio version or WinDbg.

    I have installed WinDbg, but prefer normally after a crash that Visual Studio comes up.

  2. Gabe says:

    If the only reason for engaging ntsd is to suspend the process, couldn’t you also use Process Explorer for this? You could right-click and select suspend the process, disconnect the default debugger, connect the preferred debugger, then right-click and select resume.

    [Sure, you could do that too. But at least around here, ntsd is probably one of the two debuggers involved in the handoff, thereby avoiding the “now you have two problems” problem. -Raymond]
  3. Paul says:

    It’s much easier to find a utility called Debug Chooser written by John Robbins (who used to do the Bugslayer column @ MSJ).

    He wrote an app that would let you choose which debugger to run when a GPF occurred.

    Can’t find an online copy of the relevant MSJ edition (Jan 2000) so this will have to do:

  4. I guess suspending the process using Process Explorer (Sysinternals tools) would have the same effect?

  5. Mark says:

    Paul: I believe that functionality is now built into Windows.

  6. Ok, I somehow managed to look through the existing comments but not to read the second one. Sorry about the pointless comment above.

  7. Lawrence says:

    “Non-Computer” might not be the correct category for this tip :D

    [Good catch. -Raymond]
  8. Dale says:

    "the non-invasive ntsd acts as a bridge"

    That is one clever "wish I thought of that" piece of thinking.

  9. Anonymous Coward says:

    Is it also possible to tell the Windows error report generator to detach from a process? I would like it to be enabled by default since most crashes are usually not my fault. I wish there were an extra button on its dialog, "switch to WinDbg".

  10. spampot says:


    more interesting would be how to select the right debugger for a crashing app

    Apart from Debug Chooser which Paul suggested, there’s also a similar tool – "jitmgr", written by Great. It uses a bit different approach compared to Debug Chooser.

    (blogpost is in russian; download link is at the bottom).

  11. Neil says:

    There is; it’s the button marked Debug. If you don’t have it, run WinDbg -I

  12. BC says:

    There are so many useful bits of information in your blog I had to create a new folder in Favorites to hold them all!!  

Comments are closed.

Skip to main content