驱动程序编写者指南--Driver Verifier.pdf

第一卷驱动程序编写者指南第1章驱动程序开发环境第2章测试驱动程序第1章驱动程序开发环境为Microsoft Windows 2000开发驱动程序至少需要两台机器：一台用于开发，一台用于调 试。如果驱动程序依赖于基本设备，包括高端工作站和服务器，驱动程序也可在一台多处理器计 算机上调试和测试。本章讨论如下主题：I 1.1 自由构建（Free Build）和检查构建（Checked Build）I 1.2调试环境1.1 自由构建和检查构建微软的Windows2000驱动程序的测试和调试需要Windows 2000的自由构建和检查构建。I 自由构建（或零星构建）是操作系统的终端用户版本，系统和驱动程序以最优化方式构建，不可用调试断言，且调试信息已从二进制码中去除。自由系统和驱动程序更小更快，对内存的需 求更小。I 检查构建用于操作系统和内核模式驱动程序的测试和调试，检查构建包括意外错误检查、参数检查和在自由构建中不可用的调试信息。一个检查的系统或驱动程序能帮助区分和记录驱动程 序的某些问题，如内存泄漏或不当的设备配置，这些问题将导致不可预测的后果。尽管检查构建提供额外的保护，但它比自由构建消耗更多的内存和硬盘空间，且由于下列原 因，系统和驱动程序运行得更慢。I 可执行程序含有符号调试信息。I 由于参数检查和调试输出，执行了附加的代码（诊断信息）。新的驱动程序开发通常包括以下步骤：1.编写驱动程序代码，应包括条件编译标记的调试检查。2.测试和调试基于操作系统的检查构建的驱动程序的检查构建。3.测试和调试基于自由构建的驱动程序的自由构建。4.基于自由构建的驱动程序的调整。5.使用了检查构建和自由构建的驱动程序和操作系统附加的测试和调试。6.使用了自由构建的最终的测试和检查。在驱动程序开发的早期，需要Windows2000检查构建来调试驱动程序，检查构建的附加调试 代码保护了驱动程序可能导致的许多错误（比如复发的自旋锁）。执行调整、最终测试和检查驱动程序应该基于自由构建而完成，自由构建的速度越快越有可 能发现竞争条件和其他同步性的问题。由于自由构建与Windows2000的零星版本相同，最终测试和检查也应该基于自由构建而完驱动程序代码通常包括预处理器符号，该符号允许被编译成自由和检查构建。DBG标记是一个保留的符号，可用它来决定编译时Windows2000的什么构建在运行，如果 Windows2000检查构建运行，设置DBG为1,如果自由构建运行，不定义DBG（或设置为0,如 果或者包括头文件wdm.h,或者包括ntddk.h）。驱动程序也应该在至少一个多处理器平台和至少一个单处理器平台上测试和调试；且这两个 平台应该运行Windows2000的当前版本。1.2 调试环境内核模式调试需要一个目标机和一个主机，目标机用来运行驱动程序或另一内核模式的应用 程序，主机运行调试程序。图1.1显示使用调试驱动程序的典型Windows2000设置。内核调试不需要自由或检查构建的 特别结合，从一自由或检查系统调试一自由系统或检查系统是可行的。然而，总体上说，主机没 有理由运行较慢的检查构建。图1.1典型的Windows2000调试设置参看在线DDK的Debugging Drivers和微软的调试程序使用文献来获得更多细节。第2章检查驱动程序在Windows2000上，Driver Verifier是新的可用工具，它执行几项测试和调试内核模式驱动程 序的任务。2.1 Driver VerifierDriver Verifier是一可帮助监视一个或多个内核模式驱动程序以证实他们没有非法函数调用 或引起系统讹误的工具，Driver Verifier在目标驱动程序上执行广泛的测试和检查任务。例如，如 果驱动程序以非正当的IRQL使用了内存，不正当地调用或释放自旋锁和内存分配，或者释放内 存池时没有首先删除任何定时器，Driver Verifier将发布合适的错误检查。当未装载驱动程序时，Driver Verifier检查确信驱动程序已经正确地清理了队列、线程和其他 项目。此外，Driver Verifier能够执行以下任何情况：从一个特别内存池分配驱动程序内存请求，该过程测试驱动程序是否访问它的内存分配之外 的内存，或者在释放它的分配之后访问内存。通过使内存分页代码无效而给驱动程序极端的内存压力，这个过程揭示了访问分页内存的企 图，分页的内存发生在当错误的IRQL或当保留一自旋锁时。池分配的随机失效或其他的内存请求，该过程测试了驱动程序处理低内存状况的能力。未装载的驱动程序检查所有的内存分配，以确信驱动程序没有漏掉内存。从一特别池分配驱动程序的IRP,监视驱动程序I/O以处理其他不一致的行为。这些能力可以分别激活或禁止，此外，Driver Verifier可同时用于任何数目的驱动程序。下面的部分解释了驱动程序的工作方面：2.1.1 Driver Verifier 的能力详细描述了 Driver Verifier各个作用,它应用于除过图形驱动程序之外的所有内核模式驱动程 序。2.1.2 图形驱动程序的Driver Verifier的能力描述了 Driver Verifier对内核模式图形驱动程序的作用，这里内核模式图形驱动程序使用了图 形驱动程序接口（GDI）。2.1.3 激活和监视 Driver Verifier解释了怎样启动Driver Verifier,怎样选择所要的功能，怎样选择所要检查的驱动程序，也解 释了如何利用Driver Verifier Manager来监视正被检查的驱动程序的行为。注意：Driver Verifier能够检查任何数目的驱动程序，然而，当特别内存池和I/O检查选项同 时运用于一驱动程序时，其效果将更为有效。2.1.1 Driver Verifier 的能力Driver Verifier有两种能力：一种是一直起作用，另一种只有被选择时才起作用。以下是对Driver Verifier所有能力的描述：2.1.1.1 自动检查这些是一直起作用的功能，比如IRQL和内存例程的检查，检查定时器检查释放的内存池，检查驱动程序的正确卸载。2.1.1.2 特别内存池这个功能使用了一个特别池来测试内存的上溢和下溢，及在内存释放之后的访问。2.1.1.3 强迫IRQL检查这个功能给驱动程序极端的内存压力来揭示内存分页的故障。2.1.1.4 低资源模拟这个功能注入随机分配错误和其他被拒决的请求来测试驱动程序在低内存状况下的响应。2.1.1.5 内存池跟踪这个功能检查当驱动程序被卸载时所有内存分配已经释放。2.1.1.6 I/O 检查这个功能监视驱动程序I/O对非法或不一致的行为的处理。2.1.1.1自动检查不论Driver Verifier检查一个或多个驱动程序，它将执行以下功能，这些功能不受任何Driver Verifier选项的允许和禁止之影响。IRQL和内存例程的检查Driver Verifier为下面被禁止的功能而监视所选择的驱动程序。通过调用KeLowerlrql提高IRQL通过调用KeRaiselrql降低IRQL零内存分配请求在APC.LEVER之上的IRQL分配和释放分页池在DIPATCH_LEVER之上的IRQL分配和释放非分页池尝试释放一个没有从前面的分配里返回的地址。尝试释放一个已被释放的地址。在APC_LEVER之上的在IRQL获取和释放一个快速的互斥体在IRQL而非在DIPATCH_LEVER之上获取和释放一个自旋锁双倍释放一个自旋锁指定一非法或随机（未初始化的）参数给任一 API。如果Driver Verifier没有运行，在所有状况下，这些故障不大可能会引起立即的系统崩溃，如 果以上任何故障发生，则Driver Verifier监视驱动程序的行为并发布错误检测0 xC4o（参看微软调 试程序文档的使用来获得错误检查参数。）检查被释放的内存池定时器Driver Verifier检查所有被检查驱动程序所释放的内存池，如果任何定时器保留在该池里，发 布错误检测0 xC7。（遗忘的定时器能导致最终系统崩溃，这是最难考虑到的。）检查驱动程序的卸载当一个正被检查的驱动程序卸载后，Driver Verifier执行几个检查来确信驱动程序已被清空。特别地，Driver Verifier寻找下面部分：未删除的定时器未定的DPC未删除的辅助列表未删除的工作线程未删除的队列其他类似的资源诸如以上的问题能潜在地引起系统错误检查在驱动程序卸载后被发布，引起这些错误检测的 原因难于判断。当Driver Verifier运行时，这种故障将导致错误检测0 xC7在驱动程序卸载之后立 即发布。（参看微软的调试程序文件的使用来获得错误检测参数的列表。）图形驱动程序当检查一个驱动程序时，这些自动检查没有执行。211.2特别内存池（Special Memory Pool）内存讹误是一个普通的驱动程序问题，驱动程序错误能在错误出现的长时间后导致崩溃。这些 错误中最普通要数访问已被释放的内存，并分配n字节然后是n+1字节。为发现内存讹误，Driver Verifier能够从一特别池分配驱动程序内存并监视该池防止不正确的 访问。两个特别池定位是可行的，Verify End定位更易于发现访问上溢，Verify Start分配更易发现 下溢。（注意：主要的内存讹误是由于上溢，而非下溢。）当特别内存池运行并且选择了 Verify End时，驱动程序请求的每一个内存分配被放置到不同 的内存页码上。允许分配适合分页的最高可能地址被返回，这样内存被定位于页末。分页的前面 部分用特殊的模式写入，前面的页码和紧邻的页码被标记为不可访问的。如果驱动程序在分配结束之后试图访问内存，Driver Verifier将立即发现并发布错误检测 OxCD,如果驱动程序在缓冲区的开始之前写内存，这将（大概）更改这种模式。当缓冲区被释放，Driver Verifier将发现更改并报告错误检测OxClo如果驱动程序在缓冲区释放以后读出或写入，Driver Verifier将报告错误检测OxCCo当选择Verify Start时，内存缓冲区定位于分页的开始，在这种设置下，下溢立即引起错误检 测，而上溢只有当内存被释放时才引起错误检测。这个选项的其他方面与Verify End选项是相同 的。由于驱动程序上溢错误比下溢错误普遍的多，所以Verify End是默认的定位。为改变这种设 置，使用全局标记应用程序（Global Flags Utility）。一个单独的内存分配推翻这种设置，并通过调用ExAllocateWithTagPriority的Priority参数来 设置成XxxSpecialPoolOverrun或XxxSpecialPoolUnderrun来选择它的定位。（这个例程不能够激 活或去活特别池，或者请求一个特别的内存分配，否则的话，这个内存分配将从普通池得到，只 有此种定位才能够被这个例程控制。）池标记Driver Verifier将给已选择要检查的驱动程序指定特别池，另外一种使用特别池的方法是指定 它到被一个专用poo/Sg标记的内存池。Global Flags Utility能够用来将特别池给具有一给定标记的池。同时通过Driver Verifier和Global Flags Utility来请求特别池是允许的，如果这么做，微软的 Windows2000将试图利用特别池给指定标记的所有的池和来自指定驱动程序所有的池分配请求。特别池效率每个来自特别池的分配使用一个不可分页的内存页码和两个具有虚拟地址空间的页码，如果 此池被耗尽，内存通过标准的方式分配，直到特别池再次变得可用为止。这样，如果特别内存池(Special Memory Pool)正在使用，不推荐同时检查多驱动程序。发出了大量小内存请求的单个驱动程序也能够耗尽此池，出现这种情况，给驱动程序内存分 配指定池标记且一次使特别池给一个池标记是可以选择的。特别池的大小随着系统物理内存的增大而增加，理想地，其容量至少1GB。在x86机器上，当虚拟空间(还有物理空间)被消耗时，引导而没有/3 GB开关也是可选的。增加分页文件达最 小/最大数量(通过二，三当中的一个因子)也是一个好主意。如果特别内存池可用，但是不到95%的所有池分配已经从特别池指定，在驱动程序测试管理 器(Driver Verifier Manager)的。river S必加s scree上将出现一个警告。发生这种情况，你应该检 查一个更短的驱动程序列表，通过池标记检查单个池，或者给你的系统增加更多的物理内存。为确信所有的驱动程序分配已被测试，推荐加强驱动程序较长时间周期。监视特别池Driver Verifier Manager 的 Global Counters screen 能被用来监视特别池的使用。如果是万。几s Succeeded,特别池计数器等同于Sz/cceeded计数器，于是特 别池足够覆盖所有的内存分配。如果Allocations Succeeded-.特别池少于Allocations Succeeded,则特别池至少已经被耗尽过一次。由于特别池没运用于这些计数器，所以计数器不跟踪大小为一页或更多的分配。内核调试程序扩展verifier也能够运用于监视特别池使用，它展示了与Driver Verifier Manager 相似的信息。欲获取关于调试程序扩展的信息，请参看微软调试程序使用文件。图形驱动程序为获取这种选项怎样作用显示于驱动程序和内核模式打印驱动程序，参看图形驱动程序的特 别内存池。2JJ.3 强迫 IRQL 检查(Forcing IRQL Checking)尽管内核模式驱动程序被禁止在高IRQL或保持一种自旋锁时访问分页内存，但如果分页实 际上没被修剪，这种动作将不会被注意到。当Forcing IRQL CTiec左比g可用时，Driver Verifier将给所选择的驱动程序施加极端的内存压 力。不论何时IRQL被抬伸至U DISPATCH_LEVEL或更高，或当一自旋锁被请求时，所有的驱动 程序的可分页代码和数据(和系统可分页的池、代码、数据)被标记为修剪过。如果驱动程序试 图访问任何一个这种内存，Driver Verifier发布一个错误检测。既然别的驱动程序的IRQL抬伸不会引起这个动作，这个内存压力将不会直接作用于未被选 择检查的驱动程序。然而，当一个正在检查的驱动程序抬伸IRQL时，Driver Verifier修剪分页，该分页能在未被检查的驱动程序所使用。当这个选项运行时，未被检查的驱动程序的这种错误可 能偶然被捕获。图形驱动程序Forcing IRQL Checking选项不用于图形驱动程序，如被选中，将不起作用。21.14 低资源模拟(Low Resources Simulation)当Low Resources Simulation可用时，Driver Verifier将引起驱动程序内存分配的一个随机选择 失效，这个过程测试驱动程序对低内存和其他低资源状况下正常反应的能力。为精确模拟一低内存条件，这些分配故障直到系统启动后的7分钟被注入，因此，在该过程 中暴露的任何驱动程序错误将以合法的运行问题对待，而非不切实际的情况。标记为MUST.SUCCEED的分配请求不服从于这一动作，MUST_SUCCEED池的每页最大 值被禁止。Driver Verifier能同时检查所选择的驱动程序或所有的驱动程序。图形驱动程序参看图形驱动程序的Low Resources S加德几来获得该选项如何作用于显示驱动程序和内核 模式驱动程序的细节。211.5内存池跟踪(Memory Pool Tracking)Memory Pool Thzc左讥g监视驱动程序所做的内存分配，当驱动程序未装载时，Driver Verifier 确保驱动程序所决定的任何分配都已经释放。不能释放的内存分配(也叫内存泄露)是引起低操作系统执行的通常原因，这些能引起系统 池破碎，最终导致系统崩溃。当这一选项运行时，如一驱动程序没有释放其所有的分配就卸载，Driver Verifier将发布错误 检测0 xC4(参数1等于0 x60)0如果Driver Verifier发布错误检测的参数1等于0 x51,0 x52,0 x53,0 x54或0 x59,则该驱动 程序已经写入分配之外的内存里，在这种状况下，你应该能够让特别内存池来定位错源。参看微软调试程序文件的使用来获得所有错误检测参数0 xC4的列表。监视内存池跟踪Driver Verifier Manager的Pool Tracking screen能够用来监视有分页和无分页的池分配。内核调试程序扩展！verifer2能被用于驱动程序卸载之后未决的内存分配，或当驱动程序运行 时跟踪当前的内存分配。这个扩展也表明了池标记，池大小和每一个分配的分配器地址。为更多 的调试程序信息，请参看微软的调试程序使用文件。图形驱动程序Memory Pool Tracking选项不适用于图形驱动程序，如被选中，不起作用。I/O检查Driver Verifier有两个I/O检查构建，1级I/O检查从一特别池分配驱动程序的IRP和监视驱 动程序的I/O对各种不当的动作的处理，2级I/O检查执行所有1级的动作，和许多更细更广驱动 程序I/O的使用。2级I/O检查是一更有力的检测驱动程序I/O的使用的方法，然而，这种高级的详细审查占用 了更多的内存，且它也能降低操作系统的执行级别。1级I/O检查当1级I/O检查可用时，通过loAllocatelrp获得的所有IRP从一特别池分配，且它们的使用 受到跟踪。此外，Driver Verifier检查非法的I/O调用，包括：尝试释放一个非IO_TYPE_IRP类型的IRP传递非法设备对象给loCallDriver传递一 IRP给含有非法的状态或仍保留一已取消的例程集的loCompleteRequest通过驱动程序调度例程的调用来改变IRQL尝试释放保留关联的一个线程的IRP传递一个设备对象给已经有初始化过的定时器的loInitializeTimer传递一个非法的缓冲区给 loBuildAsynchronousFsdReqiiest 或 loBuildDeviceloControlRequest当一个I/O状态块分配给一极松散的堆栈时，传递一个I/O状态块给一个IRP当一个事件对象分配给一极松散的堆栈时，传递一个事件对象给一个IRP由于特别IRP池有大小限制，只有当一次使用于一个驱动程序时，I/O检查才最有效。1级I/O检查失效将引起错误检测0 xC9发布，错误检测的第一个参数表明有什么违背发生。欲得一个全部的错误检测0 xC9参数的列表，参看微软的调试程序文件。2级I/O检查2级I/O检查错误以不同的方式显示：在一个蓝屏上、在一个崩溃的转储文件里和在一个内 核调试程序里。在一个蓝屏上，信息 IO SYSTEM VERIFICATION ERROR 和信息串 WDM DRIVER ERROR XXX记下了这些错误，这里XXX是一个I/O的错误代码。在一个崩溃的转储文件里，信息 BugCheck 0 xC9（DRIVER_VERIFIER_IOMANAGER_VIOLATION）与 I/O 错误代码一道，记下了这些错误。在此情况下，I/O错误代码以错误检测0 xC9的第一个参数出现。一个内核调试程序里（KD或WinDbg）这些错误以信息WDM DRIVER ERROR和一描述 的文本信息串出现，当内核调试程序运行时，忽略2级错误和恢复系统操作是可能的。（不可能出 现别的错误检测。）在以上的每一情况下，额外信息（例如驱动程序名和各种可用的指针）也被显示，欲知2级 I/O检查错误信息的全面描述，参看微软的调试程序文件中关于错误检测0 xC9的部分。图形驱动程序I/O检查选项不适用于图形驱动程序，如被选中，不起作用。2.1.2 Driver Verifier对图形驱动程序的能力微软的Windows2000内核模式图形驱动程序不直接分配内存池，相反，这些驱动程序使用 GDI（图形驱动程序接口）服务例程，该例程由他力32人.sys提供。由于这个差异，Driver Verifier对待图形驱动程序与内核模式驱动程序不同。下面的部分描述了 Driver Verifier在显示驱动程序和内核模式打印驱动程序上的作用。2.1.2.1 图形驱动程序的特别内存池该动作使用一特别池来检测内存的上溢和下溢，还有在其释放后访问内存。2.1.2.2 图形驱动程序的低资源模拟该动作注入随机的分配故障和其他被拒绝的请求来检测驱动程序在一个低内存状况下的反 应。图形驱动程序的不可用选项当在检查一个图形驱动程序时，Driver Verifier经常执行的自动检查（IRQL和内存例程的检 查，检查定时器释放的内存池，检查驱动程序卸载）并不执行。强迫IRQL检测、内存池跟踪和I/O检查选项不被用于图形驱动程序，如被选择，没有作用。注意：Driver Verifier能被设置检查w加32人.sys自身。然而，这对同时检查的所有图形驱动程 序都有影响。为获得更多关于图形驱动程序的具体信息，Driver Verifier应该仅当驱动程序在调查 状态下才被检查。2.1.2.1 图形驱动程序的特别内存池内存讹误是一个常见的驱动程序问题,驱动程序错误能导致在它们建立起来很长时间后崩溃。这些错误当中最常见的要数访问已释放的内存，并分配n字节然后是n+1字节。当特别内存池功能应用到图形驱动程序时，EngAHocMem例程分配的内存将被移出特别内存 池,Driver Verifier将监视该池以发现不正确的使用。两种特别内存池定位是可行的，Verify End定位能更好的发现访问上溢，Verify Start定位能 更好的发现访问下溢。（注意：最主要的内存讹误是由于上溢，而非下溢。）当特别内存池运行且选择Verify End时，驱动程序所请求的每一内存分配被放到分别的各分 页上，在每页上允许分配的最高可能地址被返回，以便内存分配到页末。每页前面的部分以特别 形式写出。前页与下一页被标记为不可访问。如果驱动程序在分配之后尝试访问内存，Driver Verifier将立即发现并发布错误检测0 xCDo 如果驱动程序先于缓冲区开始写入内存，这很有可能改变形式。当缓冲区被释放时，Driver Verifier 将发现并报告错误检测OxClo如果驱动程序在释放缓冲区之后读或写，Driver Verifier将报告错误检测OxCCo当Verify Start被选择，内存缓冲区被定位到页的开端，在这种设置下，下溢引起立即的错误 检测，而上溢当内存释放时才引起内存检测。这种选项在其他方面与Verify End选项相同。Verify End是缺省定位，是由于驱动程序上溢错误比下溢错误要普遍的多。为改变这种设置，请 使用全局标记应用程序。池标记Driver Verifier将给已选择检查的驱动程序分配特别内存池，使用特别内存池的另一个方法是 分配它给一个具有特别标记的内存池。可利用全局标记应用程序致力于将特别池给具有给定标记的池。同时通过Driver Verifier和全局标记应用程序来请求特别池是允许的，如果这么做，Windows2000将尝试为所有具有指定标记的池和所有指定的驱动程序的池分配请求使用特别池。特别池效率特别池的每一个分配使用不可分页内存的一页和有虚拟地址空间的两页。如果池耗尽，内存 以标准方法分配，直到特别池再次变得可用为止。这样，如果特别内存池在用，多驱动程序同时 被检查则不受推荐。有大量小内存请求的一个单一驱动程序也会耗尽此池，出现此情况，给驱动程序内存指定池 标记和致力于一次给特别池一个池标记将是更可取的。特别池的大小随系统里的物理内存的大小增长而增长，理想的池大小至少1GB。在x86机器 上，当消耗虚拟空间（对物理空间亦同）时，引导而没有/3GB的开关也是优先选取的。增加页面 文件的最大/最小量（通过两或三当中的一个因子）也是一个好主意。如果特别内存池可用，但是不到95%的所有池分配已经从特别池指定，在Driver Verifier管 理器的Driver Status screen上将有一个警告。发生这种情况时，你应该检查一个更短的驱动程序 列表，通过池标记检查单个池，或者给你的系统增加更多的物理内存。确信所有的驱动程序分配已被检测，推荐加强驱动程序较长时间周期 非图形驱动程序要获得这个选项怎样作用其他内核模式驱动程序的细节，参看特别内存池。2.1.2.2 图形驱动程序的低资源模拟当低资源模拟可用时，Driver Verifier将引起随机的驱动程序内存分配的选择失效，这个过程 检查驱动程序对低内存和其他低资源状况下正常反应的能力。下面的GDI回调函数易受制于随机失效：EngAllocMemEngAllocUserMemEngCreateBitmapEngCreateDeviceSurfaceEngCreateDeviceBitmapEngCreatePaletteEngCreateClipEngCreatePathEngCreateWndEngCreateDriverObjectBRUSHOBJ_pvAllocRbrushCLIPOBJ_ppoGetPath为精确模拟一个低内存条件，这些分配故障直到系统启动7分钟后才被注入，因此，任何在 该过程中暴露的驱动程序错误将被当做合法的运行时间问题，而非不切实际的现象。标记为MUST_SUCCEED的分配请求不服从于这一过程，MUST.SUCCEED池每页的最大 值被禁止。这些内存失效也许会引起着色的错误，其表现在不正确的图象和其他输出错误，所以，这个 Driver Verifier选项应该用于对一图形驱动程序的健全检测，而当检测正确执行时也应该运行。Low Resources Simulation选项也许会在外壳图标的高速缓存里引起讹误，发生此情况，图标 的高速缓存必须手工从硬盘删除。非图形驱动程序参看Low Resources Simulation来了解该选项如何作用其他内核模式驱动程序的细节。2.1.3 激活和监视 Driver VerifierDriver Verifier由Driver Verifier的图形接口或verifier.exe的命令行激活，特别内存池选项也 可通过Global Flags Utility激活成标记的内存池。Driver Verifier状态的大多数改变(激活、去活、改变选项、或者改变正被检查的驱动程序列 表)在重新启动时仍起作用，无需改变或重新编译驱动程序。Driver Verifier在Microsoft Windows 2000的自由和检查构建上都能执行。然而，一些选项在没有重新启动介入时仍能被激活或去活。细节参见Driver Verifier管理器的 易变设置窗口 或命令 verifier/volatile/flags VALUE.监视驱动程序行为Driver Verifier管理器窗口中的全局计数器和池跟踪，可用来监视Driver Verifier的动作和已 装载的驱动程序，这些窗口不监视图形驱动程序的检查。内核调试程序扩展！verifier也能用于监视和报告关于许多相关的Driver Verifier行为的统计 数字。当检查图形驱动程序时，应该以！gdikdx.verifier扩展代替。关于调试程序扩展的细节，参看微软调试程序的使用文件。2J,3.1检查器(Verifier)命令行应用程序verifier.exe可用于从命令窗口激活Driver Verifier0应用程序放在 Windows2000的system32目录下，在 Windows2000 DDK的tools目录下。命令行选项包括：verifier/flags VALUE/iolevel 2/all使用指定的选项检查所有已安装的驱动程序，W1LUE是下面位的一个综合。位 作用0 x01特别内存池0 x02强迫IRQL检查0 x04低资源模拟0 x08内存池跟踪0 x10I/O检查位也许会自由地结合，项LUE必须作为一个十进制数输入，十六进制数不被支持。缺省值是11(1+2+8),如果包括/iolevel 2,I/O检查被设置为Level 2。(缺省值是Level 1。)这些设置在下一次引导后生效。verifier/flags VALUE/iolevel 2/driver NAME NAME2 NAME3.检查所列的驱动程序，被空格分开，多个驱动程序通过罗列它们的名字被确定，但是，诸如 n*.sys等通配符的值不被支持。象上面的一样，刈LUE和/iolevel相同。这些设置在下一次引导后生效。verifier/reset它清除了所有的Driver Verifier设置，在下一次引导后，不检查驱动程序。verifier/volatile/flags VALUE不同标准的Driver Verifier激活，易变设置立即起作用，VALUE是下面位的一个结合。位 作用0 x01 特别内存池0 x02 强迫IRQL检查0 x04 低资源模拟位也许会自由地结合，必须作为一十进制数输入（而非十六进制数）。仅仅已列的选项能够有多种设置，在一个多种设置方式里，被检查的驱动程序列表不能改变,且所有的多项设置在重新引导时将丢失。verifier/query产生Driver Verifier所显示在窗口的当前数据的一个总括，数据包括内存分配的一个枚举、IRQL的增加、自旋锁和其他Driver Verifier选项的相关数据。verifier/log LOG_FILE_NAME/interval SECONDS产生记录文件来保持内存、IRQL和自旋锁信息。这个文件有以SECONDS指定的频率写上去 的当前数据，缺省间隔是30秒。verifier/?显示帮助信息。2J32 Driver Verifier 管理器Driver Verifier管理器是一个图形接口，其允许你激活Driver Verifier并监视它的动作状态。Driver Verifier 管理器有五个不同的标记页，Driver Status Global Counters 和 PoolTracking 标记用于显示信息和监视正被检查的驱动程序，Settings标记用来激活和配置Driver Verifier的动 作；对此窗口的改变将在下次引导后起作用，Volatile Settings标记用于立即改变Driver Verifier 的动作（在重新引导之前）。启动Driver Verifier管理器Driver Verifier的快捷方式能启动Driver Verifier管理器，该快捷方式安装在 Windows2000 DDK Mo在命令窗口运行应用程序verifier.exe也能启动Driver Verifier管理器。该文件放在 Windows2000%windir%system32 目录下，在 Windows2000 DDK tools 目录里也有。在没有 命令行选项时运行verifier.exe来激活Driver Verifier管理器。驱动程序状态窗口图：Driver Verifier管理器驱动程序状态窗口Driver Status窗口显示哪一些驱动程序正被装载、哪一些驱动程序被检查和哪一些DriverVerifier选项可用。全局标志部分表明哪一些Driver Verifier选项当前正在使用。被检查的驱动程序部分列出所有驱动程序，Driver Verifier已被指示检查这些程序，可能的状 态值是：Loaded这意味着驱动程序当前已经装载并正被检查。Unloaded这意味着驱动程序自最后一次引导以来被装载和检查过至少一次，但目前没被装载。Never Loaded这意味着指示Driver Verifier来检查这个驱动程序，但驱动程序自最后一次引导以来未被装 载，这可能由讹误的驱动程序图形文件所致。通过点击标题栏上的Driver或Status来分类这个列表。重设频率部分控制多久刷新状态栏一次，高、中和低指令Driver Verifier以不同的速度刷新该 栏，而手工不能自动更新此栏。按钮Refresh Now可使状态栏立即被更新。如果特别内存池可用，但是不到95%的所有池分配已经从特别池指定，窗口上将出现一个警 告信息。参看特别内存池或图形驱动程序特别内存池获取详细资料。全局计数器窗口图：Driver Verifier管理器的全局计数器窗口全局计数器(Global Counters)窗口显示统计数字，这些数字可帮助监视Driver Verifier的 行为。分配计数器对监视与特别内存池相关的统计数字特别有用，这些计数器仅记录标准内核模式 驱动程序所使用的池，而不包括图形驱动程序在内，这里Driver Verifier正在检查标准内核模式驱 动程序。当然，如果相应的功能不可用，这些计数器当中的一些将被设置为零，举例说，如果低 资源模拟没运行，注入计数器的故障将为零。重设频率部分控制这些计数器多久被更新一次，高、中和低指令Driver Verifier以不同的速度 刷新计数器，而手工不能自动更新。按钮Refresh Now可使计数器立即更新。池跟踪窗口图：Driver Verifier管理器的池跟踪窗口池跟踪(Pool Tracking)窗口显示了关于分页和未分页的池分配的信息(包括当前值和峰值)。此窗口对监视与内存池跟踪有关的统计数字非常有用。单个计数器部分每次显示一个驱动程序的统计数字，此窗口顶部的下拉框允许你从当前正被 检查的所有驱动程序中选择。在全局计数器部分，不能跟踪的分配计数器显示了当前正被检查的所有驱动程序的未跟踪分 配数目。由于特别池不能用于这些计数器，而计数器不跟踪大小为一页或更大的分配。重设频率部分控制这些计数器多久被更新一次，高、中和低指令Driver Verifier以不同的速度刷新计数器，而手工不能自动更新。按钮Refresh Now可使计数器立即被更新。设置窗口图：Driver Verifier管理器的设置窗口设置(Settings)窗口是Driver Verifier和它的选项的主要控制面板。当按下Apply按钮时，从Settings窗口传来的所有改变被写到注册表里。如果你退出Driver Verifier管理器而没有按Apply,将问你是否想应用或丢弃你的改变。当再次引导之后，Driver Verifier将遵照窗口上的改变，直到你重新引导，将不会有Settings 窗口的改变对Driver Verifier的功能起作用。窗口上当前系统可用的驱动程序部分列出了在最近的一次引导里系统所装载的驱动程序。Verification Status栏给出了每个驱动程序的当前状态，可能的检查状态值有：Verify Enabled这意味着驱动程序正被检查，在重新引导后也将继续被检查。Verify Disabled这意味着驱动程序当前没被检查，在重新引导后也不被检查。Verify Enabled(Reboot Needed)这意味着驱动程序当前没被检查，但是用户已请求检查该驱动程序，在重新引导后它将被检 查。Verify Disabled(Reboot Needed)这意味着驱动程序正被检查，但是用户已请求结束检查，重新引导后，该驱动程序不再被检 查。你可以从这个列表中选择一个或多个驱动程序，点击Verify或Dont Verify按钮，你也可以 在驱动程序名右击，并从弹出的菜单控制检查。在下一次重新引导后检查这些附加的驱动程序窗口，允许你进入当前系统并未装载的驱动程 序名。多个名字必须以空格分开。如果选择检查所有驱动程序，在重新引导后，Driver Verifier将检查所有的驱动程序。当选择 这个选项按钮时，驱动程序列表和Verify和Dont Verify按钮变成灰色。检查类型部分允许你选择在重新引导后哪一个Driver Verifier选项可用。参看Driver Verifier 能力和图形Driver Verifier能力中关于这些选项的描述。Pre