Advanced .Net Debugging 6：程序集加载器 Debugging Advanced 程序集加载器 .Net Net
一、简介
这是我的《Advanced .Net Debugging》这个系列的第六篇文章。这篇文章的内容是原书的第二部分的【调试实战】的第四章。这章主要讲的是程序集加载器，比如：CLR 加载器简介、简单的程序集加载故障、加载上下文故障、互用性与 DllNotFoundException 和轻量级代码生成的调试。有了这章内容的学习，对于 CLR 如何加载程序集，加载的上下文和算法会有一个充分的了解。当然，有关程序集加载的错误也会有所调试和验证。高级调试会涉及很多方面的内容，你对 .NET 基础知识掌握越全面、细节越底层，调试成功的几率越大，当我们遇到各种奇葩问题的时候才不会手足无措。
如果在没有说明的情况下，所有代码的测试环境都是 Net 8.0，如果有变动，我会在项目章节里进行说明。好了，废话不多说，开始我们今天的调试工作。
调试环境我需要进行说明，以防大家不清楚，具体情况我已经罗列出来。
操作系统：Windows Professional 10
调试工具：Windbg Preview（Debugger Client:1.2306.1401.0，Debugger engine：10.0.25877.1004）和 NTSD（10.0.22621.2428 AMD64）
下载地址：可以去Microsoft Store 去下载
开发工具：Microsoft Visual Studio Community 2022 (64 位) - Current版本 17.8.3
Net 版本：.Net 8.0
CoreCLR源码：源码下载
二、调试源码
废话不多说，本节是调试的源码部分，没有代码，当然就谈不上测试了，调试必须有载体。
2.1、ExampleCore_4_1_1
2.2、ExampleCore_4_1_1.1
2.3、ExampleCore_4_1_2
Entity 类的代码
2.4、ExampleCore_4_1_3
2.5、ExampleCore_4_1_4（C++）
2.6、ExampleCore_4_1_5
三、基础知识
本章主要介绍 CLR 加载器（代码名称 fusion），以及它是如何避免 DLL 地狱问题和与 CLR 加载器相关的其他一些陷阱。如果大家不知道 DLL Hell 是什么问题的，可以自行去网上查找学习。
3.1、CLR 加载器简介
从宏观来看，程序集分为两类，一种是：私有程序集，这类程序集是属于某个特定应用程序的，它们通常保存在与应用程序本身路径相同的文件中。第二种是：共享程序集，这类程序集是由同一台机器上的两个或者更多个应用程序使用的程序集。共享程序集会被安装到全局程序集缓存中（GAC）。
在面对不同类型的程序集时，CLR 加载器如何判断从什么位置加载程序集呢？我们直接上一个图来说明问题。
在请求加载一个程序集的时候，CLR 加载器将判断加载上下文，并且根据上下文采取不同的算法来判断程序集的位置。
3.1.1、程序集标识
程序集的标识定义了程序集的唯一性。当 CLR 加载器要加载程序集的时候，这个标识是非常重要的。接下来，我们看看程序集标识由什么组成。
程序集标识由以下关键部分组成：
程序集的名称：程序集简单的名称，通常是程序集的文件名，不包含扩展名 .exe 或者 .dll。
文化：程序集的目标地域（例如：中性文化=neutral）。
版本：表示程序集的版本，形如：<major>.<minor>.<build>.<revision>。
公钥：公钥属性用于强命名的程序集，包含了公钥的64位散列码，这个公钥与用于对程序集签名的私钥是相对应的。
处理器架构：在 CLR 2.0 中引入的处理器架构属性指定了程序集的目标处理器架构。
由以上5个属性合在一起构成了程序集标识。在 CLR 中广泛的使用程序集标识来判断被加载的程序集是否正确。需要注意的是，就程序集标识而言，当加载正确的程序集时，程序集的路径并不是 CLR 考虑的因素。如果两个相同的程序集位于不同的路径中，那它们也可以加载到同一个应用程序域中，只是使用了不同的加载上下文。即使这两个程序集是相同的，它们仍然被视为两个不同的程序集。当然。在程序集中包含相同的类型同样被认为是不同的。
3.1.2、全局程序集缓存
GAC 是保存所有共享程序集的常用位置。GAC 位于：%windir%\assembly，我的实际目录地址是：C:\Windows\assembly，效果如图：
大多数程序集都是使用默认加载上下文（Default load context），也是最安全的加载方式，可以避免加载不正确的程序集。使用默认加载上下文的程序集是通过 Assembly.Load 及其变化形式来加载的。在默认的加载上下文中，CLR 要执行所有的探测逻辑，从而保证加载正确版本的程序集。如图：
当一个程序集被加载到指定加载上下文中时，通常是通过 Assembly.LoadFrom 等 API 的某种变化形式来实现的，此时，CLR 不会执行探测逻辑，而是由调用者负责消除程序集的冲突。程序集依赖的所有其他程序集将从同一路径加载。
被加载到指定加载上下文中的程序集可以使用默认加载上下文中的程序集。
使用指定加载上下文时有些需要注意的，如图：
3.1.5、无加载上下文
有些程序集的加载是不需要上下文的，比如：一些通过 Reflection 命令空间和 Emit 命令空间生成的程序集。在这种情况下，CLR 是不做任何探测的。
3.2、简单的程序集加载故障
如果我们想查看 CLR 加载器在加载程序集的时候使用的探测算法，可以使用【fuslogvw.exe】工具，我们打开【Visual Studio 2022 Developer Command Prompt v17.9.4】命令行工具，直接输入【fuslogvw】，就可以打开，该文件的路径在：C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64。
如图：
眼见为实：
调试源码：ExampleCore_4_1_1（控制台程序）和 ExampleCore_4_1_1.1（类库项目）
调试任务：演示程序集加载故障和CLR 加载程序集的探测算法
开始之前，先说明操作过程，我们首先将 ExampleCore_4_1_1.1 类库项目编译好，并将 dll 文件拷贝到 ExampleCore_4_1_1 项目的 bin 目录下，并将 ExampleCore_4_1_1.1.dll 文件的后缀名改成 ExampleCore_4_1_1.1.old，这样就可以出错了，用于测试。然后我们再编译 ExampleCore_4_1_1 控制台项目，就可以开始我们的测试了。
A、NTSD 调试
在开始之前，说明一下，在这里调试，就不验证 CLR 加载器的探测算法了，因为了在 Windbg Preview 调试环节做过了，内容都是一样的。
编译项目，打开【Visual Studio 2022 Developer Command Prompt v17.9.4】命令行工具，输入命令【NTSD E:\Visual Studio 2022\Source\Projects\AdvancedDebug.NetFramework.Test\ExampleCore_4_1_1\bin\Debug\net8.0\ExampleCore_4_1_1.exe】，打开调试器。
我们继续使用【g】命令运行调试器，直到调试器输出【Press any key to load into load from context】，然后我们随便按一个键，继续运行调试器，直到程序抛出异常，调试器也进入了中断模式。
B、Windbg Preview 调试
所有准备工作完成后，我们打开【Windbg Preview】调试器，依次点击【文件】--->【Launch executable】，加载我们的项目文件：ExampleCore_4_1_1.exe。进入调试器后，直接使用【g】命令运行调试器，直到我们的控制台程序输出【Press any key to load into load from context】文本，我们按任意键，继续运行。此时，系统发生异常，调试器也中断执行。
调试器输出如下：
3.3、加载上下文故障
调试源码：ExampleCore_4_1_2
调试任务：加载上下文的故障
这节的内容是证明在不同应用程序域中传递对象会出现问题，但是原书内容写的很早，而且是 .Net Framework 框架，在 .NET 8.0 或者以后的框架已经发生了变化。而且在 .NET 8.0 环境中已经不支持 AppDomian.CreateDomain 方法了。源码我也修改了，测试没有问题，可能我还没有领悟到真谛，需要继续学习，具体就不做测试了。大家如果想测试，自己可以试试。
3.4、互用性与 DllNotFoundException
CLR 提供了一个互用性层，可以让 .NET 代码和底层的非托管代码模块相互调用。根据不同类型的非托管代码，可以有两种不同的互用性机制。第一种：平台调用（Platform Invocation，P/Invoke），这种机制可以使开发人员调用非托管代码模块（DLL）中导出的函数。要实现这种机制，必须定义与托管代码等价的方法原型，并使用【DllImport】特性来说明这是一个 P/Invoke 方法。
第二种：COM 互用性。正是由于有这个特性，才可以使托管代码和非托管 COM 对象一起工作。
当我们使用 P/Invoke 调用非托管方法时，如果没有找到指定的 dll，就会抛出 System.DllNotFoundException 异常。这个没什么好说的，也很容易理解。
如果大家想测试，我提供源码，Net8.0 项目：ExampleCore_4_1_3，C++ 项目：ExampleCore_4_1_4，该项目必须设置成输出 dll。将生成的 dll 拷贝到我们 Net 项目 debug 目录下，为了能出错，我们 ExampleCore_4_1_4.dll 的名称改成 ExampleCore_4_1_4.old，直接运行程序就可以了。如果想查看正确输出结果，把后缀名改成 .dll 就可以了。
给大家一个感性认识，效果如图：
说明一下，在 P/Invoke 调用过程中使用的非托管 DLL，都是通过底层 kernel32!LoadLibrary 来加载的，这个 API 使用了与 Windows 加载动态库时相同的探测逻辑。如果我们想使用【fuslogvw.exe】分析 P/Invoke 加载问题时是不起作用的。
3.5、轻量级代码生成的调试
CLR 提供了一种既方便又高效动态生成代码的机制（也称为 CodeGen）。在 CLR 2.0 之前，开发人员如果想实现动态生成代码，必须自己维护在 CLR 上运行的任何代码段的结构完整性。比如：如果我们想定义一个方法，该方法接受两个整型参数，返回两个参数之和，我们要做的工作是，必须定义方法本身的实现逻辑（包括 IL）、这个方法使用的类型、这个类型定义所在的模块以及程序集所在的模块等。当我们只希望生成一下规模很小或者是不是很复杂的方法时就很不方便。
在 CLR 2.0 引入了【轻量级代码生成机制（Light Weight Code Generation，LCG）】。当使用 LCG 时，我们定义代码更简单，不需要关注和代码无关的东西（模块、类型、程序集等），并通过委托机制来调用它。
System.Reflection.Emit 命名空间下的 API 可以高效、动态的生成代码。
很庆幸，使用非托管调试器调试动态生成的代码并不困难。如果我们想使用【!bpmd】命令为方法设置断点，必须先找到方法的描述符。但是，对于 LCG 代码，我们需要做一些手动工作。具体来说，我们需要通过 JIT 组件中某个函数来获得方法描述符。这个函数就是：clrjit!CILJit::compileMethod，如果我们在这个方法上设置一个非托管断点（通过 bp 命令），那么可以从这个函数的第一个参数中获得方法描述符。
眼见为实：
调试代码：ExampleCore_4_1_5
调试任务：调试由 System.Reflection.Emit 生成轻量级代码，在 Add 方法上设置断点
A、NTSD 调试
编译项目，打开【Visual Studio 2022 Developer Command Prompt v17.9.4】命令行工具，输入命令【NTSD E:\Visual Studio 2022\Source\Projects\AdvancedDebug.NetFramework.Test\ExampleCore_4_1_5\bin\Debug\net8.0\ExampleCore_4_1_5.EXE】，如图：
打开【NTSD】 调试器窗口，效果如图：
B、Windbg Preview 调试
编译项目，打开【Windbg Preview】，依次点击【文件】----》【launch executable】加载我们的项目文件：ExampleCore_4_1_5.exe。进入调试器后，继续使用【g】命令，运行调试器，调试会自动进入中断模式，也就是在这行源代码【Debugger.Break();】，我们的代码已经编译，但是还没有执行，也可以说，此时的代码还没有经过 JIT 编译。
我们先使用【lm】命令查看一下我们的 CLR 和 JIT 是否已经加载了。
这篇文章的终于写完了，这篇文章的内容相对来说，不是很多。写完一篇，就说明进步了一点点。Net 高级调试这条路，也刚刚起步，还有很多要学的地方。皇天不负有心人，努力，不辜负自己，我相信付出就有回报，再者说，学习的过程，有时候，虽然很痛苦，但是，学有所成，学有所懂，这个开心的感觉还是不可言喻的。不忘初心，继续努力。做自己喜欢做的，开心就好。
天下国家,可均也；爵禄,可辞也；白刃,可蹈也；中庸不可能也
这是我的《Advanced .Net Debugging》这个系列的第六篇文章。这篇文章的内容是原书的第二部分的【调试实战】的第四章。这章主要讲的是程序集加载器，比如：CLR 加载器简介、简单的程序集加载故障、加载上下文故障、互用性与 DllNotFoundException 和轻量级代码生成的调试。有了这章内容的学习，对于 CLR 如何加载程序集，加载的上下文和算法会有一个充分的了解。当然，有关程序集加载的错误也会有所调试和验证。高级调试会涉及很多方面的内容，你对 .NET 基础知识掌握越全面、细节越底层，调试成功的几率越大，当我们遇到各种奇葩问题的时候才不会手足无措。
如果在没有说明的情况下，所有代码的测试环境都是 Net 8.0，如果有变动，我会在项目章节里进行说明。好了，废话不多说，开始我们今天的调试工作。
调试环境我需要进行说明，以防大家不清楚，具体情况我已经罗列出来。
操作系统：Windows Professional 10
调试工具：Windbg Preview（Debugger Client:1.2306.1401.0，Debugger engine：10.0.25877.1004）和 NTSD（10.0.22621.2428 AMD64）
下载地址：可以去Microsoft Store 去下载
开发工具：Microsoft Visual Studio Community 2022 (64 位) - Current版本 17.8.3
Net 版本：.Net 8.0
CoreCLR源码：源码下载
二、调试源码
废话不多说，本节是调试的源码部分，没有代码，当然就谈不上测试了，调试必须有载体。
2.1、ExampleCore_4_1_1
1 using System.Reflection; 2 3 namespace ExampleCore_4_1_1 4 { 5 internal class Program 6 { 7 static void Main(string[] args) 8 { 9 Assembly? assemblyLoadFromContext = null; 10 Console.WriteLine("Press any key to load into load from context"); 11 Console.ReadKey(); 12 13 assemblyLoadFromContext = Assembly.LoadFrom("ExampleCore_4_1_1.1.dll"); 14 15 var localObject = assemblyLoadFromContext.CreateInstance("ExampleCore_4_1_1._1.SimpleType")!; 16 17 Console.WriteLine("Press any key to Exit"); 18 Console.ReadKey(); 19 } 20 } 21 }View Code
2.2、ExampleCore_4_1_1.1
1 namespace ExampleCore_4_1_1._1 2 { 3 public class SimpleType 4 { 5 private int _field1; 6 private int _field2; 7 8 public int Field1 9 { 10 get { return _field1; } 11 } 12 13 public int Fields 14 { 15 get { return _field2; } 16 } 17 18 public SimpleType() 19 { 20 _field1 = 10; 21 _field2 = 5; 22 } 23 } 24 }View Code
2.3、ExampleCore_4_1_2
Entity 类的代码
1 namespace ExampleCore_4_1_2 2 { 3 [Serializable] 4 public class Entity 5 { 6 public int a; 7 } 8 }View Code
EntityUtil 类的代码
1 namespace ExampleCore_4_1_2 2 { 3 [Serializable] 4 public class EntityUtil 5 { 6 public void Dump(Entity e) 7 { 8 Console.WriteLine(e.a); 9 } 10 } 11 }View Code
Program 类的代码
1 using System.Runtime.Loader; 2 using System.Runtime.Remoting; 3 4 namespace ExampleCore_4_1_2 5 { 6 internal class Program 7 { 8 static void Main(string[] args) 9 { 10 Program p = new Program(); 11 p.Run(); 12 13 Console.ReadLine(); 14 } 15 16 public void Run() 17 { 18 while (true) 19 { 20 Console.WriteLine("1、Run in default app domain"); 21 Console.WriteLine("2、Run in dedicated app domain"); 22 Console.WriteLine("Q、To quit."); 23 Console.Write("> "); 24 ConsoleKeyInfo consoleKeyInfo = Console.ReadKey(); 25 Console.WriteLine(); 26 27 if (consoleKeyInfo.KeyChar == '1') 28 { 29 RunInDefault(); 30 } 31 else if (consoleKeyInfo.KeyChar == '2') 32 { 33 RunInDedicated(); 34 } 35 else if (consoleKeyInfo.KeyChar == 'q' || consoleKeyInfo.KeyChar == 'Q') 36 { 37 break; 38 } 39 } 40 } 41 42 public void RunInDefault() 43 { 44 EntityUtil t2 = new EntityUtil(); 45 Entity t = new Entity(); 46 t.a = 10; 47 48 t2.Dump(t); 49 } 50 51 public void RunInDedicated() 52 { 53 AssemblyLoadContext assemblyLoadContext = new AssemblyLoadContext("Myload"); 54 55 var assembly = assemblyLoadContext.LoadFromAssemblyName(new System.Reflection.AssemblyName("ExampleCore_4_1_2")); 56 57 EntityUtil t2 = (EntityUtil)assembly.CreateInstance("ExampleCore_4_1_2.EntityUtil")!; 58 59 Entity t = new Entity(); 60 t.a = 10; 61 t2.Dump(t); 62 } 63 } 64 }View Code
2.4、ExampleCore_4_1_3
1 using System.Runtime.InteropServices; 2 3 namespace ExampleCore_4_1_3 4 { 5 internal class Program 6 { 7 [DllImport("ExampleCore_4_1_4.dll", CharSet = CharSet.Auto)] 8 public static extern void Alloc(string str); 9 10 static void Main(string[] args) 11 { 12 var str = "hello world"; 13 14 Alloc(str); 15 16 Console.ReadLine(); 17 } 18 } 19 }View Code
2.5、ExampleCore_4_1_4（C++）
1 extern "C" 2 { 3 __declspec(dllexport) void Alloc(wchar_t* c); 4 } 5 6 #include "iostream" 7 #include <Windows.h> 8 9 using namespace std; 10 11 void Alloc(wchar_t* c) 12 { 13 wprintf(L"%s------\n", c); 14 }View Code
2.6、ExampleCore_4_1_5
1 using System.Diagnostics; 2 using System.Reflection.Emit; 3 4 namespace ExampleCore_4_1_5 5 { 6 internal class Program 7 { 8 private delegate int Add(int a, int b); 9 10 static void Main(string[] args) 11 { 12 Type[] mylocalArgs = { typeof(int), typeof(int) }; 13 DynamicMethod method = new DynamicMethod("Add", typeof(int), mylocalArgs); 14 15 ILGenerator generator = method.GetILGenerator(); 16 generator.Emit(OpCodes.Ldarg_0); 17 generator.Emit(OpCodes.Ldarg_1); 18 generator.Emit(OpCodes.Add); 19 generator.Emit(OpCodes.Ret); 20 21 Add add = (Add)method.CreateDelegate(typeof(Add)); 22 Debugger.Break(); 23 int result = add(1, 2); 24 25 Console.WriteLine($"1+2={result}"); 26 Console.Read(); 27 } 28 } 29 }View Code
三、基础知识
本章主要介绍 CLR 加载器（代码名称 fusion），以及它是如何避免 DLL 地狱问题和与 CLR 加载器相关的其他一些陷阱。如果大家不知道 DLL Hell 是什么问题的，可以自行去网上查找学习。
3.1、CLR 加载器简介
从宏观来看，程序集分为两类，一种是：私有程序集，这类程序集是属于某个特定应用程序的，它们通常保存在与应用程序本身路径相同的文件中。第二种是：共享程序集，这类程序集是由同一台机器上的两个或者更多个应用程序使用的程序集。共享程序集会被安装到全局程序集缓存中（GAC）。
在面对不同类型的程序集时，CLR 加载器如何判断从什么位置加载程序集呢？我们直接上一个图来说明问题。
在请求加载一个程序集的时候，CLR 加载器将判断加载上下文，并且根据上下文采取不同的算法来判断程序集的位置。
3.1.1、程序集标识
程序集的标识定义了程序集的唯一性。当 CLR 加载器要加载程序集的时候，这个标识是非常重要的。接下来，我们看看程序集标识由什么组成。
程序集标识由以下关键部分组成：
程序集的名称：程序集简单的名称，通常是程序集的文件名，不包含扩展名 .exe 或者 .dll。
文化：程序集的目标地域（例如：中性文化=neutral）。
版本：表示程序集的版本，形如：<major>.<minor>.<build>.<revision>。
公钥：公钥属性用于强命名的程序集，包含了公钥的64位散列码，这个公钥与用于对程序集签名的私钥是相对应的。
处理器架构：在 CLR 2.0 中引入的处理器架构属性指定了程序集的目标处理器架构。
由以上5个属性合在一起构成了程序集标识。在 CLR 中广泛的使用程序集标识来判断被加载的程序集是否正确。需要注意的是，就程序集标识而言，当加载正确的程序集时，程序集的路径并不是 CLR 考虑的因素。如果两个相同的程序集位于不同的路径中，那它们也可以加载到同一个应用程序域中，只是使用了不同的加载上下文。即使这两个程序集是相同的，它们仍然被视为两个不同的程序集。当然。在程序集中包含相同的类型同样被认为是不同的。
3.1.2、全局程序集缓存
GAC 是保存所有共享程序集的常用位置。GAC 位于：%windir%\assembly，我的实际目录地址是：C:\Windows\assembly，效果如图：
在 GAC 中的程序集必须是强命名的，并且拥有唯一的版本号。在共享程序集加载的过程中（在默认的加载上下文中），CLR 加载器会首先检查 GAC 来确定这个程序集是否存在，然后再查看私有的加载路径。
我们可以使用【Windbg Preview】工具，使用【lm f】命令查看目标进程中所有已加载的模块以及它们相应的加载路径。这个很简单，直接贴结果。这个里面，我使用【lm】和【lm f】两个命令，大家可以自己体会区别。
1 0:006> lm 2 start end module name 3 000001d5`2a100000 000001d5`2a108000 ExampleCore_4_1_0 C (service symbols: CLR Symbols with PDB: C:\ProgramData\Dbg\sym\ExampleCore_4_1_0.pdb\E55CC9E3404548D5AF090BFC4FBE04D01\ExampleCore_4_1_0.pdb) 4 000001d5`2a110000 000001d5`2a11e000 System_Runtime (deferred) 5 000001d5`2a120000 000001d5`2a128000 ExampleCore_4_1_0_Clone (deferred) 6 000001d5`2a130000 000001d5`2a138000 System_Text_Encoding_Extensions (deferred) 7 00007ff6`5f210000 00007ff6`5f239000 apphost C (private pdb symbols) C:\ProgramData\Dbg\sym\apphost.pdb\5633DAB747FE452D91289F0AE5A53DEB1\apphost.pdb 8 00007ffc`00b00000 00007ffc`00b28000 System_Console (deferred) 9 00007ffc`00b30000 00007ffc`00ce9000 clrjit (deferred) 10 00007ffc`00cf0000 00007ffc`0197c000 System_Private_CoreLib (service symbols: CLR Symbols with PDB: C:\ProgramData\Dbg\sym\System.Private.CoreLib.pdb\44580BF6DF5DBDE0A6AF2B06590C0AF21\System.Private.CoreLib.pdb) 11 00007ffc`01e80000 00007ffc`02366000 coreclr (deferred) 12 00007ffc`02370000 00007ffc`023d4000 hostpolicy (deferred) 13 00007ffc`06f10000 00007ffc`06f69000 hostfxr (deferred) 14 00007ffc`0dff0000 00007ffc`0e005000 System_Runtime_InteropServices (deferred) 15 00007ffc`0e1a0000 00007ffc`0e1b2000 System_Threading (deferred) 16 00007ffc`daa10000 00007ffc`daaad000 msvcp_win (deferred) 17 00007ffc`dab30000 00007ffc`dab42000 kernel_appcore (deferred) 18 00007ffc`dac00000 00007ffc`dad00000 ucrtbase (deferred) 19 00007ffc`dad00000 00007ffc`dad82000 bcryptPrimitives (deferred) 20 00007ffc`dae90000 00007ffc`dafa7000 gdi32full (deferred) 21 00007ffc`db000000 00007ffc`db027000 bcrypt (deferred) 22 00007ffc`db0b0000 00007ffc`db0d2000 win32u (deferred) 23 00007ffc`db240000 00007ffc`db536000 KERNELBASE (deferred) 24 00007ffc`db540000 00007ffc`db893000 combase (deferred) 25 00007ffc`db920000 00007ffc`db952000 IMM32 (deferred) 26 00007ffc`db9c0000 00007ffc`dc12b000 SHELL32 (deferred) 27 00007ffc`dc1e0000 00007ffc`dc290000 ADVAPI32 (deferred) 28 00007ffc`dc460000 00007ffc`dc58b000 ole32 (deferred) 29 00007ffc`dc680000 00007ffc`dc6ab000 GDI32 (deferred) 30 00007ffc`dc830000 00007ffc`dc8fd000 OLEAUT32 (deferred) 31 00007ffc`dd020000 00007ffc`dd0c0000 sechost (deferred) 32 00007ffc`dd0c0000 00007ffc`dd25e000 USER32 (deferred) 33 00007ffc`dd380000 00007ffc`dd4a5000 RPCRT4 (deferred) 34 00007ffc`dd530000 00007ffc`dd5ed000 KERNEL32 (pdb symbols) C:\ProgramData\Dbg\sym\kernel32.pdb\B07C97792B439ABC0DF83499536C7AE51\kernel32.pdb 35 00007ffc`dd5f0000 00007ffc`dd68e000 msvcrt (deferred) 36 00007ffc`dd6d0000 00007ffc`dd8c8000 ntdll (pdb symbols) C:\ProgramData\Dbg\sym\ntdll.pdb\90C2362B9D1F1F5088ABFA3BDE69BAAF1\ntdll.pdb 37 38 0:006> lm f 39 start end module name 40 000001d5`2a100000 000001d5`2a108000 ExampleCore_4_1_0 E:\Visual Studio 2022\Source\Projects\AdvancedDebug.NetFramework.Test\ExampleCore_4_1_0\bin\Debug\net8.0\ExampleCore_4_1_0.dll 41 000001d5`2a110000 000001d5`2a11e000 System_Runtime C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\System.Runtime.dll 42 000001d5`2a120000 000001d5`2a128000 ExampleCore_4_1_0_Clone E:\Visual Studio 2022\Source\Projects\AdvancedDebug.NetFramework.Test\ExampleCore_4_1_0\bin\Debug\net8.0\ExampleCore_4_1_0_Clone.dll 43 000001d5`2a130000 000001d5`2a138000 System_Text_Encoding_Extensions C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\System.Text.Encoding.Extensions.dll 44 00007ff6`5f210000 00007ff6`5f239000 apphost apphost.exe 45 00007ffc`00b00000 00007ffc`00b28000 System_Console C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\System.Console.dll 46 00007ffc`00b30000 00007ffc`00ce9000 clrjit C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\clrjit.dll 47 00007ffc`00cf0000 00007ffc`0197c000 System_Private_CoreLib C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\System.Private.CoreLib.dll 48 00007ffc`01e80000 00007ffc`02366000 coreclr C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\coreclr.dll 49 00007ffc`02370000 00007ffc`023d4000 hostpolicy C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\hostpolicy.dll 50 00007ffc`06f10000 00007ffc`06f69000 hostfxr C:\Program Files\dotnet\host\fxr\8.0.3\hostfxr.dll 51 00007ffc`0dff0000 00007ffc`0e005000 System_Runtime_InteropServices C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\System.Runtime.InteropServices.dll 52 00007ffc`0e1a0000 00007ffc`0e1b2000 System_Threading C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\System.Threading.dll 53 00007ffc`daa10000 00007ffc`daaad000 msvcp_win C:\Windows\System32\msvcp_win.dll 54 00007ffc`dab30000 00007ffc`dab42000 kernel_appcore C:\Windows\System32\kernel.appcore.dll 55 00007ffc`dac00000 00007ffc`dad00000 ucrtbase C:\Windows\System32\ucrtbase.dll 56 00007ffc`dad00000 00007ffc`dad82000 bcryptPrimitives C:\Windows\System32\bcryptPrimitives.dll 57 00007ffc`dae90000 00007ffc`dafa7000 gdi32full C:\Windows\System32\gdi32full.dll 58 00007ffc`db000000 00007ffc`db027000 bcrypt C:\Windows\System32\bcrypt.dll 59 00007ffc`db0b0000 00007ffc`db0d2000 win32u C:\Windows\System32\win32u.dll 60 00007ffc`db240000 00007ffc`db536000 KERNELBASE C:\Windows\System32\KERNELBASE.dll 61 00007ffc`db540000 00007ffc`db893000 combase C:\Windows\System32\combase.dll 62 00007ffc`db920000 00007ffc`db952000 IMM32 C:\Windows\System32\IMM32.DLL 63 00007ffc`db9c0000 00007ffc`dc12b000 SHELL32 C:\Windows\System32\SHELL32.dll 64 00007ffc`dc1e0000 00007ffc`dc290000 ADVAPI32 C:\Windows\System32\ADVAPI32.dll 65 00007ffc`dc460000 00007ffc`dc58b000 ole32 C:\Windows\System32\ole32.dll 66 00007ffc`dc680000 00007ffc`dc6ab000 GDI32 C:\Windows\System32\GDI32.dll 67 00007ffc`dc830000 00007ffc`dc8fd000 OLEAUT32 C:\Windows\System32\OLEAUT32.dll 68 00007ffc`dd020000 00007ffc`dd0c0000 sechost C:\Windows\System32\sechost.dll 69 00007ffc`dd0c0000 00007ffc`dd25e000 USER32 C:\Windows\System32\USER32.dll 70 00007ffc`dd380000 00007ffc`dd4a5000 RPCRT4 C:\Windows\System32\RPCRT4.dll 71 00007ffc`dd530000 00007ffc`dd5ed000 KERNEL32 C:\Windows\System32\KERNEL32.DLL 72 00007ffc`dd5f0000 00007ffc`dd68e000 msvcrt C:\Windows\System32\msvcrt.dll 73 00007ffc`dd6d0000 00007ffc`dd8c8000 ntdll ntdll.dll
当使用 Windows 资源管理器查看 GAC 时，它是 GAC 的视图版本，它是由 shell 扩展 shfusion.dll 实现的。
大多数程序集都是使用默认加载上下文（Default load context），也是最安全的加载方式，可以避免加载不正确的程序集。使用默认加载上下文的程序集是通过 Assembly.Load 及其变化形式来加载的。在默认的加载上下文中，CLR 要执行所有的探测逻辑，从而保证加载正确版本的程序集。如图：
这样做有一个好处，依赖的程序集也可以在默认加载上下文中自动被找到。这与指定加载上下文（Load-From）或者无加载上下文（Load-Without）是不同的，在这些上下文中，调用者可以显示的选择程序集，因此，更容易出现错误。
当一个程序集加载请求进入默认加载上下文时，CLR 会首先判断这个程序集是否在 GAC 中。如果是，则直接加载 GAC 中正确版本的程序集。如果不在 GAC 中，CLR 加载器将探测其他路径，包括应用程序所在的路径和私有二进制文件所在的路径等。如果在这两个位置中的某一个找到了程序集，CLR 则直接从该位置加载程序集。
当一个程序集被加载到指定加载上下文中时，通常是通过 Assembly.LoadFrom 等 API 的某种变化形式来实现的，此时，CLR 不会执行探测逻辑，而是由调用者负责消除程序集的冲突。程序集依赖的所有其他程序集将从同一路径加载。
被加载到指定加载上下文中的程序集可以使用默认加载上下文中的程序集。
使用指定加载上下文时有些需要注意的，如图：
3.1.5、无加载上下文
有些程序集的加载是不需要上下文的，比如：一些通过 Reflection 命令空间和 Emit 命令空间生成的程序集。在这种情况下，CLR 是不做任何探测的。
3.2、简单的程序集加载故障
如果我们想查看 CLR 加载器在加载程序集的时候使用的探测算法，可以使用【fuslogvw.exe】工具，我们打开【Visual Studio 2022 Developer Command Prompt v17.9.4】命令行工具，直接输入【fuslogvw】，就可以打开，该文件的路径在：C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.8 Tools\x64。
如图：
打开【程序集绑定日志查看器】，效果如图：
主界面分为两个部分，第一部分包含了实际的日志项目，共三列：
应用程序【Application】：该列给出了日志项是来之哪个应用程序。
说明【Description】：该列给出日志项的描述信息。
日期/时间【Date/Time】：该列给出了日志项的时间戳。
在主界面的右侧有一组按钮，控制日志项和如何执行日志。【设置（Setting）】按钮控制着如何执行日志记录以及何时执行。如图：
在默认情况下，日志是禁用的。
已禁用日志：日志功能不启用。
记录异常文本【Log in Exception Text】：程序集绑定操作会被记录在异常中。
记录失败绑定到磁盘【Log Bind failures to Disk】：只有发生故障的时候才会记录到磁盘上。
记录所有绑定到磁盘【Log All Binds to Disk】：所有绑定操作都会被记录到磁盘上。
启用自定义日志路径【Enable Custom Log Path】：改变日志文件的保存路径。如果选择了改变日志路径，必须在主界面上【自定义日志路径（Custom Log Location）】中输入日志的新路径。
HKLM 表示的是【HKEY_LOCAL_MACHINE】，完整路径如下：HKEY_LOCAL_MACHINE\Software\Microsoft\Fusion。
我们在【眼见为实】中要演示如何查看 CLR 加载器加载程序集时的探测算法中，使用的是【记录失败绑定到磁盘（Log Bind failures to Disk）】这个选项。
眼见为实：
调试源码：ExampleCore_4_1_1（控制台程序）和 ExampleCore_4_1_1.1（类库项目）
调试任务：演示程序集加载故障和CLR 加载程序集的探测算法
开始之前，先说明操作过程，我们首先将 ExampleCore_4_1_1.1 类库项目编译好，并将 dll 文件拷贝到 ExampleCore_4_1_1 项目的 bin 目录下，并将 ExampleCore_4_1_1.1.dll 文件的后缀名改成 ExampleCore_4_1_1.1.old，这样就可以出错了，用于测试。然后我们再编译 ExampleCore_4_1_1 控制台项目，就可以开始我们的测试了。
A、NTSD 调试
在开始之前，说明一下，在这里调试，就不验证 CLR 加载器的探测算法了，因为了在 Windbg Preview 调试环节做过了，内容都是一样的。
编译项目，打开【Visual Studio 2022 Developer Command Prompt v17.9.4】命令行工具，输入命令【NTSD E:\Visual Studio 2022\Source\Projects\AdvancedDebug.NetFramework.Test\ExampleCore_4_1_1\bin\Debug\net8.0\ExampleCore_4_1_1.exe】，打开调试器。
我们继续使用【g】命令运行调试器，直到调试器输出【Press any key to load into load from context】，然后我们随便按一个键，继续运行调试器，直到程序抛出异常，调试器也进入了中断模式。
调试器进入中断模式，如图：
我们使用【kb】命令查看线程的调用栈，并展示了每个方法的前三个参数。
1 0:000> kb 2 RetAddr : Args to Child : Call Site 3 00007ffa`b957b3a3 : 000002a1`3cc0a090 000000c0`88d7e730 000000c0`88d7ed60 000002a1`3cc09e08 : KERNELBASE!RaiseException+0x69 4 00007ffa`b94c9cfc : 000002a1`388bc9a0 000000c0`88d7ea58 000002a1`3889c3c0 000002a1`3a2fa630 : coreclr!RaiseTheExceptionInternalOnly+0x26b 5 00007ffa`b964cc41 : 000000c0`88d7ea58 000002a1`3889c3c0 000000c0`88d7eaa0 00007ffa`b9947940 : coreclr!UnwindAndContinueRethrowHelperAfterCatch+0x38 6 00007ffa`b8ba5ea3 : 000002a1`3cc09cec 000002a1`3cc09e80 00000000`00000000 000000c0`88d7ea58 : coreclr!AssemblyNative_LoadFromPath+0x181fb1 7 00007ffa`b8bcd4ab : 000002a1`3cc09e80 000002a1`3cc09ce0 000002a1`3cc09de8 00000000`00000002 : System_Private_CoreLib!System.Reflection.Assembly System.Runtime.Loader.AssemblyLoadContext::LoadFromAssemblyPath(System.String)$##600462A+0xf3 8 00007ffa`59ab1992 : 000002e1`cef00510 00000000`00000001 000002a1`388a3380 000002a1`3cc09c38 : System_Private_CoreLib!System.Reflection.Assembly System.Reflection.Assembly::LoadFrom(System.String)$##6006760+0x17b 9 00007ffa`b961b8c3 : 000002a1`3cc08ea0 000000c0`88d7f1e8 000000c0`88d7f1e8 000000c0`88d7edd9 : 0x00007ffa`59ab1992 10 00007ffa`b9550b19 : 00000000`00000000 00000000`00000130 000000c0`88d7ede8 00007ffa`b94d0232 : coreclr!CallDescrWorkerInternal+0x83 11 (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : coreclr!CallDescrWorkerWithHandler+0x56 12 00007ffa`b954d730 : 000000c0`88d7ee68 00000000`00000000 00000000`00000048 00007ffa`b95bd046 : coreclr!MethodDescCallSite::CallTargetWorker+0x2a1 13 (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : coreclr!MethodDescCallSite::Call+0xb 14 00007ffa`b9572fc6 : 000002a1`3cc08ea0 000002a1`3cc08ea0 00000000`00000000 000000c0`88d7f1e8 : coreclr!RunMainInternal+0x11c 15 00007ffa`b95732fb : 000002a1`388a3380 000002a1`00000000 000002a1`388a3380 00000000`00000000 : coreclr!RunMain+0xd2 16 00007ffa`b94c9141 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000130 : coreclr!Assembly::ExecuteMainMethod+0x1bf 17 00007ffa`b95de8b8 : 00000000`00000001 000000c0`88d7f401 000000c0`88d7f410 00007ffb`788a23ea : coreclr!CorHost2::ExecuteAssembly+0x281 18 00007ffb`788c2b76 : 000002a1`38871980 000002a1`38871680 00000000`00000000 000002a1`38871680 : coreclr!coreclr_execute_assembly+0xd8 19 (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : hostpolicy!coreclr_t::execute_assembly+0x2a 20 00007ffb`788c2e5c : 000002a1`3885c358 000000c0`88d7f639 00007ffb`788fc9c0 000002a1`3885c358 : hostpolicy!run_app_for_context+0x596 21 00007ffb`788c379a : 00000000`00000000 000002a1`3885c350 000002a1`3885c350 00000000`00000000 : hostpolicy!run_app+0x3c 22 00007ffb`7891b5c9 : 000002a1`388707a8 000002a1`38870690 00000000`00000000 000000c0`88d7f739 : hostpolicy!corehost_main+0x15a 23 00007ffb`7891e066 : 000002a1`3886f6a0 000000c0`88d7fac0 00000000`00000000 00000000`00000000 : hostfxr!execute_app+0x2e9 24 00007ffb`789202ec : 00007ffb`789525f8 000002a1`3886df30 000000c0`88d7fa00 000000c0`88d7f9b0 : hostfxr!`anonymous namespace'::read_config_and_execute+0xa6 25 00007ffb`7891e644 : 000000c0`88d7fac0 000000c0`88d7fae0 000000c0`88d7fa31 000002a1`3886e350 : hostfxr!fx_muxer_t::handle_exec_host_command+0x16c 26 00007ffb`789185a0 : 000000c0`88d7fae0 000002a1`3886d830 00000000`00000001 000002a1`38850000 : hostfxr!fx_muxer_t::execute+0x494 27 *** WARNING: Unable to verify checksum for apphost.exe 28 00007ff7`bff4f998 : 00007ffb`8b0ef4e8 00007ffb`78919b10 000000c0`88d7fc80 000002a1`3886d520 : hostfxr!hostfxr_main_startupinfo+0xa0 29 00007ff7`bff4fda6 : 00007ff7`bff5b6c0 00000000`00000007 000002a1`3885c350 00000000`0000005e : apphost!exe_start+0x878 30 00007ff7`bff512e8 : 00000000`00000000 00000000`00000000 000002a1`3885c350 00000000`00000000 : apphost!wmain+0x146 31 (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : apphost!invoke_main+0x22 32 00007ffb`8bda7344 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : apphost!__scrt_common_main_seh+0x10c 33 00007ffb`8d7626b1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x14 34 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21
KERNELBASE!RaiseException 方法的第一个参数的地址就是异常对象的地址，这个地址就是 000002a1`3cc0a090 。有了地址，我们可以使用【!PrintException 000002a1`3cc0a090】命令，打印出异常的具体信息。
1 0:000> !PrintException 000002a1`3cc0a090 2 WARNING: SOS needs to be upgraded for this version of the runtime. Some commands may not work correctly. 3 For more information see https://go.microsoft.com/fwlink/?linkid=2135652 4 5 Exception object: 000002a13cc0a090 6 Exception type: System.IO.FileNotFoundException 7 Message: 8 InnerException: <none> 9 StackTrace (generated): 10 SP IP Function 11 000000C088D7E990 00007FFAB8BA5EA2 System_Private_CoreLib!System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(System.String)+0xf2 12 000000C088D7EAB0 00007FFAB8BCD4AA System_Private_CoreLib!System.Reflection.Assembly.LoadFrom(System.String)+0x17a 13 000000C088D7EB30 00007FFA59AB1991 ExampleCore_4_1_1!ExampleCore_4_1_1.Program.Main(System.String[])+0x61 14 15 StackTraceString: <none> 16 HResult: 80070002
我们看到了具体的异常就是 System.IO.FileNotFoundException 对象，错误码是 80070002。
B、Windbg Preview 调试
所有准备工作完成后，我们打开【Windbg Preview】调试器，依次点击【文件】--->【Launch executable】，加载我们的项目文件：ExampleCore_4_1_1.exe。进入调试器后，直接使用【g】命令运行调试器，直到我们的控制台程序输出【Press any key to load into load from context】文本，我们按任意键，继续运行。此时，系统发生异常，调试器也中断执行。
调试器输出如下：
1 0:000> g 2 ModLoad: 00007ffa`7fd80000 00007ffa`7fdb2000 C:\Windows\System32\IMM32.DLL 3 ModLoad: 00007ffa`47080000 00007ffa`470d9000 C:\Program Files\dotnet\host\fxr\8.0.3\hostfxr.dll 4 ModLoad: 00007ffa`33b70000 00007ffa`33bd4000 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\hostpolicy.dll 5 ModLoad: 00007ff9`bcc60000 00007ff9`bd146000 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\coreclr.dll 6 ModLoad: 00007ffa`80600000 00007ffa`8072b000 C:\Windows\System32\ole32.dll 7 ModLoad: 00007ffa`80160000 00007ffa`804b3000 C:\Windows\System32\combase.dll 8 ModLoad: 00007ffa`804c0000 00007ffa`8058d000 C:\Windows\System32\OLEAUT32.dll 9 ModLoad: 00007ffa`7eb80000 00007ffa`7ec02000 C:\Windows\System32\bcryptPrimitives.dll 10 (3608.614): Unknown exception - code 04242420 (first chance) 11 ModLoad: 00007ff9`952c0000 00007ff9`95f4c000 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\System.Private.CoreLib.dll 12 ModLoad: 00007ff9`ae470000 00007ff9`ae629000 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\clrjit.dll 13 ModLoad: 00007ffa`7e7d0000 00007ffa`7e7e2000 C:\Windows\System32\kernel.appcore.dll 14 ModLoad: 000001b1`09ba0000 000001b1`09ba8000 E:\Visual Studio 2022\Source\Projects\AdvancedDebug.NetFramework.Test\ExampleCore_4_1_1\bin\Debug\net8.0\ExampleCore_4_1_1.dll 15 ModLoad: 000001b1`09bb0000 000001b1`09bbe000 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\System.Runtime.dll 16 ModLoad: 00007ffa`49890000 00007ffa`498b8000 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\System.Console.dll 17 ModLoad: 00007ffa`47060000 00007ffa`47072000 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\System.Threading.dll 18 ModLoad: 000001b1`09bc0000 000001b1`09bc8000 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\System.Text.Encoding.Extensions.dll 19 ModLoad: 00007ffa`47040000 00007ffa`47055000 C:\Program Files\dotnet\shared\Microsoft.NETCore.App\8.0.3\System.Runtime.InteropServices.dll 20 (3608.614): C++ EH exception - code e06d7363 (first chance) 21 (3608.614): CLR exception - code e0434352 (first chance) 22 (3608.614): CLR exception - code e0434352 (!!! second chance !!!) 23 KERNELBASE!RaiseException+0x69: 24 00007ffa`7eeccf19 0f1f440000 nop dword ptr [rax+rax]
当有任何 CLR 异常发生时，调试器都将停止执行。KERNELBASE!RaiseException 这个方法抛出了异常，我们使用【kb】命令查看线程的堆栈帧，并显示传递给堆栈跟踪中每个函数的前三个参数。
1 0:000> kb 2 # RetAddr : Args to Child : Call Site 3 00 00007ff9`bcd1b3a3 : 000001b1`0c80a000 000000ac`9837e720 000000ac`9837ed50 000001b1`0c809dc0 : KERNELBASE!RaiseException+0x69 4 01 00007ff9`bcc69cfc : 000001b1`082dbdb0 000000ac`9837ea48 000001b1`082c52e0 000001b1`082dcdc0 : coreclr!RaiseTheExceptionInternalOnly+0x26b [D:\a\_work\1\s\src\coreclr\vm\excep.cpp @ 2795] 5 02 00007ff9`bcdecc41 : 000000ac`9837ea48 000001b1`082c52e0 000000ac`9837ea90 00007ff9`bd0e7940 : coreclr!UnwindAndContinueRethrowHelperAfterCatch+0x38 [D:\a\_work\1\s\src\coreclr\vm\excep.cpp @ 7726] 6 03 00007ff9`95635ea3 : 000001b1`0c809cec 000001b1`0c809e38 00000000`00000000 000000ac`9837ea48 : coreclr!AssemblyNative_LoadFromPath+0x181fb1 [D:\a\_work\1\s\src\coreclr\vm\assemblynative.cpp @ 221] 7 04 00007ff9`9565d4ab : 000001b1`0c809e38 000001b1`0c809ce0 000001b1`0c809da0 00000000`00000002 : System_Private_CoreLib!System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath+0xf3 [/_/src/libraries/System.Private.CoreLib/src/System/Runtime/Loader/AssemblyLoadContext.cs @ 347] 8 05 00007ff9`5d241992 : 000001f1`9e840510 00000000`00000001 000001b1`082cc500 000001b1`0c809c38 : System_Private_CoreLib!System.Reflection.Assembly.LoadFrom+0x17b [/_/src/libraries/System.Private.CoreLib/src/System/Reflection/Assembly.cs @ 374] 9 06 00007ff9`bcdbb8c3 : 000001b1`0c808ea0 000000ac`9837f1d8 000000ac`9837f1d8 000000ac`9837edc9 : ExampleCore_4_1_1!ExampleCore_4_1_1.Program.Main+0x62 [E:\Visual Studio 2022\Source\Projects\AdvancedDebug.NetFramework.Test\ExampleCore_4_1_1\Program.cs @ 13] 10 07 00007ff9`bccf0b19 : 00000000`00000000 00000000`00000130 000000ac`9837edd8 00007ff9`bcc70232 : coreclr!CallDescrWorkerInternal+0x83 [D:\a\_work\1\s\src\coreclr\vm\amd64\CallDescrWorkerAMD64.asm @ 100] 11 08 (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : coreclr!CallDescrWorkerWithHandler+0x56 [D:\a\_work\1\s\src\coreclr\vm\callhelpers.cpp @ 67] 12 09 00007ff9`bcced730 : 000000ac`9837ee58 00000000`00000000 00000000`00000048 00007ff9`bcd5d046 : coreclr!MethodDescCallSite::CallTargetWorker+0x2a1 [D:\a\_work\1\s\src\coreclr\vm\callhelpers.cpp @ 570] 13 0a (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : coreclr!MethodDescCallSite::Call+0xb [D:\a\_work\1\s\src\coreclr\vm\callhelpers.h @ 458] 14 0b 00007ff9`bcd12fc6 : 000001b1`0c808ea0 000001b1`0c808ea0 00000000`00000000 000000ac`9837f1d8 : coreclr!RunMainInternal+0x11c [D:\a\_work\1\s\src\coreclr\vm\assembly.cpp @ 1304] 15 0c 00007ff9`bcd132fb : 000001b1`082cc500 000001b1`00000000 000001b1`082cc500 00000000`00000000 : coreclr!RunMain+0xd2 [D:\a\_work\1\s\src\coreclr\vm\assembly.cpp @ 1375] 16 0d 00007ff9`bcc69141 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000130 : coreclr!Assembly::ExecuteMainMethod+0x1bf [D:\a\_work\1\s\src\coreclr\vm\assembly.cpp @ 1504] 17 0e 00007ff9`bcd7e8b8 : 00000000`00000001 000000ac`9837f401 000000ac`9837f400 00007ffa`33b723ea : coreclr!CorHost2::ExecuteAssembly+0x281 [D:\a\_work\1\s\src\coreclr\vm\corhost.cpp @ 349] 18 0f 00007ffa`33b92b76 : 000001b1`0829b9a0 000001b1`0829b6a0 00000000`00000000 000001b1`0829b6a0 : coreclr!coreclr_execute_assembly+0xd8 [D:\a\_work\1\s\src\coreclr\dlls\mscoree\exports.cpp @ 504] 19 10 (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : hostpolicy!coreclr_t::execute_assembly+0x2a [D:\a\_work\1\s\src\native\corehost\hostpolicy\coreclr.cpp @ 109] 20 11 00007ffa`33b92e5c : 000001b1`08288438 000000ac`9837f629 00007ffa`33bcc9c0 000001b1`08288438 : hostpolicy!run_app_for_context+0x596 [D:\a\_work\1\s\src\native\corehost\hostpolicy\hostpolicy.cpp @ 256] 21 12 00007ffa`33b9379a : 00000000`00000000 000001b1`08288430 000001b1`08288430 00000000`00000000 : hostpolicy!run_app+0x3c [D:\a\_work\1\s\src\native\corehost\hostpolicy\hostpolicy.cpp @ 285] 22 13 00007ffa`4708b5c9 : 000001b1`0829a7c8 000001b1`0829a6b0 00000000`00000000 000000ac`9837f729 : hostpolicy!corehost_main+0x15a [D:\a\_work\1\s\src\native\corehost\hostpolicy\hostpolicy.cpp @ 426] 23 14 00007ffa`4708e066 : 000001b1`082996c0 000000ac`9837fab0 00000000`00000000 00000000`00000000 : hostfxr!execute_app+0x2e9 [D:\a\_work\1\s\src\native\corehost\fxr\fx_muxer.cpp @ 145] 24 15 00007ffa`470902ec : 00007ffa`470c25f8 000001b1`08297ed0 000000ac`9837f9f0 000000ac`9837f9a0 : hostfxr!`anonymous namespace'::read_config_and_execute+0xa6 [D:\a\_work\1\s\src\native\corehost\fxr\fx_muxer.cpp @ 532] 25 16 00007ffa`4708e644 : 000000ac`9837fab0 000000ac`9837fad0 000000ac`9837fa21 000001b1`082982f0 : hostfxr!fx_muxer_t::handle_exec_host_command+0x16c [D:\a\_work\1\s\src\native\corehost\fxr\fx_muxer.cpp @ 1007] 26 17 00007ffa`470885a0 : 000000ac`9837fad0 000001b1`082977d0 00000000`00000001 000001b1`08280000 : hostfxr!fx_muxer_t::execute+0x494 [D:\a\_work\1\s\src\native\corehost\fxr\fx_muxer.cpp @ 578] 27 18 00007ff7`5f0ef998 : 00007ffa`7ecff4e8 00007ffa`47089b10 000000ac`9837fc70 000001b1`082974c0 : hostfxr!hostfxr_main_startupinfo+0xa0 [D:\a\_work\1\s\src\native\corehost\fxr\hostfxr.cpp @ 62] 28 19 00007ff7`5f0efda6 : 00007ff7`5f0fb6c0 00000000`00000007 000001b1`08288430 00000000`0000005e : apphost!exe_start+0x878 [D:\a\_work\1\s\src\native\corehost\corehost.cpp @ 240] 29 1a 00007ff7`5f0f12e8 : 00000000`00000000 00000000`00000000 000001b1`08288430 00000000`00000000 : apphost!wmain+0x146 [D:\a\_work\1\s\src\native\corehost\corehost.cpp @ 311] 30 1b (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : apphost!invoke_main+0x22 [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 90] 31 1c 00007ffa`7fcd7344 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : apphost!__scrt_common_main_seh+0x10c [D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 32 1d 00007ffa`814e26b1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x14 33 1e 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21
KERNELBASE!RaiseException 方法的第一个参数就是具体的异常对象地址，这个地址就是 000001b1`0c80a000，我们可以使用【!PrintException 000001b1`0c80a000】命令查看具体的异常信息。
1 0:000> !PrintException 000001b1`0c80a000 2 Exception object: 000001b10c80a000 3 Exception type: System.IO.FileNotFoundException 4 Message: 5 InnerException: <none> 6 StackTrace (generated): 7 SP IP Function 8 000000AC9837E980 00007FF995635EA2 System_Private_CoreLib!System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath(System.String)+0xf2 9 000000AC9837EAA0 00007FF99565D4AA System_Private_CoreLib!System.Reflection.Assembly.LoadFrom(System.String)+0x17a 10 000000AC9837EB20 00007FF95D241991 ExampleCore_4_1_1!ExampleCore_4_1_1.Program.Main(System.String[])+0x61 11 12 StackTraceString: <none> 13 HResult: 80070002
System.Runtime.Loader.AssemblyLoadContext.LoadFromAssemblyPath 和 System.Reflection.Assembly.LoadFrom 就是通过指定上下文加载程序集的，这也证明我们所说的。
CLR 加载器加载程序集的时候路径探测：
当我们设置好【Log Bind failures to Disk】选项时，直接运行 ExampleCore_4_1_1.exe 我们的程序，直到抛出异常。如图：
回到【fuslogvw.exe】工具并点击【刷新（Refresh）】按钮。这是，我们就能在【fuslogvw.exe】主界面中看到一条日志项。如图：
这里的信息很少，我们可以双击日志项，使用浏览器打开。输出如下：
1 *** 程序集联编程序日志项 (2024/3/28 @ 14:50:58) *** 2 3 操作失败。 4 绑定结果: hr = 0x80070002。系统找不到指定的文件。 5 6 程序集管理器加载位置: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll 7 在可执行文件下运行 C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe 8 --- 详细的错误日志如下。 9 10 === 预绑定状态信息 === 11 日志: DisplayName = System.Memory, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 12 (Fully-specified) 13 日志: Appbase = file:///C:/Windows/System32/WindowsPowerShell/v1.0/ 14 日志: 初始 PrivatePath = NULL 15 日志: 动态基 = NULL 16 日志: 缓存基 = NULL 17 日志: AppName = powershell.exe 18 调用程序集: Microsoft.VisualStudio.Telemetry, Version=16.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a。 19 === 20 日志: 此绑定从 LoadFrom 加载上下文开始。 21 警告: 将不在 LoadFrom 上下文中探测本机映像。仅在默认加载上下文中探测本机映像，例如，使用 Assembly.Load()。 22 日志: 正在使用应用程序配置文件: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.Config 23 日志: 使用主机配置文件: 24 日志: 使用 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config 的计算机配置文件。 25 日志: 策略后引用: System.Memory, Version=4.0.1.1, Culture=neutral, PublicKeyToken=cc7b13ffcd2ddd51 26 日志: GAC 查找不成功。 27 日志: 尝试下载新的 URL file:///C:/Windows/System32/WindowsPowerShell/v1.0/System.Memory.DLL。 28 日志: 尝试下载新的 URL file:///C:/Windows/System32/WindowsPowerShell/v1.0/System.Memory/System.Memory.DLL。 29 日志: 尝试下载新的 URL file:///C:/Windows/System32/WindowsPowerShell/v1.0/System.Memory.EXE。 30 日志: 尝试下载新的 URL file:///C:/Windows/System32/WindowsPowerShell/v1.0/System.Memory/System.Memory.EXE。 31 日志: 尝试下载新的 URL file:///D:/Program Files/Microsoft Visual Studio/2022/Community/Common7/Tools/System.Memory.DLL。 32 日志: 尝试下载新的 URL file:///D:/Program Files/Microsoft Visual Studio/2022/Community/Common7/Tools/System.Memory/System.Memory.DLL。 33 日志: 尝试下载新的 URL file:///D:/Program Files/Microsoft Visual Studio/2022/Community/Common7/Tools/System.Memory.EXE。 34 日志: 尝试下载新的 URL file:///D:/Program Files/Microsoft Visual Studio/2022/Community/Common7/Tools/System.Memory/System.Memory.EXE。 35 日志: 已尝试所有探测 URLs 但全部失败。
输出信息包含三个部分，第一部分包含了日志的操作状态（操作失败）、HRESULT（hr = 0x80070002）、失败原因（系统找不到指定的文件。）、CLR 加载器的路径以及可执行程序的路径。
第二部分信息主要是【预绑定状态信息】，在这部分信息中包括加载过程可能被探测的其他路径，例如：应用程序库（Appbase）、私有路径（PrivatePath）、动态库（动态基）以及缓存库（缓存基）等。这些不同路径，表示在加载程序集的时候需要探测的路径。
第三部分包含的就是实际的探测记录。从输出信息中我们可以知道它处于指定加载上下文中（因为使用了 LoadFrom）。这些信息还指出，由于没有找到应用程序的配置文件，转而使用了全局的配置文件（使用 C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config 的计算机配置文件）。找遍了所有路径，都没有找到，所以最后失败（已尝试所有探测 URLs 但全部失败。）
3.3、加载上下文故障
调试源码：ExampleCore_4_1_2
调试任务：加载上下文的故障
这节的内容是证明在不同应用程序域中传递对象会出现问题，但是原书内容写的很早，而且是 .Net Framework 框架，在 .NET 8.0 或者以后的框架已经发生了变化。而且在 .NET 8.0 环境中已经不支持 AppDomian.CreateDomain 方法了。源码我也修改了，测试没有问题，可能我还没有领悟到真谛，需要继续学习，具体就不做测试了。大家如果想测试，自己可以试试。
3.4、互用性与 DllNotFoundException
CLR 提供了一个互用性层，可以让 .NET 代码和底层的非托管代码模块相互调用。根据不同类型的非托管代码，可以有两种不同的互用性机制。第一种：平台调用（Platform Invocation，P/Invoke），这种机制可以使开发人员调用非托管代码模块（DLL）中导出的函数。要实现这种机制，必须定义与托管代码等价的方法原型，并使用【DllImport】特性来说明这是一个 P/Invoke 方法。
第二种：COM 互用性。正是由于有这个特性，才可以使托管代码和非托管 COM 对象一起工作。
当我们使用 P/Invoke 调用非托管方法时，如果没有找到指定的 dll，就会抛出 System.DllNotFoundException 异常。这个没什么好说的，也很容易理解。
如果大家想测试，我提供源码，Net8.0 项目：ExampleCore_4_1_3，C++ 项目：ExampleCore_4_1_4，该项目必须设置成输出 dll。将生成的 dll 拷贝到我们 Net 项目 debug 目录下，为了能出错，我们 ExampleCore_4_1_4.dll 的名称改成 ExampleCore_4_1_4.old，直接运行程序就可以了。如果想查看正确输出结果，把后缀名改成 .dll 就可以了。
给大家一个感性认识，效果如图：
说明一下，在 P/Invoke 调用过程中使用的非托管 DLL，都是通过底层 kernel32!LoadLibrary 来加载的，这个 API 使用了与 Windows 加载动态库时相同的探测逻辑。如果我们想使用【fuslogvw.exe】分析 P/Invoke 加载问题时是不起作用的。
3.5、轻量级代码生成的调试
CLR 提供了一种既方便又高效动态生成代码的机制（也称为 CodeGen）。在 CLR 2.0 之前，开发人员如果想实现动态生成代码，必须自己维护在 CLR 上运行的任何代码段的结构完整性。比如：如果我们想定义一个方法，该方法接受两个整型参数，返回两个参数之和，我们要做的工作是，必须定义方法本身的实现逻辑（包括 IL）、这个方法使用的类型、这个类型定义所在的模块以及程序集所在的模块等。当我们只希望生成一下规模很小或者是不是很复杂的方法时就很不方便。
在 CLR 2.0 引入了【轻量级代码生成机制（Light Weight Code Generation，LCG）】。当使用 LCG 时，我们定义代码更简单，不需要关注和代码无关的东西（模块、类型、程序集等），并通过委托机制来调用它。
System.Reflection.Emit 命名空间下的 API 可以高效、动态的生成代码。
很庆幸，使用非托管调试器调试动态生成的代码并不困难。如果我们想使用【!bpmd】命令为方法设置断点，必须先找到方法的描述符。但是，对于 LCG 代码，我们需要做一些手动工作。具体来说，我们需要通过 JIT 组件中某个函数来获得方法描述符。这个函数就是：clrjit!CILJit::compileMethod，如果我们在这个方法上设置一个非托管断点（通过 bp 命令），那么可以从这个函数的第一个参数中获得方法描述符。
眼见为实：
调试代码：ExampleCore_4_1_5
调试任务：调试由 System.Reflection.Emit 生成轻量级代码，在 Add 方法上设置断点
A、NTSD 调试
编译项目，打开【Visual Studio 2022 Developer Command Prompt v17.9.4】命令行工具，输入命令【NTSD E:\Visual Studio 2022\Source\Projects\AdvancedDebug.NetFramework.Test\ExampleCore_4_1_5\bin\Debug\net8.0\ExampleCore_4_1_5.EXE】，如图：
打开【NTSD】 调试器窗口，效果如图：
我们使用【g】命令，运行调试器，直到调试器自动中断执行，开始我们的调试。
首先，我们使用【x clrjit!*compileMethod*】命令，查找【compileMethod】方法，因为 CLR 使用该方法编译我们代码。
1 0:000> x clrjit!*compileMethod* 2 00007ffb`c13abc60 clrjit!CILJit::compileMethod (class ICorJitInfo *, struct CORINFO_METHOD_INFO *, unsigned int, unsigned char **, unsigned int *)
我们找到了这个方法，可以针对 clrjit!CILJit::compileMethod 这个方法下一个断点。
1 0:000> bp clrjit!CILJit::compileMethod
【g】继续运行，直到调试器在断点处暂停。
1 0:000> g 2 Breakpoint 0 hit 3 clrjit!CILJit::compileMethod: 4 00007ffb`c13abc60 48895c2408 mov qword ptr [rsp+8],rbx ss:00000008`889fda00=00007ffb62a444a0
我们继续使用【kb】命令，查看线程调用栈，并查看前3个参数。当然也可以为【kb 1】只显示一条栈帧。
1 0:000> kb 2 RetAddr : Args to Child : Call Site 3 00007ffb`c23789fe : 00007ffb`62a444a0 00007ffb`62a444a0 0000019a`516b8550 00000000`00000000 : clrjit!CILJit::compileMethod 4 (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : coreclr!invokeCompileMethodHelper+0x70 5 (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : coreclr!invokeCompileMethod+0xb0 6 00007ffb`c2365507 : 00007ffb`62a10008 00000000`00000000 00007ffb`62a10008 00000000`00000000 : coreclr!UnsafeJitFunction+0x7ee 7 00007ffb`c2365327 : 00010000`00000001 00007b33`88000001 00000000`00007b33 00007ffb`c2749b98 : coreclr!MethodDesc::JitCompileCodeLocked+0xef 8 00007ffb`c2364ffc : 000001da`e7d321d0 00000008`889fe2f0 000001da`e7d321d0 000001da`e7d321d0 : coreclr!MethodDesc::JitCompileCodeLockedEventWrapper+0x17b 9 00007ffb`c2364c43 : 00000008`889fe3f0 00000008`00000000 00000000`00000000 00000000`00000000 : coreclr!MethodDesc::JitCompileCode+0x2bc 10 00007ffb`c23fb146 : 00007ffb`62a44430 00000000`00000000 00000000`00000000 00000002`51650000 : coreclr!MethodDesc::PrepareILBasedCode+0xc3 11 (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : coreclr!MethodDesc::PrepareCode+0x12 12 00007ffb`c2374c6f : 00007ffb`62a44430 00007ffb`627d4190 0000019a`516a04c0 00007ffb`6283fc18 : coreclr!MethodDesc::PrepareInitialCode+0x4e 13 00007ffb`c23748d9 : 0000019a`5169b7e0 0000019a`516a04c0 00007ffb`0002a020 00007ffb`62a10008 : coreclr!MethodDesc::DoPrestub+0x26f 14 00007ffb`c24acc05 : 00000008`889fe9e8 00000008`889fe998 01e2ff49`20c38349 ff800180`02800080 : coreclr!PreStubWorker+0x1f9 15 00007ffb`62931c5a : 00000000`00000001 00000000`00000002 00000000`00000002 00000000`00000000 : coreclr!ThePreStub+0x55 16 00007ffb`c24ab8c3 : 0000019a`55c08ea0 00000008`889fef38 00000008`889fef38 00000008`889feb29 : 0x00007ffb`62931c5a 17 00007ffb`c23e0b19 : 00000000`00000000 00000000`00000130 00000008`889feb38 00007ffb`c2360232 : coreclr!CallDescrWorkerInternal+0x83 18 (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : coreclr!CallDescrWorkerWithHandler+0x56 19 00007ffb`c23dd730 : 00000008`889febb8 00000000`00000000 00000000`00000048 00007ffb`c244d046 : coreclr!MethodDescCallSite::CallTargetWorker+0x2a1 20 (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : coreclr!MethodDescCallSite::Call+0xb 21 00007ffb`c2402fc6 : 0000019a`55c08ea0 0000019a`55c08ea0 00000000`00000000 00000008`889fef38 : coreclr!RunMainInternal+0x11c 22 00007ffb`c24032fb : 0000019a`516a04c0 0000019a`00000000 0000019a`516a04c0 00000000`00000000 : coreclr!RunMain+0xd2 23 00007ffb`c2359141 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000130 : coreclr!Assembly::ExecuteMainMethod+0x1bf 24 00007ffb`c246e8b8 : 00000000`00000001 00000008`889ff101 00000008`889ff160 00007ffb`c28423ea : coreclr!CorHost2::ExecuteAssembly+0x281 25 00007ffb`c2862b76 : 0000019a`51671980 0000019a`51671680 00000000`00000000 0000019a`51671680 : coreclr!coreclr_execute_assembly+0xd8 26 (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : hostpolicy!coreclr_t::execute_assembly+0x2a 27 00007ffb`c2862e5c : 0000019a`5165c358 00000008`889ff389 00007ffb`c289c9c0 0000019a`5165c358 : hostpolicy!run_app_for_context+0x596 28 00007ffb`c286379a : 00000000`00000000 0000019a`5165c350 0000019a`5165c350 00000000`00000000 : hostpolicy!run_app+0x3c 29 00007ffb`c28bb5c9 : 0000019a`516707a8 0000019a`51670690 00000000`00000000 00000008`889ff489 : hostpolicy!corehost_main+0x15a 30 00007ffb`c28be066 : 0000019a`5166f6a0 00000008`889ff810 00000000`00000000 00000000`00000000 : hostfxr!execute_app+0x2e9 31 00007ffb`c28c02ec : 00007ffb`c28f25f8 0000019a`5166df30 00000008`889ff750 00000008`889ff700 : hostfxr!`anonymous namespace'::read_config_and_execute+0xa6 32 00007ffb`c28be644 : 00000008`889ff810 00000008`889ff830 00000008`889ff781 0000019a`5166e350 : hostfxr!fx_muxer_t::handle_exec_host_command+0x16c 33 00007ffb`c28b85a0 : 00000008`889ff830 0000019a`5166d830 00000000`00000001 0000019a`51650000 : hostfxr!fx_muxer_t::execute+0x494 34 *** WARNING: Unable to verify checksum for apphost.exe 35 00007ff6`2595f998 : 00007ffc`9a0df4e8 00007ffb`c28b9b10 00000008`889ff9d0 0000019a`5166d520 : hostfxr!hostfxr_main_startupinfo+0xa0 36 00007ff6`2595fda6 : 00007ff6`2596b6c0 00000000`00000007 0000019a`5165c350 00000000`0000005e : apphost!exe_start+0x878 37 00007ff6`259612e8 : 00000000`00000000 00000000`00000000 0000019a`5165c350 00000000`00000000 : apphost!wmain+0x146 38 (Inline Function) : --------`-------- --------`-------- --------`-------- --------`-------- : apphost!invoke_main+0x22 39 00007ffc`9a997344 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : apphost!__scrt_common_main_seh+0x10c 40 00007ffc`9c4226b1 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : KERNEL32!BaseThreadInitThunk+0x14 41 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : ntdll!RtlUserThreadStart+0x21
clrjit!CILJit::compileMethod 方法的第一个参数就是我们 Add 方法的方法描述符。我们可以使用【!DumpMD】命令来验证。
1 0:000> !dumpmd 00007ffb`62a444a0 2 Method Name: DynamicClass.Add(Int32, Int32)（这就是我们动态生成的方法） 3 Class: 00007ffb62a443b8 4 MethodTable: 00007ffb62a44430 5 mdToken: 0000000006000000 6 Module: 00007ffb62a1b070 7 IsJitted: no（还没有编译） 8 Current CodeAddr: ffffffffffffffff（因为没有编译，所以地址就是 f） 9 Version History: 10 ILCodeVersion: 0000000000000000 11 ReJIT ID: 0 12 IL Addr: 0000000000000000 13 CodeAddr: 0000000000000000 (Optimized) 14 NativeCodeVersion: 0000000000000000
我们有了 MD，就是方法描述符，就可以使用【!bpmd -md 00007ffb`62a444a0】命令，为 Add 方法设置断点了。
1 0:000> !bpmd -md 00007ffb`62a444a0 2 MethodDesc = 00007FFB62A444A0 3 This DynamicMethodDesc is not yet JITTED. Placing memory breakpoint at 00007FFB62A444D0
【g】继续运行，会到我们到 Add 方法开始暂停，我们可以使用【!clrstack -a】命令，查看托管线程调用栈来确认。
1 0:000> g 2 Unable to insert breakpoint 2 at 00007ffb`62a50040, Win32 error 0n998 3 "内存位置访问无效。" 4 The breakpoint was set with BP. If you want breakpoints 5 to track module load/unload state you must use BU. 6 bp2 at 00007ffb`62a50040 failed 7 WaitForEvent failed, Win32 error 0n998 8 内存位置访问无效。 9 coreclr!MethodDesc::SetNativeCodeInterlocked+0x24 [inlined in coreclr!PrepareCodeConfig::SetNativeCode+0x49]: 10 00007ffb`c245dfe9 7523 jne coreclr!PrepareCodeConfig::SetNativeCode+0x6e (00007ffb`c245e00e) [br=0]
我这里测试有点问题，所有使用【NTSD】做的断点测试都失败，还没有找到原因。
B、Windbg Preview 调试
编译项目，打开【Windbg Preview】，依次点击【文件】----》【launch executable】加载我们的项目文件：ExampleCore_4_1_5.exe。进入调试器后，继续使用【g】命令，运行调试器，调试会自动进入中断模式，也就是在这行源代码【Debugger.Break();】，我们的代码已经编译，但是还没有执行，也可以说，此时的代码还没有经过 JIT 编译。
我们先使用【lm】命令查看一下我们的 CLR 和 JIT 是否已经加载了。
1 0:000> lm 2 start end module name 3 0000029f`73ad0000 0000029f`73ad8000 ExampleCore_4_1_5 C (service symbols: CLR Symbols with PDB: C:\ProgramData\Dbg\sym\ExampleCore_4_1_5.pdb\11A5E302B38142129CE69ACABA26395C1\ExampleCore_4_1_5.pdb) 4 0000029f`73ae0000 0000029f`73aee000 System_Runtime (deferred) 5 0000029f`73af0000 0000029f`73af8000 System_Reflection_Emit_Lightweight (deferred) 6 0000029f`73b00000 0000029f`73b08000 System_Reflection_Emit_ILGeneration (deferred) 7 0000029f`73b10000 0000029f`73b18000 System_Reflection_Primitives (deferred) 8 00007ff7`4bf90000 00007ff7`4bfb9000 apphost C (private pdb symbols) C:\ProgramData\Dbg\sym\apphost.pdb\5633DAB747FE452D91289F0AE5A53DEB1\apphost.pdb 9 00007ffd`4be50000 00007ffd`4cadc000 System_Private_CoreLib (service symbols: CLR Symbols with PDB: C:\ProgramData\Dbg\sym\System.Private.CoreLib.pdb\44580BF6DF5DBDE0A6AF2B06590C0AF21\System.Private.CoreLib.pdb) 10 00007ffd`4d7f0000 00007ffd`4d9a9000 clrjit (deferred) 11 00007ffd`4dfc0000 00007ffd`4e4a6000 coreclr (private pdb symbols) C:\ProgramData\Dbg\sym\coreclr.pdb\0FCDE80BC2AB441FBFBD19C1354D99E71\coreclr.pdb 12 00007ffd`4f350000 00007ffd`4f3b4000 hostpolicy (deferred) 13 00007ffd`81620000 00007ffd`81648000 System_Console (deferred) 14 00007ffd`91b40000 00007ffd`91b99000 hostfxr (deferred) 15 00007ffe`35ec0000 00007ffe`35fd7000 gdi32full (deferred) 16 00007ffe`35fe0000 00007ffe`35ff2000 kernel_appcore (deferred) 17 00007ffe`36050000 00007ffe`36346000 KERNELBASE (pdb symbols) C:\ProgramData\Dbg\sym\kernelbase.pdb\4D43CAB87CB573B14B1F37FFEAF274731\kernelbase.pdb 18 00007ffe`36350000 00007ffe`363ed000 msvcp_win (deferred) 19 00007ffe`364a0000 00007ffe`364c2000 win32u (deferred) 20 00007ffe`364d0000 00007ffe`36552000 bcryptPrimitives (deferred) 21 00007ffe`366c0000 00007ffe`367c0000 ucrtbase (deferred) 22 00007ffe`36810000 00007ffe`36837000 bcrypt (deferred) 23 00007ffe`36d90000 00007ffe`36ebb000 ole32 (deferred) 24 00007ffe`36f20000 00007ffe`37045000 RPCRT4 (deferred) 25 00007ffe`37050000 00007ffe`37082000 IMM32 (deferred) 26 00007ffe`37090000 00007ffe`3722e000 USER32 (deferred) 27 00007ffe`37380000 00007ffe`3741e000 msvcrt (deferred) 28 00007ffe`37420000 00007ffe`37b8b000 SHELL32 (deferred) 29 00007ffe`37c90000 00007ffe`37d40000 ADVAPI32 (deferred) 30 00007ffe`37e00000 00007ffe`37ecd000 OLEAUT32 (deferred) 31 00007ffe`37ed0000 00007ffe`37f70000 sechost (deferred) 32 00007ffe`38460000 00007ffe`387b3000 combase (deferred) 33 00007ffe`387c0000 00007ffe`3887d000 KERNEL32 (deferred) 34 00007ffe`389a0000 00007ffe`389cb000 GDI32 (deferred) 35 00007ffe`38a10000 00007ffe`38c08000 ntdll (pdb symbols) C:\ProgramData\Dbg\sym\ntdll.pdb\90C2362B9D1F1F5088ABFA3BDE69BAAF1\ntdll.pdb
ExampleCore_4_1_5 我们的项目已经加载了，说明 CLR 和 JIT 也已经加载了，clrjit 红色标注的就是我们处理器，说明我的猜测也是对的。
然后，我们通过【x clrjit!*CompileMethod*】命令查找 CompileMethod方法。
1 0:000> x clrjit!*CompileMethod* 2 00007ffd`4d8dbc60 clrjit!CILJit::compileMethod (class ICorJitInfo *, struct CORINFO_METHOD_INFO *, unsigned int, unsigned char **, unsigned int *)
我们找到了 CompileMethod 方法，给这个方法下一个断点。
1 0:000> bp clrjit!CILJit::compileMethod
我们继续【g】运行调试器，已经在 CILJit::compileMethod 方法处断住了。
1 0:000> g 2 Breakpoint 0 hit 3 clrjit!CILJit::compileMethod: 4 00007ffd`4d09bc60 48895c2408 mov qword ptr [rsp+8],rbx ss:0000005a`bc97d8a0=00007ffcee8644a0
我们在 CILJit::compileMethod 这个方法已经断住了，然后我们使用【kb 1】命令，查看一下它的参数。
1 0:000> kb 1 2 # RetAddr : Args to Child : Call Site 3 00 00007ffd`4e1989fe : 00007ffc`ee8644a0 00007ffc`ee8644a0 0000024a`1f3716a0 00000000`00000000 : clrjit!CILJit::compileMethod [D:\a\_work\1\s\src\coreclr\jit\ee_il_dll.cpp @ 279]
00007ffc`ee8644a0 这个地址就是我们 Add 方法的描述符地址。
1 0:000> !dumpmd 00007ffc`ee8644a0 2 Method Name: DynamicClass.Add(Int32, Int32) 这就是我们要查找的方法 3 Class: 00007ffcee8643b8 4 MethodTable: 00007ffcee864430 5 mdToken: 0000000006000000 6 Module: 00007ffcee83b070 7 IsJitted: no（说明还没有被 JIT 编译） 8 Current CodeAddr: ffffffffffffffff 9 Version History: 10 ILCodeVersion: 0000000000000000 11 ReJIT ID: 0 12 IL Addr: 0000000000000000 13 CodeAddr: 0000000000000000 (Optimized) 14 NativeCodeVersion: 0000000000000000
我们使用【!bpmd -md 00007ffb`5d3244a0】命令为 Add 方法设置断点。
1 0:000> !bpmd -md 00007ffb`5d3244a0 2 MethodDesc = 00007FFB5D3244A0 3 This DynamicMethodDesc is not yet JITTED. Placing memory breakpoint at 00007FFB5D3244D0
我们继续【g】运行调试器，直到调试器在断点处中断。
1 0:000> g 2 Breakpoint 2 hit 3 00007ffb`5d330040 8d0411 lea eax,[rcx+rdx]
【g】继续运行，我们使用【!clrstack -a】命令查看一下托管调用栈。
1 0:000> !clrstack -a 2 OS Thread Id: 0x4d70 (0) 3 Child SP IP Call Site 4 0000008E08B7E558 00007ffb5d330040 SOS Warning: Loading symbols for dynamic assemblies is not yet supported 5 DynamicClass.Add(Int32, Int32) 6 PARAMETERS: 7 <no data> 8 <no data> 9 10 0000008E08B7E560 00007ffb5d211c5a ExampleCore_4_1_5.Program.Main(System.String[]) [E:\Visual Studio 2022\Source\Projects\AdvancedDebug.NetFramework.Test\ExampleCore_4_1_5\Program.cs @ 23] 11 PARAMETERS: 12 args (0x0000008E08B7E6A0) = 0x000001f28e808ea0 13 LOCALS: 14 0x0000008E08B7E688 = 0x000001f28e809640 15 0x0000008E08B7E680 = 0x000001f28e809668 16 0x0000008E08B7E678 = 0x000001f28e809bc8 17 0x0000008E08B7E670 = 0x000001f28e809ea8 18 0x0000008E08B7E66C = 0x0000000000000000 19 0x0000008E08B7E640 = 0x0000000000000000
四、总结
这篇文章的终于写完了，这篇文章的内容相对来说，不是很多。写完一篇，就说明进步了一点点。Net 高级调试这条路，也刚刚起步，还有很多要学的地方。皇天不负有心人，努力，不辜负自己，我相信付出就有回报，再者说，学习的过程，有时候，虽然很痛苦，但是，学有所成，学有所懂，这个开心的感觉还是不可言喻的。不忘初心，继续努力。做自己喜欢做的，开心就好。
天下国家,可均也；爵禄,可辞也；白刃,可蹈也；中庸不可能也