Using Handle View in Process Explorer

Learn how to inspect, search, and interpret open Windows handles in Process Explorer, diagnose locked files, and investigate resource access safely.

A Windows handle is a process-specific value used to access an operating system object. Objects include files, registry keys, synchronization objects, processes, threads, tokens, pipes, and devices. A handle is not the object itself; it is the reference that a particular process uses to work with that object.

Handle View is the Process Explorer lower-pane display that lists handles opened by the selected process. It is useful when you need to discover which resources an application currently has open, especially when troubleshooting locked files, registry usage, interprocess communication, or unexpected resource access.

This lesson assumes familiarity with selecting processes in Process Explorer, Windows paths and permissions, administrative elevation, and the difference between processes, threads, services, and DLLs. For broader orientation, see the Process Explorer course.

What Handle View Shows

Handle View exposes the resources currently opened by one selected process. Typical uses include:

Finding the process that prevents a file or directory from being renamed, deleted, replaced, backed up, or ejected.
Identifying registry keys opened by an application, service, policy component, or management tool.
Investigating named events, mutexes, semaphores, timers, and sections used for synchronization or shared memory.
Understanding whether a process is connected to other processes, threads, pipes, devices, or services.
Comparing the resources used by two applications that perform similar work.

Opening and Navigating Handle View

Enable the lower pane

Start Process Explorer and select a process in the upper process tree.
Enable the lower pane using the version-appropriate menu command, commonly View > Lower Pane > Show Lower Pane. Some versions also provide a toolbar button or keyboard shortcut; labels can vary.
Use the lower-pane view selector, commonly under View > Lower Pane View, to choose Handles rather than DLLs.

The upper pane remains the process list. The lower pane changes according to the process selected above it. Resize the lower pane by dragging its border. Hide it when you need more room for the process tree, and show it again when investigating a selected process.

Unless you are using the global search command, the lower-pane results belong to the currently selected process. Selecting another process refreshes the list for that process. This makes it possible to compare applications by selecting them one at a time and noting their object types, names, and access information.

The lower pane can also display loaded modules. Switch to DLLs when investigating mapped libraries, and switch back to Handles when investigating open operating system objects. The DLL View provides a separate explanation of module inspection.

Handle List Columns and Object Details

Column names and available details vary with the Process Explorer version, Windows version, object type, and your permissions. Common columns include:

Column	Meaning
Handle	The process-local numeric handle value. The same number in two processes does not refer to the same object.
Type	The object category, such as File, Key, Event, Mutant, Process, Thread, Section, or Token.
Name	The object path or namespace name, when available.
Access	Access rights requested or granted for the handle, when Process Explorer can display them.
Protection or attributes	Additional protection-related or object-specific information, when available.

Click a column heading to sort by that column. Drag column borders to reveal long names, and use horizontal scrolling when necessary. Sorting by Type groups files, keys, synchronization objects, and other categories. Sorting or scanning by Name helps locate a directory, registry fragment, pipe, or device.

Object names may represent several naming systems:

File system paths for documents, executables, logs, temporary files, and directories.
Registry paths for configuration and policy data.
Kernel object namespaces for named events, mutexes, sections, timers, and other objects.
Device paths, pipes, service-related objects, and driver resources.

Names can be blank, inaccessible, or truncated. Handles can also appear and disappear rapidly as a process opens and releases resources. These conditions are normal and do not, on their own, indicate malicious activity.

Common Handle Object Types

Common Handle Object Types and What They Indicate
Object type	Typical purpose	Example object name pattern	Troubleshooting relevance	Risk of force-closing
File	Open documents, executables, logs, temporary files, directories, or mapped resources.	A drive-letter path or a device-style file path.	Common starting point for file-lock and removable-drive investigations.	Can interrupt reads or writes, corrupt data, or leave an application unstable.
Key	An open Windows Registry key used for configuration, policy, services, or application settings.	A registry-root path such as a machine or user configuration namespace.	Shows which process has opened a registry location.	Can disrupt configuration operations or cause application errors.
Event	Signals that a condition or operation has occurred.	A named object under a kernel object namespace.	Helps explain wait, notification, and single-instance behavior.	Can break synchronization and produce hangs or incorrect behavior.
Mutant	Windows terminology commonly associated with a mutex, which limits access to one process or thread at a time.	A named synchronization object.	May identify a single-instance marker or coordination mechanism.	Can permit conflicting operations or make an application malfunction.
Semaphore or Timer	Coordinates access to a limited resource or schedules signaling.	A named or unnamed kernel object.	Useful when investigating worker coordination and timing behavior.	May cause deadlocks, missed signals, or uncontrolled concurrency.
Section	Shared memory or a memory-mapped file.	A named section or mapped-resource name.	Can reveal shared-memory or mapped-file relationships.	May break IPC or invalidate assumptions about mapped data.
Process or Thread	A debugger, parent process, security product, or management tool holds a reference to another process or thread.	A process or thread identifier and, sometimes, a related name.	Helps explain monitoring, debugging, or management relationships.	Can interfere with diagnostics or process control.
Token, Job, Desktop, or WindowStation	Security, grouping, session, desktop, and user-interface resources.	Session- or namespace-related names.	Useful for access, session, service, and desktop investigations.	Can disrupt security context or user-session behavior.
Named pipe, device, or network-related object	Interprocess communication, driver access, services, or network operations.	A pipe namespace, device path, or system-managed name.	Can identify IPC peers, device access, or service activity.	May terminate communication or destabilize a client or service.

