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.

  • 3
    "System" is a pseudo-process that represents (roughly speaking) the Windows kernel. More information about your configuration (e.g. what filter drivers are in user) would be needed to give a definite answer. – 0xC0000022L Mar 21 '11 at 15:18
  • What's the best way to obtain that additional information? – DNS Mar 21 '11 at 15:20
  • if those are mini filters, try checking with fltmc if those are legacy filters you'd need a tool such as GMER to list the filtered objects. I know it's not the primary purpose of GMER, but it can be used that way. There also used to be some tool from OSR, but I don't recall its name. Will reply again if I remember. – 0xC0000022L Mar 21 '11 at 15:22
  • It's an optimization for programs that repeatedly close and re-open files. The "Application Experience" service defeats the optimization for special cases like trying to delete from Windows Explorer while the handle is still cached. – user165568 Feb 28 '17 at 9:12

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.

  • 5
    #2 (Enabling the "Application Experience" service) worked for me, thanks! It was really a pain when debugging my LIVEditor (live html editor) software, since I have to repeatedly re-compile the EXE. – Edwin Yip Jul 17 '12 at 11:11
  • 1
    Indexing wasn't something I wanted to disable, but fortunately just setting Application Experience to Automatic worked. Can't believe I've lived with this problem for the last 5 years when the fix was that simple. – Mordred Jan 28 '16 at 18:29
  • past you, i love you!! – enthus1ast Jan 26 '17 at 18:00
  • Starting AeLookupSvc worked, but why? What is this mysterious service? – cdlvcdlv Apr 27 '18 at 15:17

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.

  • It wouldn't allow me to change the value of that key, so I restarted in safe mode and made the change there. On restart, the KLIF entries are gone from the fltmc output, but the locking problem remains. – DNS Mar 22 '11 at 17:33
  • I added a little more info; see my recent edit to the question. – DNS Mar 22 '11 at 17:50
  • @DNS: have you tried getting the output from fltmc in safe mode? It's well possible that SuperFetch is not active. When you read up on SuperFetch it sounds like your description about holding a handle a bit longer could be plausible. – 0xC0000022L Mar 22 '11 at 18:19
  • That's a very good thought, but alas both FileInfo and luafv were active in safe mode. – DNS Mar 22 '11 at 19:05
  • These modern “internet security” suites are way overblown rarely do any good. MSE + common sense should be sufficient. – kinokijuf Jun 21 '14 at 11:14

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.

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

  • How do you disable application experience? – Simon Sheehan Jan 30 '12 at 2:26
  • Any windows services control point will do - I use Start >> Run >> "services.msc" (enter) >> right click "application experience" >> left click "properties" >> select tab "general" (default) >> drop down "startup type" list box >> select automatic (left click) >> click "apply" – David K Feb 27 '12 at 20:21

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.