Super User is a question and answer site for computer enthusiasts and power users. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

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?

share|improve this question
Antivirus software is the most obvious suspect here. – Harry Johnston Jan 2 '12 at 1:49
up vote 3 down vote accepted

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.

share|improve this answer
Just adding a link since it was just briefly mentioned: Process Explorer ( – Uninspired Jan 1 '12 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 '12 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 '12 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 '12 at 9:02
Great! Cheers! C-:= – Mike Nakis Jan 3 '12 at 9:19

You must log in to answer this question.

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