.NET debugging Lab2 : Learn !dumpdomain command (Observe appdomains existing on a .NET application)

(The related concept section is given below of this article)

Hands-On demo

In this demo ,  we will learn to execute a WinDBG command (!dumpdomain) . It will print all the application domains existing on the .NET application.

Suggestion :Users can watch a video walkthrough of this demo provided here

Step-by-step instructions for this demo

Pre-requisites : 

1. Beginners please go through this link : Beginner tutorials.
    (They need to download WinDBG tool and make ready the tool for debugging)

2. User can download the dump file for doing this exercise from here.      
    Unzip the dump file once it is download


Demo Steps
1. Start WinDBG (x86 version) 
2. Open File Menu => Open Crash dump

3.   Select the dump file "Demo_ObserveAppDomains.dmp" . Apply OK
              (The dump file loaded to debugger)

4. Apply command .loadby sos.dll clr  
            [ Image given below . This step will enable WINDBG ready for .NET debugging.]

          

6.    Now we need to watch all app domains existing on the application
             Apply !dumpdomain command  in the command prompt 

    

7.   Scroll up and reach to the beginning of the !dumpdomain command result

8.   Observe System, Shared and default domains.

  

















     9.   Scroll down and Observe shared domain has loaded domain neutral assembly (mscorlib.dll)

      10. Observe Domain 1 contain  the application's code assemblies

11. User a shell command to find out the number of app domains in an application.
Apply  .shell -ci "!dumpdomain" FIND /c "Domain"  in the command prompt.
( The shell command will find all the strings with "Domain" in the !dumpdomain command result) 
(its result given below)

Wrap-up Discussion

In this demo we saw how to list existing app domains and how many domains are created by default.

 In the next demo session we can detail about each domain and dump their contents.

Section : Concepts

Process boundary

Applications running on windows are protected by each other. Each application has a process and they are separated (isolated) by their process boundary. So if an application crashes due to some issues, its process gets killed, but the other applications are unaffected.

The process boundary provides great security benefits. It also adds few restrictions when processes communicates each other. This is because memory addresses on one process has no meaning for the  other application. The components within an application communicate (transfer data) freely but the data transfer between the processes would require additional work like marshaling (copy data from one  process , pass the data and place it to meaningful address location of other process)

Application domains

App domains carry the same concept of providing isolation and security but they are within the process. By default , .NET CLR create three application domains to any .NET application with names (System ,Shared and default) .User can programmatically add new domains to applications.   The cross-domain communication requires marshaling. 

Ex: Hosting applications (Like  IIS processes) utilizes multiple .NET app domains to load web applications in separate app domain so that applications behave so distinct and isolated each other.

The brief description of CLR created domains for an application is listed below.

System domain : The first application domain created on the application. It is responsible for creating other two domains ( Shared and default). This domain loads mscorlib dll to shared application domain.

Shared Domain: This is the place where the shared code exists . There is a type of assemblies called domain neutral assemblies(their code can be accessible in all app domains). They are getting loaded to this app domain.

Default domain:  The domain where application specific data and assemblies resides.