我有一个与一些硬件交互的Windows应用程序。 使用CreateFile打开硬件的句柄，并使用DeviceIoControl控制硬件。
我正试图更新一个应用程序，它使用这个硬件以独占模式打开硬件，所以其他程序不能同时访问硬件（硬件有可变的状态，我不能改变在我之下）。 我通过将0作为dwShareModeparameter passing给CreateFile来完成此操作。 在做这个改变后，我仍然可以运行我的应用程序的两个单独的实例。 两个进程中的CreateFile调用都是成功的。 既不返回INVALID_HANDLE_VALUE。
我相信有几件事情正在发生，我正在寻求帮助缩小问题的范围。
我严重误解了dwShareMode参数
dwShareMode对DeviceIoControl没有任何影响 – 只有ReadFile或WriteFile
驱动程序本身负责尊重dwShareMode参数，驱动程序写得不好。 可悲的是，这并不是完全没有听说过的。
编辑选项2是无稽之谈。 dwShareMode应该防止第二个CreateFile发生，DeviceIoControl与它无关。 它必须是选项＃1或选项＃3
将原始数据写入物理磁盘（闪存驱动器）失败，窗口上显示“Bad file descriptor” – Python
为什么`poll.poll`比`epoll.poll`快？
Block Layer中重复的LBA请求
无法在Windows上写入文件
猴子补丁对象产生奇怪的结果
问题：
设备驱动程序是否负责查看dwShareMode参数，如果某人已经打开了一个不共享的句柄，或者是操作系统的责任，则拒绝请求？
如果设备驱动程序负责，那么我将假设＃3正在发生。 如果操作系统负责，那么它必须是＃1。
一些额外的线索： IRP_MJ_CREATE文档build议共享模式的确传递给设备驱动程序
如何避免状态D的程序
在SD卡上loggingIO性能
当目录存在时，Shutil.copy IO Error2
系统创build文件
我相信共享规则只在某些设备上执行。 在设备对象本身（而不是设备名称空间中的对象）上执行共享规则的许多（大多数？）情况下是没有意义的。
因此，设备驱动程序必须负责在需要的情况下执行这些规则。 （或者设备驱动程序设置一个标志来指示操作系统这样做，但似乎没有这种标志。）
例如，在卷设备的情况下，即使装入卷，也可以使用共享模式0打开设备。 [CreateFile的文档说你必须使用FILE_SHARE_WRITE，但是这不是真的。]
为了获得对卷的独占访问，您使用FSCTL_LOCK_VOLUME控制代码。
[这是一个文件系统驱动程序，所以它可能不是一个典型的案例。 但是我不认为这在这方面有什么不同。]
串行端口和LPT驱动程序将是一个应该强制执行共享规则的设备的示例。 我想可能有一些适用的示例代码，也许这会揭示事情？
编辑添加：
我已经通过Windows Research内核源代码（这与Windows server 2003内核基本相同）和：
1）打开一个设备对象（通过发送IRP_MJ_CREATE给驱动程序）的代码似乎没有试图强制执行共享模式参数，尽管它确实检查了访问权限并强制驱动程序的Exclusive标志;
2）我还搜索了代码，以查找包含请求的dwShareMode的结构成员。 据我所见，通过实现CreateFile的内部函数将其写入相关的结构中，然后传递给设备驱动程序，否则将被忽略。
所以，我的结论仍然是一样的：强制执行共享模式规则，或者在适当的情况下提供替代机制是设备驱动程序的责任。
（但是，内核确实提供了诸如IoCheckshareAccess功能来帮助文件系统驱动程序执行共享规则。）
在我们打开COM端口的情况下：CreateFile（devname，GENERIC_READ | GENERIC_WRITE，0，0，OPEN_EXISTING，0，0）; 它不允许另一个应用程序打开相同的COM端口，直到前一个句柄关闭。 我会建议通过serenum.sys来检查它是否在这里有一个角色。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
