none
LockFile() of UNC path pointing to local machine may return ERROR_LOCK_VIOLATION even when nothing else has the file open RRS feed

  • Question

  • I've found what looks like a bug in Windows 10 version 1709 (doesn't appear to be a problem in 1703 or old versions). It's possible to get the OS into a state where it thinks a file has a byte range locked even though no process has the file open. Or another way of saying it is that when a process terminates, its outstanding locks may never be unlocked (the LockFileEx documentation says "If a process terminates with a portion of a file locked or closes a file that has outstanding locks, the locks are unlocked by the operating system. However, the time it takes for the operating system to unlock these locks depends upon available system resources." but it shouldn't take hours to unlock).

    Calling StgOpenStorage on a UNC path that points to a file on the local machine will trigger the problem. E.g., if you're on a computer named MYPC and share C:\Temp as Temp, put a IStorage compound file named myfile.doc there, and call StgOpenStorage("\\MYPC\Temp\myfile.doc", NULL, STGM_SHARE_DENY_NONE | STGM_TRANSACTED, NULL, 0, &pStorage). If you use Process Explorer from Sysinternals, it'll show that the process that called StgOpenStorage has a handle to myfile.doc open. Release the IStorage and Process Explorer will show that the process no longer has a handle to the file. But even so, if you attempt to LockFile a specific range in that file (a range that StgOpenStorage had locked, and explicitly unlocked, according to Process Monitor), LockFile will return ERROR_LOCK_VIOLATION.

    I've written a VS2017 project with some code that demonstrates the issue: https://goo.gl/AUkV7W . See the readme.txt for details, but basically what it does is call StgOpenStorage with the flags mentioned above on a file, releases the IStorage, then repeats the StgOpenStorage and Release a couple times.

    If you're on a Win 10 1709 system and you're using a UNC path to a file on the local machine, the first two iterations will succeed, but the third will fail with STG_E_LOCKVIOLATION. And once it's in that state, it takes a reboot to clear the lock. If you're on a Win 10 1709 system and you're using a local C: path, it works fine... the util does 5 iterations by default, but you can tell it to do more iterations and it'll successfully StgOpenStorage and Release indefinitely. And if you're using a UNC path to a file shared on some other machine, that works fine too. A Win 10 1703 system is able to run the util with no errors, even when using a UNC path that points back to the local machine. Same with a Win 7 system.

    Any thoughts?


    • Edited by Dahan C Saturday, November 4, 2017 11:33 AM
    • Moved by Hart Wang Thursday, November 9, 2017 1:27 AM
    Saturday, November 4, 2017 11:32 AM

All replies

  • >Any thoughts?

    You've obviously done a lot of analysis of this issue.

    I presume you've tried it on different machines, and/or a VM to ensure it's not a specific hardware driver issue?

    If you're sure it'll repro on any system, have you tried using the Win 10 feedback hub (though that mechanism seems a poor means of
    reporting such issues)? I know of no other free to access means of reporting issues on Windows itself.

    Dave

    Saturday, November 4, 2017 6:43 PM
  • Hi,

    Thank you for posting here.

    >>I've found what looks like a bug in Windows 10 version 1709 (doesn't appear to be a problem in 1703 or old versions).

    The current forum just discuss general issues about developing applications for Windows. For bug issue, you can post the issue on connect website, which handle bug issue. I will move the case to off-topic forum.

    Best Regards,

    Hart


    Please remember to click "Mark as Answer" the responses that resolved your issue, and to click "Unmark as Answer" if not. This can be beneficial to other community members reading this thread. If you have any compliments or complaints to MSDN Support, feel free to contact MSDNFSF@microsoft.com.

    Monday, November 6, 2017 3:06 AM
  • Yes, I've tried it on two physical machines running Win 10 version 1709, one VM running Win 10 version 1709, and one physical machine running Win 10 version 1703 (and I wasn't able to get the problem to occur on the 1703 machine).

    I submitted a report on the Win 10 feedback hub: https://aka.ms/S6x3tq

    Thanks!

    Thursday, November 9, 2017 6:22 AM
  • I had checked the connect website before posting to the forum, and it doesn't look like Windows bug reports are accepted there. David Lowndes suggested submitting a report on the Windows 10 Feedback hub, so I've done that.
    Thursday, November 9, 2017 6:25 AM