Which process is locking a file ?

[Paddy]

We have a recurring problem where a (long-running) service throws an
exception while trying to access a file. The problem is that this is
very rare (happens once every week and without warning) but does happen
time to time. We are trying ways to find which other process is holding
on to the file or even if any other thread from our process is holding
on to the file at the specific time that the problem occurs.

So, I am trying to invesitigate whether there are any ways that when we
throw an exception that "The file is in use ...", specifically WHICH
process is holding on to it. i.e. which process is locking the file or
using it. As I was saying, this is a rarely occuring phenomenon and
Process Explorer is not of much use to us as it (as far as I know) does
not have a monitoring mode.

Can anyone please let me know how this can be accomplished in code (C#,
C, C++ .... doesn't matter) ?

- K

 

[John B]

We have a recurring problem where a (long-running) service throws an
exception while trying to access a file. The problem is that this is
very rare (happens once every week and without warning) but does happen
time to time. We are trying ways to find which other process is holding
on to the file or even if any other thread from our process is holding
on to the file at the specific time that the problem occurs.

So, I am trying to invesitigate whether there are any ways that when we
throw an exception that "The file is in use ...", specifically WHICH
process is holding on to it. i.e. which process is locking the file or
using it. As I was saying, this is a rarely occuring phenomenon and
Process Explorer is not of much use to us as it (as far as I know) does
not have a monitoring mode.

Can anyone please let me know how this can be accomplished in code (C#,
C, C++ .... doesn't matter) ?

- K

A quick search revealed the following:

http://www.codeguru.com/Cpp/W-P/dll/article.php/c3641/#more

http://ccollomb.free.fr/unlocker/

The first one has the source code (c++) included.

HTH

JB

 

[Willy Denoyette [MVP]]

| Paddy wrote:
| > We have a recurring problem where a (long-running) service throws an
| > exception while trying to access a file. The problem is that this is
| > very rare (happens once every week and without warning) but does happen
| > time to time. We are trying ways to find which other process is holding
| > on to the file or even if any other thread from our process is holding
| > on to the file at the specific time that the problem occurs.
| >
| > So, I am trying to invesitigate whether there are any ways that when we
| > throw an exception that "The file is in use ...", specifically WHICH
| > process is holding on to it. i.e. which process is locking the file or
| > using it. As I was saying, this is a rarely occuring phenomenon and
| > Process Explorer is not of much use to us as it (as far as I know) does
| > not have a monitoring mode.
| >
| > Can anyone please let me know how this can be accomplished in code (C#,
| > C, C++ .... doesn't matter) ?
| >
| > - K
| >
| A quick search revealed the following:
|
| http://www.codeguru.com/Cpp/W-P/dll/article.php/c3641/#more
|
| http://ccollomb.free.fr/unlocker/
|

Both aren't exactly what the OP is looking for, the first is to find the
DLL's locked, the second is an interactive application that requires an
operator to be present, this is not usable in the OP's user context.

Willy.

 

[Willy Denoyette [MVP]]

| We have a recurring problem where a (long-running) service throws an
| exception while trying to access a file. The problem is that this is
| very rare (happens once every week and without warning) but does happen
| time to time. We are trying ways to find which other process is holding
| on to the file or even if any other thread from our process is holding
| on to the file at the specific time that the problem occurs.
|
| So, I am trying to invesitigate whether there are any ways that when we
| throw an exception that "The file is in use ...", specifically WHICH
| process is holding on to it. i.e. which process is locking the file or
| using it. As I was saying, this is a rarely occuring phenomenon and
| Process Explorer is not of much use to us as it (as far as I know) does
| not have a monitoring mode.
|
| Can anyone please let me know how this can be accomplished in code (C#,
| C, C++ .... doesn't matter) ?
|
| - K
|

It's nearly impossible in real-time, to know which other process/thread has
the file open in Windows. The only way to find the process who has a file
open is by inspecting each process handle table (by taking a snapshot like
Process Explorer does), this is an expensive (time consuming) operation
which requires elevated privileges (not something you want your service to
run with), by the time you have taken a snapshot of THE process, it's
possible that the handle has been released.

If the file is shareable across processes, there is very little you can do,
other than retrying to open the file. If the file can only be shared across
your process threads, you have a design flaw.
If the file must be shared across threads you should have set the correct
sharing mode (ReadWrite), on the other hand, if the file should not be
shared across threads, then you should synchronize the file accesses, or
better, have only one thread accessing the file.

Willy.

 

[John Duval]

Could you try an approach like this? I've never done this myself, so
take it with a grain of salt...

1) Run SysInternal's Filemon
2) When the long-running service detects the problem, have it send a
command to Filemon to suspend capturing output (i.e. CTRL-E keystroke)
3) Dump the Filemon output to a file, and search in it for the
offending app

Your service might need to be set to "interact with desktop" for this
to work and/or run under a Windows account with the proper privs.

If the size of the output is unmanageable, you might want to set the
history depth of Filemon -- I'm not sure what happens if you set it to
"no limit" and it runs for a week. Also you might want to set it up to
filter its output (is it always the same file?) and if necessary,
periodically send a keystroke to clear the output.

If you have trouble sending keystrokes for some reason, you might also
be able to simply suspend the Filemon process from your service. When
you know the problem has happened, you could resume Filemon and then
manually dump the output.