你有没有写过不太正确但足够接近的代码？当一切顺利的时候，你是否不得不编写运行良好的代码，但是你不太确定当出了问题时会发生什么？有一个简单的、不正确的语句可能位于您编写或必须维护的代码中：catch (Exception e)。这似乎是无辜和直截了当的，但这个小小的声明会造成很多问题，当它不能做你期望的。

如果您像下面的代码那样使用异常的代码：

public voidFileSave(String name)

{try{ 

        FileStream fs= newFileStream(name, FileMode.Create); 

       }catch(Exception)

      {throw new System.IO.IOException("File Open Error!"); 

      } 

}

硬件异常可以分为三种：

• fault(错误)，在处理此类异常时，操作系统会将遭遇异常时的“现场”保存下来（比如EIP、CS等寄存器的值），然后将调用相应的异常处理函数，如果对异常的处理成功了（没成功的情况会在下文中提到），那就恢复到原始现场，继续执行。最经典的fault例子莫过于Page Fault了，在分页机制下，当我们读到某个还未载入到内存的页时，就会触发该异常，操作系统会将该页载入内存，然后重新执行读取该页的指令，这是分页机制实现的重要机制。
• trap(陷阱)，在处理此类异常时，操作系统会将异常的“下文”保存，在处理异常后，直接执行导致异常的指令的下一条指令。我们在调试过程中常用的断点操作就是基于这类异常的，当我们在某处下断点时调试器会将原本此处的指令对应的十六进制保存下来，然后替换第一个字节替换为0xCC的，也就是int 3，造成断点异常，中断（此处的中断用的是break，而我们一般说的中断是interrupt，请读者务必区分清楚）到调试器，程序在运行到此处就会停止等待下一步的指令，而当我们继续执行时调试器就会将该指令替换为原来的指令，程序也就恢复正常执行了。不知道大家有没有注意过，在进行程序调试时经常会看见hex界面显示大量的“烫烫烫”，这其实是0xcc对应的中文字符，因为这些地址的内容程序并不想让我们访问，一旦我们访问这些地址，就会读到0xcc，程序也就“中断”了。
• abort(中止)，中止异常，主要是处理严重的硬件错误等，这类异常不会恢复执行，会强制性退出。

以栈作为基础的SEH本身具有很大的危险性，我们可以利用各种手段对栈上SEH节点进行覆盖重写，再次执行异常处理操作时就会将执行权给到了我们用来覆盖的函数上，这实际上在以前是很常见的windows栈溢出手段，当然，除了这种方法外还有许许多多的利用手段，可见这样的异常处理机制还是不够完善的。为了解决这些问题，微软逐步加入了Safe SEH、SEHOP、VCH等来弥补。

Safe SEH

SafeSEH又叫做软件DEP，是一种在软件层面实现的对SEH的保护机制，它需要操作系统和编译器的双重支持，在vs2013及以后的版本中会自动启用 /SafeSEH 链接选项来使用SafeSEH。也正是因为该项技术使得以往简单的覆盖异常处理句柄的漏洞利用几乎失效了

在加载PE文件时，SafeSEH将定位合法的SEH表的地址（如果该映像不支持SafeSEH的话则地址为0），然后是用共享内存中的一个随机数进行加密处理，程序中所有的异常处理函数的地址提取出来汇总放入SEH表，并将该表放入程序映像中，还会将将加密后的SEH函数表地址，IMAGE的开始地址，IMAGE的长度，合法SEH函数的个数，作为一条记录放入ntdll（ntdll模块是进行异常分发的模块）的加载模块数据内存中,每次调用异常处理函数时都会进行校验，只有二者一致才能够正常进行，该处理由RtlDispatchException() 开始，首先会经历两次检查，分别是：

• 检查异常处理链是否在当前的栈中，不是则终止
• 检查异常处理函数的指针是否指向栈，是则终止

通过两次检查后会调用RtlIsValidHandler() 来进行异常的有效性检查，08年的black hat给出了该函数的细节

BOOL RtlIsValidHandler( handler )

{if (handler is in the loaded image)      //是否在loaded的空间内
{if (image has set the IMAGE_DLLCHARACTERISTICS_NO_SEH flag) //是否设置了忽略异常
            returnFALSE;if (image has a SafeSEH table)       //是否含有SEH表
            if (handler found in the table)  //异常处理函数地址是否表中
                returnTRUE;else
                returnFALSE;if (image is a .NET assembly with the ILonl    y flag set)returnFALSE;                    

    }if (handler is on non-executable page)   //handler是否在不可执行页上
{if (ExecuteDispatchEnable bit set in the process flags) //DEP是否开启
            returnTRUE;elseraise ACCESS_VIOLATION;          

    }if (handler is not in an image)          //handler是否在未加载空间
{if (ImageDispatchEnable bit set in the process flags) //设置的标志位是否允许
            returnTRUE;else
            returnFALSE;

    }return TRUE;                             /s/允许执行异常处理函数

}

我的应用程序，一个可执行文件，正在远程计算机上崩溃。我没有访问那台机器的权限，所以我请求了一个转储，通过任务管理器生成。使用WEBBG，在执行命令!analyze -v时，我可以看到许多其他的文本

EXCEPTION_RECORD:  (.exr -1)

ExceptionAddress: 0000000000000000

ExceptionCode: 80000003 (Break instruction exception)

ExceptionFlags: 00000000

NumberParameters: 0

我怎么知道它是不是对坠机事件负责？如果不是，我如何确定真正的原因？