windows – 谁在CreateFile上强制执行dwShareMode？操作系统或驱动程序？

我有一个与某些硬件交互的 Windows应用程序.使用CreateFile打开硬件句柄,我们使用DeviceIoControl控制硬件.

我正在尝试更新使用此硬件以独占模式打开硬件的应用程序,以便其他程序无法同时访问硬件(硬件具有我无法更改的可变状态在我之下).我通过将0作为dwShareMode参数传递给CreateFile来实现此目的.进行此更改后,我仍然可以运行我的应用程序的两个单独的实例.两个进程中对CreateFile的两次调用都是成功的.都不会返回INVALID_HANDLE_VALUE.

我相信其中一件事正在发生,我正在寻求帮助以缩小问题范围.

>我严重误解了dwShareMode参数
> dwShareMode对DeviceIoControl没有任何影响 – 只有ReadFile或WriteFile
>驱动程序本身在某种程度上负责尊重dwShareMode参数,并且我们的驱动程序写得很糟糕.遗憾的是,这并非闻所未闻.

编辑选项2是无稽之谈. dwShareMode应该阻止第二个CreateFile发生,DeviceIoControl与它无关.它必须是选项#1或选项#3

问题：

设备驱动程序是否负责查看dwShareMode参数,如果某人已经打开了没有共享的句柄,或者操作系统是否负责,则拒绝请求？

如果设备驱动程序负责,那么我将假设#3正在发生.如果操作系统负责,那么它必须是#1.

一些额外的线索：
IRP_MJ_CREATE文档表明共享模式确实传递给设备驱动程序

解决方法

我相信只在某些设备上强制执行共享规则.在许多(大多数？)情况下,强制执行设备对象本身的共享规则(而不是设备命名空间中的对象)是没有意义的.

因此,设备驱动程序必须负责在需要它们的极少数情况下强制执行这些规则. (或者设备驱动程序设置一个标志来指示操作系统这样做,但似乎没有这种标志.)

例如,对于卷设备,即使已装入卷,也可以以共享模式0打开设备. [CreateFile的文档说你必须使用FILE_SHARE_WRITE,但这似乎不是真的.]

要获得对卷的独占访问权限,请使用FSCTL_LOCK_VOLUME控制代码.

[这是一个文件系统驱动程序,所以它可能不是典型的情况.但我不认为这在这方面有所作为.]

串行端口和LPT驱动程序将是可能强制执行共享规则的设备的示例.我想可能会有一些适用的示例代码,也许这会对事情有所了解？

编辑添加：

我已经浏览了Windows Research内核源代码(这与Windows Server 2003内核基本相同)并且：

1)打开设备对象的代码(通过向驱动程序发送IRP_MJ_CREATE)似乎没有尝试强制执行共享模式参数,尽管它确实检查访问权限并强制执行驱动程序的Exclusive标志;

2)我还搜索了代码,以获取包含所请求的dwShareMode的结构成员的引用.据我所知,它是由实现CreateFile的内部函数写入相关结构,后来传递给设备驱动程序,但否则被忽略.

因此,我的结论仍然是相同的：强制执行共享模式规则,或者在适当的情况下提供替代机制,是设备驱动程序的责任.

(但是,内核提供了诸如IoCheckShareAccess之类的功能来帮助文件系统驱动程序执行共享规则.)