.Net7运行模型之托管Main函数的调用

前言：

.Net7的CLR最具特色的一个地方，就是运行模型。因为它主宰了整个CLR的运行过程。

又因为其庞大的代码量，有的几十万行甚至百万行。所以理解起来非常不容易。本篇拆分来看下，里面一个细节Main函数（注意这里的Main指的是托管Main，因为还有非托管main，所以特别指出下以免混淆）是如何被CLR调用的。

概括

Main函数的调用，基本上是最后才会被CLR引擎所调用。为啥？因为，如果.Net标准类库，以及底层的非托管C++类库没有在Main函数被调用之前，加载完成，那么你强行调用Main函数就会出错。

我们可以在Windows/Linux平台通过Windbg或者是LLDB来看下托管的Main函数的堆栈

00007ff7f55703b0
coreclr.dll!CallDescrWorkerInternal
coreclr.dll!CallDescrWorkerWithHandler
coreclr.dll!MethodDescCallSite::CallTargetWorker
coreclr.dll!MethodDescCallSite::Call	C++
coreclr.dll!RunMainInternal	C++
coreclr.dll!``RunMain'::`30'
coreclr.dll!`RunMain'::`30'
coreclr.dll!RunMain	C++
coreclr.dll!Assembly::ExecuteMainMethod
coreclr.dll!CorHost2::ExecuteAssembly
coreclr.dll!coreclr_execute_assembly	C++
corerun.exe!run	C++
corerun.exe!wmain	C++
corerun.exe!invoke_main	C++
corerun.exe!__scrt_common_main_seh	C++
corerun.exe!__scrt_common_main	C++
corerun.exe!wmainCRTStartup	C++
kernel32.dll!BaseThreadInitThunk
ntdll.dll!RtlUserThreadStart

这个堆栈里面我们可以得出很多的信息：

比如：

1.最上面的地址：00007ff7f55703b0是.Net里面的托管Main函数的入口地址。

2.整个程序的运行最开始的代码是ntdll.dll模块里面的RtlUserThreadStart函数。

3.非托管的CLR的入口是wmain函数。

有了以上的信息，我们很容易分析到。托管的Main函数调用是在程序集的ExecuteMainMethod函数里面调用RunMain这个函数，整个函数的名字一看就知道是运行Main函数的。

此后通过CallDescrWorkerInternal来调用RyuJIT编译MSIL代码为机器码。返回到托管Main函数的开头地址。

也就是上面的这个地址：00007ff7f55703b0

分析：

这个过程看似分析非常简单，但是实际上会遇到很多问题。但是如果你只用单一的调试器，比如只用Windbg。你可能完全看不出来以下这些问题。

比如你在调试.Ctor，也就是.Net 7里面默认的构造函数的时候。如果在VS上Debug CLR上面，如果进入到托管Main的机器码当中，运行到.Ctor的机器码的地方。它会报一个不是错误的错误，而跟踪下来居然是MapViewOfFile这个微软的官方函数的错误，关于这一点可以看这里，之前写的一篇文章：点击这里查看之前文章

而另外如果你在Linux上面用LLDB调试的时候，会发现托管的Main入口断点可能会进不去的情况。

当然这些类似Bug但可能不是Bug东西，需要深厚的功力去发现和验证它到底是啥。

结尾：

作者:江湖评谈

欢迎关注我，带你了解.Net7的CLR的各种奇巧淫技。让.Net7，甚至后面的.Net8,9,10。在你面前毫无神秘可言。