2.2.1 Points to Consider about Processing IRPs

Keep the following points in mind when designing an NT driver:

• A new NT driver must handle the same set of IRP_MJ_XXX as any system-supplied driver it replaces. The I/O Manager returns STATUS_INVALID_DEVICE_REQUEST for a given I/O request to a target device if its driver does not define an entry point for that IRP_MJ_XXX. A device driver also must handle the same I/O control codes for IRP_MJ_DEVICE_CONTROL requests as any system-supplied driver it replaces. In other words, a new NT device driver must not “break applications” by implementing less functionality than an existing driver for the same type of device.

• A new NT intermediate driver inserted into a chain of existing drivers should recognize the same set of IRP_MJ_XXX as the driver it displaces. Such a driver can simply pass on IRPs for those requests that it does not process to the next-lower-level driver. However, a new NT intermediate driver must not “break the chain” for drivers above and below it by neglecting to define an entry point for an IRP_MJ_XXX request that the newly displaced, next-lower-level driver does handle.

• A lowest-level device driver can access only its own I/O stack location in any IRP that it is sent. A higher-level driver can access only its own and the next-lower-level driver’s I/O stack locations in any IRP that it is sent.

• Every NT driver communicates information to higher-level drivers (and ultimately, to user-mode applications via the I/O Manager) only in the I/O status blocks of IRPs because the I/O Manager zeros the corresponding I/O stack location as each driver in a chain completes an IRP. Any new NT driver that attempts to implement back-door communication with a particular higher (or lower) driver compromises its portability and its interoperability with other NT drivers from one Windows NT platform or version to the next.

• A pair of NT drivers can define a set of device-specific (also called private) I/O control codes for IRP_MJ_INTERNAL_DEVICE_CONTROL requests that the higher of the pair can send down to the lower of the pair. However, such a pair of drivers must follow all of the preceding guidelines if they are to remain portable and interoperable with other NT drivers from one Windows NT platform or version to another. If you design a pair of NT drivers with such a private interface, consider the set of I/O control codes to be defined carefully. Make them as generally useful as possible and design your paired drivers to follow the preceding guidelines, so that you (or someone else) can reuse, replace, or displace either or both of your new drivers easily as they migrate from one Windows NT platform or version to another.