2 minute read

I came back from a long vacation today and I’ve finally caught up with enough emails to do something useful with my day.

As I scanned through my blog email folder I noticed that I had a lot of emails relating to my last post on dumping .net exceptions in windbg, and most of them asked why they see OutOfMemoryExceptions on the heap, and how to troubleshoot this.

I think I have mentioned this before, but it seems like it is worth mentioning again as it is probably buried deep in some post from way back when…

When you dump out all the exceptions on your .net GC heap (using !dumpheap -type Exception for example) these 3 types of exceptions will always show up, independently of what type of .net process you are debugging.

79330c30        1           72 System.ExecutionEngineException
79330ba0        1           72 System.StackOverflowException
79330b10        1           72 System.OutOfMemoryException

Contrary to what you may believe, this does not necessarily mean that the process has suffered from a stack overflow for example.

When you run !dumpheap –type Exception, what you are really doing is dumping out any type of object on the GC heap whose name contains the word Exception, not just the ones that are thrown.

These 3 exceptions (ExecutionEngineException, StackOverflowException and OutOfMemoryException) are very special in the sense that it would be impossible to create an object of type OutOfMemoryException when you are in an OOM situation, as that would fail with yet another OOM. In the same way you can’t create a StackOverflowException object when you are running into a stack overflow as this would require a call to its constructor which is impossible when the stack is overflowing.

To mitigate this, the CLR will generate these 3 exception objects at startup so that it can just throw them whenever the exception occurs.

In short, if you see these on the heap, don’t panic, unless you have some other evidence that they are occurring, they probably aren’t.

To see if you are really suffering from one, run !threads and you should see if any threads have recently thrown one. All of these will make the process crash/exit so you shouldn’t really see them unless you are also seeing a crash. The only one that you might see without a crash is the OOM, but if you do see one when you run !threads or in the event viewer, you are pretty close to a crash so it should be investigated.

If you do see any of these running !threads, check out the post index to find articles related to troubleshooting each of these types of issues.

Have a good one, Tess