Abstract

In this article, you’ll drill deeper into the details of how an assembly is hosted by the CLR and come to understand the relationship between the application domain (appdomain) and processes. The appdomain, in a nutshell, comprises logical segments within a given process that host a set of related .NET assemblies. In addition to that, this article also explores manipulating a currently running process.

Process

A process is a fixed, safe boundary for a running program and an operating system level concept used to describe a set of resources and the necessary memory allocations used by a running application. The operating creates a separate and isolated process for each executable loaded into memory. Furthermore, in application isolation, the result is much more stable and robust in the runtime environment because the failure of one process does not affect the functioning of another process. Data in one process can’t be directly accessed by another process, unless you make use of distributed API programming such as WCF, COM+ and Remoting.

Every Windows process is assigned a unique process identifier (PID) and may be independently loaded and unloaded by the OS. You can view the various running processes of Windows OS through Task Manager as following;


Every Windows process contains an initial thread that functions as an entry point for the application. Formally speaking, a thread is a path of execution within a process. Processes that contain a single primary thread of execution are considered to be thread-safe.

Process in Depth

The System.Diagonostic namespace defines a number of types that allow you to programmatically interact with processes and various other manipulations such as performance counter and event log.

To illustrate the process of manipulating the Process object, assume you have a console application that displays all the currently running processes in the system.

using System;
using System.Diagnostics;

namespace ProcessDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            Process[] p = Process.GetProcesses("system-machine");

            foreach (Process a in p)
            {
                Console.WriteLine("Current Running Processesn");
                string str = string.Format("PID::{0} t Name::{1}",a.Id,a.ProcessName);
                Console.WriteLine(str);
                Console.ReadKey();
            }
        }
    }
}

You will see the PID and names for all processes on your local computer as follows:


In addition to obtaining a full list of all running processes on a given machine, the GetProcessById() method allows you to obtain a single Process object via its associated PID.

using System;
using System.Diagnostics;

namespace ProcessDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.Write("Enter Process ID::");
            string pid = Console.ReadLine();
            Process p = null;
            try
            {
                p = Process.GetProcessById(int.Parse(pid));
            }
            catch(Exception)
            {
                Console.WriteLine("PID not Found");
            }

            Console.WriteLine("Threads used by: {0}",p.ProcessName);
            ProcessThreadCollection ptc = p.Threads;
            foreach (ProcessThread a in ptc)
            {
                Console.WriteLine("Current Running Processesn");
                string str = string.Format("PID::{0} t Start Time::{1}",a.Id,a.StartTime.ToShortTimeString());
                Console.WriteLine(str);
                Console.ReadKey();
            }
        }
    }
}

When you run your company, you can now enter the PID of any process on your machine, and threads used in the process as follows:


The following sample shows the Start() method. This method provides a way to programmatically launch and terminate a process as follows:

using System;
using System.Diagnostics;

namespace ProcessDemo
{
    class Program
    {
        static void Main(string[] args)
        {
            Process p = null;
            try
            {
                p = Process.Start("chrome.exe","www.google.com");
            }
            catch(Exception)
            {
                Console.WriteLine("Error!!!");
            }
            Console.WriteLine("Process Start: {0}",p.ProcessName);
            Console.ReadKey();
        }
    }
}

Application Domain

An application domain is a logical container for set of assemblies in which an executable is hosted. As you have seen, a single process may contain multiple application domains, each of which is hosting a .NET executable. The first appdomain created when the CLR is initialized is called the default AppDomain and this default one is destroyed when the Windows process is terminated. Here are some specific features offered by AppDomain:

  • AppDomain can be independently secured

    When an appdomain is created, it can have a permission set applied to it that determines the maximum rights granted to assemblies running in the AppDomain, which ensure the code cannot be corrupted.

  • AppDomain can be unloaded

    The CLR doesn’t endorse the ability to unload a single assembly from an AppDomain. However, the CLR will notify to unload entire currently contained assemblies from an appdomain.

  • Independently configured

    AppDomain can have cluster of configuration settings associated with it, for instance, how the CLR loads assemblies into appdomain, search path and loader optimization.

  • No mutual intervention by multiple appdomain

    When code in an AppDomain creates an object, it is not allowed to live beyond the lifetime of the AppDomain. Code in another AppDomain can access another object only by marshal by reference or marshal by value. This enforces a clean separation because code in one appdomain can’t have a direct reference to an object created by another code in different appdomain.

  • Performance
  • The application domains are less expensive thus the CLR is able to load and unload application domain in much quicker than formal process and improve the performance.

The following image shows a single Windows process that has one CLR COM server running in it. This CLR is currently managing two application domains. Each appdomain has its own heap and has a record of which types have been accessed since the appdomain was created. Apart from that, each application domain has some assemblies loaded into it. AppDomain #1 (default) has three assemblies and AppDomain #2 has two assemblies loaded: xyz.dll and System.dll.

