DLL that was not present in memory despite not being formally unloaded

背景

在 Windows 系统底层开发中，shell32.dll 团队收到了一份关于某第三方程序大量崩溃的报告。通过深入分析崩溃转储文件（Crash Dumps），工程师们发现了一个极具迷惑性的现象：虽然崩溃最终表现为栈溢出（Stack Overflow），但根源却指向了一个看似不相关的模块，且涉及 Windows 内核异常处理机制中一个鲜为人知的边界情况。

这个案例揭示了当用户态代码在 DLL 卸载过程中发生异常时，Windows 异常分发机制可能陷入无限递归，从而导致进程终止。更令人困惑的是，崩溃现场显示程序试图执行一个在内存中处于“未加载”或“不可执行”状态的地址，这为调试带来了巨大的挑战。

核心内容

1. 崩溃表象：递归异常处理死循环

分析崩溃转储文件时，首先观察到的是典型的栈溢出特征。调用栈（Call Stack）中反复出现以下三个函数的交替调用：

• ntdll!RtlLookupFunctionEntry：用于查找函数的异常处理信息。
• ntdll!KiUserExceptionDispatch：用户态异常分发入口。
• ntdll!RtlDispatchException：实际分发异常给处理程序。

这种重复模式表明系统陷入了递归异常处理死循环（Recursive Exception Handling Death Spiral）。其工作流程如下：

1. 程序发生了一个异常。
2. 内核决定该异常无法在内核态处理，因此将其反射（Reflect）回用户态，调用 KiUserExceptionDispatch。
3. 在用户态尝试查找异常处理程序时（调用 RtlLookupFunctionEntry），系统再次发生异常。
4. 这触发了新一轮的异常分发，再次调用 KiUserExceptionDispatch。
5. 如此循环往复，直到耗尽栈空间，最终触发栈溢出异常，终止进程。

2. 追溯根源：shell32 与 combase 的纠缠

尽管崩溃表现为栈溢出，但通过回溯调用栈底部，可以找到引发最初异常的源头。调用栈显示异常发生在 shell32.dll 的卸载过程中：

• shell32!dllmain_dispatch
• shell32!dllmain_crt_process_detach
• ucrtbase!execute_onexit_table
• shell32!wil::details::string_maker::~string_maker

然而，真正触发第一个异常的指令地址指向了 combase!CoTaskMemFree。这表明 shell32 被错误地指派了责任，因为它是异常发生时的上下文模块，而非异常的原始制造者。

3. 深入调试：神秘的“不可执行”地址

为了确认原始异常，工程师检查了传递给 RtlDispatchException 的异常记录（Exception Record）和上下文记录（Context Record）。

• 异常代码：STATUS_ACCESS_VIOLATION (0xC0000005)。
• 异常描述：Attempt to execute non-executable address（尝试执行不可执行地址）。
• 故障地址：00007ff9fcba0af0，该地址属于 combase.dll 模块中的 CoTaskMemFree 函数。

这就引出了一个巨大的矛盾：combase.dll 是 Windows 的核心系统库，通常应该加载在内存中且可执行。然而，调试器 !address 命令显示，该地址所在的内存区域状态为 MEM_FREE，保护属性为 PAGE_NOACCESS。

这意味着，当程序试图执行 CoTaskMemFree 时，该内存页已经被释放或标记为不可访问。这解释了为什么异常记录显示“尝试执行不可执行地址”——因为从操作系统的角度来看，那块内存确实不属于可执行映像。

4. 关键矛盾点

标题所暗示的“DLL 不在内存中”并非指 DLL 完全未加载，而是指DLL 的某些内存页在运行时被释放或保护，导致其中的代码地址变得无效。

在 shell32 的 DLL 卸载例程（dllmain_crt_process_detach）中，代码试图调用 CoTaskMemFree 来释放内存。然而，由于某种原因（可能是 DLL 卸载顺序问题或内存损坏），combase.dll 的相关代码页已经不再处于可执行状态。当 CPU 尝试跳转执行该地址时，硬件触发访问违规，进而引发上述的递归异常风暴。

关键要点

• 递归异常陷阱：当异常处理程序本身引发异常时，Windows 的 RtlLookupFunctionEntry 和 KiUserExceptionDispatch 会陷入无限递归，迅速耗尽栈空间导致崩溃。这是调试此类崩溃的关键特征。
• 异常反射机制：内核态无法处理的异常会被反射回用户态。如果用户态在尝试处理该异常时再次出错，系统会陷入死循环。
• 调用栈误导：崩溃时的调用栈底部可能指向当前正在执行代码的模块（如 shell32），但真正的错误源头可能在其他模块（如 combase）。必须结合异常记录（Exception Record）中的故障地址来判断。
• 内存状态异常：STATUS_ACCESS_VIOLATION 且试图执行代码，可能意味着目标 DLL 的内存页已被释放（MEM_FREE）或标记为不可访问（PAGE_NOACCESS）。这通常发生在 DLL 卸载过程中，如果代码逻辑依赖于已卸载模块的功能，就会发生此类错误。
• 调试技巧：通过分析 KiUserExceptionDispatch 的参数，可以从栈中提取出原始的 EXCEPTION_POINTERS，从而获取真实的异常代码和故障地址，绕过递归栈的干扰。

意义与影响

这一案例对 Windows 系统稳定性和应用程序开发具有深远的影响：

1. DLL 卸载顺序的重要性：应用程序和系统组件在卸载时必须极其小心。如果 shell32 在卸载过程中调用了 combase 的代码，而 combase 或其内存页已经处于不稳定状态，就会导致灾难性的崩溃。这强调了模块间依赖关系的严格管理。
2. 异常处理的健壮性：开发者应避免在异常处理程序中进行可能引发新异常的操作。Windows 内核的异常分发机制并非无限递归安全的，一旦陷入死循环，唯一的恢复手段是终止进程。
3. 调试复杂崩溃的能力：对于系统工程师而言，能够从看似混乱的递归栈中剥离出原始的异常记录，是诊断底层系统问题的核心技能。理解 KiUserExceptionDispatch 的参数布局有助于快速定位问题根源。
4. 对第三方软件的警示：第三方程序如果依赖复杂的 DLL 卸载逻辑或全局状态，可能会无意中触发此类系统级边界情况。开发者应确保在进程退出或 DLL 卸载时，所有回调和清理操作都是安全的，且不依赖于可能已失效的模块。

总之，这个看似简单的“栈溢出”错误，实则揭示了 Windows 内存管理、异常处理和模块生命周期之间复杂的交互关系。它提醒我们，在系统编程中，任何假设（如“DLL 始终可用”）都可能成为导致系统崩溃的隐患。