My application running on a Windows server makes use of a Jet/Access database. For some reasons around every two weeks that database file gets locked by the System process (PID 4, seems to be fixed) After some googling I found some other users having their files locked by that special process, but different files (of course). What's the general reason for the System process to keep an open file handle? Is my application the cause for this locking situation? Are all handles implicitly opened by the System process? I could imagine that after a process has crashed, the handle may still be open and the System process somehow takes owernship of that handle. Can I do something in my application to prevent it from happening?

Reputation: 72514

Under which circumstances does the System process (PID 4) retain an open file handle?

My application running on a Windows server makes use of a Jet/Access database. For some reasons around every two weeks that database file gets locked by the System process (PID 4, seems to be fixed)

After some googling I found some other users having their files locked by that special process, but different files (of course).

What's the general reason for the System process to keep an open file handle?
Is my application the cause for this locking situation?
Are all handles implicitly opened by the System process? I could imagine that after a process has crashed, the handle may still be open and the System process somehow takes owernship of that handle.
Can I do something in my application to prevent it from happening?

Upvotes: 32

Answers (8)

Jimmy Za

Reputation: 1

Check the security settings for each folder and subfolders. Make sure that the system did not just automatically create a special permissions setting which will not allow anyone to delete the file. Apparently for some odd reason the OS creates a weird special permission setting that protects the file from being deleted.

Upvotes: 0

greenvomit8

Reputation: 11

For me I had to hit it with a sledgehammer. Chkdsk /f on the drive where the folder was located fixed it. Use with caution.

Upvotes: 1

eric frazer

Reputation: 1648

For me, it was "Windows Defender" (anti-virus). I excluded my Visual Studio build folders from Windows Defender's list of folders it checks, and the problem went away. (Visual Studio wasn't able to build to the EXE file, PID 4 was locking it to check for virii)

Upvotes: 2

Saintali

Reputation: 4571

It may be a lingering session from a remote computer to a shared folder. If that's the case, it can be unlocked from the command line:

net session /delete

Upvotes: 7

Maiku Mori

Reputation: 7469

Here's another possible cause I've found:

There is a bug in Windows 7 and likely in Windows Server 2008 (possibly 64bit versions only). It surfaces when you disable Application Experience service and causes the same problems as described in the question.

Re-enabling this service has fixed this problem for me.

A bit more info here as to why it's causing a problem.

List of other SO questions which seem to be related:

Upvotes: 29

janv8000

Reputation: 1625

Files accessed through a share will be locked by the system process (PID 4).

Try opening compmgmt.msc -> System Tools -> Shared Folders -> Open Files to see if the locked file is listed there

See also the sysinternals forum for a way to replicate this.
Not all applications lock files when they are opened, Excel however does. I don't know if Access does the same...

Upvotes: 47