So the whole purpose of an application domain is to provide the isolation the CLR needs to be able to unload an appdomain and free up all of its resources without adversely affecting any other appdomain.

System.AppDomain Class

The AppDomain class is used to create and terminate application domains, load and unload assemblies and types, and enumerates assemblies and threads in a domain. The following table shows some useful methods of the AppDomain class;

Methods Description
CreateDomain() It allows us to create a new application domain.
CreateInstance() It creates an instance of type in an external assembly.
ExecuteAssembly() It executes an *.exe assembly in the application domain.
Load() This method, used dynamically, loads an assembly into the current app domain.
UnLoad() It allows us to unload a specified AppDomain within a given process.
GetCurrentThreadID() It returns the ID of the active thread in the current application domain.

In addition, the AppDomain class also defines a set of properties which can be useful when you wish to monitor activity of a given application domain:

Properties Description
CurrentDomain Gets the application domain for the currently executing thread.
FriendlyName Gets the friendly name of the current application domain.
SetupInformation Gets the configuration details for a given application domain.
BaseDirectory Gets the directory path that the assembly resolver uses to probe for assemblies.

The following sample illustrates a created assembly being called from another application domain. First create a console application AppDomainTest. In the main() add a Console.WriteLine() so that you can see when this method is called.

using System;

namespace AppDomainTest
{
    class Program
    {
        static void Main(string[] args)
        {
            // Main assembly that is called from another AppDomain
            Console.WriteLine("AppDomainTest in new created Domain '{0}' called"
                      , AppDomain.CurrentDomain.FriendlyName);
            Console.WriteLine("ID of the Domain '{0}'"
                     , AppDomain.CurrentDomain.Id);
            Console.ReadKey();
        }
    }
}

Then create a second project named DemoTest. First display the name of the current domain using the property FriendlyName. With the CreateDomain() method, a new application domain with the friendly name New AppDomain is created. Then load the assembly AppDomainTest.exe into the new domain and call the Main() method by calling ExecuteAssembly();

Using System;
//add a reference to AppDoaminTest.exe
namespace DemoTest
{
    class Program
    {
        static void Main(string[] args)
        {
            AppDomain d1 = AppDomain.CurrentDomain;
            Console.WriteLine(d1.FriendlyName);

            AppDomain d2 = AppDomain.CreateDomain("New AppDomain");
            d2.ExecuteAssembly("AppDomainTest.exe");
        }
    }
}

When you compile the DemoTest project, first the current domain friendly name will be displayed, followed by the called assembly as follows:


Loading Assemblies into Custom Application Domain

The CLR will always load assemblies into the default application domain when required. If you want to manually load assemblies into an application domain, you can achieve this by using the AppDomain.Load() method. Here, suppose that you want to load a previously create library TestLib.dll into a secondary application domain:

Want to learn more?? The InfoSec Institute Web Application Penetration Testing Boot Camp focuses on preparing you for the real world of Web App Pen Testing through extensive lab exercises, thought provoking lectures led by an expert instructor. We review of the entire body of knowledge as it pertains to web application pen testing through a high-energy seminar approach.

The Web Application Penetration Testing course from InfoSec Institute is a totally hands-on learning experience. From the first day to the last day, you will learn the ins and outs of Web App Pen Testing by attending thought provoking lectures led by an expert instructor. Every lecture is directly followed up by a comprehensive lab exercise (we also set up and provide lab workstations so you don't waste valuable class time installing tools and apps). Benefits to you are:

  • Get CWAPT Certified
  • Learn the Secrets of Web App Pen Testing in a totally hands-on classroom environment
  • Learn how to exploit and defend real-world web apps: not just silly sample code
  • Complete the 83 Step "Web App Pen Test Methodology", and bring a copy back to work with you
  • Learn how perform OWASP Top 10 Assessments: for PCI DSS compliance
using System;
using System.IO;
using System.Linq;

namespace DemoTest
{
    class Program
    {
        static void Main(string[] args)
        {

           AppDomain newDomain = AppDomain.CreateDomain("New AppDomain");

            try
            {
                newDomain.Load("TestLib");
            }
            catch (FileNotFoundException)
            {
                Console.WriteLine("Not Found");
            }
            ListAssemblies(newDomain);
            Console.ReadKey();
        }

        static void ListAssemblies(AppDomain ad)
        {
            var la = from a in ad.GetAssemblies()
                     orderby a.GetName().Name
                     select a;

            Console.WriteLine("Assemblies Loaded {0}n",ad.FriendlyName);

            foreach(var a in la)
            {
                Console.WriteLine("Name:: {0}:", a.GetName().Name);
                Console.WriteLine("Version:: {0}:n", a.GetName().Version);
            }

        }
    }
}

This time the output of the aforementioned program is as follows:


Summary

The triggering point of this article is to examine how a .NET executable image is hosted by the .NET platform. As you have seen, a single process can host multiple application domains, each of which is capable of hosting and executing any number of related assemblies.