如何深入了解.NET编译器中CLR加载过程

 -- subsystem，可执行文件的用户界面使用的子系统类型。具体值的含义为：

1 不需要子系统（比如设备驱动）

2 在Windows图形用户界面子系统下运行

3 在Windows字符子系统下运行（控制台程序）

5 在OS/2字符子系统下运行（仅对OS/2 1.x）

7 在 Posix 字符子系统下运行

所以可以看到我们的程序是一个控制台程序。

       -- 最后定义了一些数据目录，具体内容不再赘述。

                                                                     图 3

5)  section header

Section header可以有一个或多个，见图4、图5、图6。

-- name，表示这个section的名字，例如这个section的名字为.text；

-- virtual address，保存section中数据被载入内存后的RVA；

-- file pointer to raw data，从文件开头到section中数据的偏移量。

图 6
-- CLR头，从图7可以找到随托管代码IL同时生成的元数据表的RVA。

图 7

2、PE loader通过查找CLR头发现该目录不为空，则自动将mscoree.dll载入进程地址空间中，mscoree.dll一定是唯一的，且总是处于系统目录的system32下，例如我的机器为C:\WINDOWS\system32目录下。.net 2.0的mscoree.dll的大小只有256k左右，这个dll被叫做shim，它的作用是连接PE文件和CLR之间的一个桥梁。

3、PE loader接着会找到entry point，例如本例中图3所示，这个PE文件的入口点地址为0040251E，然后通过这个地址来查找.text section的原始数据表，由图6所示，0040251E这个地址开始的6个字节的内容为【FF 25 00 20 40 00】，这个内容就是由编译器写入PE文件的.text section的重要信息，FF在x86汇编语言与机器码对照表中代表无条件转移指令Jmp，这条指令的作用是无条件跳转到00402000地址处，从图3可以看到image base 是00400000，2000是import address table的RVA地址，由图7可以看到，此时程序会跳转到00402000这个地址所引用的mscoree.dll的_CorExeMain(_CorExeMain为mscoree.dll的入口方法)方法，所有的托管应用都会通过上述过程找到并执行_CorExeMain方法；

4、_CorExeMain方法会帮助程序找到并载入适当的CLR版本，在.net 2.0以后实现CLR的程序集为mscorwks.dll或mscorsvr.dll，例如，在我的机器上mscorwks.dll的位置是：C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\；

5、启动CLR服务，开始初始化工作，这个初始化工作包括:

-- 分配一块内存空间，建立托管堆及其它必要的堆，由GC监控整个托管堆

-- 创建线程池

-- 创建应用程序域(AppDomain):利用sos.dll可以查看CLR创建了哪些AppDomain。

用VS2005打开我们的程序，在即时窗口中敲入：.load sos.dll。

在VS2005的即时窗口中敲入：后的结果），但是依然可以说明问题：

图 8

由图8可见，CLR创建了System Domain、Shared Domain和Domain1，这个Domain1是默认Appdomain。

6、接下来就会向默认AppDomain中载入mscorlib.dll，由图八可见，任何托管代码，CLR在创建好默认AppDomain后，第一个载入的组件一定是mscorlib.dll，实际上这个组件定义了System.Object、所有基元类型：如System.Int32等，利用sos.dll可以看到有哪些类被载入，依据Domain 1里的Module地址，在即时窗口敲入命令!dumpmodule -mt790c2000，结果如下，比较长，我只列出部分：

图 9

从图9可以看到System.Object被第一个加载进来，接着是System.ICloneable、System.IEnumerable、System.Collection.ICollection、System.Collection.IList、System.Array……

7、产生主线程后可能会触发一些mscorlib.dll里的类型并加载入内存，接着，当你的PE文件：hello.exe被载入后，默认Appdomain的名字被改为你的PE文件的名字，载入过程完成后的结果可见图8。

8、包含在mscorwks.dll中的_CorExeMain2方法接管主线程，它将调用System Domain中的SystemDomain::ExecuteMainMethod方法，然后由此方法调用类型加载器的ClassLoader::LoadTypeHandleFromToken方法，该方法会读取程序集中的元数据表，并在里面查找包含.entrypoint的类型，并返回由EECLASS结构表示的该类型的实例，EECLASS结构中包含重要信息有：指向当前类型父类的指针、指向方法表的指针、实例字段和静态字段等。

(1)、在即时窗口敲入命令0097c

图 10

从图10可以看到在当前模块中所定义的类型：hello.Program和所引用的类型：System.Object和System.Console。

(2)、在即时窗口敲入命令后，有如下结果：

图 11

由图11可以得到如下信息：为hello.Program类型分配的EECLASS在内存中的地址为00971260，通过这个地址查看其信息，发现hello.Program的父类地址为： 790f8a18，在即时窗口敲入命令790f8a

图 12

方法表Method Table的地址为00972ff8。

 (3)、方法表里存的是什么呢？其实是当前类型中所有定义和引用到的方法的入口点，这个入口点被叫做Method descriptors，从图11可以看到。

 (4)、实际上Method descriptors被分为两个部分，第一部分是m_CodeOrIL，在当前方法没有被JIT的时候，m_CodeOrIL存的是这个方法的MSIL的RVA，也就是从这个RVA可以找到当前方法的MSIL代码；第二部分是对JIT编译器的一个Stub(存根)，当方法是第一次被调用的时候，CLR会通过这个Stub调用mscorjit.dll组件，通过m_CodeOrIL里存储的RVA，找到这个方法对应的MSIL代码，然后将其编译为本地CPU指令，假设这里存到地址RVA1，最后将m_CodeOrIL和Stub的值都修改为RVA1，那么当这个方法第二次被调用的时候将会直接通过RVA1去寻找本地代码，换句话说只有当方法第一次被调用的时候才会被Jit编译器编译，之后则直接使用编译好的本地代码。同时这也说明托管代码被编译了两次，第一次编译是将托管代码编译为MSIL代码，并同时生成Metadata元数据文件，第二次编译发生在方法被调用时由Jit编译器完成。

图 13

被Jit过得方法则会修改m_CodeOrIL，如Main方法的m_CodeOrIL被指向地址00e50070，而没有被Jit的方法m_CodeOrIL的值为ffffffffffffffff。

 (6)、在即时窗口敲入命令

图 14

图14列出helloProgram.Main方法的本地代码。而如果在即时窗口敲入命令!u ffffffffffffffff则显示Unmanaged code。

9、进入Main方法，进而执行后续程序。

最后，从上述分析也可以看出，.NET的几个核心组件的被调用顺序大致是： mscoree.dll -----> mscorwks.dll(mscorsvr.dll)  -----> mscorlib.dll ----->mscorjit.dll。
一般来说调试.NET程序使用VS2005就可以了，但是要想得到更详细的信息，如内存情况等就需要借助其他工具了，个人觉得sos.dll和Windbg是很好的工具，Windbg可以在http://www.microsoft.com/whdc/devtools/debugging/default.mspx下载，而如果你装的是VS2005 Team Version，那么自带sos.dll。