The scenario we're about to introduce is an unbeatable classic for anyone working with Windows. You need to move, rename or delete a file and - as soon as you try to do that - you're greeted by the following popup message:
File in Use. The action can’t be completed because the file is open in another program.
Or maybe this one:
The action cannot be completed because the file is open in SYSTEM.
If you're an experienced Windows user you most certainly know that, when you see something like this, it usually means that there is a running application which still has that file opened in an exclusive mode - thus locking it from any IO write operations: no rename, no move and certainly no delete. Whenever that's the case, the fix is right around the corner: you close the offending application - be it MS Word, MS Excel, MS Access, Photoshop and so on - then go back to the file and do whatever you want with it. Problem solved!
What to do when there are no active applications that seems to be locking that file? As soon as you are sure about it you can focus your attention to other Windows processes, such as some active services that could have it open: Antivirus software, Database services, Source Control Managers, Software Optimizers, Backup Tools, Firewall/security systems and so on. Again, if you're a seasoned Windows user, you will have no problem to figure it out soon enough.
However there is always a small chance that, after you spent a reasonable amount of time checking and/or temporarily shutting down your resident software, you would still have absolutely no idea of what process is actually keeping that file open. Whenever this happens, you're going to equip yourself with a few freeware tools that might really help you fixing your issue for good.
Solution #1 (bad): Unlocker
If we don't want to bother about what's happening to our system and just want to release that damn file we can think about trying to use Unlocker, a freeware application made by Cedrick Collomb that could automatically fix your issue... or not! I personally don't recommend using this software for at least two reasons:
- You won't learn anything from using that, including what process (or process chain) will be abruptly shutdown with the intent to free your file.
- The program is freeware, but it carries a huge amount of bloatware you need to opt-out from: doing that will even require some attention, because the setup program will try to guide you into installing them and I just really don't like it.
As a viable alternative you could also try IOBit Unlocker, which is basically the IOBit attempt to capitalize the "unlocker" brand because the original author didn't make it into a commercial hit (yet). The software is also freeware and it gets the job done just like the former one.
Solution #2 (good): Process Explorer
With Sysinternals Process Explorer (or simply ProcessExplorer) things start looking good. This small, yet great portable utility (no setup, just download and run) allows you to see all the currently active processes within your system, including the names of their owning accounts and a full list of handles (files) that the process selected in the top window has opened, including (if we switch it to DLL mode) the system DLLs: this basically means that we can fully understand what's going on, and which process is holding our files.
The tool also features a powerful search capability that will quickly show you which processes have particular handles opened or DLLs loaded. This will allow us to use it to easily fix most unwanted file locks in a matter of seconds: we just have to search for the locked file, retrieve the process which is keeping the handle and close (or kill) it accordingly.
Solution #3 (great): Handle
SolutionExplorer is a great analysis tool, yet it lacks some useful options to actually fix our specific issue: altough we can use it to kill a whole process, it doesn't provide a way to release a specific handle: whenever we're dealing with files locked by processes we cannot kill, such as SYSTEM, this can be a problem. In order to achieve such surgical result we need to get our hands to another great Sysinternals utility that goes by the name of Handle.
Handle is basically the console version of ProcessExplorer: think of it like a ProcessExplorer with command-line options instead of the GUI. This could make it less intuitive when we need to investigate our system, yet it has extremely powerful tools when it comes to fix the issues we found.
The most common usage of Handle - for our specific scenario - is the following:
- Download Handle and unzip it into a folder of your choice.
- Open a command prompt window with administrative priviledges and input the following command:
Handle64.exe > output.txt . The tool will then create a list of active processes/handles and write the (huge) outcome into the output.txt file. - Do not close the command prompt, as you will need it again. Open the output.txt file with your favourite text editor and search for a row containing your locked file name. Once you find it, look for the HEX number to the left and write it down: this is the ID of the handle you need to close. Right after that, go up through the file until you reach the parent row, which contains the informations about the process which is holding that handle. Again, look for the small HEX number to the left and write it down: this is the ID of the process you'll need to use in the following step. As a side note: SYSTEM process ID is usually 4, although it could vary in the future.
- Go back to the command prompt and try to close the handle by typing the following:
handle.exe -c <handleID> -p <processID> , replacing the placeholders with the values you found in the previous step.
If everything goes correctly, you will fix your problem without killing the process and - more importantly - without having to reboot the system.
That's it for now: happy "handling"!
Hi
I just wanted to say, that I have used both the unlockers mentioned, and that it seems odd that you write the following:
IObit Unlocker is freeware without any bloatware. Unlike most of their software, IObit Unlocker is completely free from bloatware offers, and there are no pro version nor other methods used, where they ask you for money nor do they ask you to sign up for anything.
Other than the above, I think that it is a good article, I would however have liked to see Process Hacker mentioned as an alternative to Process Explorer
You’re right, I edited the post accordingly. Will also add PH as soon as I have the chance. Thank you for your valuable feedback!
No problem :)
Is there a fix or solution for when all these programs respond with “The handle is invalid” ?
Hello Lucy,
I once had your issue: if I remember correctly, the file I was trying to delete was inside a SMB share: all I did to fix that was to delete and re-create the Share. If that’s your scenario, I suggest to try that as well.
Otherwise, here’s a couple more suggestions:
If you’re running an anti-virus package try to temporarily disable it (it could lock or hide the handle).
Try to use SysInternals Process Explorer to check the process(es) related to PID 4. You can download ProcessExplorer at the following link: https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
I also keep getting “The handle is invalid” when attempting to close a System handle (PID: 4).
The only antivirus we have is the built-in defender and Malwarebytes. Unfortunately, I cannot disable Malwarebytes.
I have not been able to resolve this.
Closing a handle that isn’t yours to close is a VERY BAD IDEA. Handles get reused by Windows, so if you close handle H belonging to app A, there’s a risk that H may be reassigned to some other app B. Since A doesn’t know that H was closed (because nobody told it), if it decides to manipulate whatever object H is now referring to, it will be manipulating an object belonging to B, most likely corrupting it. Should A now decide to close H (which is no longer A’s handle to close, but again: A doesn’t know this), the problem of possible reassignment and data corruption repeats itself. This can go on indefinitely, corrupting huge amounts of data. Though the above described scenario may not be very likely to occur, it is indeed a real possibility. Therefore, the best way to close a handle is either to (a) make the app that opened it close it or (b) shut down your PC.
Peter,
There are reasons for doing this. Don’t need a lecture.
I’m getting “The handle is invalid” from plain local NTFS USB disks in Windows 10 pro. As the process involved is System, trying to close it, likely can’t succeed, or wouldn’t end well anyway.
The related handles refers to \$Extend\$RmMetadata\ so closing them should be safe, as no other process reasonably has any business there, especially once the disk is no longer attached, but even as administrator, I’m not allowed to close them, which needs to be rectified, as it is MY computer, after all.
It smells like some Windows services such as Distributed-Tracking and/or Windows-Search, etc.: maybe try to disable it and try again?
Also, take a look at this very useful thread on that same topic:
https://superuser.com/questions/491539/how-to-safely-remove-a-device-blocked-by-the-system-process-with-a-handle-on-e
That could help you to find the underlying cause of the issue.
Good luck!
Hey ho!
A few days ago my telegram desktop app started facing an issue causing it to not be able to start: the log.txt file inside the installation folder (AppData\Roaming\Telegram Desktop) was locked by another program/handle.
My first move was to use the unlocker to rename the file – which only worked by letting it restart the pc and accessing the file before startup, which actually worked.. but as anticipated: after the next reboot the file was blocked again.
Since then I tried everything, from the Resource Monitor to the Process Explorer and even using Handle, to figure out wtf is blocking that textfile. But none of these softwares was able to find a handle which is using this file.
I’m somewhat getting desperate here.. is there something else I can try?
Cheers!
Been killing the process for few years. With handle.exe, now job getting easier. Thanks.
If the process that has the file handle locked is “system”, I’m not sure I can kill that process!
You most definitely “can”… but there are a number of scenarios where you really shouldn’t. This post is mostly meant to handle situations where you have locked archive files (image, video or Mp3 files, and so on) by known “non critical” processes: for a SYSTEM lock I would definitely suggest to gracefully shutdown the service that is locking the file (or reboot the system) instead than going for the process kill.
Following the superuser.com link above, I found the suggestion to open “Computer Management” (as admin), go to “Disk Management”, right-click the affected drive and set it to Offline.
After that, I have been able to “safely remove” several USB drives that otherwise would neither budge to the regular remove command (Microsoft, should you be listening, a command is not a suggestion – it is an order), nor to third party “ejector” type programs.
While evaluating this approach, I did verify that the System process was keeping a few
\$Extend\$RmMetadata\ handles open on the USB disk. As I found no other reasons for Windows to obstruct, I guess just unplugging the drives would also have been safe.
Then again, if so, why didn’t Windows close the handles and eject the disk? If it’s just a bug, why hasn’t it been fixed in all these years? Either way, “guess” does not belong in the same context as “backup”, where 99% sure equals doesn’t know. I’m doing this to not guess.
For context, I have disabled indexing on these USB drives and I am using “quick removal” (no write caching). In my case, ExFAT, which doesn’t have the $Extend\ in the first place, might be viable, though with certain pros and cons outside the scope of this thread.