Who enforces dwShareMode on CreateFile? The OS or the Driver?

Question

I have a Windows application that interacts with some hardware. A handle to the hardware is opened with CreateFile, and we control the hardware using DeviceIoControl.

I'm attempting to update an application which uses this hardware to open the hardware in an exclusive mode, so that other programs can't access the hardware at the same time (the hardware has mutable state that I can't have changed out from under me). I do this by passing 0 as the dwShareMode parameter to CreateFile. After making this change, I am still able to run two separate instances of my application. Both calls to CreateFile in both processes are successful. Neither returns INVALID_HANDLE_VALUE.

I believe one of several things is happening, and I'm asking for help narrowing the problem down.

1. I badly misunderstand the dwShareMode parameter
2. dwShareMode doesn't have any effect on DeviceIoControl - only ReadFile or WriteFile
3. The driver itself is somehow responsible for respecting the dwShareMode parameter and our driver is written badly. This, sadly, isn't totally unheard of.

Edit Option 2 is nonsense. dwShareMode should prevent the 2nd CreateFile from happening, DeviceIoControl has nothing to do with it. It must be option #1 or option #3

The Question:

Is the device driver responsible for looking at the dwShareMode parameter, and rejecting requests if someone has already opened a handle without sharing, or is the OS responsible?

If the device driver is responsible, then I'm going to assume #3 is happening. If the OS is responsible, then it must be #1.

Some additional Clues: IRP_MJ_CREATE documentation suggests that the sharing mode does indeed get passed down to the device driver

Answer 1

I believe that sharing rules are only enforced on some devices. In many (most?) cases enforcing sharing rules on the device object itself (as opposed to on objects within the device namespace) would make no sense.

Therefore, it must be the responsibility of the device driver to enforce these rules in those rare cases where they are required. (Either that or the device driver sets a flag to instruct the operating system to do so, but there doesn't seem to be a flag of this sort.)

In the case of a volume device, for example, you can open the device with a sharing mode of 0 even though the volume is mounted. [The documentation for CreateFile says you must use FILE_SHARE_WRITE but this does not appear to be true.]

In order to gain exclusive access to the volume, you use the FSCTL_LOCK_VOLUME control code.

[That's a file system driver, so it might not be a typical case. But I don't think it makes a difference in this context.]

Serial port and LPT drivers would be an example of a device that should probably enforce sharing rules. I think there may be some applicable sample code, perhaps this would shed light on things?

Edited to add:

I've had a look through the Windows Research Kernel source (this is essentially the same as the Windows Server 2003 kernel) and:

1) The code that opens a device object (by sending IRP_MJ_CREATE to the driver) does not appear to make any attempt to enforce the sharing mode parameter, though it does check access permissions and enforces the Exclusive flag for the driver;

2) I've also searched the code for references to the structure member that holds the requested dwShareMode. As far as I can see it is written into the relevant structure by the internal function that implements CreateFile, and later passed to the device driver, but otherwise ignored.

So, my conclusion remains the same: enforcing the sharing mode rules, or providing an alternative mechanism if appropriate, is the responsibility of the device driver.

(The kernel does, however, provide functions such as IoCheckShareAccess to assist file system drivers in enforcing sharing rules.)

Answer 2

In cases where we open a COM port with : CreateFile(devname,GENERIC_READ | GENERIC_WRITE, 0, 0, OPEN_EXISTING, 0, 0); It doesnt allow another application to open the same COM port until the previous handle is closed. I would suggest walking through serenum.sys to check if it has a role here.