Handle Output

When not in search mode (enabled by specifying a name fragment as a parameter), Handle divides its output into sections for each process it is printing handle information for. Dashed lines are used as a separator, immediately below which you will see the process name and its process id (PID). Beneath the process name are listed handle values (in hexadecimal), the type of object the handle is associated with, and the name of the object if it has one.

When in search mode, Handle prints the process names and id’s are listed on the left side and the names of the objects that had a match are on the right.

More Information

You can find more information on the Object Manager in Windows Internals, 4th Edition or by browsing the Object Manager name-space with WinObj.

Download Handle (887 KB)

Windows find file handles

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I need to discover what file handles a process has open. The best example is what system internals ProcessExplorer does.
However they use NtQuerySystemInformation which it a C++ call.

While I’m not against wrapping the call I figure there must be a direct C# call.

The closest c# option I can find is WMI calls.
Win32_Process will tell me what processes I’m running but it won’t tell me what file handles I have open.

Question:
1) Is there a WMI call that can tell me what File Handles are open? Either for a given process or at least what PID is holding the file handle?
2) Is there any other call I can do to copmlete this task?

Answers

All replies

Ya, I’ve actually already started using this particular project. It covers what I need but it’s not in C# and as you point out, its never going to be forwards compatible.

NtQuerySystemInformation is not recommended to use in applications, so I do not suggest it even though you may be able to P/Invoke the API from C#.

I’m not aware of a WMI class that can tell what file handles are open. May I know the business requirement behind the request of enumerating open file handles for a process? If you want to find out who has a file open, you may propably try the restart manager API which is available in Windows Vista and later operating systems.

http://msdn.microsoft.com/en-us/library/aa373524(VS.85).aspx
The primary reason software installation and updates require a system restart is that some of the files that are being updated are currently being used by a running application or service. Restart Manager enables all but the critical applications and services to be shut down and restarted . This frees the files that are in use and allows installation operations to complete. It can also eliminate or reduce the number of system restarts that are required to complete an installation or update.

Another idea is to redirect stdIO of handle.exe utility
http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx
and parse its output to get the opened files of a process. However, third party applications are not allowed to distribute the tool:

http://technet.microsoft.com/en-us/sysinternals/bb847944.aspx
Q: May I distribute Sysinternals utilities in my software, on my website, or with my magazine?
A: No. We are not offering any distribution licenses, even if the 3rd party is distributing them for free. We encourage people to download the utilities from our download center where they can be assured to get the most recent version of the utility.

Regards,
Jialiang Ge Please remember to mark the replies as answers if they help and unmark them if they provide no help.
Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.

Find open handles within a Windows program

In Windows (MinGW), my program is inheriting unwanted handles from the calling process.

The process has no need to have these files open, but because it lives on beyond the lifetime of the parent I get the usual problems with files being held open.

On Linux I fix the problem like this:

This does not appear to work in Windows.

How can I determine which file handles have been inherited? How can I then close them?

The project is written in C (no C++) using MinGW and Windows’ Unix compatibility API.

2 Answers 2

I’ve now investigated this somewhat, and I’ve found a solution to the real problem, but not way I had intended.

I had thought that I would be able to find and clean up any undesired open files, but this turns out to be hard. I found a few different tutorials (here, and here) how to do this, but they rely on undocumented APIs. I couldn’t make this technique work — possibly I was doing it wrong, or possibly the API has changed in Windows Server 2012 — but in any case I’m not sure I want to go there; it’s OK for Sysinternals to track this stuff and keep Process Explorer working, but I don’t wish to have that maintenance burden on my project.

I now have two choices:

Put some special case code in the parent (calling) process to have it call CreateProcess with inheritance disabled, when appropriate (it currently uses _spawnlp because it’s compatible with the Unix-style pipes and file handles, and you can’t use CreateProcess with those very reliably).

Have the process immediately call itself with CreateProcess and then exit (or wait indefinitely) in order to kill any unwanted handles.

