最近测试时发现代码中一处关于 std::function 函数对象的问题。在卸载某个 Dll（记为 A）的时候会触发该模块中一个单例对象的析构，在它析构内部的 std::function 成员时产生了内存访问异常（0xc0000005）。而触发这个异常的 std::function 其实是复制于另一个 Dll（记为 B），卸载 Dll A 时，Dll B 已经卸载掉了。

此时调用它关联的函数会抛异常容易理解，但这时并没有进行调用操作。原因在于函数对象析构时会调用关联的 _Delete_this 方法释放资源，而这个函数一般定义在 std 的 _Func_impl / _Func_impl_no_alloc 模板类中。所以当实例化 function 时对应删除函数的代码也是属于当前模块里的（也就是 Dll B）。现在 Dll B 已经卸载，那么只要有任何触发相关代码执行的操作都会引发异常。

所以自己的屁股还是要自己擦干净，清理工作要记得做好。

未能觉察的异常

看提交记录这个异常也存在有一段时间了，但还是在挂着调试器下时才被发现。软件中实际上包含了基于 signal 的异常捕获方式，显然这个场景下 SIGILL 的 handler 没有被触发、同时全局的 UnhandledExceptionFilter 也没有被调用，所以使用时注意不到这个异常。

在代码中 signal 的捕获早在每个线程创建后就会注册完毕，而且显然也是正常在发挥作用的。此外最上层的 UnhandledExceptionFilter 也没有得到处理机会，这样考虑的话应该是系统在加载/卸载动态库时附加了额外的异常处理器并处理掉了异常，所以我们自己的异常报告模块才感知不到有异常发生。

异常分发

异常分发的核心函数是 KiDispatchException，它会首先尝试将异常发送给调试器。如果发送失败或者调试器没有处理，再调用异常处理块处理异常。用户态下异常处理由 ntdll 中的 KiUserExceptionDispatcher 函数进行。KiUserExceptionDispatcher 就会从 fs:[0] 开始遍历异常过滤器，直到有处理器处理异常或是执行 UnhandledExceptionFilter 函数。通过在代码里添加 __try / __except 就可以添加自定义的 seh 异常处理器。

因为异常注册信息存放在每个线程 TIB 的第一个字段 ExceptionList 中，而 x86 系统中的段寄存器 fs 总是指向线程的 TIB 结构。也就是说 fs:[0] 总是指向异常处理链表的表头，通过它就可以查看到线程上所有的异常处理器。在 windbg 中可以使用 !exchain 命令输出当前线程的异常处理链。

在 crt\src\vcruntime\dll_dllmain.cpp 的 dllmain_dispatch 函数中我们可以看到，crt 的初始化相关代码以及 DllMain 都被包含在运行库创建的 __try / __except 块里，负责过滤的是 __scrt_dllmain_exception_filter 函数。而 __scrt_dllmain_exception_filter 函数会调用 _seh_filter_dll，后者又会调用 _seh_filter_exe 进行实际处理。关键的 signal handler 触发是在 _seh_filter_exe 函数中。然而区别在于 _seh_filter_dll 中会判断当前的异常是不是一个 c++ 异常（异常代码为 0xe06d7363），是就直接跳过不处理。执行不可访问内存实际触发的是 0xc0000005，所以 _seh_filter_dll 就会直接返回 EXCEPTION_CONTINUE_SEARCH。

调试

我写了个简单的测试程序来模拟异常发生的情况

在调用 FreeLibrary 卸载 dll 时就会触发到全局变量析构函数中的内存访问异常。
调试器收到异常后查看当前的异常链：

异常发生时的堆栈：

在 ntdll!ExecuteHandler2 中下断点观察，可以发现前面的过滤器都跳过了处理，最终是由

处理了异常，处理异常时的堆栈

可以看到这里将异常报告发送给了 WER 服务，该操作完成后也就结束了本次的异常处理。在做完扫尾的栈展开后线程便会继续执行后续的代码。