views:

286

answers:

3

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?

+2  A: 
  • 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.
Franci Penov
I was using windbg to load the pdb file of a very simple c# project executable. The pdb file is loaded but it can't even insert the breakpoint in windbg. Then I issue the command to load the SOS, but it still can't insert the BP. The command I used to load SOS is: .loadby sos mscorwks. No error shows after the command issued.
Bin Chen
+1  A: 

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.

Michael Valenty
Actually it didn't talk a lot about that details.
Bin Chen
On the podcast they discuss when to use Visual Studio to debug (attach to the process on a server) vs. when to use windbg. I just listened to this podcast on my way to work and thought that was relevant to your question.
Michael Valenty
A: 

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).

Brian Rasmussen