exe文件双击之后(.net版)

我们知道,.net编译器在生成托管代码时会将一些重要信息写入PE文件的header和.text section(后边我会介绍这些写入程序集的重要信息是什么),本文介绍当我们双击一个托管代码写的exe程序时发生的事情。
以下说明所使用的工具是VS2005+sos.dll,示例程序代码如下: 

using System;
using System.Collections.Generic;
using System.Text;

namespace hello
{
    class Program
    {
        static void Main(string[] args)
        {
            Int32 a = 1;
            Int32 b = 2;
            b = a + b;
            Console.WriteLine(b);

            Console.ReadKey();
        }
    }
}
那么CLR是如何被加载的呢?
1、当你双击一个.exe文件时,Windows操作系统提供的PE Loader会将该exe文件载入内存;
(1)、首先明确一点,PE Loader问什么能加载exe文件呢?因为exe文件就是一种PE文件,PE(Portable Execute)文件是微软Windows操作系统上的程序文件, EXE、DLL、OCX、SYS、COM都是PE文件。 (2)、有必要了解一下PE文件的结构:

1) Dos stub 由100个左右的字节所组成,用来输出类似“这个程序不能在DOS下运行!”这样的错误信息;
2) PE Signature DWORD类型,PE文件签名,用来表示这是个PE文件,用ASCII码表示;
3) File Header 包含PE文件最基本信息,通过dumpbin可以看到,
如图2所示 从这里可以看到:CPU类型为14c,是Intel I386、I486或者I586;section的数量为2;链接器产生这个文件的日期;COFF符号表的文件偏移量,为0;COFF符号表的符号数目,为0;Optional Header的大小。

图2
4) Optional Header 用来存储除了基本信息以外的其他重要信息,具体含义大家可以查阅PE文件格式的相关资料,我这里对一些关心的域根据图3进行一下说明: 
— entry point,指明这个PE文件的入口地址,是一个RVA(相对虚拟地址);
— base of code,代码块起始地址的RVA,在内存中,代码块通常在PE首部之后,数据块之前;
— base of data,数据块;
— image base,PE文件被链接器重定位后的内存地址,可以是链接器优化,节省载入时间和空间;
— 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中数据的偏移量。

图 4
— Section 的原始数据

图 5

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

图 7
2、PE loader通过查找CLR头发现该目录不为空,则自动将mscoree.dll载入进程地址空间中,mscoree.dll一定是唯一的,且总是处于系统目录的system32下,例如我的机器为C:WINDOWSsystem32目录下。.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:WINDOWSMicrosoft.NETFrameworkv2.0.50727;
5、启动CLR服务,开始初始化工作,这个初始化工作包括: — 分配一块内存空间,建立托管堆及其它必要的堆,由GC监控整个托管堆 — 创建线程池 — 创建应用程序域(AppDomain):利用sos.dll可以查看CLR创建了哪些AppDomain。 用VS2005打开我们的程序,在即时窗口中敲入:.load sos.dll。 在VS2005的即时窗口中敲入:!dumpdomain,(注:这个结果是完成步骤7后的结果),但是依然可以说明问题:

图 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 -mt 790c2000,结果如下,比较长,我只列出部分:
图 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)、在即时窗口敲入命令!dumpmodule -mt 0097c24,有如下结果:

图 10
从图10可以看到在当前模块中所定义的类型:hello.Program和所引用的类型:System.Object和System.Console。
(2)、在即时窗口敲入命令!dumpmt –md 00972ff和!dumpclass 00971260后,有如下结果:

图 11
由图11可以得到如下信息:为hello.Program类型分配的EECLASS在内存中的地址为00971260,通过这个地址查看其信息,发现hello.Program的父类地址为: 790f8a18,在即时窗口敲入命令!dumpclass 790f8a18,有图12,可见hello.Program类型的父类为:System.Object。

图 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编译器完成。
(5)、在即时窗口敲入命令!dumpmd 00972fe8和!dumpmd 00972f0可以看到已经被Jit过的和还没有被Jit的方法的信息:

图 13
被Jit过得方法则会修改m_CodeOrIL,如Main方法的m_CodeOrIL被指向地址00e50070,而没有被Jit的方法m_CodeOrIL的值为ffffffffffffffff。 (6)、在即时窗口敲入命令!u 00e50070,结果如下:

图 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。

2 条关于 “exe文件双击之后(.net版)” 的评论

发表评论