IRP详解

操作IRP: 所有驱动开发人员都要知道的知识(Draft)

翻译：Puffel

2007-8-3

概要

在微软的Windows操作系统家族中，都通过发送I/O请求包(IRP, I/o R equest P ackets)来进行和驱动程序的通讯。用来封装IRP的数据结构不仅仅用来描述一个I/O操作的请求本身的内容，还要用来维护这一请求在一系列驱动程序中传递的过程中的相关状态信息

．．．．。实现这一数据结构其实是为了两重目的，也就是说IRP可以被定义[理解]为：

l一个放置I/O请求的容器

或者

l一个与线程无关的调用栈

从以上这两个角度来考虑IRP，将有助于驱动开发人员理解作为驱动，程序应该如何去正确响应发来的I/O请求。

本文中关于例程（routines）和问题的讨论，请参考最新的微软Windows驱动开发包(WDK, Microsoft W indows D river K it)。

第一重定义：IRP是一个放置I/O请求的容器

操作系统以IRP的形式进行绝大多数发给驱动程序的I/O操作请求。因为下列特点，使得IRP 非常适合于这一目的：

l IRP设计来可以被异步操作

l IRP可以被在完成前取消

l IRP设计来适合于需要多驱动协同完成的输入输出操作

IRP数据结构封装了一个被请求

．．．的驱动所需要的，用来回复这一请求的[全部]信息。而请求则可能来自于用户模式或者内核模式。其实不论请求来自那里，对于被请求的驱动程序，所需要的信息是一样的。

所有的IRP都包含有下“表一”中的两个部分：

l一个用来描述主要I/O请求的头部

l一组用来描述下级请求（有时就被称作子请求，sub-requests）的参数

表一: IRP的结构

其中，头部的数据尺寸是固定，且对所有IRP都相同的。而下级请求数组的尺寸则依赖于会有多少个驱动要来操作这一请求。

IRP头部的内容：

一个IRP通常会被某个由一些驱动程序组成的栈来执行。每个IRP的头部信息，都各自包含着每个要操作这个IRP的驱动程序会要使用的数据。当一个给定的驱动正在处理一个IRP 时，这个驱动就被定义为此IRP的当前拥有者(the current owner)。

每一个IRP的头部，都包含有以下的指针(Pointer)：

l指向针对这一IRP的用以读取输入以及写回输出的缓冲区

l指向当前拥有这一IRP的驱动程序的内存区域

l指向一个由当前拥有这一IRP的驱动提供的例程。这一例程将由系统在IRP被取消时[后]调用。

l指向当前的子请求的参数

另外，除了这些指针，IRP头部还包含有其它数据，用来描述请求的状态和其它内在信息(微软未开放的信息)。

IRP参数组：

在IRP头部之后是子请求数组。一个IRP可以有不只一个子请求，这是由于IRP通常会是被由多个[一些]驱动程序组成的栈来操作。每一个IRP都被分配了一个固定数量的，这样的子请求，通常是对应于设备栈中的每一个驱动程序有一个。这个编号恰好与相应栈最顶端设备的StackSize相匹配[一致]，虽然在栈中间的驱动其实可以被分配的小一点。还有，如果一个驱动程序需要把请求发送到一个不同的设备栈处理，这个驱动程序就必须重新分配[创建]一个新的IRP。

每一个子请求都表示一个对应的I/O栈的位置(一个类型为IO_STACK_LOCATION的结构)，并且特定的IRP通常[典型的]为每一个其被发送到的目的设备栈上的每个驱动仅维持[包含]一个这样的栈位置信息。在IRP头部的一个域中还包含有标识当前正在被使用的I/O栈位置信息。这个域的值被称作IRP栈指针(IRP stack pointer)或者当前栈位置(current stack

location)。

对于特定的IO_STACK_LOCA TION结构，会包含有以下内容：

l对于特定IRP的主要以及次要的方法代码

l针对这些代码的参数

l一个指向相应驱动的设备对象（device object）的指针

l一个指向IoCompletion例程的指针，如果驱动有过设定

l一个指向和这一请求相关联的文件对象的指针

l一些可变标志以及上下文[关联]区域

特定的IO_STACK_LOCATION结构并不包含有指针标识[指向]输入和输出位置，这些（输入、输出）指针本身就由IRP自身所包含。所有的子请求操作都使用同一缓冲区进行。

第二重定义：IRP作为一个线程无关的调用栈

进行一个设备的I/O操作通常[典型的]需要调用这一设备相关的不止一个驱动。每一个和这一设备相关的驱动都会创建一个设备对象(device object)，并且这些设备对象会垂直压入（排列进）一个设备栈(device stack)中。IRP会在设备栈中从上到下的一个个被传递过去（进去）。对于栈中的每一个驱动，IRP都会用（包含）一个指针标识一个栈位置。由于驱动可以异步的处理请求，因此IRP就像是一个线程无关的调用栈一样，就像表二中所表示的：

表二：IRP作为线程无关的调用栈

在表二中，左侧，线程栈表示了驱动程序A,B和C的参数和返回值地址是如何在调用栈(call stack)中被组织的；而右侧，图表展示了这些参数和返回值地址是如何在一个IRP中对应到I/O栈位置以及IoCompletion例程上的。

IRP操作所具有的异步特质对于操作系统和Windows驱动模型(WDM, Windows Driver Model)是非常关键的。在一个同步的，单线程的I/O结构设计中，发送了请求的应用程序以及传递请求的驱动程序都要在更低层的组件完成请求任务之前处于等待中。这样的设计对于运用系统资源是很没有效率的，会降低整个系统的性能。

IRP的结构提供了一种可被继承的异步方式的设计，使得应用程序能够将一个或多个I/O请求排入队列，而不必等待。在I/O请求被处理的过程中，这个应用程序被解放出来可以进行其他的计算，或者向队列里排入更多的I/O请求。由于所有被用来处理请求的信息都被以IRP 的形式封装起来了，所以请求线程的调用栈可以从I/O请求中分离出去。

