How do I find out any more information about file handles held open by the System process?

5

1

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?

rossmcm

Posted 2012-01-01T20:04:14.240

Reputation: 1 328

Antivirus software is the most obvious suspect here. – Harry Johnston – 2012-01-02T01:49:27.450

Answers

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.

Mike Nakis

Posted 2012-01-01T20:04:14.240

Reputation: 351

1

Just adding a link since it was just briefly mentioned: Process Explorer (http://technet.microsoft.com/en-us/sysinternals/bb896653)

– Uninspired – 2012-01-01T21:15:06.567

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 – 2012-01-02T07:13:55.183

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 – 2012-01-03T05:32:43.113

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 – 2012-01-03T09:02:00.443

Great! Cheers! C-:= – Mike Nakis – 2012-01-03T09:19:01.777

Asked: 2012-01-01T20:04:14.240

Viewed: 1 317 times

Active: 2014-09-09T12:02:43.623