相信有很多朋友在遇到应用程序各种奇葩问题后，拿下来一个dump文件，辛辛苦苦分析了大半天，终于在某一个线程的调用栈上找到了一个可疑的方法，但 windbg 常常是以 <code>汇编</code> 的方式显示方法代码的，可惜的是，现如今的汇编，有多少像我们这些速成系码农还看的懂呢？ 😂😂😂
接下来尖锐的问题就来了，如何将这些汇编代码转成 C# 源代码，如果转不成源代码转成 IL代码也好呀，起码我努努力还是能试着看的懂的。。。
本篇我就来分享下如何把 dump 中的方法源码提取出来。
为了能够演示方便，我用 .netcore 3.1 写了一个简单的demo，代码如下：
将程序跑起来后，使用 <code>任务管理器</code>, <code>adplus</code>, <code>procdump</code> 随便哪一个抓取 dump 都可以。
如果你的程序足够简单，可以直接用 lm 获取程序中所有的模块，然后使用 savemodule 将模块导出为 <code>exe/dll</code> 物理文件，如下所示：
使用 lm 提取出所有模块
可以隐约的看到，我有一个名为 <code>ConsoleApp6_2c2264b0000</code> 的模块，这就是我要提取的 <code>ConsoleApp6.exe</code>，顺便提一下，那个很碍眼的 <code>ConsoleApp6 (deferred)</code> 是 PE 文件，要问我怎么知道的？ 试一下就好啦😁
使用 savemodule 提取
从上面第一行 start 列中可以看到 ConsoleApp6_2c2264b0000 的开始地址为 <code>000002c2264b0000</code>，接下来用 savemodule 导出到 <code>E:\dump</code>。
然后就可以看到 <code>E:\dump</code> 里面多了一个 ConsoleApp6.exe 🐂，有了这玩意看源码就简单多了，直接用 ILSpy 对其进行反编译即可。
实际开发中有可能你的程序非常复杂，使用 lm 直接提取模块是找不到的，最好的办法就是 <code>按图索骥</code> 的方式寻找你要的 module，还记得 <code>CLR Via C#</code> 上说过的 AppDomain，Assembly，Module 之间的关系吗？如果要详细了解，建议翻看一下，这里我大概简述一下， Assembly 一般包含若干个 <code>Module + 资源文件</code>, Assembly 就是一个 dll/exe 文件，程序跑起来后，Assembly是被妥善安置在 AppDomain 中的。
有了上面这个思想，是不是就可以通过这个流程 <code>AppDomain -> Assembly -> Module</code> 找到 module 啦？ 接下来看看如何去实现。
使用 !dumpdomain 找到 ConsoleApp6 所在的程序域
尴尬，记得不错的话，在 .NET Framework 中默认会有三个应用程序域。
System Domain
Shared Domain
Domain 1
咋到 .NET Core 上就丢了一个 <code>Shard Domain</code> 呢 😄😄😄，先不管啦，从图中可以清楚的看到 Domian 1 上有我的dll <code>E:\net5\ConsoleApp3\ConsoleApp6\bin\Debug\netcoreapp3.1\ConsoleApp6.dll</code>，同时还有一个 module 的地址 <code>00007ffa45b5f7d0</code>。
使用 !dumpmodule 获取 module 详细信息
从上面的 <code>BaseAddress: 000002C2264B0000</code> 可以看出，module 的start 地址为 000002C2264B0000，是不是和刚才我用 lm 提取出来的地址一致哈，最后用 savemodule 导出一下就可以啦,为了做区分，我取名为 ConsoleApp7.exe, 如下所示：
哈哈，剩下来的就是用 ILSpy 反编译 CosoleApp7 啦。
更多高质量干货：参见我的 GitHub: dotnetfly