Reviewing the Debugging Object Model for Automation
Visual Studio .NET has a comprehensive extensibility model. This model includes macro capabilities as well as support for customizing Visual Studio .NET by programming against the Automation Model. The Automation Model includes objects for managing the integrated debugger and related concepts. The major objects in the EnvDTE supporting the Debugging Object Model are Breakpoint , Debugger , Expression , Language , Process , Program , Stack Frame , and Thread . You can read more about the Debugging Object Model by navigating to the ms-help://MS.VSCC/MS.MSDNVS/vsdebugext/html/vxoriDebuggerObjectModel.htm URL or searching for the Visual Studio Debugger Object Model in Visual Studio .NET help documentation.
Reviewing Available Debuggers
On no occasion so far have I found the integrated debugger lacking. However, you should be aware that other debuggers also ship with VS .NET, including the Cordbg.exe command-line debugger and the DbgClr.exe Windows debugger. Cordbg.exe is a text-based command-line debugger that was likely used to debug C# before VS .NET could do so, and DbgClr.exe probably had a similar role in testing Windows applications before VS .NET was ready.
Cordbg.exe is as cryptic as debug.exe (the old DOS-based debugger) but significantly more advanced. The command-line debugger would probably take quite a bit of practice to get used to; the DbgClr.exe Windows debugger looks and feels a bit like debugging in VS .NET. The VS .NET debugger contains substantial functionality and ease of use, but I suppose some could make an argument for using the command-line or Windows debugger just as some programmers make an argument for using vi (a common text-based UNIX editor still in use).