Jochen Kalmbach was kind enough (thanks Jochen!) to point in a comment to my previous post that release is a BETA version of WinDbg.
He also pointed out this post in the WinDbg newsgroup that confirms this information.

Sorry for not finding this out just now, but it seems the only place that the word “beta” was written was in the “redist.txt” file in the installation folder.

It seems that some code Jochen wrote doesn’t work with the new version of DbgHelp.dll so there are a few things you should watch out in betas…
I personally like to live on the bleeding edge when it comes to WinDbg so I usually do care if a version is a beta or not. On the other hand, I can sympathize with Jochen’s frustration about using a new beta version and finding out something is broken…

Oh well… I’m sure this will get fixed very soon.

I just wish WinDbg releases were a bit more often than every 6 to 9 months.

A new version of WinDbg (version was released a couple of days ago.
Download it from here.

You can read some of the highlights of the new version here.

For some reason, the only SOS.dll that comes with this release (as in previous releases) is for .NET Framework 1.1 only, so there is no new SOS.dll for .NET Framework 2.0 yet.

Say you have an ASP.NET application with some code written in the ASPX pages themselves (I know its so ASP, but it happens sometimes 😉 ).
Say you need to update some of this code and change it, or you just want to extend an existing web application with some ASPX pages and you don’t want to get into a code-behind adventure.
Say that some of the code is giving you problems and you really want to debug it in a debugger and its not even a production environment and you even have Visual Studio installed.

What do you do?


That’s all.

This little line will pop up the dialog that you usually see when an error occured that is not handled and if you have a debugger installed, Windows will offer you to debug the problem.

Then you can simply select to open the debugger and debug your code.

Do mind that you’ll need to have the debug=”true” flag in your web.config (otherwise debug symbols will not be generated).

Easy, isnt’ it?! 🙂

Since .NET 2.0 is released for about a month, I think its time for me to cover a few new commands that exists in the SOS.dll WinDbg extension that comes with .NET 2.0.

First of all, the current version of WinDbg – – has an SOS.dll that can only work with .NET 1.1, so even if you do load it and try it out it will not find any .NET data in the processes since the internal .NET structures in .NET 2.0 have changed.

To start using the SOS.dll that comes with .NET 2.0 issues the following commands:

.load C:\<Windows Home Directory>\Microsoft.NET\Framework\v2.0.50727\sos.dll

If you are performing a live debug (you have attached to the process), in newer WinDbg versions you can use the following commands

.loadby sos mscorwks

This command will load the sos.dll near the mscorwks.dll that is currently loaded in the process.

Usually newer versions of WinDbg (I always recommend running the latest version of WinDbg 😉 ) contains a newer version of SOS.dll, so you should prefer to use the SOS.dll provided with WinDbg, although currently, the only SOS.dll that supports .NET 2.0 is located in the Framework’s directory, near the mscorwks.dll.

New and interesting commands

  • !dumparray – Dumps the content of an array.
    The .NET 1.1 version of SOS.dll had a !dumpcollection method which usually didn’t work for me, so it nice to have something that will dump arrays.
  • !printexception – If a parameter is given, it will dump that exception, if no parameter is given, it will dump the last exception on the stack.
    In .NET 1.1 version of SOS.dll one had to dump the stack objects, find one that is an exception and print it using !dumpobj. Now, all one has to do is call !dumpexception and the last managed exception on the current thread’s stack will be printed out.In addition to that, !dumpexception can now parse the _stackTrace field, which is a binary array if the _stackTraceString is not filled.

    !printexception will also notify you if there are nested exceptions (exceptions being thrown inside a catch handler). If you want to see those as well, use the -nested parameter.

  • !bpmd – Sets a breakpoint on managed code.
    Setting a breakpoint on a managed code prior to .NET 2.0 was very tricky. I covered this issue in a previous post.
    In that older post I only covered settings a breakpoint on an already JITed method. Setting a breakpoint on a non-JITed method is even harder. !bpmd will cover all of these aspects.To set the breakpoint all you need to do is provide the module name and method name, or the MethodDesc handle (if you have it).
    !bpmd also works on generic types. If a breakpoint is set on a generic type it will break on all derived types.

    The only way to set a breakpoint on managed code with ease before .NET 2.0 was to use CorDbg (which I covered in an previous post as well).

  • !StopOnException – stops on a particular managed exception.
    This functionality was only supported in CorDbg prior to .NET 2.0. Now, instead of breaking on every CLR exception you can specify a specific .NET exception type, such as System.ApplicationException.
  • !DumpIL – Dumps the IL code of a method.
    This was previously very hard to do. In .NET 2.0 one can always dump the IL code of a method (even at runtime).
    The main advantage here is to debug dynamic methods which are built on the fly. Its also useful for dynamically generated types (using Reflection.Emit).

As in previous version of SOS.dll, you can type !help <CommandName> to get detailed help and sometimes examples on that specific commands.

Though I’ve briefly mentioned in a previous post that WinDbg has a built-in Semi-Scripting language to instrument it a bit, I didn’t explained much about it, so here is a nice little trick that you can do with it.

As part of this semi-scripting language there are a few flow controls that are very useful for performing a specific opeartions on multiple items such as object addresses.
One such useful flow control is “.foreach” which enables one to run a command that returns a result and for each line that returns invoke another command on that specific line.

Let’s say you want to view the full content of all of the string objects in your application that are in Generation 2.

The long way to perform this is to run dump all Generation 2 string objects using “!dumpheap“, save the list of addresses on the side and run “!dumpobj” on each and every one of the addresses we got.

The quick way to do it would be to use the “.foreach” command like this:
.foreach (obj { !dh -type System.String -gen 2 -short }) { !do ${obj} }

What we are doing here is running “!dh -type System.String -gen 2 -short” which returns all of the Generation 2 String objects currently alive on the heap (!dh is the short form of !dumpheap).

Mind the “-short” parameter. It is essential for this to work since “-short” tells the “!dumpheap” command to return the object’s address, one in each new line, instead of the normal output of “!dumpheap“.

NOTE: “-short” was only introduced in newer version of the SOS.dll that comes with WinDbg, so be sure to catch the latest version if you want to use it.

The second part of the “.foreach” command expands the obj parameter which contains each new line that we recieved from the “!dumpheap” command and we expand it by using the “${obj}” syntax.

This will run “!do” (the short form command of “!dumpobj“) on each and everyone of the addresses that returned from the “!dumpheap” command.

Just a small and useful tip for debugging… Enjoy!

Dan McKinley Emailed me to tell me about a WinDbg Extension he wrote that interogates CLR information. In the process of writing it he also documented the process of its creation, thus producing a tutorial of how to create WinDbg extension.

It’s all written in a nice and tidy post on his blog.

What is most interesting about his extension is that it interogates CLR information, so it should be a good basis for people writing WinDbg extensions that perform operations on CLR information.

If you are in the process of thinking about writing a WinDbg extension that’s a good place to start.

I’ve just stumbled upon this blog, by Microsofty named jimgries.

It has some wonderful tips and trick on how to debug stuff using Visual Studio 2005.

I specifically liked this post about tracepoints as well as this post about C#’s and J#’s ability to add an “Object ID” on objects to track them down around the application.

It’s definitly going on my subscribed list!

I got the following question from a reader named “Bysza” in the form of a comment on post about “How to tackle memory issues in a server application”:

“I’m using this approach for some time now, but I not always succeed in finding roots to objects.
I’m looking for a method to find objects that hold reference to my live object which sould be already gone.

Could you help me in that matter?”

If I understand the question correctly, you want to be able to find who is holding your live objects.

If that is the case, its quite simple.
What you need to do is either take a memory dump (I explained a bit on how to use it in this post) or attach WinDbg to the relevant process.

After you loaded the dump or attached to the process perform the following operations:

  1. Run !dumpheap -type [Part of the full namespace of the object] for example:
    !dumpheap -type MyNamespace.MyObjectThis will get you a list of the live objects of that type.
  2. Take the address from the first colum (that’s the address of the object) of the relevant object and run the command !gcroot [Object Address], for example:
    !gcroot 0x235025aThis will show you the chain of references up to the root object that is holding your referencing your object.
    This chain contains the addresses of each object in the chain so you will be able to know exactly who is holding who and why.

If a rooted object is directly holding your object you need to check one of the following things:

  • Do you have some kind of a Static (Shared in VB.NET) object in the application? If you do, this object is rooted and therefore every object it referecnces will never die until the application’s process is closed.Usually people have some kind of a static collection in which they store various objects and in a lot of the cases they forget to remove the objects from the collection.
  • Do you specifically pin objects? Do you call GCHandle.Alloc ? If so, be sure to release those handles or make sure that the objects being pinned do not hold references to objects you want to release.

I hope this helps a bit. If not, post a comment and we will continue the discussion there.

If any of you have various questions as to issues raised in this blog or from personal experience, please write me an email to eran.sandler at or leave a comment on one of the posts. Also, if any of you have some other comments about how did you implemet/use some of the things we have talked about here, I would love to hear about it.

I’m going to be helping out in the Visual Studio 2005 Launch Event here in Israel in a side session titled (and it’s a translation from Hebrew): “Error detection in off-road terrain and combining your application with Windows Error Reporting”.

Sounds a bit long for a title, isn’t it? 😉

There are a few such side sessions which will be going on at the same time as other “Main” sessions. The main idea behind the side sessions is to have a smaller more intimate session (~50+ peoplee) that will allow better interaction between the lecturers and the people coming to hear the lecture.

We will be talking about how to do some production debugging at a customer site and how to handle memory dumps for post mortem debugging when you can’t have access to the client’s site. Gadi Meir of Idag (who is leading the session) will also talk about Windows Error Reporting (WER) and how to make your program work with it.
I will be talking about the managed areas of production and post mortem debugging as well as some samples on how to use, instrument and extend MDbg (which I talked about quite a bit in previous posts). Mainly these are topics that I’m usually covering here on the blog.

For some reason, since I’m a second chair in the presentation (and there are a lot of other second chairs for the other side sessions) I was not mentioned in the invitation.

That’s not nice, isn’t it? (remind me to have a small chat with the organizers. The second chairs should also be mentioned!)

Oh well… at least it’s going to be a cool event.
All of you in Israel – be sure to register here.

See you there and “Get Ready to Rock” (god, these marketing guys needs someone to help them a bit… 😉 )

If you want to catch me for a quick talk/question/whatever I will be hanging around the place where the session will be conducted and probably all around the place, so be sure to catch me!

Following some of the samples posted in Mike Stall’s blog and after actually needing something like this at work, I’ve decided to write a small program called ExceptionDbg which uses MDbg’s APIs and tracks all exceptions being thrown in an application (including those that are being swallowed by try..catch blocks).

We had a case of exceptions being thrown in the finalization code (this is C++ code that has destructors and therefore has finalizers. I’ve talked about C++ destructor in this previous post).

ExceptionDbg let you attach to a process and dump all of the exceptions being thrown live to your console and/or log file.

There are a few filters on the exception types being logged including:

  • Show only exceptions being caught by try..catch blocks
  • Show full Call Stack and if debug symbols are present, show line numbers as well as source file names.

So what is it good for, you ask?

  • Check exceptions in the finalizer thread – These exceptions are ALWAYS being caught so the finalizer thread will not die. It can mean that if you have some code that frees some unmanaged resources they will not get freed and this is a potential memory leak.
  • Got a performance problem? Check how what are all the exceptions being thrown and caught (try..catch blocks) to verify that some pieces of code doesn’t use exception throwing as a logic to handle things other than failure.

As you can see, it’s useful for a number of scenarios and it help me a lot in finding some of these problems.

You can get the binaries here and the source code here.

You need the .NET Framework 2.0 for this which can be downloaded from here.
If you want to compile it you’ll need the .NET Framework 2.0 SDK which you can download from here.

Enjoy and send me feedback!