SEH分析笔记（X86篇）
历史：
v1.0.0, 2011-10-05：最初版本。
v1.0.1, 2011-10-06：补充总结之前的资源泄漏示例。
v1.0.2, 2011-10-31：调整若干描述语句；增加 ExceptionNestedException 返回值的补充说明。
注：本帖内容没有同步更新，请下载附件。
[不介意转载，但请注明出处 boxcounter.com
附件里有本文的原始稿，一样的内容，更好的高亮和排版。分别是 html 和 rtl 格式。
后面的部分代码可能会因为自动换行变得很乱，需要的朋友手动复制到自己的代码编辑器就可以正常显示了]
这两天琢磨了下SEH，这里记录一下自己琢磨的一些心得。
SEH 这个概念我就不嗦了，任何一个介绍 SEH 的资料都有讲。我主要记录一些自己的理解。可能有一些概念理解的不够清晰，有一些说法比较狭隘，欢迎看到本文的朋友一起讨论、修正，非常感谢。
首先，SEH 是针对于异常的一种处理机制，这个异常分为硬件异常和软件异常，这里所说的硬件异常是狭义的异常，也就是 CPU 产生的异常。比如除零操作，CPU 执行除零操作时候，会自主启动异常处理机制。软件异常，就是程序模拟的异常，比如调用 RaiseException 函数。软件异常是可以随意触发的，windows 系统内部遇到问题会触发，开发人员高兴了也可以触发。
抛出了问题，就要有解决方案。那这么多问题和解决方案，如何管理呢？windows 系统当仁不让的提供了它管理方案 SEH。我看一些资料有详细的讨论 SEH 的确切含义，这里我不参与讨论，而只是简单的理解为“系统提供的异常处理机制，以及编译器对其进行增强的部分”。
来说说系统提供的异常处理机制。
windows 提供的异常处理机制实际上只是一个简单的框架，一般情况下开发人员都不会直接用到。咱通常所用的异常处理（比如 C++ 的 throw、try、catch）都是编译器在系统提供的异常处理机制上进行加工了的增强版本。这里先抛开增强版的不提，继续说原始版本。
原始版本的机制很简单：谁都可以触发异常，谁都可以处理异常（只要它能看得见）。但是不管是触发还是处理都得先登记。系统把这些登记信息保存在一个链表里，并且这个链表保存在线程的数据结构里。也就是说，异常所涉及的一些行为都是线程相关的。比如，线程 T1 触发的异常就只能由线程 T1 来处理，其他线程根本就不知道 T1 发生了什么事，更不会狗拿耗子。
等登记完毕后，线程就可以抛出或处理异常了，系统也可以做相应的管理工作了。（这里嗦一句，系统提供的 SEH 其实是一个针对于“触发异常-解决异常”的管理机制，系统自身是不提供任何具体异常的解决方案的。解决方案还是要由用户自身来提供（增强版里编译器也会来提供解决方案，来帮“不负责”的程序猿擦屁股，这是后话））
系统提供的管理工作简单来说包括（但不限于）：找到触发异常的线程的异常处理链表（前头登记的那个），然后按照规则（具体的规则后续再说）对该异常进行分发，根据分发后的处理结果再进行下一步的分发或者结束处理。
系统管理所使用的数据结构和宏：
注意：上传附件及图片大小不得大于30M。
⚠️ 版权声明：
本博客所有内容（含教程、源码、工具）仅供个人技术学习与研究交流使用，严禁商用、倒卖、二次分发及非法用途。
未经作者书面授权，任何组织或个人不得转载、复制或用于其他平台，违者将追究相关责任。
参与讨论
登录后可查看全部回复并参与讨论。
