6.3.1.1 Basic DispatchCreateClose Routines

Many NT drivers merely need to establish their existence on receipt of a create request and merely need to acknowledge the receipt of a close request, particularly lower-level drivers in a chain of layered NT drivers.

For example, a port driver of a device controller with one or more closely coupled class drivers that call IoGetDeviceObjectPointer might have a minimalist DispatchCreateClose routine. Such a port driver’s DispatchCreateClose routine might do nothing more than complete the IRP as follows:

    :	: 
{ 
    Irp->IoStatus.Status = STATUS_SUCCESS; 
    Irp->IoStatus.Information = 0; 
    IoCompleteRequest(Irp, IO_NO_INCREMENT); 
    return STATUS_SUCCESS; 
} 
 

This minimalist DispatchCreateClose routine sets the Information member of the I/O status block to zero indicating the file object is opened for a create request; Information has no meaning for a close request. It sets the Status member with and returns STATUS_SUCCESS, which indicates that it is ready to accept I/O requests for the target device object from the higher-level class driver that caused the create IRP to be sent to the port driver’s DispatchCreateClose routine when that class driver called IoGetDeviceObjectPointer.

This minimalist DispatchCreateClose routine completes the create IRP without boosting the priority of the originator of the IRP (IO_NO_INCREMENT) because the originator of the request is assumed to wait for an indeterminate but very small interval on the completion of this request.

How much work a DispatchCreateClose routine does depends partly on the nature of the driver’s device or the underlying device and partly on the design of the driver(s). At the discretion of the driver designer, an NT driver can handle these requests in separate DispatchCreate and DispatchClose routines, particularly when the driver performs quite different operations for each request.

For a create request to open a file object that represents a logical or physical device, a highest-level NT driver should do the following:

1. Call IoGetCurrentIrpStackLocation to get a pointer to its I/O stack location in the IRP.

2. Check the FileObject.FileName in the I/O stack location and complete the IRP with STATUS_SUCCESS if the Unicode string at FileName has a zero length; otherwise, complete the IRP with STATUS_INVALID_PARAMETER.

Following the preceding steps ensures that no attempt to open a pseudofile on a device can cause problems later. For example, this prevents attempts to open a nonexistent \\device\parallel0\temp.dat.