You start writing your driver, carefully including support for multiple O/S versions. You discover the perfect DDK or IFS kit function that solves one of your key problems. You?re happy! But, in the software world you don?t always get to live happily ever after: You discover that this perfect function isn?t available on all the versions of the O/S that you need to support! Arrgh!

Well this is exactly what happened recently here at OSR when we tried to use IoCreateFileSpecifyDeviceObjectHint for a file system filter driver that needed to run on Windows 2000, Windows XP, and Windows Server 2003. This article discusses our solution to implementing this functionality on Windows 2000, while allowing us to use the native functionality on Windows XP and Windows Server 2003.

Let?s start by explaining the problem. We were writing a file system filter driver for insertion into the storage stack above a file system. By default, we knew that our filter may be one of a number of filters attached to the file system. The specific issue arose when our filter needed to open or create a file on the file system we were filtering. In order to do the open, in Pre Windows XP systems, we either had to use ZwCreateFile or attempt to build our own Create IRP. Each of these 2 methods had problems, they were:

The introduction of IoCreateFileSpecifyDeviceObjectHint in Windows XP solved the problem. Specifically,

Great...except that this solution only addresses support for Windows XP/Server 2003. Given we need to implement this functionality in Windows 2000 as well, we sought to mimic the functionality of IoCreateFileSpecifyDeviceObjectHint on Win2K. So what do we do?

We know that the I/O Manager and Object Manager work together to parse names to determine the Device Object that is the eventual target of a Create request. So, for example, if \\??\\C:\Fred.Txt (or \\Global??\\C:\Fred.Txt on XP) was specified in a Create request, as part of parsing this name string the I/O Manager and Object Manager might determine that the Device Object named "\Device\HarddiskVolume1" was the target for operations on the logical device named "C:". Thus, the I/O Manager would build a Create IRP (containing the remainder of the file name, "\fred.txt" in our example) and pass it to the driver that?s responsible for processing requests for the "\Device\HarddiskVolume1" device.

Further, we know if we create a Device Object with a unique name we can get the I/O Manager to deliver Create requests with that name to our Device Object so that we can process the create.

Finally, we know we can still use ZwCreateFile to build a Create IRP.

So we just have to pool what we know in order to get Create Requests delivered to the correct place.

Okay, so recall that we want OSR Filter B to build a Create request and have that request sent to Filter C without having it reenter the top of the stack. So, let?s say that our filter creates a named Device Object, as shown in Figure 2, in addition to the one that it created and attached to Filter C. Whenever OSR Filter B needs to do a Create, it does a ZwCreateFile to the named Device Object.

Here it is in more detail. Let?s say that our stack of filters is filtering drive "C:" and a Win32 user does a CreateFile request to open up "C:\FRED.TXT". When OSR Filter B receives the request, the name contained within the File Object is "\FRED.TXT". Now OSR Filter B wants to open up the file and do something with it before it allows the Win32 user?s Create to continue. What OSR Filter B would do is issue a ZwCreateFile request specifying the name "\Device\OurUniqueDeviceName\Fred.Txt". This would result in a IRP_MJ_CREATE being passed to the named Device Object that we created in OSR Filter B.

When OSR Filter B gets an IRP_MJ_CREATE request, it needs to look at the Device Extension that we have created for our Device Object. Specifically, it needs to look for a bit that we set when we created the Device Extension that indicates that this is our Named Device Object as opposed to our regular unnamed Device Object. If the bit is not set, then we know that this is just a normal Create that came down the top of the stack. If the bit is set however, then we know that this request is one that we built for ourselves and all we need to do is pass it on to Filter C by calling IoCallDriver with the address of "Filter C?s" Device Object (which we stored in our named Device Object?s Device Extension when we created it). Pretty simple don?t you think?