Searching for Handles and DLLs Globally

When you do not know which process owns a resource, use the global Find Handle or DLL feature. Open it from the Process Explorer menu, commonly Find > Find Handle or DLL; the keyboard shortcut can vary by version.

Enter a distinctive filename, directory fragment, registry-key fragment, pipe name, or other object-name text.
Prefer a short but unusual term. A unique filename is usually better than a common word such as data or system.
Review each result to identify the owning process and the matching handle or loaded module.
Select a result to navigate to its owning process, then inspect the process's lower-pane Handle View and process properties.

Handle Search Result Interpretation
Result field	What it identifies	How to validate it	Common misinterpretation
Process name or PID	The process that owns the matching handle or module.	Check the process path, publisher, command line, user, parent, and service association.	Assuming a familiar process name is automatically trustworthy.
Match text	The displayed object name or loaded-module name containing the search term.	Inspect the complete name and object type in the lower pane.	Assuming every textual match is the exact file or registry object expected.
Object type	Whether the match is a File, Key, synchronization object, or another handle category.	Compare the type with the original symptom.	Treating a DLL result as an open file handle, or a registry result as proof of modification.
Module result	A DLL or other loaded module whose name matches the search.	Switch to DLL View and inspect the module path and process properties.	Assuming a loaded DLL is holding a file open in the same way as a File handle.

Diagnosing Locked Files and Folders

A file lock is a condition in which an open file or directory prevents an operation such as deletion, renaming, replacement, uninstall, backup, or eject. Use this workflow:

Start with the exact symptom and record the full path or a distinctive filename.
Search globally for the filename or a unique path fragment.
Confirm that the matching result is a File object and identify the owning process.
Inspect the process path, publisher, command line, parent process, user account, service association, and current activity.
Close the owning application normally, or use the application's release, disconnect, or unmount function.
Repeat the search. When the expected result disappears, retry the original operation.

Several processes may legitimately hold the same file. For example, an application may have it open while an antivirus scanner, search indexer, backup agent, or preview component also reads it. An ordinary open handle does not prove that a process is actively modifying the file. To establish modification, correlate the handle with the application's behavior and, when necessary, use a file and registry activity tracing tool rather than relying on Handle View alone.

Example: a document cannot be deleted

Search for the document filename or a unique portion of its path. Identify the process whose result is a File handle. Close that application normally and verify that the result disappears. If the application is unresponsive, assess whether unsaved work, transactions, or other users could be affected before ending it. If a service owns the handle, stop the appropriate service through its normal management path rather than closing an arbitrary handle.

Example: an installer cannot replace an application file

Search for the executable or DLL filename. Possible owners include the application, updater, antivirus scanner, indexing service, or a diagnostic tool. Use process properties and command-line details to determine which process should normally be closed or stopped. Retry the installer after the expected holder releases the file.

Example: a removable drive is reported as in use

Search for a path or filename on the removable volume. Check Explorer windows, command prompts, backup agents, media tools, and applications. Close the relevant window or program and confirm that matching file handles disappear. The absence of one visible file handle does not guarantee that every caching, device, driver, or network condition has cleared, so use the operating system's safe-eject feedback as an additional validation.

Safe Response Options for a Locked Resource
Situation	Preferred action	When escalation is appropriate	Potential consequence
Normal desktop application owns the file	Save work and close the application normally.	Only if it is unresponsive after allowing time for cleanup.	Forced termination can lose unsaved data.
Service owns the file	Use the service's normal stop or restart procedure.	Escalate after checking dependencies and service purpose.	Clients may lose connectivity or queued work.
Several legitimate readers own the file	Close or pause the relevant applications, scanners, or agents.	Escalate when the operation is urgent and the business impact is understood.	Monitoring, scanning, or backup activity may be interrupted.
Unresponsive or unknown owner	Record findings and investigate identity, command line, user, and parent process.	End the process only after assessing consequences and following change procedures.	Data loss, corruption, service interruption, or system instability.
System-critical or protected owner	Avoid handle manipulation; use supported maintenance or restart procedures.	Use documented recovery procedures and appropriate administration.	System failure or security controls being disrupted.

Interpreting Namespaces Correctly

Kernel object paths and namespaces do not always look like familiar Win32 drive-letter paths. A file may appear through a file-system device path rather than a path beginning with a drive letter. Registry objects use registry-root namespaces, while named events, mutexes, sections, and other objects may appear in named kernel namespaces. Pipes and devices use their own naming conventions.

