In the real world scenario, at times you would have more than one applications running in the Default Web Site. For example:
--> Buggy App
Capturing the memory dump with Debug Diagnostic 1.1, you would end up seeing the following app domains loaded into your worker process (w3wp.exe)
0:000> !dumpdomain -stat
Domain Num Assemblies Size Assemblies Name
7a3bd058 0 0 System Domain
7a3bc9a8 39 131,832,320 Shared Domain
000dd770 11 50,011,648 DefaultDomain
00104ec0 64 130,407,424 /LM/W3SVC/1/Root/1-129144361934940766
00135d38 40 108,036,096 /LM/W3SVC/1/Root/HR-2-129144361939315794
1c315168 56 120,163,328 /LM/W3SVC/1/Root/Buggy App-3-129144361951347121
System Domain ==> It is responsible for creating and initializing the SharedDomain and the default AppDomain
Shared Domain ==> All of the domain-neutral code is loaded here. Mscorlib/GAC are loaded here
DefaultDomain ==> It is an instance of AppDomain within which application code is typically executed.
Here is the excellent article on CLR runtime objects describing the App Domains in detail.
If one of these applications was spiking the CPU and/or causing the high memory usage, there was no way to figure out which one of these was spiking?
In fact looking through the Task Manager or Perfmon, we would end up seeing it as just a single worker process spiking!
With ASP.NET 4, there is a new option introduced which would help in isolating the culprit application within the worker process.
For enabling this new “Performance monitoring” feature, we need to add the following in the aspnet.config file of the framework folder [C:\Windows\Microsoft.NET\Framework\v4.0.30319]
Now there would be two new performance counters available in the "ASP.NET Applications" performance category:
1) % Managed Processor Time
2) Managed Memory Used
Both of these performance counters use the new CLR application-domain resource management feature to track estimated CPU time and managed memory utilization of individual ASP.NET applications.
Looking in the Perfmon:
At this point you would be able to figure out the culprit application and can point it to its own app pool.
This way you would have a more granular view into the resource consumption of individual applications within in a single worker process[w3wp.exe]