Windows 2008 R2 - Kernel (System Process PID=4) is

Question

Windows 2008 R2 - Kernel (System Process PID=4) is locking files and folders for a long time. For example when deleting a file, the file may remain locked for 1 minute or more and only after that be deleted. On another occasions I encountered files or folders I could not delete. ProcMon showed that the System Process was holding a handle to those resources for a couple of minutes and then released them None of the resources I mentioned were system resources, only files and folders installed be me and handled by my applications.

Answer 1

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

Answer 2

As Dani has already mentioned in the comment:

It's a bug in Windows 7 and likely in Windows Server 2008 (possibly 64bit versions only). It surfaces when you disable Application Experience service.

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?
• Under which circumstances does the System process (PID 4) retain an open file handle?

Answer 3

Hope this helps others.

open windows run and lauch mmc.exe

File -> Add or Remove Snap-ins --> Shared Folders --> localcomputer

Select Open Files scroll down to the directory or file and right click to close.

You can also get the username that has the lock and go to sessions and right click --> close session.

In my case it was MacOS 10.13 holding file locks open... https://support.apple.com/en-us/HT208209

Answer 4

Had this issue just now whilst trying to replicate data to a new file server (both source & destination servers running Windows 2008 R2).

PID 4 was found locking the file (using procexp as above), but Application Experience has never been installed on either server & the file was not shown in the list of open files.

Fortunately we use scheduled shadow copies on this server (to enable users to self-serve most file recoveries). I just used the Previous Versions option (available through Properties of the containing folder), selected the most recent copy of the file & copied it to somewhere else, then deleted and replaced the problem file.

You might need to delete the containing folder to delete the file - which could be a problem if lots of files in use obviously (this wasn't an issue for me given this was the only file in the folder).

For a one-off issue like I had (single locked file for the whole server drive), this worked without any disruption to the server or users.

Given you are talking about a server & that Shadow Copies are using VSS - you should be able to recover the locked file from your backups (presumably you have these) if you don't use Shadow Copies. Otherwise there are some useful utils like ShadowSpawn (https://github.com/candera/shadowspawn) around that might help.

Answer 5

In my case, it was fixed by a simple command in the command line:

net session /delete

I hope that helps.

Answer 6

Tried all these...

Even copying the file, deleting the original, renaming copy to original name (all on server) would immediately tell me the user had it locked.

In the end -

used Unlocker to clear the file locks. Copied the file OFF THE SERVER to a desktop. Deleted the original file off the server. Changed the filename of the copy on the desktop. Renamed it back to the original name on the desktop. Put the file back into the original location ON THE SERVER.

HTH, YMMV... :)