A device-style path can still refer to an ordinary file on a mounted volume.
A registry key handle identifies an opened key, not necessarily a write operation.
A named mutex or event may be normal application coordination.
A blank or truncated name may mean the object is unnamed, inaccessible, or no longer available for display.
A rapidly changing list is expected for applications that perform short-lived operations.

Permissions, Elevation, and Protected Processes

Your account permissions affect which processes and handles Process Explorer can inspect. To obtain broader visibility, run Process Explorer with administrative privileges. Use the supported Run as Administrator option and approve the Windows User Account Control prompt.

Elevation does not remove every restriction. Protected processes and some protected security objects can limit inspection or prevent handle operations even for an administrator. Do not attempt to change handles belonging to system-critical, security, or protected processes unless you are following a documented recovery procedure.

An Access denied result means that a permission or protection boundary prevented inspection or action. It is not evidence that the process is malicious. It may simply be running under another account or using Windows protection features.

Closing an Individual Handle

Process Explorer can offer a Close Handle command for a selected handle in some circumstances. Select the handle in the lower pane, open its context menu, and choose the close command if it is available. Availability depends on permissions, the process, the object, and Windows protections.

Before considering Close Handle, confirm all of the following:

You recorded the process identity, object type, object name, and reason for the action.
You understand what the process does and whether it has unsaved work or active transactions.
You tried closing the owning application normally or using its release or disconnect function.
If the owner is a service, you evaluated whether stopping or restarting that service is safe.
You have appropriate elevation and a recovery plan, including a restart if necessary.

Safer alternatives include closing the application, stopping or restarting the appropriate service, pausing a scanner or backup job through its supported interface, signing out when a user-session resource is involved, or rebooting when appropriate. Related process operations are covered in Process Actions and Kill a Process; ending a process is also disruptive and should be assessed first.

Investigation Workflow and Validation

Define the symptom. Write down the operation that failed and identify the precise file, directory, registry location, pipe, or other object involved.
Search globally. Use Find Handle or DLL with a distinctive term that reduces false matches.
Verify ownership. Confirm the process ID, object type, complete name, and whether the result is a handle or a loaded module.
Inspect context. Review the executable path, publisher or signer, command line, parent process, user account, service association, integrity level, and current activity. Process properties can provide additional context; see Process Properties.
Choose the least disruptive response. Close the application, release the resource, or stop the appropriate service before considering process termination or handle closure.
Validate. Search again after the application closes or service stops. Confirm that the handle disappeared and retry the original operation.
Record findings. Preserve names, process identifiers, timestamps, screenshots or notes, and the action taken before disruptive changes.

Practical Investigation Examples

An application appears to run only once

Inspect its Handle View for a named Mutant or mutex, or a named Event. An application may use a named mutex as a single-instance marker. Do not close the synchronization handle merely to launch a second copy: the application may depend on it for correctness, and removing it can allow conflicting instances or cause failures.

Unexpected access to a registry location

Search for a distinctive registry-key fragment and identify processes with Key-type handles matching it. Validate the executable path, publisher, command line, parent, user, and expected role before drawing conclusions. An open registry key alone does not prove that the process changed the configuration. Use activity tracing when you need evidence of a query or modification.

Troubleshooting Handle Searches

The expected file does not appear

Search for a shorter, unique filename fragment.
Try a directory fragment or the displayed device-style path.
Inspect likely processes directly in Handle View.
Run Process Explorer with appropriate elevation.
Repeat the search while reproducing the problem because the handle may be short-lived.
Consider that the resource may be accessed through a service, driver, mapping, or another mechanism rather than a persistent visible file handle.

A handle cannot be viewed or closed

Possible causes include insufficient privileges, a protected process or object, or a handle that was released before the action. Elevate Process Explorer when appropriate, use the owning application's normal shutdown path, and avoid overriding protections on critical system or security processes.

Closing a handle does not resolve the lock

Another process may still hold the file, the application may immediately reopen it, or the apparent lock may involve a service, driver, shell extension, or network condition. Search again immediately, identify all owners, and prefer closing the application or stopping the related service. Restart the system only after safer options have been considered.

A suspicious handle name is found

Legitimate applications use synchronization and IPC objects, and security products, debuggers, and management tools often monitor other processes. Verify the executable path, signer or publisher, command line, parent process, user context, and expected software role. Do not classify activity as malicious based solely on one handle; follow established endpoint-security and incident-response procedures when other evidence supports concern.

Exam-Relevant Notes

A handle is a process-local reference to a Windows-managed object.
Handle View normally shows handles for the selected process in the lower pane.
The global Find Handle or DLL command identifies an owning process for matching object names or loaded modules.
The handle value is meaningful within its owning process and should not be compared as a global identifier.
A File handle indicates an open reference, not proof of active writing.
Registry Key, Event, Mutant, Section, Process, Thread, Token, pipe, and device entries can all be legitimate.
Elevation increases visibility but does not bypass every protected-process restriction.
Closing an individual handle is risky and should be a last resort.

For related investigations, compare Handle View with DLL View, Threads, and other process properties. Handle View explains what a process has opened; it does not by itself provide a complete history of what the process did with those resources.