Debugging Microsoft .NET 2.0 Applications

Category: Programming
Author: Dino Esposito
4.5
All Stack Overflow 11
This Month Stack Overflow 4

Comments

by Wayne   2019-07-21

You should look into setting up a symbol server and indexing the PDB files to your source code control system. I just recently went through this process for our product and it works very well. You don't have to be concerned about making PDB files available with the binaries, nor how to get the appropriate source code when debugging dump files.

John Robbins' book: http://www.amazon.com/Debugging-Microsoft-NET-2-0-Applications/dp/0735622027/ref=pd_bbs_sr_1?ie=UTF8&s=books&qid=1222366012&sr=8-1

Look here for some sample code for generating minidumps (which don't have to be restricted to post-crash analysis -- you can generate them at any point in your code without crashing): http://www.codeproject.com/KB/debug/postmortemdebug_standalone1.aspx

by anonymous   2019-07-21

Tess Ferrandez's blog If broken it is, fix it you should is both directly relevant to specific real-life scenarios you're likely to encounter in .Net debugging, (typically involving ASP.Net), and more generally thought provoking.

John Robbins' debugging books and blog are similarly worth reading.

Mike Stall's .Net Debugging Blog likewise.

Mark Russinovich's blog is remarkable - his knowledge of Windows internals combined with great forensic skill is impressive.

by anonymous   2019-07-21

WinDbg might be a useful tool for you. It comes with the Debugging Tools for Windows.

Once your app is running, you can attach WinDbg and explore the managed heap. (Or you can take a memory dump and explore it offline). It will be able to very quickly tell you the object types consuming the largest amounts of memory.

First you will need to load the SOS extension which enables debugging of managed applications:

.loadby sos mscorwks

Then you can use !dumpheap to get heap information, the -stat switch gives overall heap info on which types are allocated:

!dumpheap -stat

The -type parameter gives specific information on allocated instances of the specified type:

!dumpheap -type System.String

There's a bunch of other commands you might find helpful like:

  • !gcroot - to follow an allocated object back up it's root to find why it is in memory.
  • !dumpobj - to dump out a specific object so you can see it's contents.
  • !EEHeap - to give some general heap stats.

MSDN has a full list of SOS commands and their switches.

WinDbg is a pretty complex tool, but there are lots of tutorials and guides online if you search to help you get started. Alternatively, I can recommend the book Debugging Microsoft .NET 2.0 Applications by John Robbins which goes into some good detail in the .net debugging abilities of WinDbg and SOS.

You can load the SOS extension into visual studio instead by entering this into the immediate window, then you should be able to use the SOS commands directly in the VS immediate window:

.load SOS.dll

You also might find the CLR Profiler and this Usage guide helpful.

by Preet Sangha   2019-07-21

I remember a Debugging book that I think that had a chapter on FXCop rules and discussed how to write one. For the life of me I cannot find my copy. And I suspect you'll need reflector

by anonymous   2017-08-20

Personally, I rarely use the Debug class at all for any of my programming. I've read a lot of comments and suggestions, such as those by John Robbins (author of Debugging .NET 2.0 Applications and the Bugslayer columns) about why you should be asserting proactively - especially parameters for methods.

The problem I have is this - say I was to write code like this:

Public Sub Test(source As Object)

  Debug.Assert(source IsNot Nothing, "source is Nothing")

  ' Do something....
End Sub

This works well during development with debug builds, but I end up doing this anyway:

Public Sub Test(source As Object)

  If source IsNot Nothing Then

  ' Do something....

  End If
End Sub

If there's a chance for 'source' to be nothing, then I'm going to do an 'If' check on it anyway. I'm not going to leave the assert call in the release build.

The other reason I don't use the Debug class is that I write a lot of unit tests. Doing so has led me to covering a lot of code paths, thus having a Debug.Assert in my code is not required.

As for debug logging, then I simply use Trace calls and SysInternals DebugView or text files to log the output of trace calls.

I would love to hear from others on this topic, since I'm also interested in knowing how they might be using the Debug class during development. It's an area I don't have much experience in, so I'm eager to learn.

by anonymous   2017-08-20

There is no easy way of doing that. The only working approach I've seen is adding code to your application that will attach external debugger to itself and read stack information. John Robbins is showing this is his book using modified sources of MDBG.

by Michael Burr   2017-08-20

Since you asked for pointers to books... As far as Windows debugging goes, John Robbins has several editions of a good book on Windows debugging:

Debugging Applications for Microsoft .NET and Microsoft Windows

Note that the most recent edition (Debugging Microsoft .NET 2.0 Applications) is .NET only, so you might want an older one (like in the first link) if you want native code debugging (it covers both .NET and native).