VEH系列写到第三篇前两篇已经把“什么是VEH”“和SEH差别在哪”这些基础问题聊透。这篇不再重复概念重点转向实战怎么把AddVectoredExceptionHandler这个API用明白回调函数里哪些事情能做、哪些做了就是给自己挖坑以及注册顺序、上下文修改、调试器联动的那些细枝末节。适用对象是正在用C/C做Windows客户端和系统组件的开发者做逆向分析、崩溃诊断、热修补的朋友更会关心。前两部分相当于把机制再过一遍但更抠细节后面给出能直接抄的代码和排错经验新手照着落地也不难。1. 先把机制拉通VEH到底站在异常处理的哪个位置1.1 从API签名到调用时机一条线看明白VEH的注册入口只有一个就是AddVectoredExceptionHandler签名很短ULONG AddVectoredExceptionHandler( ULONG FirstHandler, PVECTORED_EXCEPTION_HANDLER VectoredHandler );回调函数长这样LONG NTAPI MyHandler(PEXCEPTION_POINTERS pExceptionInfo);这组API是Windows XP开始加入的目的很直接给进程提供一个不依赖栈帧的全局异常观察点。为什么说不依赖栈帧SEH之所以叫“结构化”是因为__try/__except块要和当前线程的栈帧绑定异常分发要靠栈指针一级一级找处理者而VEH是内核态的异常分发流程里直接维护了一个进程级的回调链表只要进程活着任何线程的任何异常都会先从这条链上过一遍。这个差异带来的直接好处是栈已经被破坏得面目全非时SEH可能根本找不到自己的登记记录VEH却照常被调用。所以想让崩溃发生时还能有一块“干净”的执行入口来做记录VEH比SetUnhandledExceptionFilter更靠前后者要等到整套处理链全部失败才轮得上。时序上其实很简单只记一句话进程内部的异常分发顺序是VEH链先跑再进SEH链最后才轮到UnhandledExceptionFilter兜底。这个顺序是硬编码在ntdll的RtlDispatchException流程里的不是谁想调就能调的。1.2 返回值的两个分支异常“所有权”的边界要划清楚回调的返回值只有两个有意义的值EXCEPTION_CONTINUE_EXECUTION和EXCEPTION_CONTINUE_SEARCH。记住宏名很容易但要理清背后的语义逻辑才行。返回EXCEPTION_CONTINUE_SEARCH等于告诉系统“这个异常我看到了但我不打算接手。”系统会走向下一个VEH处理器没有就继续进SEH。返回EXCEPTION_CONTINUE_EXECUTION等于宣布“我已经解决掉了”系统会用当前ContextRecord里的寄存器状态重新执行指令从异常点继续跑。这里有一个经典的死循环坑你返回了CONTINUE_EXECUTION但根本没有修改任何寄存器或指令那系统会回到同一条异常指令上再次抛出同一个异常再次进VEH。如果回调里每次都不做修改就返回这个值程序就是无限循环表面上看像卡死了实际上是在同一个地址上反复触发异常。判断一个异常是不是真的被“处理”了标准很简单Rip/Eip、栈指针、异常地址是否落在不会再次触发的位置。1.3 一个容易被忽略的点异常记录的嵌套关系PEXCEPTION_POINTERS里的ExceptionRecord是个结构体里面有个字段也叫做ExceptionRecord它是指向下一层异常记录的指针。这个链表达的是“异常套异常”的关系。例如你在VEH回调里访问了坏指针回调自身又抛出访问冲突异常链上就有两层记录。实操里看异常不要只看最外层那一条。如果最外层是0xC0000005内层也是0xC0000005且ExceptionAddress指向你回调代码所在的模块那多半是回调自身出错了。这种场景打印整个异常链比只打印一层更接近真相。很多人排查崩溃时只看第一个异常代码却忽略了VEH回调里的二次异常走了不少弯路。2. 关键API细节决定成败的隐藏语义2.1 FirstHandler参数与整个链表顺序规则AddVectoredExceptionHandler的第一个参数真正决定你的回调在整条VEH链里的优先级。系统维护一个双向链表FirstHandler传TRUE回调插到链表头部传FALSE插到尾部。分发时从头部开始遍历所以后注册的TRUE处理器反而最先执行。这个设计经常被用歪。很多项目里多个模块各自注册VEH每个都传TRUE后加载的模块就把先注册的挤到后面。如果你靠VEH做最后的崩溃兜底被别人抢占位置之后你的回调必须等前面所有回调都返回CONTINUE_SEARCH才跑得到别人把异常“吞了”你根本看不到。我的习惯是做全局兜底和崩溃记录的VEH注册时传TRUE且只在主程序启动阶段注册一次做辅助功能的VEH如果有协作需求用FALSE把自己排到后面明确自己的从属身份。模块之间要通信、要约定谁先谁后不要在注册参数上暗斗。2.2 ExceptionRecord与ContextRecord两个对象各有什么用途回调拿到的PEXCEPTION_POINTERS两个成员各管一摊活。ExceptionRecord描述的是“发生了什么”ContextRecord描述的是“发生那一刻寄存器长什么样”。拿访问冲突0xC0000005来说。ExceptionRecord-ExceptionCode是0xC0000005ExceptionAddress是出错指令的地址ExceptionInformation[0]表示操作类型0是读、1是写、8是执行ExceptionInformation[1]是要访问的非法地址。这三个信息组合起来基本能还原崩溃现场它在读位于0x0的地址时炸了。日志要记这些而不是只记一个“Access Violation”。ContextRecord是恢复执行的核心凡是打算用CONTINUE_EXECUTION来做修复最后都落在修改ContextRecord上。有几个字段值得重点关注数据用途典型场景ExceptionRecord-ExceptionAddress定位出错指令、判断是否命中已知问题崩溃快照、断点识别ExceptionInformation[0]/[1]访问冲突的读写类型与目标地址判断是否是空指针写、越界读ContextRecord-Rip/Eip修改执行流、跳过错误指令软补丁、指令模拟ContextRecord-Rsp/Esp检查栈是否泄漏、是否需要篡改栈数据复杂修复逻辑2.3 修改上下文让程序“觉得什么都没发生”既然系统在CONTINUE_EXECUTION之后会用ContextRecord恢复执行那修改寄存器就成了VEH最强大的能力之一。一个典型的例子是除零异常STATUS_INTEGER_DIVIDE_BY_ZERO0xC0000094发生后ExceptionAddress指向那一条除法指令ContextRecord-Rip也停在那里。如果这时把Rip改成“除法指令的下一条指令”程序执行流就绕过了除法相当于修复成功。但修改前一定要确认指令长度不能凭感觉加个固定的数字。x86指令长度不等你跳进指令中间就变成另一条非法指令或完全无关的指令。稳妥的流程是用反汇编引擎确认长度再把Rip设置成ExceptionAddress 长度。另一个修改上下文的场景是把ContextRecord当作临时寄存器仓库。比如我要让某个路径的返回值变成默认值可以先把Rax改成预期返回值再让Rip跳到已知的返回位置。这种操作对栈布局、编译优化极为敏感一般只在特定二进制、特定版本的补丁方案里用不建议在通用框架里铺开。注意一个区别ExceptionAddress和ContextRecord-Rip在大部分情况下指向同一条指令但在极少数系统调用边界场景下Rip可能已经停在内核返回后的地址。以ExceptionAddress为准做指令定位更保险。3. 三种高频实战场景与落地代码3.1 崩溃快照在异常现场留下第一手证据崩溃日志要解决的实际问题Release版程序崩了用户反馈一个“程序没反应/闪退”手头只有截图不知道代码哪一行。注册一个VEH回调在进程彻底死掉之前把异常代码、线程ID、模块名、调用栈写下来这是最朴素也最有效的用法。代码骨架LONG NTAPI CrashDumpHandler(PEXCEPTION_POINTERS ep) { // 过滤掉可恢复的/调试用的异常 DWORD code ep-ExceptionRecord-ExceptionCode; if (code STATUS_BREAKPOINT || code STATUS_SINGLE_STEP) return EXCEPTION_CONTINUE_SEARCH; FILE* f NULL; fopen_s(f, crash.log, a); if (f) { fprintf(f, code0x%08X addr%p tid%u\n, code, ep-ExceptionRecord-ExceptionAddress, GetCurrentThreadId()); if (code STATUS_ACCESS_VIOLATION) { fprintf(f, op%llu target%p\n, ep-ExceptionRecord-ExceptionInformation[0], (void*)ep-ExceptionRecord-ExceptionInformation[1]); } fclose(f); } return EXCEPTION_CONTINUE_SEARCH; }这个简单回调有两个关键点一条路径是记录完继续搜让系统走默认的错误弹窗或者UnhandledExceptionFilter另一条把日志交给专门进程。直接fopen_s写日志其实有隐患异常状态下的堆可能已损坏文件API也可能与正在出错的代码产生锁竞争。实测下来fopen_s fprintf在绝大多数访问冲突场景能正常工作因为CRT文件操作只锁自身结构但遇到堆破坏型崩溃就可能二次异常。更稳妥的工程方案是预先申请固定缓冲区回调里只做内存写之后再从另一个线程或守护进程落盘。想让日志更详细可以用GetModuleFileNameA和VirtualQuery来定位出错模块名但回调里越复杂越危险能少做就少做。真正要拿完整转储可以用MiniDumpWriteDump。这个函数需要在回调里拿进程句柄、线程句柄、栈信息对栈和堆都有依赖风险比打印一行日志高不少。建议把生成dump交给独立watchdog进程VEH回调里用事件或命名管道发个信号就行。我自己在正式项目里就是这么拆的VEH只负责“报信”不负责“善后”。3.2 软断点进程内的简易调试辅助器0xCC对应的指令是int 3执行到它会触发STATUS_BREAKPOINT0x80000003。调试器的一大基本原理就是把指令首字节改写为0xCC等异常触发后再把原指令放回去重放。不用调试器我们完全可以在自己的进程里用VEH实现一个辅助观察器。应用场景很直接怀疑某个函数的调用路径、想确认某条分支是否被走到。平时不加日志只在关键位置插入0xCCVEH回调发现异常地址命中目标后输出一行日志然后把原指令写回把Rip指回断点地址让程序继续执行。注意一个细节0xCC触发后Rip已经指向int 3的下一条指令所以不能直接沿用Rip要把它改回断点地址才能重新执行原指令。代码示意struct BPEntry { void* addr; BYTE originalByte; }; LONG NTAPI BreakpointHandler(PEXCEPTION_POINTERS ep) { if (ep-ExceptionRecord-ExceptionCode ! STATUS_BREAKPOINT) return EXCEPTION_CONTINUE_SEARCH; void* hit ep-ExceptionRecord-ExceptionAddress; // 查找映射表命中后恢复原指令 BPEntry* entry FindBreakpoint(hit); if (!entry) return EXCEPTION_CONTINUE_SEARCH; DWORD oldProtect; VirtualProtect(hit, 1, PAGE_EXECUTE_READWRITE, oldProtect); *(BYTE*)hit entry-originalByte; VirtualProtect(hit, 1, oldProtect, oldProtect); OutputDebugStringA([BP] hit); ep-ContextRecord-Rip (DWORD64)hit; return EXCEPTION_CONTINUE_EXECUTION; }这个场景的价值在于不需要重新编译、不需要停止程序就能在运行中的进程里观察指定位置。局限也明显对已经执行过的代码不能回溯另外这不是真正的调试器不会暂停其他线程。调试器做这套逻辑还涉及单步重放原指令再断回VEH方案里不做那么深够用就好。3.3 定向补丁让特定错误指令“绕过去”第三种场景更接近补丁性质。某个第三方库在特定输入下会执行到非法指令或者某个较老模块对新的CPU指令支持不好跑在新CPU上会炸这种情况在兼容性适配时很常见。思路是VEH先判断ExceptionAddress是否落在已知的“病区”里如果是直接把Rip改到一条安全的代码路径比如跳到自己的修复函数。示意代码extern C void FixupRoutine(void); LONG NTAPI IllegalInstructionHandler(PEXCEPTION_POINTERS ep) { if (ep-ExceptionRecord-ExceptionCode ! STATUS_ILLEGAL_INSTRUCTION) return EXCEPTION_CONTINUE_SEARCH; if (!IsInKnownBadRange((ULONG_PTR)ep-ExceptionRecord-ExceptionAddress)) return EXCEPTION_CONTINUE_SEARCH; ep-ContextRecord-Rip (DWORD64)FixupRoutine; return EXCEPTION_CONTINUE_EXECUTION; }FixupRoutine怎么写要看具体业务多数时候它要利用栈上的返回地址、读参数寄存器然后模拟原函数成功返回。跳转之后栈布局可能不一致所以补丁函数要尽量“轻”建议只做修改寄存器和跳到原指令后面的正常流程而不是跳到一个完整的C函数里去跑复杂业务。经验之谈这种“外科手术”只适合两类情况。一类是无法修改源码的第三方模块另一类是测试环境中验证某个理论比如想试一下“如果跳过这条指令程序逻辑还能不能继续”。拿到生产环境里用你要对这条指令周边的数据流和状态变化有百分之百的把握否则修一个异常带出一串连锁崩溃排查起来比原来的崩溃还痛苦。4. 与调试器、C异常、UEF的联动顺序4.1 有调试器时的真实时序先说结论VEH的“最先执行”指进程内部。进程被调试时内核把异常作为调试事件发给调试器的时机比进程内部VEH链更早。也就是说调试器附加后first-chance异常通知会先到调试器那边调试器如果选择继续不处理异常事件才重新进入进程的异常分发流程VEH才会被调用。这带来一个实操上的现象在Visual Studio或WinDbg里调试时你看不到VEH先跑它更像“调试器放行之后的第二道手”。很多项目开着调试器跑得好好的关了调试器直接崩部分原因就在这调试器的first-chance拦截掩盖了VEH的时机判断。所以做自定义崩溃捕获时代码里要考虑当前进程是否被调试。一个常用做法是用IsDebuggerPresent判断被调试时跳过VEH里的复杂操作只在日志里简单记一行避免我们的VEH把断点异常吃掉干扰调试器。4.2 为什么不该在VEH里直接接管C异常MSVC的C异常throw/catch底层用的是异常代码0xE06D7363它挂在SEH机制上靠__CxxFrameHandler去做栈展开。VEH靠前所以C异常发生时VEH一定能看到。但看到归看到千万别在VEH里对C异常返回CONTINUE_EXECUTION。原因在栈展开。C异常被catch时要一层一层调用析构函数释放局部对象这个过程由SEH框架负责在找到匹配的catch之前完成。如果VEH直接宣布“我已经修复”C运行时就不会再继续找catch也不会展开栈直接跳回去执行栈上的临时对象、异常对象已经是个半坏状态后续行为完全无法预测。VEH对C异常的合理姿态是“旁观记录”。可以在回调里判断code 0xE06D7363把抛出点地址记下来然后返回CONTINUE_SEARCH让C运行时正常处理。很多第三方崩溃分析SDK就是这么干的记录C异常但不干预。5. 高频问题与排查经验速查5.1 回调里做了不该做的事二次异常不奇怪典型翻车行为在VEH里调用CRT堆函数malloc、new、进入临界区、使用PostMessage等需要消息队列的API。异常分发时线程状态可能非常特殊比如持有锁、堆受损、栈指针漂移这些操作很容易触发重入和死锁。我踩过一次坑回调里想多线程安全地打印日志用了临界区。结果异常恰恰发生在另一个线程持有这把临界区时VEH回调等锁出异常的主线程又等着异常处理完才继续直接死锁。从那次以后崩溃日志回调里我只用原子标志位来控制“同一时刻只处理一次”日志先写进预设缓冲区不碰临界区也不做堆分配。5.2 递归与重入VEH里的VEHVEH回调自身访问非法地址会再一次抛异常再次进VEH链形成“异常套异常”。如果回调查表没做好边界判断无限递归直接栈溢出。处理手段回调开头判断当前是否已经是重入状态用一个原子标志或TlsGetValue记录如果已重入直接返回CONTINUE_SEARCH并且不再记录。这样二次异常就能交给系统UEF最多出现两个错误弹窗不会递归到栈爆。还有一个细节值得注意任何线程的异常都会进全局VEH你无法保证同一时刻只有一条线程在回调里跑。所以处理标志要用进程级原子标志而不能只用线程局部存储否则两个线程同时崩溃标志位会被串掉。5.3 64位下的坑与几个容易忽略的点x64下实践VEH有几个高频问题集中列一下寄存器名字差异ContextRecord里x64用Rip/Rsp/Raxx86用Eip/Esp/Eax。写代码时预先用#ifdef _WIN64分开别混用。地址完整性给Rip赋值前确认是规范地址别把低32位随便扩展跳进一个完全随机的地址。编译优化影响Release版下通过ExceptionAddress定位指令但该地址附近的机器码可能因为跳转表、指令对齐而和你反汇编看到的不一致务必在运行时反汇编确认。回调使用浮点/SSE指令异常上下文里浮点环境可能不一致除非是你自己的代码否则慎用复杂浮点运算。回调所在DLL的卸载RemoveVectoredExceptionHandler要在DLL detach前执行否则VEH回调查一个已卸载的DLL等于直接引爆炸弹。5.4 排错速查表症状可能原因建议操作回调执行后程序卡死返回CONTINUE_EXECUTION但上下文没改检查是否修改Rip/Eip或异常地址日志只打到一半回调里使用锁或堆函数触发重入换成原子标志预设缓冲区多个VEH后面的不执行前面的回调返回CONTINUE_EXECUTION吃掉了异常确认各模块VEH注册参数与意图关了调试器才崩调试器first-chance拦截掩盖了真实时序用IsDebuggerPresent分支做对照测试崩溃日志大量重复访问冲突发生在回调代码异常链嵌套打印ExceptionRecord-ExceptionRecord整条链x64下Rip改完还是崩指令长度判断有误或跳入指令中间用反汇编引擎确认指令边界我个人做了这么多年Windows端侧崩溃治理最大的体会是VEH不是用来“修复一切”的银弹它最稳的位置永远是“观察者”。把现场记下来把可控的异常按预期放行这已经是70分的姿势。改上下文这种能力很强但强能力对应高风险没有百分之百把握就别在正式环境里乱跳。如果你正在做一个需要全局统一处理异常和崩溃记录的框架VEH是很好的地基但请一定记住地基之上还要留好逃生门回调越短越好、越无状态越好。写完这篇VEH的三篇基本完整了希望对正在折腾Windows异常处理的朋友有帮助。
