Why would SYSTEM continue locking executable file handles after the app has exited?

Question

I'm seeing strange behavior on my Windows 7 machine; it appears that when an executable runs, SYSTEM keeps a handle to it open for the next minute or so. Here's my most recent encounter:

I installed Steam, which starts steam.exe post-install to update itself. It appears to do this by writing a temporary copy of itself, launching that to perform the download, then overwriting the original copy of the executable. In my case this failed, claiming that steam.exe could not be deleted.

I opened the folder and tried to delete steam.exe manually, but Windows claimed that I didn't have permission. My account is an Administrator, and is the only user account on this machine. But just in case, I started Explorer as Administrator, but still couldn't delete the file. I brought up the file's Properties to the Security tab, but it showed only a message saying that I didn't have permission to view permissions.

Next, I brought up Process Explorer to see whether anything had a lock on the file. SYSTEM (PID 4) did, but when I attempted to close the file handle, it produced an error stating that the handle was invalid. I tried to view the file handle properties, but I didn't have permission to do that either.

I've terminated everything but the non-terminable system processes, and stopped all services that I'm able to, including everything AV & firewall-related, but the problem continues to appear. I've tried using 'takeown' to give myself ownership of the file, but it claims that I don't have permission to do that. Other people have claimed success using a tool called 'Unlocker', but it had the same problem as Process Explorer in closing the file handle.

I long ago disabled Windows Indexing & Search, and excluded C:\ from indexing, so the answer to this question doesn't apply to me.

Every time, after roughly a minute, the handle disappears and the file is immediately deleted; apparently the updater's attempt to delete it got queued up and finally finished once the file was no longer locked. Unfortunately the update has already terminated, and can't resume. And when I reinstall, it of course tries to run steam.exe again, and I'm back to square one.

My question is: why are these handles hanging around, and how can I prevent them from doing so?

Edit: Here's additional information as requested from comments:

C:\>fltmc instances
Filter                Volume Name                              Altitude        Instance Name      Frame  VlStatus
--------------------  -------------------------------------  ------------  ---------------------  -----  --------
KLIF                  \Device\Mup                             320400       KLIF                     0
KLIF                  C:                                      320400       KLIF                     0
KLIF                                                          320400       KLIF                     0
luafv                 C:                                      135000       luafv                    0
FileInfo              \Device\Mup                              45000       FileInfo                 0
FileInfo              C:                                       45000       FileInfo                 0
FileInfo                                                       45000       FileInfo                 0

Edit: GMER indicates that my antivirus (Kaspersky) is still active in some way, despite disabling it from its own GUI, and its service being stopped.

AttachedDevice  \Driver\tdx \Device\Ip     kl1.sys (Kaspersky Unified Driver/Kaspersky Lab ZAO)
AttachedDevice  \Driver\tdx \Device\Tcp    kl1.sys (Kaspersky Unified Driver/Kaspersky Lab ZAO)
AttachedDevice  \Driver\tdx \Device\Udp    kl1.sys (Kaspersky Unified Driver/Kaspersky Lab ZAO)
AttachedDevice  \Driver\tdx \Device\RawIp  kl1.sys (Kaspersky Unified Driver/Kaspersky Lab ZAO)

But these all seem to be for network services; I don't see anything relating to the filesystem. Could any of these be the cause of the problem?

Edit: I disabled the Kaspersky KLIF filter, but the locking problem remains.

Edit: I solved the specific problem with Steam by installing, force-terminating the installer before it could launch steam.exe, then restarting in safe-mode and running it there. So apparently whatever is locking the executable is not present in safe-mode.

Though I've solved this particular case, the problem comes up elsewhere as well, so I'd still like to understand what is happening.

Answer 1

Do the following:

1. Disable Indexing on the problematic location.

2. Enable the "Application Experience" service and set it to "Automatic".

That is it.

If your problem still persists, it may be Superfetch, although disabling that has brought me no luck.

Answer 2

KLIF is the Kaspersky AV driver. It's rather likely that it has to do with it.

My course of action in such a case would be to contact Kaspersky and ask for advice.

However, there is another thing you can try first: disable the driver (under HKLM\SYSTEM\CurrentControlSet\Services) by looking for KLIF or something similar as key name and setting the REG_DWORD value named Start to 4 (which means disabled), then reboot. This should prevent the KAV filter driver from being loaded. You can then use fltmc to verify the result.

The output from GMER you gave is irrelevant for the case at hand as it would affect only network connections, not file operations. It seems you had something like Kaspersky Internet Security installed (or still have it dormant on your machine).

Edit: just FYI luafv is responsible for FS virtualization in conjunction with UAC. I.e. if you don't have access to a file it's being put into a separate folder inside your profile. FileInfo belongs to SuperFetch - which actually could be part of your problem, but I've not had a similar problem on Windows 7 myself. It's generally not recommended to disable SuperFetch, though one can.

Answer 3

I was having this issue with a Java Executable being held open and I had disabled application experience...(windows search disabled as well) setting application experience to auto start fixed it for me. thanks!!! (I'd also had issues with files not saving for a whole minute and not being able to delete files until one minute after I had closed them...

Answer 4

This happened to me once, and it turned out to be a remote computer which had the share folder open.

1. Use Handle to find out what process is holding the file
2. (It was System in my case)
3. Try to close the Handle: handle.exe -c E14 -p 4. Your file handle will be found in the output of your search for the file handle, and the processid will likely be the same for system.
4. It output Error closing handle: T
5. Googling this, I found this related to the network
6. I found on another machine, I did in fact have the folder open. Closed it. All good.

Answer 5

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. This would likely address the issue mentioned here as well.