Enumerating AppDomains – I

Surprisingly, enumerating AppDomains is not that straightforward. The System.AppDomain type does not expose functionality to enumerate them at all. The way to enumerate them will be to use the V1 Hosting interface, ICorRuntimeHost and then invoke the EnumDomains and NextDomain methods against it to get the list. If you are using CLR 2.0, you needn’t worry as CLR 2.0 does implement the V1 interfaces as well.

 

Below is the snippet that exemplifies the concept (note: AppDomains will only be enumerated in the current process – I will discuss AppDomain enumeration in remote processes later). You can download the source code (VS Solution) from http://www.wintoolzone.com/ListDotNET.aspx?Listtype=5

 

// EnumAppDomains.cpp : Defines the entry point for the console application.
// 
#include "stdafx.h"
#include <windows.h>
#include "mscoree.h"
#import "C:\\Windows\\Microsoft.NET\\Framework\\v2.0.50727\\mscorlib.tlb" raw_interfaces_only
using namespace mscorlib; 
#define EXITONERROR(hr, mesg) \
if (FAILED(hr)) \
{ \
printf("%s\n", mesg); \
ExitProcess(1); \
} 
#define SUCCESSFUL(hr) (SUCCEEDED(hr) && hr != S_FALSE) 
int _tmain(int argc, _TCHAR* argv[])
{
ICorRuntimeHost * pV1HostPtr = NULL;
HRESULT hr = CorBindToRuntimeEx(NULL,
NULL, 0, 
CLSID_CorRuntimeHost,
IID_ICorRuntimeHost,
(LPVOID *)&pV1HostPtr);
EXITONERROR(hr, "Unable to get ICorRuntimeHost*"); 
// Start the runtime
hr = pV1HostPtr->Start();
EXITONERROR(hr, "Unable to start the runtime"); 
// Enumerate the AppDomains
HDOMAINENUM adEnum;
hr = pV1HostPtr->EnumDomains(&adEnum);
EXITONERROR(hr, "Unable to enumerate AppDomains");
// Loop thru the domains
IUnknown * pDomainUnk = NULL;
hr = pV1HostPtr->NextDomain(adEnum, &pDomainUnk);
while(SUCCESSFUL(hr))
{
// Got the IUnknown* to the AppDomain - convert it to AppDomain pointer
_AppDomain * pCurDomain = NULL;
hr = pDomainUnk->QueryInterface(__uuidof(_AppDomain), (VOID**)&pCurDomain);
if (SUCCESSFUL(hr))
{
// Display the name of the AppDomain
BSTR str;
if (SUCCESSFUL(pCurDomain->get_FriendlyName(&str)))
{
wprintf(L"AppDomain: %s\n",str);
}
else
{
printf("AppDomain: unable to get the name!\n");
}
} 
// Loop onto the next Domain
hr = pV1HostPtr->NextDomain(adEnum, &pDomainUnk);
} 
// Stop the runtime
if (pV1HostPtr)
{
pV1HostPtr->Stop();
}
return 0;
} 

Article: Customizing AppDomain Creation

Did you have a scenario where you wished you could customize the creation of AppDomains? Or, you could control how many AppDomains any code that runs in your application context (e.g. if you are writing a plugin load framework) could create? Or, how about reusing AppDomains for various assemblies?

I have just finished an article on how any of the above scenarios can be accomplished using the System.AppDomainManager type, introduced in .NET Framework 2.0, by intercept AppDomain creation requests.

You can read the article at http://www.wintoolzone.com/articles/Customizing_AppDomain_Creation.aspx and download associated source code from http://www.wintoolzone.com/downloads/Customizing_AppDomain_Creation_src.zip

How the SSCLI [a.k.a. Rotor] managed "new" works

One of the best ways to understand how the CLR works internally is to have a look at the SSCLI [a.k.a Rotor] source code.

In How the SSCLI [a.k.a. Rotor] managed “new” works, I have used Rotor source code to discuss what happens behind the scenes when you use the managed new operator to instantiate a managed type, discussing implications of object size, how requests from multiple threads are handled, the different validations that are done, when out-of-memory exception is thrown, etc. If you are a managed code developer, you may learn a thing or two that can help you write better code besides understanding how the managed allocation works internally.

