Does anyone use dbgclr? Or even know what it is?

My third blog entry in a row which is a question, and its becease we really want your input on these things.

Do you use dbgclr? If you dont even know what it is, then the answer is clearly no. For those folks, dbgclr is a GUI managed debugger that ships with the .NET Framework SDK (and hence with Visual Studio since 7.0). It looks and feels like a tiny version of VS, which is funny because that is exactly what it is. You can debug managed code, edit text files (in black & white), Attach to processes, and well that's about it.

dbgclr is an appid, which is a customized version of Visual Studio, which we, the debugger team, happen to own. 98% of its binaries are taken from the regular VS drop, its only unique bits are its exe and main menu resource table. Most of the bugs we fix for "proper" VS will automagically fix the same issue in dbgclr, but very occasionally we get dbgclr-only bugs (usually Setup-related).

Of course its free, because it ships with the SDK (which you can download). It ships along with cordbg (a command-line managed-only debugger) and, soon, mdbg, yet another managed debugger, but with UI and its own source code (its a C# sample).

Why am I asking? Well we've just had some dbgclr-specific bugs, and I really dont like putting valuable resources on it when almost no-one uses it. I actually tried to kill it several times during the Whidbey product cycle, but failed, so yes, there is a .NET 2.0-matching version.

As the SDK will soon ship with a cmdline managed debugger, a UI one (with its source) I really dont see the point of shipping yet another one, but of course my real reason is to get out of the business of maintaining it, and keeping it alive when we start on the next release.

So if you do actually use it, please tell me why.

A Digression: dbgw64

Have you ever used dbgw64? Well that particular VS appid was created specifically to debug IA64 native code, and was first released sometime in the previous millenium. It was built much like dbgclr, except it included only native-debugger components, and could only debug IA64 code. It was important as there was no other UI debugger for 64-bit around (well except windbg, if you could call that vintage edition a UI debugger). The really unique thing about dbgw64 was it was built in native IA64 code. All of it. Including core bits of Visual Studio. It was also built from a very early Whidbey source tree, so early that it predates the Everett (7.1 source tree): we originally started on Whidbey before Everett was a twinkle in a VP's eye. dbgw64 was the first IA64 Windows native code that shipped (outside of Windows and its SDK). Its no good any more because it cannot read PDB format 8 files, and because the OS changed the context record since we shipped it. Its a shame there is no native-64 bit version of VS for Whidbey, it would be a screamer.

Comments (22)
  1. We’ve been using it during the early phase of the 2.0 preview cycle, when there wasn’t a VS.NET around; it does make things a heck of a lot easier to deal with at that stage, but we really couldn’t care if it was nixed at the actual shipping stage.

  2. Paul Winwood says:

    Yes I have used DbgClr extensively because it seems to use fewer resources and doesnt need the full VS to use it. If MDbg is as good (haven’t tried it yet) it can be replaced otherwise please keep it. It aso useful not to have to learn another keyboard accelerator set.

  3. brad says:

    I must confess that I use it quite a bit. Maybe it’s must the way my brain works, but I find it handy when all of the complexity of VS isn’t required. That being said, if the debug UI thingy that’s going to ship is equally "light" and reasonably easy to use, I’ll be perfectly happy.

  4. Jared says:

    I find that dbgclr is very helpful when you are trying to track down web app bugs that only repro on your deployment box. It’s a lot easier to install the framework SDK on all of the boxes rather than VS

  5. Bryce says:

    I use almost nothing but the dbgclr, though I’m the only one in my group who does use it. I don’t think anyone else even knows it’s there as I get quite a few "what happened to your VS install" when they see me using it. Then again, I’m also pretty much the only one writing Windows services and ASP.NET applications and I prefer to "attach to process" with dbgclr over the full VS. For the few winform apps I’ve had a part in, I do use VS. If MDbg is almost equivalent though, it won’t bother me if dbgclr is gone.

  6. Andy,

    i know it exists. i have never used it. i see no point in doing so in the future.


    thomas woelfer

  7. I’ve used it once or twice out of curiosity when asked to pick a debugger.

  8. Philip Rieck says:

    I second the "great for deployment boxes" – web server or client – to reproduce issues without a license and install.

    However, even though it is useful, it’s not essential. If you can put more resources into VS.NET (Whidbey, Orcas, etc) go for it.

    I’d much rather no dbgclr and have the Whidbey post-release bugs fixed in a gasp service pack, then have the same situation as vs2003 where we have dbgclr, but getting hotfixes for known issues requires 30-60 minutes per client talking to PSS.

  9. I third the "useful occasionally on deployment boxes" comments, but in my case it’s on the occasions when I have a bug on a client site that we can’t reproduce on the test machines.

    That’s not often, but when it does happen, it’s really nice to have around.

  10. noraguta says:

    I’m using it to debug nemerle ( assemblies, and it is quite cool.

  11. Laurent Fournie says:

    A little digression: does anybody knows how to install the DbgClr only (not the full SDK)? I’ve tried to xcopy the files but it does not work (pop-up asking me to reinstall).

  12. As far as I know there’s no easy way to install DbgClr without installing the full SDK. There used to be some unsupported hacks but I’m not even sure if they work anymore.

    I strongly believe that there should be a lightweight, xcopy-installable GUI debugger for .NET code. It could be based on DbgClr, MDbg or WinDbg – I don’t really care as long as it works reasonably well.

  13. David Wilcock says:

    This thread is dead I know…. Yes! Not everyone develops using Visual Studio you know. Also, it is wonderfully lightweight in comparison to debugging from visual studio. mdbg.exe appears to be command line still so I’m guessing somebody realised it is worth a little maintenance overhead 🙂

  14. David, I’m with you.  I was googling for info on DbgClr in 2.0, and my heart almost stopped when I read this entry!  Fortunately I found the little bugger and I remain among the living.

  15. nch says:

    Could you make hint how to install C# editor to dbgclr? Overall debugging is cool, but plain text editor is annoying a little bit…

  16. Andy-Pennell says:

    nch: The C# editor requires the C# project system, which requires the VS project system, which requires…

    Use VS.

  17. nch says:

    andypennell: Thanks, I’ve tried but unsuccessfully. The reason is that application utilizes .net framework 1.1.

    VS 2003 hangs without any slight reason during debugging, maybe due to the application complexity.

    VS 2005 doesn’t support debugging of such applications (.net 1.1).

    So I use dbgclr from vs 2005 – it consumes less memory and hangs much lesser 🙂

    But why "C# editor requires the C# project system"? Doesn’t editor should be provided by a language service for VS?

    I mean, maybe a chain "x requires y requires z" will be not so long?

  18. Andy-Pennell says:

    The C# language service requires a real project in order to work (parsing projects and building the class hierarcy), hence the dependency tree.

    Suggest upgrading your app to use Net FX 2.0 at least: 1.1 is six years old now.

    You can always edit your C# in VS2005, while debugging in dbgclr: get the best of both worlds.

  19. Ashraf Sabry says:


    I use the CLR debugger frequently, my budget doesn’t afford VS standard or professional editions, I use the express edition, so dbgclr is important to me.

    The second reason is to debug software at the production environment as the above comments pointed.

    My question: Is the visual CLR debugger (DbgCLR.exe) available with the windows SDK v6.1? or I must install the .net framework 2 SDK to have it?

  20. James says:

    Hi there,

    What is the replacement for Dbgclr.exe ?  

    I have an application (.NET 3.0) running on Win 7 RC and don’t want to install the whole of Visual Studio to debug it.  I really liked that I could attach to process with dbgclr and this doesn’t seem to be available with C# Express.

    Dbgclr.exe crashes on boot with Win7 so i’m not sure what the alternatives are.

    I know there are some command line debuggers but for simplicity a UI like dbgclr would be much easier to use.

    Please advise,


Comments are closed.

Skip to main content