cordbg and dbgclr

Guess there's 3: you forgot windbg with sos.dll :)

Use cordbg all the time :)

Nice, but why do you use cordbg all the time?

I use cordbg to see the optimized x86 output from the JIT.

I for one did not know that there were other managed debuggers, nor why I would want to use one :(

Marcie

I'm in the same boat as Datagrid girl. Can someone give a few mode use cases to illustrate when an alternative debugger would be useful?

I use windbg (actually, cdb) and sos because:

1. I can't install VS on every machine where I need to debug.

2. For certain classes of problems where you don't need to step through code (like deadlocks or crashes), command line interface is more convenient.

3. Windbg has a ton of really useful extensions and builtin commands. Advanced remoting, working with crash dumps, digging into OS or CLR internals, etc.

One more reason for cordbg: You can debug a fully optimized program. VS.NET doesn't allow you to do that.

I'll also echo Pavel's comment about debugging on other machines. Many times (usually on Win98) I've (and people I work with have) run into issues where the app crashes oddly and it can't be reproduced on a dev machine. The other debuggers are extremely useful at times like this.

What I want in a debugger is to watch every thread, if I break @ a breakpoint, I would like to be able to see a threadview and see where every thread is (maybe if they all are paused)

I want to set up a remote Server for the specific purpose of being the development enviornment for serveral developers. When you terminal service into the server, VS.Net only allows one debugger to be running concurrently.