将IRP传递到下一级的驱动程序

将IRP传递到下一级驱动程序(又被称作为转发IRP)是指IRP等价于一个子例程调用。当驱动转发一个IRP，它（驱动程序）必须向IRP参数组增加下一个I/O栈位置，告知这一IRP 栈的指针，然后调用下一驱动的分发例程(dispatch routine)。基本说来，就是驱动向下调用IRP栈(calling down the IRP stack)。

传递一个IRP，驱动通常(典型的)会采取以下几个步骤：

1.建立下一个I/O栈位置的参数。驱动程序可以采取：

l调用IoGetNextIrpStackLocation例程来得到一个指针指向下一个I/O栈位置，然后将请求参数组复制到那个得到的位置。

l调用IoCopyCurrentIrpStackLocationToNext例程（如果驱动按第二步设置了IoCompletion例程），或者IoSkioCurrentIrpStackLocation例程(如果没有在第二

步设置IoCompletion例程)来传递当前位置所使用的同样的参数组。

注意：驱动程序不能够使用RtlCopyMemory例程来复制当前的参数组。这个

例程把指针复制到当前驱动的IoCompletion例程，而且这样会导致

IoCompletion例程被调用不止一次（重入？）。

2.如果需要的话，调用IoSetCompletionRoutine例程，为后期处理(post-porcessing)设

置一个IoCompletion例程。如果驱动设置了IpCompletion例程，那么他在上一步（第一步）中必须使用IoCopyCurrentIrpStackLocationToNext。

3.通过调用IoCallDriver例程将请求传递到下一个驱动。这个例程会自动通告IRP栈

指针，并且调用下一个驱动的分发例程。

在驱动程序将IRP传递个下一个驱动之后，就不再拥有这个IRP，并且不能试图再去访问这个它。否则会导致系统崩溃。那个IRP会被其它的驱动或者线程释放或完成。如果驱动需要访问一个已经在栈里传下去的IRP，这个驱动必须实现(设置)IoCompletion例程。当I/O 管理器(I/O Manager)调用IoCompletion例程时，这个驱动就能够在IoCompletion例程执行期间重新获得对这一IRP的所有权。如此，IoCompletion例程就能够访问IRP中的域。

若是驱动的分发例程也还须在IRP被后面的驱动处理完成之后再处理它，这个IoCompletion 例程必须返回STA TUS_MORE_PROCESSING_REQUIRED，以将IRP的所有权返回给分发例程。如此一来，I/O管理器会停止IRP的处理，将最终完成IRP的任务留给分发例程。分发例程能够在之后调用ICompleteRequest来完成这个IRP，或者还能将这个IRP标记为等候进一步处理。

完成（齐整）一个IRP

当输入、输出操作（I/O）完成时，完成这个I/O操作的驱动会调用IoCompleteRequest例程。这个例程将IRP栈指针移到指向IRP栈中的前一个（更上面）的位置，如表三所示。

表三：IRP的完成过程及栈指针

表三表示出了在驱动C调用IoCompleteRequest后的当前栈位置。左侧的实线箭头表示出栈指针现在指向了驱动B的参数组和回调函数。点虚线箭头表示出前一个栈位置。右侧的中空箭头表示出IoCompletion例程被调用的顺序。

注意：为了解释上的方便，本文把IRP中I/O栈位置的顺序表示成“倒置”的，就是说，是从A到C的反向顺序，而不是从C到A。用这样的倒置图表是为了更直观用“向下”将调用在栈中沿向下的方向进行表现出来。

如果一个驱动在设备栈中向下传递IRP时设定了IoCompletion例程，I/O管理器就会在IRP 栈指针再次指向这一驱动的这个I/O栈位置时调用此例程。如此一来，IoCompletion例程就表现成为，当IRP在设备栈中传递时，操作IRP的那些驱动的返回地址。

一个IoCompletion例程能够返回两个状态值中的任一个：

l STATUS_CONTINUE_COMPLETION – 继续向上完成特定IRP。I/O管理器提升IRP栈指针，并且调用上一个驱动的IoCompletion例程。

l STATUS_MORE_PROCESSING_REQUIRED – 中断向上完成特定IRP的过程，并且把IRP栈指针留在当前位置。返回这一状态的驱动通常会在过后调用

IoCompleteRequest例程来重新开始向上完成特定IRP的过程。

当每一个驱动都完成了它对应的子请求，I/O请求就完成了。I/O管理器从Irp->IoStatus.Status 域取回请求的状态信息，并且从Irp->https://www.360docs.net/doc/a212877556.html,rmation域取回传输的字节数。

同步（化）I/O响应

虽然Windows操作系统是为异步I/O设计的，大多数应用程序还是发送同步I/O请求。驱动程序也能够即发送同步又发送异步请求，同时也能响应不论是同步还是异步请求。

要判断一个请求是异步完成的还是同步的，驱动需要检查由IoCallDriver返回的状态，如下面的例程序所示：

KEVENT event;

KeInitializeEvent(&event, NotificationEvent, FALSE);

IoCopyCurrentIrpStackLocationToNext(Irp);

IoSetCompletionRoutine(Irp,

CatchIrpRoutine,

&event,

TRUE,

TRUE,

TRUE

);

status = IoCallDriver(DeviceObject, Irp);

//

// Check for synchronous or asynchronous completion.

//

if (status == STATUS_PENDING) {

// Code to handle asynchronous response

// omitted for now.

}

return status;

驱动程序初始化一个事件，设置I/O栈位置，设置一个IoCompletion例程，再调用IoCallDriver 去转发IRP。由IoCallDriver返回来的状态标示了后面（底下）的驱动是否在同步操作这个IRP，还是异步的。如果请求是被异步方式操作的，IoCallDriver返回STA TUS_PENDING。如果后面的驱动以同步方式响应，IoCallDriver会返回一个由更后面（下面）一驱动返回的完成状态信息。如同例程序所示，驱动只是简单的返回同一个完成状态。

