One thing that annoys me no end about Windows is the old sharing violation error. Often you can't identify what's holding it open. Usually it's just an editor or explorer just pointing to a relevant directory but sometimes I've had to resort to rebooting my machine.

Any suggestions on how to find the culprit?

  • 9,999
  • 9
  • 37
  • 40
  • 21
    You would think that after all this time, the Windows guys would give us a way to do this easily from within Explorer. I wonder why this hasn't happened? –  May 05 '09 at 00:19
  • 12
    I find that Explorer is very often the problem process that is holding onto a file for no obvious reason. – Eddie May 08 '09 at 15:49
  • I know this doesn't help you much, but I think I remembered that this was a planned feature of the next Windows release after vista and 2008 server. or maybe it's a WinFS thing. not sure where i read that... – Kip May 30 '09 at 00:00
  • see my answer on [superuser here](https://superuser.com/a/1485069/16847), in summary [OpenedFilesView](https://www.nirsoft.net/utils/opened_files_view.html) still works in 2019 – Vijay Sep 22 '19 at 12:42
  • 2
    2021... Issue still exists in Windows 10. Randomly got to this question on unrelated search. When I stumble upon this problem with something holding the file, it's often `explorer.exe` as Eddie suggested, I kill `explorer.exe` from Task Manager, this fixes the issue and disables almost all UI. Now you need to restart your `explorer.exe`, I just press Win+R and type `explorer.exe` there and press enter, it starts `explorer.exe` and life is good again :). – KulaGGin Mar 07 '21 at 07:14
  • Hard Mode: Without installing anything (no Sysinternals) and without admin access (no resmon) I don't think it's possible - for the average cubicle jockey that doesn't have admin rights and isn't allowed to install utilities, you're probably going to have to cough up the 5 minutes of your work day and reboot. – Jonathan Baldwin Oct 21 '21 at 16:17

18 Answers18


I've had success with Sysinternals Process Explorer. With this, you can search to find what process(es) have a file open, and you can use it to close the handle(s) if you want. Of course, it is safer to close the whole process. Exercise caution and judgement.

To find a specific file, use the menu option Find->Find Handle or DLL... Type in part of the path to the file. The list of processes will appear below.

If you prefer command line, Sysinternals suite includes command line tool Handle, that lists open handles.


  • c:\Program Files\SysinternalsSuite>handle.exe |findstr /i "e:\" (finds all files opened from drive e:\"
  • c:\Program Files\SysinternalsSuite>handle.exe |findstr /i "file-or-path-in-question"
  • 4,805
  • 5
  • 25
  • 33
  • 11,432
  • 8
  • 37
  • 48
  • 22
    You can close the handle, but keep in mind, you're pulling the rug out from under an application, results will be unpredictable at best. – WaldenL May 01 '09 at 21:57
  • 13
    @Walden: Absolutely. YMMV. With WinXP, I've many times had Explorer open a handle for no obvious reason and refuse to close it. When this happens on a file you need to delete, you have the choice of forcing the handle closed, or rebooting. So far, having done this dozens of times, I have suffered no ill effect. As with any advanced tool, use with caution and judgment. – Eddie May 01 '09 at 22:32
  • 6
    Closing the handles can cause the app to re-use the handle on another file, causing corruption - see Jeff's answer below: http://serverfault.com/a/15695/79266 ... much safer to kill the application holding the file open, if you don't want to reboot. – RichVel Mar 30 '12 at 08:32
  • 14
    For explorer, btw, hold ctrl-shift and right-click a blank area of the start menu, and you'll get "Exit Explorer" - ps, not quite Jeff's answer.. – Mark Sowul Apr 02 '12 at 18:56
  • I have on more than one occasion had this cause a blue screen for me. Closing random handle to a file. – floyd Sep 06 '12 at 23:34
  • processexplorer (and most of the Sysinternals tools) is great. Use it to find the process which have the handle open, but then close the process (not the handle!) (see below for Raymond's Chen nice explanation about the danger of closing the handle! in a nutshell, that handle once closed could be reused by another app, and therefore point to another file. The original app could then maybe write/close/change that other file, thinking it's still pointing to the original file! Possibly causing corruption in the new file pointed at.) – Olivier Dulac Dec 10 '12 at 16:48
  • 2
    It doesn't help for non executive file i.g. a text file. I need to know who is writing to a log file. Any idea? – Xaqron Mar 06 '13 at 23:54
  • 2
    sure this works for a text file. It doesn't care what kind of file is open. – Eddie Apr 08 '13 at 17:15
  • Process Explorer solved the problem for me. The weird thing is that it was the flash player plugin, a sub-process of the browser. I don't understand why that was, but it's a mystery for another time. – Vince Aug 17 '15 at 14:14
  • 4
    It should be noted that ProcessExplorer must be run _as Administrator_ or it may not able to see files open by system processes. – end-user May 04 '17 at 10:22
  • 1
    @MarkSowul I don't see that menu in Win10. To restart explorer I normally run `taskkill /f /im:explorer.exe` then open task manager and run `explorer` – Carl Walsh Oct 11 '17 at 15:00
  • It's not longer there in Windows 10. But now you'll see "Restart" (instead of "End Task") if you select Windows Explorer in Task Manager (in "processes" after selecting "more details", if you have only the simple task list currently shown). – Mark Sowul Oct 15 '17 at 20:27
  • @Xaqron I'm having the same problem. My log file isn't on my C:\ drive, it's on my D:\ drive. I'm wondering if that's the reason why when I search for the file name, it doesn't show in the results. I've also tried putting in the path and file name into the search box, still doesn't find it. – Eric Milliot-Martinez Jan 17 '18 at 15:14
  • 0 results, file is still locked... – Aaron Franke Feb 03 '18 at 00:51
  • While useful, Process Explorer really didn't tell me what the problem was - having the drive shared. Once I turned off sharing for the drive, the open handles went away. – FKEinternet Feb 26 '18 at 00:47
  • Make sure Process Explorer is in "Handle Mode". View > Lower Pane Mode, or press `Ctrl + H`. – Protector one Jul 18 '18 at 14:55
  • you don't need to use `findstr`. v4.22 and perhaps earlier ` handle` will search by name: e.g. `handle name-fragament-i-cant-delete`. This method also shows more info than the findstr method does: https://i.imgur.com/JYtVLvM.png – matt wilkie Dec 30 '21 at 17:31
  • Using handle, I found I had to escape the backslash, ie "E:\\" – johnny Feb 25 '23 at 12:22

You can use the Resource Monitor for this which comes built-in with Windows 7, 8, and 10.

  1. Open Resource Monitor, which can be found
    • By searching for Resource Monitor or resmon.exe in the start menu, or
    • As a button on the Performance tab in your Task Manager
  2. Go to the CPU tab
  3. Use the search field in the Associated Handles section
    • See blue arrow in screen shot below

When you've found the handle, you can identify the process by looking at the Image and/or PID column.

You can then try to close the application as you normally would, or, if that's not possible, just right-click the handle and kill the process directly from there. Easy peasy!

Resource Monitor screenshot

Copied from my original answer: https://superuser.com/a/643312/62

  • 6,977
  • 15
  • 38
  • 45

Just be very careful with closing handles; it's even more dangerous than you'd think, because of handle recycling - if you close the file handle, and the program opens something else, that original file handle you closed may be reused for that "something else." And now guess what happens if the program continues, thinking it is working on the file (whose handle you closed), when in fact that file handle is now pointing to something else.

see Raymond Chen's post on this topic

Suppose a search index service has a file open for indexing but has gotten stuck temporarily and you want to delete the file, so you (unwisely) force the handle closed. The search index service opens its log file in order to record some information, and the handle to the deleted file is recycled as the handle to the log file. The stuck operation finally completes, and the search index service finally gets around to closing that handle it had open, but it ends up unwittingly closing the log file handle.

The search index service opens another file, say a configuration file for writing so it can update some persistent state. The handle for the log file gets recycled as the handle for the configuration file. The search index service wants to log some information, so it writes to its log file. Unfortunately, the log file handle was closed and the handle reused for its configuration file. The logged information goes into the configuration file, corrupting it.

Meanwhile, another handle you forced closed was reused as a mutex handle, which is used to help prevent data from being corrupted. When the original file handle is closed, the mutex handle is closed and the protections against data corruption are lost. The longer the service runs, the more corrupted its indexes become. Eventually, somebody notices the index is returning incorrect results. And when you try to restart the service, it fails because its configuration files have been corrupted.

You report the problem to the company that makes the search index service and they determine that the index has been corrupted, the log file has mysteriously stopped logging, and the configuration file was overwritten with garbage. Some poor technician is assigned the hopeless task of figuring out why the service corrupts its indexes and configuration files, unaware that the source of the corruption is that you forced a handle closed.

Mark Sowul
  • 1,839
  • 1
  • 11
  • 14
  • 14
    important warning, this should go nearer the top - a reboot is probably better than a silently corrupted file. – RichVel Mar 30 '12 at 08:27
  • 12
    +1 This will certainly make me think twice about forcing handles closed! It seems strange to me that Windows would immediately re-use the number of a closed handle, rather than continuing to increment the number and only wrapping around when necessary. That would at least greatly reduce the chances of this problem happening. – EM0 Dec 08 '14 at 20:49
  • 3
    @RichVel Terminating the culprit process is probably better than a complete reboot. – Dmitry Grigoryev May 05 '17 at 08:21
  • @DmitryGrigoryev - good point, and in fact I already mentioned that [here](https://serverfault.com/questions/1966/how-do-you-find-what-process-is-holding-a-file-open-in-windows#comment383110_1980) – RichVel May 24 '17 at 08:27
  • Wow. Raymond Chen blows me away every time I read something he writes. – pomeroy May 24 '17 at 21:06
  • 3
    This is a very important warning, but doesn't answer the question *How do you find what process is holding a file open in Windows?* –  Jul 26 '17 at 14:56
  • This is probably a "legacy" characteristic of Windows which they never changed, but still very much need to change because it is a security vulnerability. Since "handles" are simply integers, they should never be re-issued. (Even if the underlying resource, the open-files table entries, are of course reused.) – Mike Robinson Mar 03 '20 at 16:07
  • 1
    I don't think it is a security vulnerability. The process already has access to whatever it had access to. Raymond describes this situation as "It rather involved being on the other side of this airtight hatchway" -- a recent example: https://devblogs.microsoft.com/oldnewthing/20200203-00/?p=103391 – Mark Sowul Mar 03 '20 at 19:16
  • This probably isn't likely to change -- it's probably not a deliberate reuse; handles can just be "the memory address of this thing", and as memory is freed and reused, so too do the "handle values" get reused. – Mark Sowul Mar 03 '20 at 19:17
  • @EM0 that's an entirely sensible improvement which a majority of ordinary people support. It's a shame none of the general computing population has the legal right to just, you know, fix the operating system's flaw ourselves to improve everyone's lives. – iono Jul 04 '22 at 04:41

If you are having enough privileges, try the openfiles command.

You might have to enable listing of localy opened files by running openfiles /local on and rebooting.

  • 3,037
  • 6
  • 27
  • 40
John Fouhy
  • 1,141
  • 7
  • 4
  • 10
    +1 for a builtin command, although I personally use ProcessExplorer for this most of the time. – RBerteig May 06 '09 at 02:04
  • Really helpful. – marko Sep 22 '11 at 08:40
  • 8
    ERROR: The target system must be running a 32 bit OS. – Bozojoe Oct 24 '12 at 17:29
  • 5
    doesn't work for 64 OS! –  Sep 30 '14 at 15:14
  • 15
    This looks to be working for Windows 2012R2 64bit, but you need to enable the "open local tracking" service by running `openfiles /local on` and restarting. This makes this feature not very useful. – Guss Aug 30 '15 at 13:06
  • 1
    `C:\WINDOWS\system32>openfiles /local on` `SUCCESS: The system global flag 'maintain objects list' is enabled. This will take effect after the system is restarted.` Oh great, that was helpful thanks. – Andrew Oct 28 '17 at 07:41
  • John all contributions are appreciated, I was not aware of this command, thank you. What do you think of editing the answer to clarify it requires a 32-bit system, or possibly turning on a service to work with 64-bit versions? As @Guss and others have pointed out, sometimes alternates paths may be more optimal. You might save people sum total lots of time (a bit of time x number of users reading the answer) . Respectfully - – whitneyland Mar 11 '19 at 20:08

I've used Handle with success to find such processes in the past.

Greg Hewgill
  • 6,849
  • 3
  • 30
  • 26
  • 4
    I use this tool all the time. If I can't eject a USB drive, I just type "handle H:" (or whatever the drive letter). Best of all, you can use it to force close handles. – Chris Thompson May 02 '09 at 07:02
  • I've been told so many times at SO that link-only answers are discouraged. With this here now I'm one of those purists. ;) – Gerold Broser Sep 12 '21 at 12:16

Lockhunter (http://lockhunter.com/) works on 32 and 64bit systems.

  • 524
  • 6
  • 9
  • It's also available from that file's context menu in Windows Explorer. – user61849 Jun 26 '19 at 22:01
  • 1
    In my case none of other answers worked, also Lockhunter when I typed in the file name did not find any process locking it, but the context menu option worked! Thanks! – raj Feb 25 '21 at 13:14
  • I've been told so many times at SO that link-only answers are discouraged. With this here now I'm one of those purists; and even a double one. ;) – Gerold Broser Sep 12 '21 at 12:17
  • @GeroldBroser this was one of the best answers I've seen here and it's "link only". You might wanna rethink your last statement lol – Gaspa79 Dec 02 '21 at 17:26
  • @Gaspa79 My last statement is the "double one". And this is still true. See my comment to [the answer above(AToW)](https://serverfault.com/a/1970/249782). :) – Gerold Broser Dec 02 '21 at 20:06
  • @GeroldBroser Lol wtf. This link only answer is still one of the best I've seen in SO. – Gaspa79 Dec 14 '21 at 15:42

Just to clarify, this is more likely to be a result of misbehaving 3rd party apps not using the CreateFile API call correctly than it is to be anything in Windows itself. Perhaps it's a consequence of the design of CreateFile, but done is done and we can't go back.

Basically when opening a file in a Windows program you have the option to specify a flag that allows shared access. If you don't specify the flag, the program takes exclusive access of the file.

Now, if Explorer seems to be the culprit here, it may be the case that that's just on the surface, and that the true culprit is something that installs a shell extension that opens all files in a folder for it's own purposes but is either too gung-ho in doing so, or that doesn't clean up properly after itself. Symantec AV is something I've seen doing this before, and I wouldn't be surprised if other AV programs were also to blame. Source control plug-ins may also be at fault.

So not really an answer, but just some advice to not always blame Windows for what may be a badly written 3rd party program (something that can also happen on any other OS which has implicit file locking, but any unix based OS has shared access by default).

Maximus Minimus
  • 8,987
  • 2
  • 23
  • 36
  • 2
    I won't blame a 3rd party app on the fact that my windows explorer always locks Thumbs.db files in its working directory, but does not always unlock it when I switch working directory. At least they are unlocked when I close the window, I don't have to kill ALL explorers... – Alexander Mar 07 '14 at 07:32
  • @Darth, Are you a marketer from Microsoft? – Pacerier Jun 08 '15 at 20:29

Apropos Explorer holding a file open: "When this happens on a file you need to delete, you have the choice of forcing the handle closed, or rebooting."

You can just end Explorer.

If this is a one-time thing (Explorer does not normally hold this file open) then I would guess logging off and logging back on will do the trick.

Otherwise, kill the desktop Explorer process and do what you want while it's gone. First start a copy of cmd.exe (you need a UI to do your intended cleanup). Make sure there are no non-desktop Explorers running. Then kill the last Explorer with, e.g., Task Manager. Do what you want in the command prompt. Finally, run Explorer from the command prompt, and it will become the desktop.

I'd guess there may be some residual unpleasantness if some systray programs can't deal with the shell restarting.

  • 1
    This is much safer than closing the handle, and less disruptive than rebooting. Applies to other programs too - I often find a Microsoft Office program holds locks on files even after I've closed them. – RichVel Mar 30 '12 at 08:30

On a remote server, when you're checking on a network share, something as simple as the Computer Management console can display this information and close the file.

K. Brian Kelley
  • 9,034
  • 32
  • 33

Who Lock Me works well and keeps people amused with the name!

  • 16,758
  • 4
  • 29
  • 50
Generic Error
  • 593
  • 3
  • 8
  • 16

Files can be locked by local processes (unlocker is the tool to use) and by file access that comes in through shares.

There is a built-in function in Windows that shows you what files on the local computer are open/locked by remote computer (which has the file open through a file share):

* Select "Manage Computer" (Open "Computer Management")
* click "Shared Folders"
* choose "Open Files"

There you can even close the file forcefully.

Dirk Paessler
  • 914
  • 1
  • 7
  • 15

With Process Hacker you can identify what processes are holding your files easily:

Find Handles or DLLs

Ivan Kochurkin
  • 183
  • 1
  • 1
  • 6

There is NirSoft's Opened Files View as well.


  • 1
    Personally I like this better than Process Explorer for this specific tasks. – JamesBarnett Feb 25 '13 at 19:38
  • I've been told so many times at SO that link-only answers are discouraged. With this here now I'm one of those purists; and even a quadruple one. ;) – Gerold Broser Sep 12 '21 at 12:20
  • @GeroldBroser: You seem to have a wrong impression of "link-only answer". It does not mean that the answer contains a link which is relevant to the entire answer. It means that if the link cannot be followed (e.g. you look at a screenshot of the answer) that all information is lost. That isn't the case here, with no links this is still a valid answer (and already was in the version you commented on, as the text alone was meaningful, although the image definitely improved the answer). – Ben Voigt Mar 30 '22 at 20:26

There have new PowerToys available from Microsoft.

File Locksmith utility for Windows | Microsoft Learn

After installing PowerToys, right-click on one or more selected files in File Explorer, and then select What's using this file? from the menu.

Ivan Chau
  • 261
  • 1
  • 12

The above upvoted answers cover situations where a program process is holding the file handle open, which (fortunately) is most of the time - however in some cases (as is occurring on this system at the moment), the system itself holds a file handle open.

You can identify this situation by following the instructions to find the file handle holding process with process explorer above, and noting that the process name is listed as 'system', or by following the the instructions using resource monitor and noting that no image is shown having a filehandle open on your file of interest (Although obviously something does as you can't edit/delete etc the file).

If that happens, your option (so far as I'm aware) is to restart - or forget about doing anything with that file.

  • 31
  • 2

I got turned on to the Free Extended Task Manager a while ago by Jeremy Zawodny's blog, and it's great for tracking down further info on processes too. +1 for Process Explorer as above, too, especially for killing processes that the standard Task Manager won't end.

Gerold Broser
  • 148
  • 1
  • 9
  • 5,630
  • 5
  • 32
  • 52

You can also do it programmatically by leveraging on the NTDLL/KERNEL32 Windows API. E.g. have a look at the following code in Python:

import ctypes
from ctypes import wintypes

path = r"C:\temp\test.txt"

# -----------------------------------------------------------------------------
# generic strings and constants
# -----------------------------------------------------------------------------

ntdll = ctypes.WinDLL('ntdll')
kernel32 = ctypes.WinDLL('kernel32', use_last_error=True)

NTSTATUS = wintypes.LONG

INVALID_HANDLE_VALUE = wintypes.HANDLE(-1).value

FileProcessIdsUsingFileInformation = 47


# -----------------------------------------------------------------------------
# create handle on concerned file with dwDesiredAccess == FILE_READ_ATTRIBUTES
# -----------------------------------------------------------------------------

kernel32.CreateFileW.restype = wintypes.HANDLE
kernel32.CreateFileW.argtypes = (
    wintypes.LPCWSTR,      # In     lpFileName
    wintypes.DWORD,        # In     dwDesiredAccess
    wintypes.DWORD,        # In     dwShareMode
    LPSECURITY_ATTRIBUTES,  # In_opt lpSecurityAttributes
    wintypes.DWORD,        # In     dwCreationDisposition
    wintypes.DWORD,        # In     dwFlagsAndAttributes
    wintypes.HANDLE)       # In_opt hTemplateFile
hFile = kernel32.CreateFileW(
    raise ctypes.WinError(ctypes.get_last_error())

# -----------------------------------------------------------------------------
# prepare data types for system call
# -----------------------------------------------------------------------------

class IO_STATUS_BLOCK(ctypes.Structure):
    class _STATUS(ctypes.Union):
        _fields_ = (('Status', NTSTATUS),
                    ('Pointer', wintypes.LPVOID))
    _anonymous_ = '_Status',
    _fields_ = (('_Status', _STATUS),
                ('Information', ULONG_PTR))


    _fields_ = (('NumberOfProcessIdsInList', wintypes.LARGE_INTEGER),
                ('ProcessIdList', wintypes.LARGE_INTEGER * 64))


ntdll.NtQueryInformationFile.restype = NTSTATUS
ntdll.NtQueryInformationFile.argtypes = (
    wintypes.HANDLE,        # In  FileHandle
    PIO_STATUS_BLOCK,       # Out IoStatusBlock
    wintypes.LPVOID,        # Out FileInformation
    wintypes.ULONG,         # In  Length
    FILE_INFORMATION_CLASS)  # In  FileInformationClass

# -----------------------------------------------------------------------------
# system call to retrieve list of PIDs currently using the file
# -----------------------------------------------------------------------------
status = ntdll.NtQueryInformationFile(hFile, ctypes.byref(iosb),
pidList = info.ProcessIdList[0:info.NumberOfProcessIdsInList]
  • 121
  • 4

There is a tool FILEMON and shows open files and handles. Its hard to keep up with its display if you watch it live, it does so quickly. But you can stop it from displaying live and you can watch all file open/write activity. Now owned by Microsoft but originally by Sysinternals

  • 41
  • 3
  • 1
    The updated version of this is process monitor. You can get it here:[http://technet.microsoft.com/en-us/sysinternals/bb896645](http://technet.microsoft.com/en-us/sysinternals/bb896645) – yitwail Jun 09 '11 at 19:49