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.