Visual Studio and Windbg: which one is better to debug large scale managed application

Visual Studio seems开发者_开发知识库 is very native to debug the C# project but when the scale is up seems it is not very convenient to debug, for example when the project contains some code that is calling in/out of native code...

I wanna to know if there is any evidence that windbg is better over VS.Net when we are debugging large/serious project.

Another question is without the SOS extension can windbg set breakpoint on C# source file?

• WinDbg is at least an order of magnitude faster than VS when debugging unmanaged applications.
• It is faster when debugging managed applications as well; however, it does not offer the level of support for managed debugging VS offers.
• WinDbg can't be used for managed debugging without SOS.

On a separate note, sometimes it is possible to get the best of both worlds by running VS inside WinDbg. However, you need to:

1. Have a screaming fast machine with tons of memory. Don't even dream of doing this in a VM.
2. Don't forget to set the option on WinDbg to attach to child processes as well.
3. Avoid building in VS while running under WinDbg.

This hanselminutes podcast goes into some detail on windbg:

Scott's in Sweden this week and he sat down with master debugger and ASP.NET Escalation Engineer Tess Ferrandez. She explains .NET Debugging 101. What's a dump file? Do you need PDBs? How do you use WinDBG and what are the best ways to debug memory issues, perf problems and hangs.

I use WinDbg on a regular basis for debugging a very large mixed mode application. I find that the options for digging into the runtime details, the heaps, threads, and so forth are very useful. Several of the options are hardly supported in VS, so WinDbg is really useful in that context.

The biggest problem with WinDbg is probably its long and steep learning curve, but once you have a grasp of the basics I find WinDbg a lot easier to use than VS for many tasks. I have used it for some years now and I still learn new stuff on a regular basis.

The current version of WinDbg + SOS does not support source level debugging for managed code. If you really need this try to locate version 6.7.5. For additional details see this post: http://voneinem-windbg.blogspot.com/2007/04/windbg-6750-released.html

The next version of SOS (for .NET 4) does support some source level debugging, as it is able to extract source file and line info for managed call stacks and disassembly (using the !u command).