写这个“什么是VEH”系列本来没打算做成连续剧。上一篇把VEH和SEH的差别讲完评论区立刻冒出来一批新问题有问“VEH能不能在SEH之前抢跑”的有问“为什么用AddVectoredExceptionHandler注册的回调经常不执行”的还有人直接让我聊聊64位下异常上下文怎么改。这些问题其实都指向同一个核心——VEH的调度机理和边界行为没有真正吃透。这篇我就把VEH的完整分发链路、链表结构、几个高阶玩法以及我踩完坑才知道的排查方法一次性讲明白。适合已经在做调试器、安全工具或者崩溃日志收集并且想进一步提高异常处理稳定性的朋友。1. 从异常分发链路看VEH的真实地位1.1 异常从CPU到用户态的完整旅行很多文档告诉你“VEH先于SEH执行”但你有没有想过这个“先”到底发生在哪一层我花了很久才把整个链路理顺先记一个结论VEH是用户态异常分发过程中最后一道接触异常编码的机会甚至比你自己的main函数栈还早。具体过程是这样的。当CPU执行到非法指令、除零或者访问到无效内存时异常向量会进入内核的陷阱处理器。如果是用户态异常内核会构造一个异常记录然后回转到用户态的ntdll中调用KiUserExceptionDispatcher。这个函数是用户态异常分发真正开始的地方。在KiUserExceptionDispatcher内部第一步会遍历当前进程的VEH链表逐个调用你通过AddVectoredExceptionHandler注册的回调。只有当所有VEH都返回EXCEPTION_CONTINUE_SEARCH时系统才开始查找当前线程的SEH链也就是RtlDispatchException做的事情。如果SEH链也没有处理才会进入UnhandledExceptionFilter最终弹出一站式错误报告或者调用SetUnhandledExceptionFilter注册的兜底函数。所以拿公司汇报流程来类比的话SEH是各部门一层层往上汇报而VEH是公司门口的门卫谁先碰到异常门卫先知道。你甚至不需要在代码里建try/mf嵌套层只要进程里注册了VEH任何线程的任何异常都会先经过它。这个“全局钩子”特性是VEH最大的资本也正因为如此它的回调签名里接收到的EXCEPTION_POINTERS结构里ExceptionRecord和ContextRecord都是从内核/运行时层传下来的原始快照。1.2 为什么微软要把VEH放在SEH之前从设计初衷看VEH是Windows为了满足“进程级异常预处理”而单独引入的机制而不是替代SEH。SEH的最大问题是它依赖栈上的_EXCEPTION_REGISTRATION_RECORD链这个链必须在函数入口处建立帧。如果一个线程的栈已经损坏比如缓冲区溢出把栈帧破坏了SEH链本身可能都找不到异常就无法正确分派。VEH不依赖栈它在ntdll里以全局链表形式存在只要进程活着就能被调用所以哪怕栈被砸只要ntdll的代码还能执行你的VEH就有机会兜底。另外VEH可以被多个独立模块注册且按FILO顺序反向调用。这意味着一个库的作者完全不知道宿主程序里是否有其他模块也需要处理异常大家都能注册系统按后进先出的顺序逐个询问。这样做的好处是越后注册的模块优先级越高相当于整个社区里谁最后一个表态谁先发言。调试器需要第一时间捕获异常所以它可以在加载后注册一个First参数为1的VEH让自己稳居链首而崩溃上报库希望自己能看到最终无人处理的异常可以选择注册到链表尾部或者再结合SetUnhandledExceptionFilter。2. VEH链表顺序、删除与“危险”的直接操作2.1 First参数决定你是插头还是插尾AddVectoredExceptionHandler的函数原型很简单只有两个参数PVOID AddVectoredExceptionHandler( ULONG First, PVECTORED_EXCEPTION_HANDLER Handler );Handler不用多说就是你的回调函数指针。First这个参数的口语化解释是TRUE实际是非零表示把当前回调插入链表头部FALSE或者0表示插入尾部。头部是链表遍历的起点所以First1的回调总是第一个被询问而First0的回调只有在所有头部之后同时又是所有人之后才被问道。如果你连续两次都用First1注册两个处理器那么后注册的那个会更靠前形成“先注册可能在后面”的反直觉效果。我做崩溃恢复模块时就吃过这个亏。A模块先注册了一个需要记录异常上下文的VEHB模块后注册了一个显示弹窗的VEH两个都用First1。结果异常发生时弹窗先出现记录上下文的函数执行时栈已经被用户搞乱了最后抓到的现场不完整。后来我把记录函数的First改成1弹窗处理改成在记录函数返回CONTINUE_SEARCH之后再启用才让顺序稳定下来。理解顺序之后你还能做一个轻量级的“优先级控制”如果你想确保某个处理器在尽可能前面就动态移除已注册的处理器然后重新用First1注册一次。每重复一次它就会跑到链表头一次。2.2 保存返回值它是句柄不是函数地址很多人把AddVectoredExceptionHandler的返回值当成函数指针去保存后来移除时传错了。实际上这个返回值是系统内部链表节点指针在微软的私密符号里叫_VECTORED_EXCEPTION_NODE。RemoveVectoredExceptionHandler必须接收这个指针才能准确断链。如果你在注册时把返回值弄丢之后想撤销处理器几乎只能靠进程卸载来清理那就会一直留在别人的调试器视野里。我个人的代码习惯是在类封装里用一个PVOID成员保存句柄析构时先用成员保存的句柄移除再置空绝不把回调函数地址传进去。一旦传错系统可能去释放一个非节点的地址最终触发访问冲突甚至让下一个异常在ntdll里递归爆炸。2.3 直接操作链表节点的邪道玩法如果你真想深入底层可以通过读取ntdll导出的全局变量LdrpVectorHandlerList一个LIST_ENTRY来枚举所有VEH节点。这个技术主要用于安全分析比如检测自己的VEH是否被别的模块提前插入到了链表头或者判断是否存在恶意堆栈、隐藏回调。结构大致如下typedef struct _VECTORED_EXCEPTION_NODE { LIST_ENTRY ListEntry; // 双向链表指针 PVOID VectorHandler; // 实际回调函数地址 ULONG First; // 是否插头 } VECTORED_EXCEPTION_NODE, *PVECTORED_EXCEPTION_NODE;这种枚举技术也可以在调试工具里使用但我想先给个提醒永远不要直接对这个链表做插入或删除操作除非你完全明白ntdll内部没有加锁而你插入正好撞上另一个线程正在派发异常。真实场景下一旦链表被并发修改破坏轻则当前异常丢失重则进程直接崩溃。我亲眼见过一个项目在debug build下把节点里的ListEntry改坏用户态直接蓝屏其实是系统进程触发IOCTL导致。所以普通业务代码千万不能用这里的方法它只适合分析工具。3. 实战用VEH拦截调试类异常与硬件断点3.1 自定义调试器接管单步和硬件断点如果你是做调试器或者仿真器的VEH是一个成本很低的“断点分发器”。举个例子我想在某条指令被访问时暂停不需要像插INT3那样改写指令字节而是直接设CPU调试寄存器DR0~DR7。当程序执行到那个地址时CPU会产生EXCEPTION_SINGLE_STEP异常这时你注册的VEH会在任何SEH之前获得控制权。下面是初始化设置,Demonstrating如何给当前线程设置一个读/写断点#include windows.h void SetHardwareBreakpoint(HANDLE hThread, DWORD_PTR address) { CONTEXT ctx; ctx.ContextFlags CONTEXT_DEBUG_REGISTERS; GetThreadContext(hThread, ctx); // 只使用DR0开启本地读/写断点位14-15 对应 DR7 的 RW 字段 ctx.Dr0 address; ctx.Dr7 ~0x000F0000; // 清空第4个断点的状态避免干扰 ctx.Dr7 | 0x00000003; // 启用DR0本地断点标志 ctx.Dr7 ~0x00030000; // 确保DR0的RW是00表示仅执行 // 如果要设置读/写访问需要设置RW为11数据读写这里略过细节 SetThreadContext(hThread, ctx); } LONG WINAPI VectoredHandler(EXCEPTION_POINTERS* ep) { if (ep-ExceptionRecord-ExceptionCode EXCEPTION_SINGLE_STEP) { // 此时异常地址在 ep-ContextRecord-Rip wprintf(LHit hardware breakpoint at %p\n, (void*)ep-ContextRecord-Rip); // 这里可以做停止或单步继续之类的操作 return EXCEPTION_CONTINUE_EXECUTION; } return EXCEPTION_CONTINUE_SEARCH; }这里有几个很容易踩的细节GetThreadContext和SetThreadContext必须传当前线程句柄不能传伪句柄-1在64位进程里使用调试寄存器需要ContextFlags里包含CONTEXT_DEBUG_REGISTERS如果你想结束单步后继续断点需要在返回EXCEPTION_CONTINUE_EXECUTION之前确保DR7没被系统清除某些情况下系统会在异常处理后自动把单步标志复位。我的经验是在VEH回调里重新调用SetThreadContext能保证下次命中仍然触发。3.2 软件断点INT3与无缝热补丁VEH处理软件断点也很有用。比如你想在关键函数开头做一个“热补丁”不改变原指令只把首字节改成0xCC然后当CPU执行到这个字节时抛出EXCEPTION_BREAKPOINTVEH在回调里判断地址是否属于你的补丁集合如果是就把Rip改到你的补丁函数入口否则恢复执行或忽略。这里最核心的问题是怎么修改上下文的Rip。请看这个最小实现LONG WINAPI HotpatchHandler(EXCEPTION_POINTERS* ep) { if (ep-ExceptionRecord-ExceptionCode EXCEPTION_BREAKPOINT) { ULONG_PTR addr (ULONG_PTR)ep-ExceptionRecord-ExceptionAddress; // 假设我们对 0x401000 这个位置下了断点补丁跳转到函数 MyPatch if (addr 0x401000) { ep-ContextRecord-Rip (ULONG_PTR)MyPatch; return EXCEPTION_CONTINUE_EXECUTION; } // 其他断点则恢复原指令继续执行 return EXCEPTION_CONTINUE_SEARCH; } return EXCEPTION_CONTINUE_SEARCH; }注意对于EXCEPTION_BREAKPOINTExceptionAddress指向断点后的下一条指令也就是0xCC的下一个字节但实际触发地址是0xCC所在的位置。所以严谨做法里需要自己根据ExceptionAddress减1来对齐。我在windowswin10 2004上测试过没有减1直接判断地址有很多坑最好把原指令字节恢复后再把Rip设置成原地址并单步执行一次这样最稳妥。如果是在自己写的Hook引擎里我更推荐用一个极小汇编跳板而不是在VEH里做Rip篡改因为处理大数据量和异步异常时VEH回调里改上下文会导致整个指令流跳变缓存和指令预取问题很多。VEH更适合做“一次性断点”而不是常驻Hook。3.3 安全视角VEH链本身也是“被检测目标”我们做安全分析时经常要检测进程的VEH链是否被注入过异常处理器。攻击者在做反调试或者执行代码保护时喜欢注册一个VEH来混淆反汇编器。反过来杀毒引擎也可以枚举LdrpVectorHandlerList看看是否有不在信任名单里的模块注册了VEH。这种“互相检测”很常见。我提醒一句不要在自己的普通应用里做这种链表篡改来隐藏任何行为那会让你从“正常的软件保护”滑向“对抗检测”的灰色地带。作为安全研究员了解这些机制并用在防御侧比如监控自己的进程里VEH链是否被改是合理的但把它用来对抗杀软或者绕过授权就完全不推荐了。技术本身没有善恶玩到什么边界心里是要有数的。4. 实战用VEH处理内存访问异常实现“自愈”式执行4.1 捕获Access Violation并动态提交内存VEH的最高价值场景之一是用它来实现一个类似“惰性分配”或“软内存补丁”的机制。比如你设计了一个超大数组但一开始并不物理提交物理内存只保留虚拟地址空间。当你读取某个未提交页时CPU产生EXCEPTION_ACCESS_VIOLATIONVEH判读地址在合法范围内然后调用VirtualAlloc提交这页内存最后让CPU重新执行触发异常的那条指令。整个过程对上层代码完全透明相当于用异常操作作为“内存不足”的中断信号。示例代码只体现思路LONG WINAPI AccessGuardHandler(EXCEPTION_POINTERS* ep) { if (ep-ExceptionRecord-ExceptionCode EXCEPTION_ACCESS_VIOLATION) { ULONG_PTR faultAddr ep-ExceptionRecord-ExceptionInformation[1]; // 判断 faultAddr 是否在声明的保留区域内避免接入偶然的野指针 if (faultAddr (ULONG_PTR)guardRegionBase faultAddr (ULONG_PTR)guardRegionBase guardRegionSize) { if (VirtualAlloc((LPVOID)(faultAddr ~0xFFF), 0x1000, MEM_COMMIT, PAGE_READWRITE)) { return EXCEPTION_CONTINUE_EXECUTION; // 重新执行原指令 } } } return EXCEPTION_CONTINUE_SEARCH; }这里最关键的语义是ExceptionInformation[1]。对于访问违规操作系统把ExceptionInformation[0]设置成0表示读取1表示写入2表示执行ExceptionInformation[1]是访问的具体虚拟地址。不要搞错不然你可能提交了错误的内存或者漏掉真正的写入冲突。另外重新执行原指令后CPU会重新读取内存这一次因为内存已经提交正常执行就不再异常了。4.2 跳过指令修改Rip继续执行的利与弊另一种常见需求是“遇到某种非法访问时不处理而是跳过这条指令”。比如一个游戏引擎读取一个可选的配置对象对象为空时就该跳过。你可以注册VEH检查访问的地址值是否为配置对象的固定地址然后直接修改Rip往下跳。要正确跳过指令至少要解决两件事第一精确计算当前触发指令的长度第二如果原指令有副作用比如某个寄存器已经被更新到一半你必须把上下文里的寄存器修正为“这条指令执行完后的效果”否则后续指令使用的寄存器状态会错。我自己做过一个精简的指令长度解码表但很多人的项目里用的是LDE库比如Zydis。用LDE解码完Rip instrLen。这个是能用的但要切记x64下不要随便对Rip做字节加减因为有些指令前缀和ModRM组合的长度不是固定值盲猜1通常会让CPU执行到一个错误的位置造成另一次异常。还有一个更隐蔽的问题如果你修改后的Rip指到一个无效的填充区域可能会触发反汇编器完全无法识别的字节这样后续异常状态无法预测。所以这个技巧只适合你知道自己在跳什么的时候用对于自动化Hook框架并不稳健。4.3 64位与32位上下文修改的差异到了x64下VEH回调里修改寄存器有几个值得注意的地方。首先CONTEXT结构里所有通用寄存器RAX、RCX、等等都可以直接改但EFlags字段里的RFResume Flag可能不准确。其次x64下指令指针是64位的Rip如果你的程序是WOW6432位运行在64位系统异常上下文其实是64位的WOW64_CONTEXT和原生32位不一样。建议用IsWow64Process2或者判断模块来区分。此外Windows 10 1809以后系统对SetThreadContext写入x64上下文的校验更严格你如果在VEH回调里修改了SegFs等段寄存器玩脱系统可能拒绝写入。所以绝大多数场景下只改Rip、Rsp和通用寄存器就够了不要碰段寄存器。5. 常见问题与排查技巧实录5.1 我的VEH回调压根没执行这是被问得最多的情况。如果回调已经注册成功却从未被调用按下面顺序排查检查是否在DLL卸载时调用了RemoveVectoredExceptionHandler把处理器注销掉了很多时候不是没执行而是你DLL里某个全局对象的析构在异常前删掉了handler。确认异常是用户态异常而且没有被内核直接吞掉。比如某些STATUS_ACCESS_VIOLATION在任务管理器结束进程时直接由系统点终止VEH可能没机会跑。确认你是用同一个进程注册和调用。AddVectoredExceptionHandler是进程粒度的DLL注入后注册的VEH会随注入进程存在但如果你在DLL_PROCESS_DETACH里删除了进程如果还跑就没了。检查是否被更高优先级的东西提前返回EXCEPTION_CONTINUE_EXECUTION了。因为链表是FILO后注册的其他模块可能把你挤到后面而且别人已经处理掉异常你的回调就不会被问。我在开发一个崩溃采集器时发现自己的VEH在检测机上不工作排查后才发现宿主程序里装了另一个安全软件它的VEH优先返回了EXCEPTION_CONTINUE_EXECUTION并且没有继续搜索。解决办法是我改用SetUnhandledExceptionFilter兜底或者把自己的处理器注册为链表头的同时增加一个“被抢跑”的统计日志。5.2 移除VEH时崩溃多半是句柄传错了如果RemoveVectoredExceptionHandler崩溃我见过九成是传入的地址不是注册时返回值。有人图省事直接把自己的回调函数指针传过去这会让ntdll去解引用一个地址值完全不对的节点。正确做法是保存返回值并原样传回。还有一个小坑同一个处理函数被注册了多次返回值不同你移除时只移除其中一个另一个仍然在链上。如果处理函数指针是同一个静态函数这没问题但如果你在多个对象里注册且对象已经析构那链上就会留下一个悬空指针下一次异常时就可能跳到已释放的代码地址。所以注册和移除必须严格配对并在移除函数里置空否则很容易踩内存越界。5.3 VEH与C异常、CRT的冲突C的try/catch和__except使用的是基于栈的SEH正常情况下VEH先执行你返回EXCEPTION_CONTINUE_SEARCH后C异常处理才能正常捕获。但有个隐蔽行为如果你在VEH回调里再次触发一个异常比如你调用了带异常的函数但没保护新异常会递归进入KiUserExceptionDispatcher。此时如果链表里还是同一个VEH就会无限递归栈很快被打爆。所以VEH回调里不要做任何可能再次触发异常的事情包括使用带分配的STL函数。另外在64位下如果启用了控制流保护CFGVEH回调的地址必须是在CFG的合法调用目标表中。如果回调是从动态生成的JIT代码里注册的可能因CFG严格校验而无效。这种情况下需要申请VirtualAlloc时用VirtualProtect设置可执行并且把它加入CFG的call target表通过SetProcessValidCallTargets否则异常来临时系统可能拒绝调用你的处理函数。很多JIT引擎在Windows上跑VEH不生效原因就在这里。结尾一点真实体会我最初接触VEH是被“可以不依赖栈结构处理全局异常”这个特性吸引后来在实际项目里拆了不下几十个崩溃现场才慢慢摸清它的脾气。如果你只是想给程序加一个最通用的异常记录器那直接用SetUnhandledExceptionFilter可能更合适如果要做调试器或内存保护系统VEH的提前进场和上下文可修改性无可替代。但也要记住VEH不是一个快函数它在ntdll分发最前端任何阻塞、死锁或者递归都会直接影响全进程的稳定性。我通常只在最关键的几个场景里注册它并且要求回调里只做简单判断和极少数系统调用连日志都只写环形缓冲区而不是直写文件。最后分享一个小技巧在VEH回调里如果需要判断异常是否源自当前线程可以用GetCurrentThreadId()对比保存的线程ID避免在多线程并发下做无差别修复。这个过滤器看起来简单实际能让你的处理器避免很多“帮倒忙”的瞬间。
