We are not talking about a reboot/restart here (similar to another question). This question distinguishes the different way that windows handles existing file locks on a taskkill versus the way it responds to a shutdown/reboot.

If I force kill a program, will the files it has locked still remain locked or do the locks get released when the process dies as well?

By force kill, I mean such as using the 'taskkill' command or 'end process tree' in taskmanager.

To further clarify, I am not talking about a process leaving a resident un-removed auxiliary lock file, such as does MS Word. I am talking about the status of an actual exclusive or shared file lock.

Does taskkill release a filelock? Or does the lock stay put until such time as a reboot or an admin user action is taken within the computer management console?

Here is what I can confirm - killing a 16-bit process that places an exclusive lock

This is using a small console program that puts an exclusive lock on a file in the same local directory. The program stays running until the user presses a key and then it will unlock the file. Here is what happens:

  • If launched at the command-prompt and killed in taskmanager, it does release the lock. The process to kill is the specific cmd.exe that launched the program. Killing it does release the lock.

  • If launched by clicking and then killed by closing the window, then the lock is released.

  • However, if launched by clicking and then killing the conhost.exe in taskmanager, it does not release the lock. In this case, there is also no cmd.exe because it was clicked. So the only way to kill it is via killing the conhost.exe or ntvdm.exe it is running in. The lock stays in place until after the reboot.

  • If launched by clicking and then killing the ntvdm.exe in taskmanager, it does release the lock.

  • At no time does the exclusive lock actually prevent the file from being deleted. However, windows does not allow the file to be copied in explorer while the lock is in place.

So, two different behaviours depending on whether the task is launched via cmd prompt or via clicking and killing the conhost or ntvdm subsystem. Of course, killing the ntvdm.exe subsystem also kills any other processes being tasked in the ntvdm thread.

  • I agree, the questions are slightly different. However, the information from superuser.com/a/918448/401839 answers both questions. The reason Windows works that way when rebooting is basically the reason that Windows works that way when a program is terminated.
    – TOOGAM
    May 23, 2015 at 0:13
  • If you kill a process then that process which had a file lock no longer exists. So there is nothing to lock the file.
    – Ramhound
    May 23, 2015 at 2:02

1 Answer 1


Yes, the locks remain but you cannot predict when they will get released by the OS. See LockFile() and LockFileEx():

If a process terminates with a portion of a file locked or closes a file that has outstanding locks, the locks are unlocked by the operating system. However, the time it takes for the operating system to unlock these locks depends upon available system resources. Therefore, it is recommended that your process explicitly unlock all files it has locked when it terminates. If this is not done, access to these files may be denied if the operating system has not yet unlocked them.

  • 1
    Now that was useful. Because in our case, the system is never releasing then until reboot. So "depends upon available system resources" really means "don't count on it" :) And that explains some things. May 23, 2015 at 2:40
  • @SaintHill: The question is, why are you killing so many tasks that hold locks with taskkill (or doing so frequently even with a few tasks) that this is becoming a major issue?
    – Karan
    May 23, 2015 at 2:41
  • because our webserver spawns a special database process that runs and then returns a special query. Only one can run simultaneously, and it also locks several files when it runs. But if it timesout, then we need to kill it. So the webserver kills it 'taskkill' and then ... the OS often does not release the locks. And many other processes also share those database locks. So ... we will need to look at a better solution to this problem. At least we understand the spec now. May 23, 2015 at 2:44
  • @SaintHill: Got it. Yes, you will definitely have to rethink the process.
    – Karan
    May 23, 2015 at 2:46
  • So what happens is the file is locked on a network share? May 23, 2015 at 9:23

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .