One of our customers has a 2008R2 Datacenter Edition SP1 file server, and runs our application on several machines which access these files. There is a specific situation when a file is present (in a fileserver folder) which each machine opens (for read and write) every 20 or 30 seconds, decides it cannot process it, and immediately closes again. A completely separate interlock mechanism prevents multiple nodes from even attempting to open the file concurrently.

This works well when all the accessing machines are running Server 2008R2, even though the server open files list shows the file as permanently open. But when a Windows 2003 machine starts up running the same application and the same interlock, it always fails to open the file with a sharing violation, and this machine is also unable to delete the file. Closing all the 2008R2 accessors causes the file to disappear from the file server open files list and allows the Windows 2003 machine to be able to open the file, and delete it. However PROCMON reveals no contact with the file as the accessor is closed.

It's as if there is a private code which the 2008R2 machines and server use to keep the file in a pseudo-open state, and which 2003 is not aware of, so it thinks the file is really open. It cannot really be permanently open because the 2008 nodes are regularly opening it. If my theory is correct, how could our customer fix it?


I'm immediately suspicious that there's some lossage in the interoperability of SMB and SMB2 clients accessing the same file. You could, at least, try to isolate the behavior to being an SMB/SMB2 interoperability problem by disabling SMB2 on the Windows Server 2008 R2 clients. (It's a bad thing to do, from a performance standpoint, but it might isolate the problem enough to make the determination that removing the Windows Server 2003 clients is the "solution".)

Can you describe how your "interlock" protocol functions?

  • It's completely independent, using lock files in another folder. We are confident that it is working here from analysis of the trace files, and that there is no possibility of concurrent access to the file. Moreover when we run with only a SINGLE 2008R2 client opening and immediately closing the file every 20 seconds, the file cannot be opened or deleted from the 2003 client, even between these accesses. – frogb Jan 12 '12 at 11:04
  • Disabling SMB2 does allow 2003 clients to access (and delete) the files. Thanks for this suggestion! Now they have to decide whether this is a greater or lesser evil. There need to be some XP clients which have hardware which has no later drivers. – frogb Jan 13 '12 at 0:22
  • @frogb - actually this should work and is probably a defect. You may want to test the following fixes for known issues with SMB described in this article: support.microsoft.com/?id=2473205 – Greg Askew Jan 14 '12 at 18:16
  • @Greg - revisiting your link revealed a Hotfix added in February. It seems that support.microsoft.com/kb/2625434 is the one! – frogb Jul 2 '12 at 13:41

Evan's advice is solid so I would follow that first. If you don't get any traction, there is something you should know about Windows Server 2003: it has a serious race condition/locking bug in rdbss.sys when performing some types of activities on a file share.

The symptoms and circumstances can vary, and can even lock up the Windows 2003 server if the file contention is heavy enough. I'm not sure why it does not manifest more often, but I definitely hit it hard doing something similar. Also be aware that even with an independent locking mechanism, there may be other processes accessing these file(s), such as antivirus.

Here are the kb articles. Don't be distracted by the rather irrelevant titles.



To get a better idea of what is actually occurring for sure, you would need to perform a network packet capture on the 2003 server when this occurs. The NetMon parsers for SMB are actually quite good and you can usually spot a lock contention issue.

  • Thanks; I don't believe AV is involved but I will check. – frogb Jan 12 '12 at 11:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.