.NET announced... PDC 2000

A co-worker of mine attended PDC 2000 and was blown away with what Microsoft had coming in the Visual Studio .NET lineup.

I found a some notes from the PDC 2000 by Chris Maunder of CodeProject.com Luckily I had been playing with eariler versions of .NET and was amazed by the power of ASP+ (ASP.NET).  I creates some sites, toyed with post-backs and was amazed at ADO.NET for database access.

On to Betas.. and Beta Support

My love of .NET was no secret in product support, so when there was an opening in the Beta Support team for Visual Studio .NET, I jumped at the chance to work with this pre-release product.

While on the Beta support team, I supported customers and filed bugs in order to make a better product come RTM.  Coming from a native debugging WinDNA debugging background, I was always looking for supportability enhancements that could be made to make the .NET Framework more supportable within production environments.

Since I was new to the product and the Beta Support team, I had to keep an open mind about the tools that we would use to debug .NET applications.  The tools that I was investigating were:

  • Visual Studio .NET
  • DBGClr
  • WinDbg/CDB/NTSD w/ strike.dll

Visual Studio .NET

The Visual Studio .NET is the best debugger to use when developing applications.  The watches, evaluations, and other debugger windows make it easy to track down bugs in assemblies that you have source code for.  Once the application moved into the stress / staging environment, it becomes difficult to install a full version of Visual Studio .NET for debugging purposes.


DBGClr is installed with the .NET Framework SDK.  The user interface is very similar to the Visual Studio .NET debugger with a few limitations.  DBGClr only debugs managed code, and there is no remote debugging capability.  Another big difference is that DbgClr is that there is no compiler included.  In order to compile in the SDK you need to use the command line compilers like CSC.EXE and VBC.EXE.


I noticed that the .NET Framework SDK was shipping with a console based debugger called CORDBG.  CORDBG was a sample debugger that was provided as an example of how a developer could use the ICordbg interface from native C++ code.  One nice thing about CORDBG is that it can perform basic source level debugging (step into, step over, show source, locals etc.) and has an extremely light footprint.  (3 files in addition to CORDBG.EXE)  Unfortunately, the command syntax is different than the native debuggers that I was used to.

One handy command in CORDBG is the command * where.  This command will dump the managed call stacks for all threads in the process.  Also CORDBG has the ability to "detach" from a managed process and let the process continue as if it was never debugged.

WINDBG/CDB/NTSD w/ strike.dll (now SOS.dll)

While on the Visual Studio .NET beta I was tasked with debugging some stress related bugs in the CLR.  Some of them were production managed memory issues.  At the time, the only way to debug these issues was using WinDbg and strike.dll. Jason Zander goes into the history of the name strike (and soon Son of Strike) in his blog post.  Look for the word "Lighting" right under his reference to the PAG Guide for Debugging. Our team investigated strike.dll and then worked with Jason Zander's CLR team to create and test SOS.dll. 

 SOS.dll was first released in the Production Debugging for .NET Applications whitepaper in a set of download tools.  SOS.dll now ships with the .NET Framework 1.1 and 2.0 in the \Framework\<version>\ directory.  The Debugging tools for Windows download ships the latest version of SOS.dll that works on 1.0 and 1.1 versions of the .NET Framework in the \clr10 directory.