结构化驱动开发及综合汇总.docVIP

结构化驱动开发 开发驱动程序并不是一件容易的事情。更加不幸的是，将驱动程序加入你产品包里边有可能更加糟糕。而且作为Windows执行体的一部分的驱动可能干掉你的系统，而这种错误还非常的难以检测。再者系统当机有可能是有规律的出现，也可能是时不时的出现（一般地，你将会希望你的驱动不出现问题，因为她确实在做一些非常重要的事情。更加糟糕的事情是系统统当机有可能破坏你存储，而且当你会现这种情况的时候，已经晚了。 因此当你开发驱动程序的时候，你必须得满足以下的条件： ·你的程序应该不会引起数据的破坏。这个是对于驱动程序设计师的一个最基本的要求，但是这也是最难以评估的。 ·你的程序应该不会造成系统当机。这个要求的目标是在一些不利的情况，当额外连接的设备（如磁盘或者网卡）没有正常工作的情况下，你的程序应该优雅的处理这种异常的情况。优雅的处理一个驱动程序的错误并不是一个十分明晰的定义：她可能意味你确实能够处理这种异常，也可能意味着您至少可将该驱动程序从内存当中卸载，从而允许系统的其他组件运行。 ·对第二点进行扩展，驱动程序当中的代码不应该导到系统当中的发生。这听上去可能有点儿自相矛盾，因为从定义来看，臭虫就是因为不可预知才被称为臭虫，如果可以预知就不是臭虫了。既然不可预知，我如何可以知道这个臭虫是否会造成系统当机。然而，在大部分的情况下，驱动程序设计师其实还是可以为代码可能造成的错误来进行处理，来防止系统的崩溃。 ·驱动程序应该能够将运行情况报告给管理员。例如，一个错误发生之后，驱动程序应该能够向管理员提供造成错误的原因，以便管理员对系统作出相应的调整来解决这个问题，或者了解到这个驱动程序已经出现功能上边的错误或者即将出现错误。即算是你的驱动程序运行正常，你也应该提供报告给管理员，包括一些该驱动使用的方法及一些参数的规则。管理员有可能使用这些规则来完成对驱动的调整以及除错处理。 这些要求的完成都是驱动程序设计师的责任。但是好消息是Windows操作系统为在你的驱动程序实现这些特性，提供了丰富的支持。 异常派发支持(Exception Dispatching Support) 一个异常是一个线程当中的代码产生的。而且异常所导致的异常处理例程将会在产生异常的该线程当中执行。因为异常是一个由代码产生的同步事情，所以如果提供了一个同样的条件，异常可以重现。Windows为异常提供了派发机制。 为异常的线程建立一个陷阱帧。这个线程的陷阱帧所有已经被破坏的寄存器的值。比如在执行异常代码之后写入的寄存器的值。 可选的为异常的线程建立一个陷阱帧。这个陷阱帧将包括所有没有被破坏的寄存器的值。所有的Windows异常处理程序都会为异常的线程建立一个这样的陷阱帧。 建立一个异常的结构体。这个结构体包括了异常产生的原因，异常的种类，异常发生的地址以及其他相应的参数。异常的种类在目前的情况下只有EXCEPTION_NONCOUNTINUEABLE，表明这是一种非常严重的异常，发生这种异常之后系统将不能再继续正常的运行。 一些异常有可能还会提供一些参数来表明该异常的一些特定的情况。这里只有EXCEPTION_ACCESS_VOLIDATION才可以使用参数。一个参数来表明出现内存访问错误 的操作类型是读还是写，另外一个参数来表明出现错误访问的内存地址。 将控制权交给位于系统内核的异常派发例程来进行处理。这个位于内核的异常派发例程叫作KiDispatchException(). 异常处理有可能产生的结果(Possible Outcomes of Exception Processing) 异常处理例程将会判断异常发生在何种运行模式下。内核模式和用户模式的处理有些许的不同。在我们探索异常处理的内部的结构之前，先让我们看一些异常处理例程执行后，有可能出现的结果。 每一个异常的情况都可由异常处理例程使用以下三种方法来进行处理： ·异常处理例程会修改将造成异常的条件，然后通过派发消息，让出现的异常的线程继续运行。 我们可以考虑一种页错误的情况。异常处理例程将会从第二存储的设备当中将内存的数据取回来或者从网络当中将所请求的数据传储到内存当中，这样当发生异常再继续执行的时候，她就可取到相应页面的数据了。 另外一种情况是一段代码段的代码试图分配一块内存。如果该内存分配失败，那么使用返回的内存地址将会产生访问权限错误的异常。让我们看一下这个例子的代码： //分配4k 的内存 SomePtr = ExAllocatePool(PagedPool,4096); //一般情况下使用ExAllocatePool的例程能够成功的得到内存，当然也有分配失败的可能。这里我们为了方便，先假定这个内存的申请确实是失败了，而且SomePtr将会返回NULL。 RtlZeroMemory(SomePtr,