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.
Windows 2008 R2 - Kernel (System Process PID=4) is locking files and folders
Asked Answered
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:
+1 isn't enough for this answer - this has tormented me for a couple of years, manifesting as Visual Studio 2010 failing to build due to a locked file. And now it's fixed. –
Sargeant
In case of Windows 10 the Application Experience is found following these instructions answers.microsoft.com/en-us/windows/forum/… –
Sarraceniaceous
@Sarraceniaceous so the same thing happens on Windows 10 if you disable it? –
Nothing
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...
Thanks! After trying for quite some time to find which Excel process had the file open, it turned out to be a shared user :-) –
Penutian
Thank you for this response @janv8000. I've tried Process Explorer from SysInternals (couldn't close the handle, file was being used by System process), Process Monitor on windows server 2008 (no dice) and a few other things to find what was locking it. I didn't know there was an Open Files list under Shared Folders. That even showed who was accessing it remotely so I could check to verify they were done. Thanks! –
Mellins
This is very interesting, I've literally spent 3 weeks trying to solve this in many ways (without having to restart the server) by any chance, have you found a way of automating this process? running it through cmd prompt/powershell, thanks a lot , your answer is more than enough –
Ipswich
Is there a way to prevent this behavior? –
Praemunire
Brilliant! Still applies to Windows 2016 Server. Indeed Process Monitor couldn't do it for me either. In case Google indexes these comments, this was essential to fix a Sage / PeachTree accounting 2021 upgrade process gone awry, allowing me to free up
SUA00021.LCK and PT.LCK for deletion and Sage could launch. –
Paraguay In my case, it was fixed by a simple command in the command line:
net session /delete
I hope that helps.
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
I had this issue when trying to rename a folder. I had to stop the server service while performing the rename. Just restarting didn't help, as the system process re-locked the folder as soon as the server service restarted.
Make this and resolve the problem:
Go to Services and activate Application Experience.
Worth mentioning that this service does not exist as of Windows 10. It was present in the preview, but release versions use a different approach to managing compatibility. If you have problems with PID 4 (system kernel) locking files in windows 10, this is not the reason. –
Deuteragonist
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... :)
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.
© 2022 - 2024 — McMap. All rights reserved.