我知道这听起来像一个编程问题，但实际上并不是。 请跟我来
我有一个客户遇到了一个我无法解释的奇怪问题：程序在共享模式下打开共享SMB驱动器（Windows 2008R2服务器）上的文件。
在文件内执行更新之前，程序将使用LockFilelocking特定药水，读取数据，将所需更改写入这些部分，然后将其解锁。
这样做是为了确保同一个程序的多个实例可以覆盖彼此的变化。
在我的客户案例中，该程序（在所有其他位置performance良好）在locking文件时成功，但在同一句柄上对ReadFile的后续调用失败，并且GetlastError返回错误64 The specified network name is no longer available
因此，我的问题是：
是否有一些在Windows SMB客户端或服务器可能导致这样的事情设置？
它看起来像一个乐观的锁，但Windows默认情况下并不乐观锁（它确实机会锁 ）。
我的第一个怀疑是，这个问题是由反病毒软件（卡巴斯基）造成的，但是站点pipe理员发誓，所有AV都排除了这个networkingpath，无论是在客户端还是在文件服务器上。
客户端操作系统是Windows XP，7,2003和2008R2的混合（通过terminal服务）。 这似乎只发生在重负荷的时候（每个人每天早上进来的时候，或者每个人都在登台的时候）。
好吧，答案比我想象的要简单得多：服务器NIC的错误设备驱动程序显然是造成这些麻烦的原因。
这实际上是一个编程问题，恕我直言，但它可能会恢复到“工作”的方式，通过降级您的操作系统。 Windows 7引入了一个新的locking机制到CIFS中，这几乎肯定是您的问题的原因。 这意味着您需要更新程序以使用新的lockingscheme（编程概率），或者您需要降级或find兼容性修复（pipe理问题）。