Exchange Server 调试问题以及解决方案

前言

在使用 dnspy 调试 Exchange Server 的时候，会出现各种问题，各种问题组合起来导致调试无法进行。本文将遇到的各种问题和对应的解决方案一一展示出来，供读者参考。

dnspy 是否有新版本

是的，目前有一个 fork 版本是一直在更新的。

https://github.com/dnSpyEx/dnSpy

调试过程中频频卡顿

调试过程中频频卡顿导致调试过程会因为调试退出，而完全无法调试。经过分析我发现主要因为以下几点问题：

1 内存不足

Exchange Server 的机器内存的占用大概就在 10/16 GB，反编译断点调试之后可能直接增加 2-3 GB 的内存使用，但是这个只要不超过内存应该不是最主要的原因。

解决方案：

增加可用内存。 总的来说，16 GB 的内存是足够的。

2 调试附加进程过多

这个原因是我们通常为了方便，直接附加所有的 w3wp.exe 进程去进行断点调试。

解决方案：

找到目标的 w3wp.exe 进程，尽可能附加调试少的进程。那么问题来了，我们该如何找到我们目标的 exe 呢？使用 proexec 查看对应进程发现对应进程数量其实没差几个，这算是一个缩小进程的办法。

另外的方法就是我们还是附加所有的 w3wp.exe 进程去直接调试你想调试的方法，在断点调试的时候触发到断点的时候，我们就可以在 dnspy 左下角看到对应的进程的 pid，这个时候我们去到 cmd 里面查看并记下对应的进程参数，下次我们附加进程的时候只附加一个进程就好了。

无法逐过（Step over）调试

通常调试到某行代码的时候，点击 Step over 之后，dnspy 的高亮一直在原来的代码行，似乎一直无法调试下去，当你多点几次之后，dnspy 会直接无响应直至奔溃自动关闭。这个时候 w3wp.exe 似乎会直接奔溃退出，而且不会重启。这个时候我们只能重启系统才可以保证 w3wp.exe 全部都在。具体情况如下图。

我们可以看到左下角有不同 pid 的进程触发到断点，所以才导致一种无法调试的假象。原因就是我们把所有的 w3wp.exe 进程都附加了，我们需要选择一个正确对应的进程就不会出现这种问题了。

解决方案：

参考上文的 调试附加进程过多。

dnspy 搜索不到想要调试的类

这个的原因是可能 dnspy 无法完整的自动加载所有对应的 dll 文件。

解决方案：

这个时候需要我们先查看我们想要找的类或者方法在哪个 DLL 里面。之后使用文件搜索工具帮助我们定位到 DLL 的文件位置，最后我们手动拖入到 dnspy 的 程序集资源管理器中即可。

提示：

我们可以直接在这种别人反编译好的项目中直接在线搜索类名或者方法名，虽然这样可能查找的不完整，但是也是最快定位 DLL 文件的方式。

调试过程中看不到变量的值

可能是调试代码优化问题。

解决方案：

参考：https://learn.microsoft.com/zh-cn/dotnet/framework/debug-trace-profile/making-an-image-easier-to-debug

没有调用栈窗口

这个是 dnspy 设计的问题。在默认情况下是没有调试相关的窗口的。如下图

解决方案：

实际上调用栈窗口和其他和调试有关的窗口只能在调试开始之后才可以调出来。在相同的位置下可以调出关于调试的窗口。