Well… the short answer is: not necessarily ?
I had this discussion a few days ago with a customer who called CSS for a crash they were having, and since he was also starting to learn some debugging and dump analysis basics, he was interested to have some deeper details about my findings in the crash dump they sent in.
In particular, he thought the crash was due so an OutOfMemoryException because checking the exceptions with WinDBG, he saw something like the following:
0:000> !dumpallexceptions
Going to dump the .NET Exceptions found in the heap.
Number of exceptions of this type: 1
Exception 0cf500bc in MT 79b94ee4: System.ExecutionEngineException—————–
Number of exceptions of this type: 1
Exception 0cf5007c in MT 79b94dac: System.StackOverflowException—————–
Number of exceptions of this type: 1
Exception 0cf5003c in MT 79b94c74: System.OutOfMemoryException—————–
The point is that we are pre-loading a few exception objects on the heap when starting an AppDomain, and the reason is quite simple if you think about it for a moment. Let’s pretend we don’t have exception objects preloaded: if an application ever reaches a condition where needs to allocate some more memory but there is not enough memory available, then the CLR will have to throw an OutOfMemoryException; but if there is no more memory available on the system (I’m avoiding some details here, but you get the idea), where can we find the memory needed to allocate a new exception object (and all other objects involved in the background)? ?
I think you already found the answer: those objects must be already on the heap, thus the CLR is pre-loading them. There is a similar reason behind the ExecutionEnginException and the StackOverflowException objects.
Carlo