5

I have an app that writes data to a local disk file regularly. It always opens, writes, then closes the file. Recently I had an issue where it stopped writing data, and this was due to it being unable to open the file because of a sharing violation. The situation seemed to be permanent.

Process Explorer showed a handle to the file held by the System process, PID 4. As soon as I forced this handle to close, my app behaved normally again.

Now I have my suspicions, as the file can also be accessed from other machines on the network, but the file is always opened briefly and closed again, and always with flags of "RW-", and the app is designed to cope with these brief accesses from elsewhere. The handle that was holding the file open had flags shown as "R--" by process explorer.

My questions: how can I find out more about a handle owned by the System process, and what sort of process might be holding the file open such that I wasn't able to write to it?

Improve this question
1
  • Antivirus software is the most obvious suspect here.
    – Harry Johnston
    Jan 2, 2012 at 1:49

1 Answer 1

Reset to default
4

You are probably correct in suspecting that the file was being accessed via the network. Other things I could speculate about would be the indexing service or your antivirus, but I do not think that any of those would show up as "System".

I do not think there is any way to obtain any more information about a handle than process explorer.

Perhaps there is a bug in the way your application "is designed to cope with these brief accesses from elsewhere"? You could post code on CodeReview and ask people if they see any problem with it.

Improve this answer
5
  • 1
    Just adding a link since it was just briefly mentioned: Process Explorer (technet.microsoft.com/en-us/sysinternals/bb896653)
    – Uninspired
    Jan 1, 2012 at 21:15
  • Thanks @MikeNakis. Your last comment had me thinking and yes, I did find that the app that opens the file over the network was opening with a FileMode := fmOpenRead instead of FileMode := fmOpenRead or fmShareDenyNone. However, even with that fixed, the app that writes to the file still snags on the reset occasionally. Time to look at that end....
    – rossmcm
    Jan 2, 2012 at 7:13
  • Simply opening the file with the right share flag is not enough, because the other process might have already opened it with fmShareDenyRead or fmShareExclusive. (I know, very rude on its behalf, but things like that happen.) So, I would suggest that if your file-open function fails with a sharing violation, you keep retrying for a while, sleeping for a few milliseconds between the retries.
    – Mike Nakis
    Jan 3, 2012 at 5:32
  • Thanks @MikeNakis. Exactly what I have been doing. I found I got the best results sleeping 50 mS between retries, and allowing for 10 retries before giving in and reporting an error. The most retries I have seen so far is 6.
    – rossmcm
    Jan 3, 2012 at 9:02
  • Great! Cheers! C-:=
    – Mike Nakis
    Jan 3, 2012 at 9:19

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .