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.