The first feels more efficient. The second is more flexible (it allows the process to choose for itself).

I think I’m going to choose option one because, for my current needs, it feels like the least worst.

How to do a simple file search in cmd

I want to quickly search for a file given its name or part of its name, from the windows command line (not power shell). This is similar to opening explorer and using the search box at the top.

Note: dir can search based on a string template but it will not search in the subdirectories.

Note2: findstr can be used to search for a token inside files and has a recursivity flag; it’s funny that a more complex find can be easily discovered .

5 Answers 5

dir /s *foo* searches in current folder and sub folders.

It finds directories as well as files.

/s Lists every occurrence of the specified file name within the specified directory and all subdirectories.

searches for all txt file in the directory tree. Before using it just change the directory to root using

you can also export the list to a text file using

and search within using

EDIT 1: Although this dir command works since the old dos days but Win7 added something new called Where

will search for exe & dll in the drive c:\Windows as suggested by @SPottuit you can also copy the output to the clipboard with

just wait for the prompt to return and don’t copy anything until then.

EDIT 2: If you are searching recursively and the output is big you can always use more to enable paging, it will show — More — at the bottom and will scroll to the next page once you press SPACE or moves line by line on pressing ENTER

How to Identify the Process that has Locked a File in Windows

When you attempt to delete a file or folder which is in use by a process, the File In Use dialog appears showing the name of the program that has locked the file.

However, there are cases where the “File In Use” dialog doesn’t show the name of the process that has a lock on the file you’re trying to delete. In some cases, the dialog will show “the action can’t be completed because the file is open in another process“.

For investigating processes and locked files, Windows Sysinternals Process Explorer is probably the first option that comes to mind for most users. However, there are two built-in solutions to display the current open files list along with corresponding process names.

Find which process has locked a file using:

1. Resource Monitor

Resource Monitor (resmon.exe) is a built-in tool that has many useful features. With Resource Monitor, you can track current network and internet usage, view associated handles for locked files, as well as manage processes just as you’d using the Task Manager.

To find the process name that has a file locked, click the CPU tab, type the file name or part of it in the Associated Handles text box.

2. Process Explorer

Process Explorer needs no introduction. In Process Explorer, all you need to do is use the Find feature and type in the file name. This shows the process that’s accessing the file.

From the lower pane view, you can close the file handle if necessary.

You must run Process Explorer as administrator in order to manage processes which are running elevated. To elevate Process Explorer, click the File menu → Show Details for All Processes.

3. Handle from Windows Sysinternals

Handle is a utility from Microsoft Sysinternals that displays information about open handles for any process in the system. You can use it to see the programs that have a file open, or to see the object types and names of all the handles of a program. Handle is like a command-line version of Process Explorer.

Note: Handle v4.21 has a small bug where it always reports “No matching handles found” if the drive-letter is in uppercase. Hope Microsoft fixes it in the next update.

From an admin Command Prompt window, use the command-line syntax to find the process which is having the file open:

If the file name contains spaces, enclose it within double quotes.

Example:

(Mentioning the filename without the path may not necessarily work in every situation. It’s advisable to include the full path always.)

The output shows the process name, the process identifier, user name, the locked (target) file name with path.

Sysinternals Handle: Command-line arguments

No arguments will dump all file references.

Add Sysinternals Handle to right-click menu

You can add Sysinternals Handle to the right-click menu for files to quickly find the program that has locked the file. To add it to the context menu, follow these steps:

1. Download Handle from Microsoft Sysinternals site.
2. Copy the files handle.exe & handle64.exe to a folder – e.g., d:\tools
3. Copy the following lines of code to Notepad, and save the file as find_handle.vbs to a permanent location.

Note: The Sysinternals Handle.exe path is hard-coded as d:\tools\handle.exe in the above script. If the program is located on a different path, modify the path in the script accordingly. For 64-bit Windows, you can use either handle.exe or handle64.exe