CLR Profiler for .NET Framework 2.0

Download it from here.

Adding process enumeration support in Rotor v1.0

Share Source CLI, better known as Rotor, is one of the best ways to understand how .NET Framework works. And with the source code availability as part of Rotor distribution, its an excellent academic/hobby interest – you can extend it by adding more functionality, or modify the existing one and see how it behaves.

Yesterday, I went about doing the same. One of the functionality which I found missing in Rotor is that of enumerating system process list. .NET Framework’s System.Diagnostics.Process class has methods, like GetProcesses, that allow you to do the same.

So, I went about implementing GetProcesses method overloadsin System.Diagnostics.Process class that allow me to enumerate process list on the local machine only. This required modification in the Platform Adaptation Layer (PAL) of Rotor. Since, I just have it running on Win32 for the moment, I modified the Win32 PAL to implement the support via ToolHelpAPI. Now, on a Windows system, its possible to enumerate the system process list using Rotor, as exemplified by the snippet below:

You can download the updated source files for Rotor v1.0 from http://www.wintoolzone.com/showpage.aspx?url=rotor.aspx. The zipped archive contains Changes for Process Enumeration.txt that indicates where the updated files need to be copied. Once done, rebuild Rotor to get the changes into effect.

using System; 
using System.Diagnostics;

public class EnumProcess
{
    public static void Main()
    {
        Process[] arrProcess = Process.GetProcesses();
        if (arrProcess == null)
        {
            Console.WriteLine("Unable to get process list!");
            return;
        }

        Console.WriteLine("{0} processes enumerated.", arrProcess.Length);

        foreach (Process proc in arrProcess)
            Console.WriteLine("Process ID {0}, Handle: {1}", proc.Id, proc.Handle);
    }
}

Understanding CLR’s Special Threads

There are multiple special threads which the CLR maintains and executes. Yun Jin talks about them in his blog at http://blogs.msdn.com/yunjin/archive/2005/07/05/435726.aspx.

Must read for those who want to understand CLR better!

..and ThreadPool.GetMinThreads

And I am finally done with extending the Rotor’s ThreadPool class. Finished implementing the GetMinThreads method.

Download the source code from http://www.wintoolzone.com/showpage.aspx?url=rotor.aspx.

Rotor – SetMaxThreads, SetMinThreads

Just finished extending Rotor’s ThreadPool class to support SetMaxThreads and SetMinThreads methods – to modify the extent of the threadpool maintained by the Rotor runtime – just like .NET FX 2.0 has it.

Will post the source code soon…meanwhile, here’s my implementation of SetMinThreadsInternal in Win32ThreadPool.cpp:

/************************************************************************/
// Will be used to set the minimum number of threads in the Rotor Threadpool
// Kumar Gaurav Khanna - 22-Jul-2004
BOOL ThreadpoolMgr::SetMinThreads(DWORD MinWorkerThreads, 
                                     DWORD MinIOCompletionThreads)
{

    if (IsInitialized())
    {
        BOOL result = FALSE;

        // 1) cannot have minimum worker thread limit <=0
        // 2) cannot have minimum worker thread limit equal to 

        //    or greater than the maximum worker thread limit
        if ((MinWorkerThreads > 0) && (MinWorkerThreads < MaxLimitTotalWorkerThreads)) 
        {
            if (MinWorkerThreads <= (DWORD) MinLimitTotalWorkerThreads)
            {
                MinLimitTotalWorkerThreads = MinWorkerThreads;
                result = TRUE;
            }
        }

        return result;
    }

    if (InterlockedCompareExchange(&Initialization, 1, 0) == 0)
        {
                Initialize();

        BOOL result = FALSE;
        
        if ((MinWorkerThreads > 0) && (MinWorkerThreads < MaxLimitTotalWorkerThreads))
        {
            if (MinWorkerThreads <= (DWORD) MinLimitTotalWorkerThreads) 
            {
                MinLimitTotalWorkerThreads = MinWorkerThreads;
                result = TRUE;
            }
        }

                Initialization = -1;

        return result;
        }
    else // someone else is initializing. Too late, return false
    {
        return FALSE;
    }

}