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

Question

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?

Answer 1

This sounds to me like a driver-level issue with a leaky handle.

If you're running an anti-virus package try upgrading, disabling (temporarily!) or switching to a different brand.

Answer 2

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...

Answer 3

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:

• Visual Studio output file permissions?
• Windows 2008 R2 - Kernel (System Process PID=4) is locking files and folders

Answer 4

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

Answer 5

Is your server set up to perform periodic file backups?

If so, is the backup running as System, perhaps prompting the locked file when you get a conflict?

Answer 6

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)

Answer 7

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.

Answer 8

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.