SOS Command: !DumpDomain [<Domain address>]
When called with no parameters, !DumpDomain will list all the AppDomains in the process. It enumerates each Assembly loaded into those AppDomains as well.
In addition to your application domain, and any domains it might create, there are two special domains: the Shared Domain and the System Domain.
Any Assembly pointer in the output can be passed to !DumpAssembly. Any Module pointer in the output can be passed to !DumpModule. Any AppDomain pointer can be passed to !DumpDomain to limit output only to that AppDomain. Other functions provide an AppDomain pointer as well, such as !Threads where it lists the current AppDomain for each thread.
!dumpdomain -------------------------------------- System Domain: 7a3bd058 LowFrequencyHeap: 7a3bd07c HighFrequencyHeap: 7a3bd0c8 StubHeap: 7a3bd114 Stage: OPEN Name: None -------------------------------------- Shared Domain: 7a3bc9a8 LowFrequencyHeap: 7a3bc9cc HighFrequencyHeap: 7a3bca18 StubHeap: 7a3bca64 Stage: OPEN Name: None Assembly: 001a58e8 -------------------------------------- Domain 1: 0015d2e0 LowFrequencyHeap: 0015d304 HighFrequencyHeap: 0015d350 StubHeap: 0015d39c Stage: OPEN SecurityDescriptor: 0015e608 Name: FindProduct.exe Assembly: 001a58e8 [C:WINDOWSassemblyGAC_32mscorlib2.0.0.0__b77a5c561934e089mscorlib.dll] ClassLoader: 001a5968 SecurityDescriptor: 001a4720 Module Name 790c1000 C:WINDOWSassemblyGAC_32mscorlib2.0.0.0__b77a5c561934e089mscorlib.dll Assembly: 001b0788 [C:svnNetInverseFindProductbinDebugFindProduct.exe] ClassLoader: 001b0808 SecurityDescriptor: 001b0688 Module Name 00932c5c C:svnNetInverseFindProductbinDebugFindProduct.exe
System Domain
The SystemDomain is responsible for creating and initializing the SharedDomain and the default AppDomain. It loads the system library mscorlib.dll into SharedDomain. It also keeps process-wide string literals interned implicitly or explicitly. String interning is an optimization feature that saves memory by having only a single instance of the string for a given literal across all the application domains. SystemDomain is also responsible for generating process-wide interface IDs, which are used in creating InterfaceVtableMaps in each AppDomain. SystemDomain keeps track of all the domains in the process and implements functionality for loading and unloading the AppDomains.
SharedDomain
All of the domain-neutral code is loaded into SharedDomain. Mscorlib, the system library, is needed by the user code in all the AppDomains. It is automatically loaded into SharedDomain. Fundamental types from the System namespace like Object, ValueType, Array, Enum, String, and Delegate get preloaded into this domain during the CLR bootstrapping process. User code can also be loaded into this domain, using LoaderOptimization attributes specified by the CLR hosting app while calling CorBindToRuntimeEx. Console programs can load code into SharedDomain by annotating the app’s Main method with a System.LoaderOptimizationAttribute. SharedDomain also manages an assembly map indexed by the base address, which acts as a lookup table for managing shared dependencies of assemblies being loaded into DefaultDomain and of other AppDomains created in managed code. DefaultDomain is where non-shared user code is loaded.
DefaultDomain
DefaultDomain is an instance of AppDomain within which application code is typically executed. While some applications require additional AppDomains to be created at runtime (such as apps that have plug-in architectures or apps doing a significant amount of run-time code generation), most applications create one domain during their lifetime. All code that executes in this domain is context-bound at the domain level. If an application has multiple AppDomains, any cross-domain access will occur through .NET Remoting proxies. Additional intra-domain context boundaries can be created using types inherited from System.ContextBoundObject. Each AppDomain has its own SecurityDescriptor, SecurityContext, and DefaultContext, as well as its own loader heaps (High-Frequency Heap, Low-Frequency Heap, and Stub Heap), Handle Tables (Handle Table, Large Object Heap Handle Table), Interface Vtable Map Manager, and Assembly Cache.
LoadHeaps
Frequently accessed artifacts like MethodTables, MethodDescs, FieldDescs, and Interface Maps get allocated on a HighFrequencyHeap, while less frequently accessed data structures, such as EEClass and ClassLoader and its lookup tables, get allocated on a LowFrequencyHeap. The StubHeap hosts stubs that facilitate code access security (CAS), COM wrapper calls, and P/I