6.3.1  DispatchCreate and DispatchClose Functionality

A create request can originate either in a user-mode subsystem’s attempt to get a handle for the file object representing the device (possibly on behalf of an application or subsystem-level driver) or in a higher-level driver’s call to IoGetDeviceObjectPointer or IoAttachDevice.

The reciprocal close request can originate in a user-mode subsystem’s close of the file object handle associated with the driver’s device object or in a higher-level driver’s call to IoDetachDevice.

Each of these requests is inherently synchronous.

An NT driver’s Dispatch routine(s) for IRP_MJ_CREATE and IRP_MJ_CLOSE requests might do nothing more than complete the input IRP with STATUS_SUCCESS, as already mentioned in Chapter 4.

Another NT driver’s Dispatch routine(s) for IRP_MJ_CREATE and IRP_MJ_CLOSE requests might do more work, depending on the underlying device driver or on the underlying device. Consider the following scenarios:

·On receipt of a create request, a class driver might initialize an internal queue and send an IRP_MJ_INTERNAL_DEVICE_CONTROL request down to the corresponding port driver requesting device configuration information or exclusive access to a controller port.

·On receipt of a close request, a highest-level driver might need to delay until it has completed device I/O processing for all outstanding IRPs currently queued to the target device object.

·On receipt of a create request, an NT driver of an infrequently used device might call MmLockPagableImageSection to make resident some of the driver routines that process other IRP_MJ_XXX requests. On receipt of a reciprocal close request, the driver might call MmUnlockPagableImageSection to conserve system memory by having its pageable-image section paged out when all file object handles for such a driver’s device object(s) are closed.

For more information about discardable, pageable, and pageable-image driver code, see the Programmer’s Guide. For more information about the preceding support routines, see the Kernel-mode Driver Reference.

Although many NT drivers have a single Dispatch routine for create and close requests, any NT driver writer can implement separate DispatchCreate and DispatchClose routines. Some NT drivers handle IRP_MJ_CLOSE requests only for symmetry because, after their device objects have been opened by a protected subsystem or higher-level NT driver, the lower-level drivers’ device objects are not closed until the system itself is shut down.

In general, a DispatchClose routine is not called if it is implemented in any lower-level NT driver for an underlying physical device that must be available for the system to continue running.

For example, keyboard and mouse drivers set up device objects representing physical devices that must be functional while the system is running, so these drivers might have minimalist DispatchClose routines for symmetry or combined DispatchCreateClose routines.

As another example, some of the the system disk drivers have no DispatchClose routine, but these drivers usually have DispatchFlush and DispatchShutdown routines to complete any outstanding file I/O operations before the system is shut down.