当一个IRP被同步的完成，则驱动由它的分发例程返回这个IRP的完成状态。在它上面的那些驱动可以通过下列两种方法得到这个状态：

l在分发例程中，由IoCallDriver返回的值获得。

l在IoCompletion例程中，由IRP的IoStatus.Status域获得。

当I/O管理器调用某个驱动的IoCompletion例程，这个驱动就拥有了相应（特定）的IRP，从而能够访问到IoStatus.Status域。如果驱动没有设置IoCompletion例程，它就不会在调用IoCallDriver后拥有相应的IRP，因此决不能访问IRP中的域。

表四展现了驱动程序或者应用程序能够获得IRP状态的两种方法。为了解释的方便，表中将那些IoCompletion例程以及他们所调用（被调用？）的参数组放在了同一个I/O栈位置，而不是一个跟低的位置。

Status=IoCallDriver(?;Status=Irp->IoStatus.Status;

表四：由IoCallDriver例程返回的状态，以及对IoCompletion例程的可用性

在表四的左侧，IoCallDriver例程返回了由后面（下面？）一个驱动报告上来的完成状态。在右侧，IoCompletion例程由IRP的IoStatus.Status域读出那个状态。若是IRP以同步方式完成，每一个驱动的IoCompletion例程都会在IoCallDriver之前返回，从而使得IoCompletion 例程比分发例程更早得到状态的值。

表四所示驱动C返回ST ATUS_SUCCESS，驱动B返回STATUS_RETRY，而驱动A返回STATUS_ERROR。那个IRP的最终状态只能够由初始的请求发出者得到，其他的驱动只能够读到由后面一个驱动返回的状态。

异步（化）IO响应

驱动程序应该在当它无法以一个时间区间(Timely manner)以同步方式完成一个IO请求时，由分发例程返回ST ATUS_PENDING状态。理解何时该返回ST ATUS_PENDING对很多驱动开发者都是一个问题。

一个驱动程序，因该在以下的情况返回ST ATUS_PENDING：

l当它的分发例程有可能会在一个IRP被完成以前就返回

l它会在另外一个线程中完成特定的IRP

l它的分发线程在返回之前无法判断某个IRP是否完成

这个驱动程序必须在它释放对特定IRP的控制，以及在它返回ST ATUS_PENDING之前，调用IoMarkIrpPending宏。IoMarkIrpPending会在当前的IO栈位置的Control域，置

SL_PENDING_RETURNED位(bit)。每当一个IO栈位置被完成，IO管理器都会将此位的值复制给特定IRP头部的Irp->PendingReturned域，如表五所示：

表五：准备待处理（Pending）位

在表五中，驱动C对IoMarkIrpPending宏的调用将驱动C的IO栈位置中的Control域上的SL_PENDING_RETURNED置位。当驱动C完成了对特定IRP的处理，IO管理器就改变IRP 栈指针使之指向驱动B，并且复制（propagates）SL_PENDING_RETURNED位的值给IRP 头部的PendingReturned域。

IoCompletion例程与异步IO响应

如果一个驱动为某个IRP设置了IoCompletion例程，这个IoCompletion例程就能够通过检查Irp->PendingReturned域来判断这个IRP是否要被异步完成。

若Irp->PendingReturned域的值为TRUE，这个IoCompletion例程就将（或者已经）返回STATUS_PENDING。如果Irp->PendingReturned域的值为FALSE，IoCallDriver此刻已经以Irp->IoStatus.Status域上的值返回了。中间驱动的IoCompletion例程能够仅仅简单地通过测试Irp->PendingReturned就判断出有他们转发的请求的结果是如何被操作的。

那些以异步方式完成IO请求的驱动，有时还必需要在IRP从设备栈中向上移回时再进行一些附加的处理。下面的代码在它向下层驱动转发一个IRP时设置了一个IoCompletion例程，然后等待一个事件（event）。如此一来，它就以和同步相同的方式（manner）来处理异步响应：

KEVENT event;

KeInitializeEvent(&event, NotificationEvent, FALSE);

IoCopyCurrentIrpStackLocationToNext(Irp);

IoSetCompletionRoutine(Irp,

CatchIrpRoutine,

&event,

TRUE,

TRUE,

TRUE

);

status = IoCallDriver(DeviceObject, Irp);

//

// Wait for lower drivers to be done with the Irp.

// It’s important to note here that when you allocate

// memory for an event on the stack you must do a

// KernelMode wait instead of UserMode to prevent

// the stack from being paged out.

//

if (status == STATUS_PENDING) {

status = KeWaitForSingleObject(&event,

Executive,

KernelMode,

FALSE,

NULL

);

ASSERT(NT_SUCCESS(status));

status = Irp->IoStatus.Status;

}

return status;

在这种情况下，驱动等待一个由它的IoCompletion例程所设值的事件。由于事件是被分配到堆栈空间的，所以这个驱动必须在内核模式中等待。出于性能的考虑，驱动只有在IRP 异步完成时才需要等候事件(events)的到达。特定的KeWaitForSingleObject例程使用系统范围的分配锁（dispatcher lock）。这个锁保护了事件的信号状态（signal state）、信号（semaphores）、以及互斥体（mutexes），从而在操作系统中被频繁和广泛的用到。如果要求每个同步的IO操作也使用这个锁，将会导致对性能无法容忍的干扰。

下面的代码表示了程序片段上IoCompletion例程的设置：

NTSTATUS

CatchIrpRoutine(

IN PDEVICE_OBJECT DeviceObject,

IN PIRP Irp,

IN PKEVENT Event

)

{

if (IrpàPendingReturned) {

// Release waiting thread

KeSetEvent( Event, IO_NO_INCREMENT, FALSE );

}

return STATUS_MORE_PROCESSING_REQUIRED;

}

IoCompletion例程测试Irp->PendingReturened域的值。它基于这个值，仅当

STATUS_PENDING已经或将要被返回给调用者的时候，设置一个事件。这样就避免一次对会使用系统范围的分发者锁（dispatcher lock）的KeSetEvent例程调用。

这个IoCompletion例程会返回STATUS_MORE_PROCESSING_REQUIRED。这一状态告知（指示）IO管理器，当前的驱动当获得IRP时还需进行额外的操作。IO管理器会停止IRP 向上完成（upward completion）的过程，将IO栈位置就留在当前位置。当前的驱动就仍然拥有这个IRP，并且能够继续在其它例程中处理它。

IRP的所有权（Ownership）非常重要，因为它判定（determine）特定的驱动是否能够访问这个IRP。一旦驱动放弃了对特定IRP的所有权，这个IRP就可以由其他的线程完成或者释放，而这个驱动之后任何企图对这一IRP进行的访问都能够导致系统崩溃。

传播（Propagating）待处理位

任何时候当一个驱动处理一个由下一层驱动（next-lower driver）返回的IO请求，在它的IO 栈位置上的待处理位（IO_STACK_LOCATION结构中Control域上的

SL_PENDING_RETURNED）的值都必须和那个下一层驱动保持一致。如果某个驱动没有设置IoCompletion例程，IO管理器就会自动的传播那一位的值，而不需要驱动再负责此事了。然而，一旦驱动设置了一个IoCompletion例程，并且下一层的驱动返回了

STATUS_PENDING，当前的驱动就必须把自己的IO栈位置标为待处理（pending），例如：// Forward request to next driver

IoCopyCurrentIrpStackLocationToNext( Irp );

// Send the IRP down

status = IoCallDriver( nextDevice, Irp );

// Return the lower driver’s status

return status;

由于这个例子里没有设置IoCompletion例程，驱动程序必须避免调用IoMarkIrpPending宏。驱动只是简单的返回与下一层的驱动的返回一致的状态，由IO管理器复制待处理位的值。

然而，一旦驱动设置了一个IoCompletion例程，这个代码就不足以处理下一级驱动返回STATUS_PENDING的情况了。在这种情况下，驱动必须调用IoMarkIrpPending宏来为自己的IO栈位置上的SL_PENDING_RETURNED置位；驱动不能够在分发例程上调用这个宏。因此，下面的代码是不正确的：

// Forward request to next driver

IoCopyCurrentIrpStackLocationToNext( Irp );

// Send the IRP down

status = IoCallDriver( nextDevice, Irp );

// The following is an error because this driver

// no longer owns the IRP.

If (status == STATUS_PENDING) {

IoMarkIrpPending( Irp );

}

// Return the lower driver’s status

return status;

这里由于IoMarkIrpPending操作在当前的IO栈位置上进行，所以这样的处理是不正确的。当IoCallDriver将某个IRP传递到下一级驱动之后，当前的驱动此刻已经不再拥有这个IRP 了。如此一来，当对IoMarkIrpPending被调用时，就已经没有“当前IO栈位置”了；实际

上，如果下级驱动完成了IRP，那么这个指针就不再合法了。为了避免这样的问题，这个驱动必须从IoCompletion例程中调用IoMarkIrpPending。例如：

NTSTATUS

CompletionRoutine( ... )

{

if (IrpàPendingReturned) {

// Return the lower driver’s result. If the

// lower driver marked its stack location pending,

// so do we.

IoMarkIrpPending( Irp );

}

… //additional processing in IoCompletion routine

return STATUS_CONTINUE_COMPLETION;

}

驱动应该仅在返回和下级驱动一致的状态时使用这样的代码序列（code sequence）。如果驱动程序没有设置IoCompletion例程，IO管理器会自动向上级IO栈位置传递

SL_PENDING_RETURNED标志位的值。驱动程序并不必仅仅为了调用IoMarkIrpPending

而设置IoCompletion例程；然而一旦驱动程序确实有IoCompletion例程，并且下级驱动会返回STA TUS_PENDING，在IoCompletion例程中就必须要调用IoMarkIrpPending。

关于待处理IRP（Pending IRPs）的指导（Guidelines）的总结

当驱动作者处理会返回STA TUS_PENDING的IRP时，必须遵从特定的指导（guidelines）。忽略这些指导可能会导致后期处理（post-processing）的重复（双重）发生，造成系统崩溃；或者阻止了后期处理的发成，造成系统死锁。

以下是对于返回ST ATUS_PENDING的基础指导：

l如果一个驱动返回ST ATUS_PENDING，它必须首先调用IoMarkIrpPending宏来把特定的IO栈位置标记为待处理（pending）

l反而言之，如果一个驱动调用了IoMarkIrpPending，它就必须返回

STATUS_PENDING。

另外：

l如果一个驱动设置了IoCompletion例程，并且返回和下级驱动一致的状态，这个IoCompletion例程就必须在Irp->PendingReturned域的值为真（TRUE）时调用

IoMarkIrpPending。

l如果一个IO请求在一个驱动接收到它的线程之外的其他线程上完成，这个驱动的分发例程或者IoCompletion例程必须调用IoMarkIrpPending，并且分发例程必须返

回STATUS_PENDING。

优化

一个驱动可以通过对Irp->PendingReturned域上值进行测试，来从待处理标志位上获得优化对IO请求的后期处理的益处。例如，驱动可以有效的使用处理器的高速缓存，从而通过在

IoCallDriver例程返回一个同步的回复之后的IRP的后期处理来提高吞吐量。进行这样的优化的逻辑遵从：

l在一个同步IO请求中，发起特定IO请求的进程能够在IoCallDriver不返回STATUS_PENDING的情况下进行后期操作。在这样的情况下，这个IRP在

IoCallDriver返回时被完成，从而使得分发例程能够进行任何需要的操作。

l在一个异步IO请求中，如果IoCallDriver返回STATUS_PENDING，就需要由IoCompletion例程来进行后期处理。这个IoCompletion例程必须如本文前面

“IoCompletion例程与异步IO响应”说描述的，测试Irp->PendingReturned的值。

如果Irp->PendingReturned的值为真（TRUE），IoCompletion例程就进行需要的后

期处理。

操作系统正是使用这样的技术来处理读请求、写请求以及一些IO控制代码（IOCTRLs）。因此，如果驱动没有遵从本文前面的“关于待处理IRP（Pending IRPs）的指导（Guidelines）的总结”，操作系统就会重复（双重，twice）进行后期处理，或者根本不处理。

一个文件对象的生命周期

每当一个设备被打开，一个文件对象就被建立了。每一个文件对象都体现了对一个独立文件的单重使用，并且维护当次使用的的状态信息（如当前的文件偏移）。当IO管理器创建并打开一个文件对象，它同时创建一个指向（refer）这一对象的句柄。IRP_MJ_CREA TE、IRP_MJ_CLEANUP以及IRP_MJ_CLOSE请求定义了一个文件对象的生命周期。

IRP_MJ_CREATE请求：

一个IRP_MJ_CREA TE请求告知特定的驱动：一个新的文件对象被创建出来了。IO管理器典型的做法（通常）是在用户模式的应用程序调用CreateFile函数或者内核模式驱动调用ZwCreateFile例程时发送出一个IRP_MJ_CREA TE请求。

在一个IRP_MJ_CREA TE请求中，当前IO栈位置包含了一个FileObject结构，用以标示（identify）要被打开的文件对象。这个FileObject结构列明了：

l要打开的文件的名称，在FileObject->FileName域

l两个提供给驱动程序使用的指针，在FileObject->FsContext以及

FileObject->FsContext2域。

注意：在一个WDM设备栈中，只有功能设备对象才能够使用上述两个上下文（context）指针。文件系统驱动使用特别的函数来在多个驱动中共享这些域。

IRP_MJ_CREA TE请求到达特定线程的上下文并且对它进行了处理，就打开或者创建了特定的文件。驱动能够在需要时记录下每个调用者的信息（per-caller information）。

在响应一个创建请求时，操作系统会依下面的描述检查相应的访问权限：

l如果请求没有包含文件名称，操作系统依照ACL检查通过名称打开的设备对象的权限。

l如果请求包含有文件名称，则操作系统仅在DeviceObject->Characteristics域中的FILE_DEVICE_SECURE_OPEN特性（characteristic）被设置时检查安全性。否则，

就由驱动程序负责对安全性的检查。

一旦请求成功，操作系统就将得到的权限保存在对象句柄中供后续的IO请求使用。关于驱动安全性的具体信息，参见WDK文档。

IRP_MJ_CLEANUP请求

一个IRP_MJ_CLEANUP请求通告驱动程序：一个文件对象的上个（last）的句柄被关闭了。这一请求并不表示那个文件对象已经被删除了。

IO管理器在一个文件对象的最近一个句柄被关闭后为之发送一个IRP_MJ_CLEANUP请求。当一个驱动收到一个IRP_MJ_CLEANUP请求，这个驱动就必须完成这一特定文件的所有待处理的IRP。当这些IRP被完成之时，IO管理器就将文件对象销毁。当这些IRP还在等待处理时，IO管理器是不能删除那个对象的。

IRP_MJ_CLEANUP请求到达调用者（caller）的上下文，以尝试关闭最近的句柄。一旦驱动在IRP_MJ_CLEANUP请求到达时记录着（了）任何关于调用者的信息，它就应该在处理IRP_MJ_CLEANUP请求时将这些信息释放。然而，如果文件句柄被复制了，

IRP_MJ_CLEANUP请求的上下文就有可能不再和相应的IRP_MJ_CREA TE请求相一致。因此，驱动的作者必须在进行清理（cleanup）造作中使用到处理信息（process information）时小心的判定合适的上下文。

例如，一个应用程序能够调用DuplicateHandle()函数来将文件句柄复制到另一个进程中。如果这个新的句柄最近被关闭，而且是在原进程中所有的句柄之后，驱动程序就会收到一个在新进程上下文中的句柄上传来的IRP_MJ_CLEANUP请求。这个上下问依然代表了调用者，但已经不是同一个创建文件对象的原调用者了。

IRP_MJ_CLOSE请求

一个IRP_MJ_CLOSE请求通告驱动程序：一个文件对象被删除了。

IO管理器在以下两种情况都为真时，为相应的文件对象发送IRP_MJ_CLOSE请求：l文件对象所有的句柄都被关闭了

l没有显著的联系（参考，reference）指向这一对象，例如由遗留的待处的IRP产生的

与IRP_MJ_CREA TE和IRP_MJ_CLEANUP请求所不同，一个IRP_MJ_CLOSE请求并不是随着调用者的上下文到达。

在对IRP_MJ_CLOSE请求的响应中，驱动程序需要进行所有在响应相对应的

IRP_MJ_CREA TE请求时的动作的逆操作（reverse）。附加的任务就要看驱动的设计和它所支持的硬件类型了。

数据传输的机制

Windows操作系统家族支持三种数据传输机制：

l缓存IO（Buffered I/O）在内核模式上操作对用户数据的拷贝

l直接IO（Direct I/O）通过内存描述元列表（MDL, M emory D escriptor L ist）以及内核模式的指针直接访问用户数据

l非上述方法IO（Method neither I/O，既非缓存，也非直接IO）通过用户模式的指针访问用户数据

对于标准的IO请求，例如IRP_MJ_READ和IRP_MJ_WRITE，由驱动在设备刚创建后，马上通过修改DeviceObject->Flags域的值来指定支持那一种传输机制。

缓存IO

为了以缓存IO的方式接收读、写的请求，驱动会在初始化时在DeviceObject->Flags域上设置DO_BUFFERED_IO

．．．．．．．．．．．．．．标志。当驱动收到了一个缓存IO的请求，在特定的

Irp->AssociatedIrp.SystemBuffer域中会放有驱动应该操作的内核模式缓冲区的地址。IO．．管理

．．器．在进行读请求时将数据由内核模式缓冲区拷贝到用户模式缓冲区，或者在进行写请求时从用户模式缓冲区向内核模式缓冲区拷贝数据。

直接IO

为了以直接IO的方式接收读、写请求，驱动会在初始化时在DeviceObject->Flags域上设置

DO_DIRECT_IO

．．．．．．．．．．．．标志。当驱动接收到一个直接IO请求，特定的Irp->MdlAddress域中会放有一个用来描述请求缓冲区的MDL的地址。这个MDL列出了缓冲区的虚拟地址和尺寸，连同相应缓冲区中的物理页表（physical pages）。IO管理器会在将请求发送给驱动之前锁定这些物理页，并在（请求）完成的过程中解锁。驱动千万不能使用MDL中列举的用户模式缓冲区地址，而必须通过调用MmGetSystemAddressForMdlSafe宏来得到一个内核模式的地址。

非缓存非直接IO

为了接收非缓存非直接IO的方式的请求，驱动初始化时在DeviceObject->Flags域上既不设置DO_BUFFERED_IO标志，也不设置DO_DIRECT_IO标志。当驱动接收到这样的请求，相应的Irp->UserBuffer域会放有附属于这个请求的数据地址。因为这个缓冲区在用户地址空间上，驱动程序必须在用之前使相应的地址合法化。驱动程序在try/except块里调用ProbeForRead或者ProbeForWrite函数来合法化特定的指针。驱动还必须完全在try/except 块里处理所有对这一缓冲区的访问。

另外，驱动还必须在应用（manipulating）数据之前将它拷贝到池（the pool）或堆栈里一个安全的内核模式地址。将数据拷贝到内核模式缓冲区确保了用户模式的调用者不会在驱动已

经合法化数据之后再修改它。

注意：关于探测（probing）和驱动IO路径中常见错误的信息，请参阅白皮书“Common Driver Reliability Issues”

输入、输出控制码（IOCTLs, I/O Control Codes）

IO管理器将一个IO控制码（IOCTL）作为IRP的部分将请求发送出去，而不同于读、写的请求。一个IOCTL是一个32位的控制码，用来标识一个IO或设备操作。对那些特定IOCTL 的请会同时有输入和输出的缓冲区。

操作系统支持两种类型的IOCTL，它们被放在两样不同的IRP中发送：

l IRP_MJ_DEVICE_CONTROL请求，能够被从用户模式或者内核模式发出。这些请求有时候被称作公共IOCTL（public IOCTLs）

l IRP_MJ_INTERNAL_DEVICE_CONTROL请求，只能够由内核模式的组件发出。

这些请求典型的用途是驱动到驱动的通讯，有时被称作私有IOCTL（private

IOCTLs）

对于一个IOCTL，传输机制是在控制码的Method域指定的。IOCTL支持以下的传输机制：l METHOD_BUFFERED

l METHOD_OUT_DIRECT

l METHOD_IN_DIRECT

l METHOD_NEITHER

METHOD_BUFFERED IOCTLs

在一个METHOD_BUFFERED IOCTL中，如同一个缓存类型的读或者写请求，数据传输是通过对Irp->AssociatedIrp.SystemBuffer域上传递的用户缓冲区的一个副本（拷贝）进行的。输入及输出缓冲区的长度，由Parameters.DeviceIoControl.InputBufferLength域和Parameters.DeviceIoControl.OutputBufferLength域传递给驱动的IO_STACK_LOCATION结构。这些值体现了驱动在相应对应的IOCTL时所允许（应该）读取或写入的最大字节数。

应为缓冲区指针是被确保合法并被排列（aligned）在处理器正常（natural）边界范围内，加之缓冲区中的数据是不能改变的，所以说METHOD_BUFFERED IOCTL是最为安全的IOCTL。

IO管理器并不会在发出请求前对输出缓冲区做清零初始化。驱动程序要负责，以其在

Irp->https://www.360docs.net/doc/a212877556.html,rmation域中指定的返回字节技术为上限，向输出缓冲区写入合法的数据或清零。如果不能正确写入合法数据或清零会导致将内核模式的私有数据返回给用户模式的应用程序。由于这一数据有可能属于另外的用户，这样的错误被认为是对系统安全性的破坏。

METHOD_OUT_DIRECT IOCTLs

一个指定了METHOD_OUT_DIRECT或者MTHOD_DIRECT_FROM_HARDWARE的IOCTL体现了一个对硬件发出的读操作。METHOD_OUT_DIRECT和

MTHOD_DIRECT_FROM_HARDWARE是可以互换的（interchangeably）。

在METHOD_OUT_DIRECT请求中，Irp->AssociatedIrp.SystemBuffer域容纳了一个请求发出者的输入缓冲区的内核模式拷贝。Irp->MdlAddress域放着一个MDL用来描述请求者的输出缓冲区。IO管理器读取这个缓冲区给驱动去写。在读和写的操作中，驱动程序必须调用MmGetSystemAddrssForMdlSafe宏来得到MDL所描述的缓冲区的内核指针。

请求者的输入缓冲区通常包含有一个指针指向一个应该由驱动发送或转译给硬件设备的命令。请求者的输出缓冲区通常是一个应该用于驱动传输操作结果的位置。

METHOD_IN_DIRECT IOCTLs

一个指定了MTHOD_IN_DIRECT或者METHOD_DIRECT_TO_HARDWARE的IOCTL请求了一个对硬件的写操作。MTHOD_IN_DIRECT和METHOD_DIRECT_TO_HARDWARE 的IOCTL也是可以互换的。

在METHOD_IN_DIRECT请求中，Irp->AssociatedIrp.SystemBuffer域容纳了一个请求者的输入（？？？原文如此）缓冲区的内核模式拷贝。Irp->MdlAddress域放着一个MDL用来描述请求者的输出缓冲区。IO管理器读取这个缓冲区给驱动去读。在读和写的操作中，驱动程序必须调用MmGetSystemAddrssForMdlSafe宏来得到MDL所描述的缓冲区的内核指针。

输入和输出缓冲区对METHOD_OUT_DIRECT和METHOD_IN_DIRECT IOCTL通常的使用是相似的方法。请求者的输入缓冲区包含一条给驱动或设备的命令。请求者的输出缓冲区包含有要驱动传输给设备的数据。本质上，它其实是第二个输入缓冲区。

METHOD_NEITHER IOCTLs

驱动可以定义IOCTL使用既非直接（direct）也非缓冲（buffered）的输入输出方式。METHOD_NEITHER IOCTL拥有分离的用户模式指针提供给输入及输出缓冲区：l IrpSp->Parameters.DeviceIoControl.Type3InputBuffer指向相应输入缓冲区

l Irp->UserBuffer指向相应输出缓冲区

相应的输入和输出缓冲区的地址是用户模式指针。因此，驱动必须在使用它们之前，通过在try/except块中调用ProbeForRead以及ProbeForWrite例程来合法化这些指针。另外，驱动还必须在合法化操作之前将所有的参数复制到内核模式的内存中（可以是池或者栈）。

注意：关于探测（probing）和驱动IO路径中常见错误的信息，请参阅白皮书“Common Driver Reliability Issues”

IRP完成的成功（Success），出错（Error）和警告（Warning）状态

当一个驱动以成功或警告状态完成了一个IRP，IO管理器会：

l如果IRP指定了METHOD_BUFFERED IO，就将数据从IRP中指出的缓冲区拷贝回用户缓冲区。驱动在Irp->IoStatusInformation域中指出要拷贝的字节数。

l将结果从IRP的状态块，Irp->IoStatus.Status以及Irp->https://www.360docs.net/doc/a212877556.html,rmation，拷贝到调用者的原始请求块中。

l发出由调用者在初始化请求是指定的事件信号。

并非所有这些动作在各种情况下都会发生。例如，如果一个驱动以错误的状态完成了一个IRP，IO管理器就不会向用户缓冲区复制任何数据，并且仅仅拷贝Irp->IoStatus.Status域的值，而不拷贝https://www.360docs.net/doc/a212877556.html,rmation域的值。如果一个驱动同步完成了一个IRP，IO管理器不会发送事件信号。如果驱动异步完成一个IRP，IO管理器则可能会也可能不会发送事件信号。因此，一个调用ZwReadFile、ZwDeviceIoControl或者类似ZwXxx例程的驱动仅当相应的ZwXxx例程返回ST ATUS_PENDING时才应该等待事件信号。

下列值指示了错误和警告的状态码范围：

l NTSTA TUS代码0xC0000000 到0xFFFFFFFF是错误

l NTSTA TUS代码0x80000000 到0xBFFFFFFF是警告

如果Irp->IoStatus.Status域上的值是一个错误代码，操作系统就不返回任何数据，从而

Irp->https://www.360docs.net/doc/a212877556.html,rmation域应该总是为零。如果Irp->IoStatus.Status域上的值是一个警告代码，操作系统能够返回数据，从而Irp->https://www.360docs.net/doc/a212877556.html,rmation域上的内容可以是非零。

一个简单的想定可以帮助我们解释这个情况。假设一IRP请求某个驱动返回由下列两个域所定义出的缓冲区里的数据：

ULONG Length;

UCHAR Data []; // 可变长度数组

其中Length域指定了需要得到数据的尺寸。应用程序发送一个ULONG请求以得到相应的Length，接着发送一个“第二”（second）请求伴随一个大一点儿的缓冲区，已接受所有的数据。驱动，轮流着，总是预期缓冲区的至少是一个ULONG数据的尺寸。

如果缓冲区足够大，驱动会以ST ATUS_SUCCESS完成相应的IRP，并且由Length以及

Irp->https://www.360docs.net/doc/a212877556.html,rmation接收被传输的字节数。

如果缓冲区不足以保存那些数据，驱动会以警告ST ATUS_BUFFER_OVERFLOW完成IRP。在这种情况下，数据对于缓冲区来说就太大了。驱动会用需要的尺寸更新相应的Length并且将sizeof(ULONG)写入Irp->https://www.360docs.net/doc/a212877556.html,rmation。

如果缓冲区太小而无法写入需要的长度（就是说，缓冲区比sizeof(ULONG)还要小），这个驱动就会以ST ATUS_BUFFER_TOO_SMALL的错误完成IRP，并且将

Irp->https://www.360docs.net/doc/a212877556.html,rmation设置为0.

创建IRP

驱动程序可以建立两种类型的IRP：

l线性（线程化？）IRP，也称作同步请求。

l非线性（非线程化？）IRP，也称作异步请求。

线性化的IRP

线性IRP在被创建时，被绑定在执行体的当前线程上。当相应的线程终止，所有与之关联的线性IRP既自动被取消了。

驱动通过调用下述例程之一来建立线性IRP：

l IoBuildSynchronousFsdRequest

l IoBuildDeviceIoControlRequest

IoBuildSynchronousFsdRequest为读、写请求分配并建立起一个线性IRP。IoBuildDeviceIoControlRequest分配并建立起一个线性IRP以发送一个IOCTL。

当创建一个线性IRP时，驱动指明一个事件作为这个IRP完成时的信号，并且提供指向用以返回被请求数据的缓冲区的指针。当IRP中每一个的子请求都被完成时（就是说，当所有被请求的驱动都将相应的IRP完成了），整个请求就被完成了。这时，IO管理器就接着进行下述的后期处理：

l将内核模式中的数据拷贝到要被返回给调用者的缓冲区中。例如，ZwReadFile，IoBuildDeviceIoControlRequest，和类似的系统支持的例程会传递用户模式缓冲区。

l如果响应是异步的，则发送事件信号。一旦IoCallDriver例程返回了

STATUS_PENDING，相应的调用者就应该等待特定的事件（信号）。

l如果响应是异步的，则将Irp->IoStatus.Status域上的值复制给相应用户IO状态块的Irp->Userlosb.Status域。如果IoCallDriver返回STATUS_PENDING，调用者能

够在特定事件被以信号形式发出后读取这个域。

l如果相应是异步的，并且IO请求得以成功，则复制Irp->https://www.360docs.net/doc/a212877556.html,rmation域上的值给用户状态块中的Irp->https://www.360docs.net/doc/a212877556.html,rmation域。同样，如果IoCallDriver返回

了STATUS_PENDING，调用者能够在特定事件被以信号形式发出后读取这个域。

如果特定的请求返回一个错误的状态，IO管理器不会传输任何数据到用户缓冲区，则调用者应该将Irp->https://www.360docs.net/doc/a212877556.html,rmation的值当作零对待；有些驱动作者可能宁

愿零初始化（zero-initialize）这个域作为一个附加的防范措施。

l释放IRP

未线性化的IRP

未线性化IRP不和任何线程关联。初始化一个未线性化IRP的驱动程序必须设定一个完成例程来在相应IRP完成时“捕捉”它。IO管理器不会释放未线性化的IRP；初始化这个IRP 的驱动必须负责释放它。未线性化的IRP是为了驱动与驱动之间相互通讯而设计的。

驱动通过调用下列进程之一来创建未线性化IRP：

l IoBuildAsynchronousFsdRequest

l IoAllocateIrp

IoBuildAsynchronousFsdRequest为读或写请求分配并创建一个未线性化IRP。IoAllocateIrp

为驱动分配一个IRP用以发送到同一设备栈的下层驱动或者其他的设备栈中。

IRP的取消

IRP可以被取消（有时也被描述为“召回（recalled）”）。一旦某个IRP被取消了，当前拥有这个IRP的驱动必须立即完成它。

驱动要求特殊的处理以取消一个IRP必须：

l提供一个IoCancel例程，以在处理过程中的不同时间里等待取消事件发生的通报以及测试IRP中的Cancel标记，用以判断这个IRP是否被取消

l使用新的“取消-安全”（cancel-safe）IRP排列例程（IoCsqXxx）

正确编码IRP的取消会是有困难的，这是应为取消本身固有的异步性以及竞争（race condition）的多发性（会发生在很多点）。取消-安全的IRP队列很大程度上简化了取消的逻辑，因而被强烈建议使用在所有的新驱动上。IRP的取消在WDK和白皮书“Cancel Logic in Windows Drivers”中有相关内容。

调试输入、输出中的问题

驱动作者可以使用驱动验证器（Driver V erifier）以及微软调试器（MS debugger）的扩展来调试处理IRP过程中的问题。

驱动验证器能够捕获IRP处理中各个方面的错误。驱动验证器随各个版本的操作系统提供。驱动验证器在附有调试器一同运行时效果最好。然而，所有的驱动作者仍然必须提供并使用那些用以检验（exercise）他们的驱动的测试工具以使得驱动验证器能够检测到错误。使用驱动验证器以及驱动专用的测试工具应当是调试和开发过程中的一个标准部分。

!irp以及!irpfind调试器扩展能够帮助在调试过程中跟踪IRP。!irp扩展用于显示关于一个指定IRP的详细信息，而!irpfind扩展用于显示系统里的全部IRP之信息或者关于一个或多个符合特定标准的IRP。要得到关于这些扩展的详细信息，参看Debugging Tools for Windows 包中的相关文档。你可以从WHDC的Web站点下载到这个包，就在本文中“行为准则（Call to Action）和资源”中所列的地址下。

行为准则（Call to Action）和资源

为驱动开发人员的行为准则：

l从所有的IoCompletion例程中返回STATUS_CONTINUE_COMPLETION或STATUS_MORE_PROCESSING_REQUIRED

l理解何时该为一个IRP返回STA TUS_PENDING。仅当你为某个IRP调用了IoMarkIrpPending宏；反之，仅当你打算返回STA TUS_PENDING时，才为一个IRP

调用IoMarkIrpPending。

l在IoCompletion例程中测试Irp->PendingReturned标志的值，以优化IRP的后期处理。

l理解错误状态和警告状态的不同，以及每种类型的状态下IRP中包含的数据。

l使用驱动验证器来捕获IRP处理中的错误，并且使用调试器扩展来理解独立的IRP 是如何被处理的。

资源：

WHDC Web site

https://www.360docs.net/doc/a212877556.html,/whdc/default.mspx

Current White Papers

I/O Completion/Cancellation Guidelines

https://www.360docs.net/doc/a212877556.html,/whdc/driver/kernel/Iocancel.mspx

Cancel Logic in Windows Drivers

https://www.360docs.net/doc/a212877556.html,/whdc/driver/kernel/cancel_logic.mspx

Scheduling, Thread Context, and IRQL

https://www.360docs.net/doc/a212877556.html,/whdc/driver/kernel/IRQL.mspx

Locks, Deadlocks, and Synchronization

https://www.360docs.net/doc/a212877556.html,/whdc/driver/kernel/locks.mspx

Common Driver Reliability Issues

https://www.360docs.net/doc/a212877556.html,/whdc/driver/security/drvqa.mspx

Debugging Tools for Windows

https://www.360docs.net/doc/a212877556.html,/whdc/DevTools/Debugging/default.mspx

Microsoft Knowledge Base

https://www.360docs.net/doc/a212877556.html,/

Knowledge Base Article 320275, “Different Ways of Handling IRPs—Cheat Sheet (Part

1 of 2)”

Knowledge Base Article 326315, “Different Ways of Handling IRPs—Cheat Sheet (Part

2 of 2)”

Microsoft Windows Driver Kit (WDK)

https://www.360docs.net/doc/a212877556.html,/whdc/driver/WDK/default.mspx

Microsoft Platform Software Development Kit (SDK)

https://www.360docs.net/doc/a212877556.html,/downloads/details.aspx?FamilyId=484269E2-3B89-47E3-8E B7-1F2BE6D7123A&displaylang=en