How to Track Down Windows Handle Leaks

Use live handle growth, marks, and allocation stacks to find the leak.

A process handle count can climb for many reasons: files left open, event objects never closed, registry keys retained too long, token leaks, section leaks, thread handles, or handles duplicated in from another process. HandleLeakInvestigator turns that single count into actionable groups: process, object type, live count, growth since a mark, and the allocation stack responsible for the group.

Mark A / Mark B Workflow

1. Run HandleLeakInvestigator elevated and press Start.
2. Let the target workload reach a steady state.
3. Press Mark A to store the current live count for every group.
4. Run the suspected leak path once, or run it N times to create a stronger signal.
5. Press Mark B and enable Growth only.
6. Select the group whose growth matches the scenario and inspect its allocation stack.

This gives you the familiar two-snapshot leak hunt, but with the call stack already attached. If a group grows by exactly 10 after you run a scenario 10 times, that group is usually the leaking open path.

Prepare the Capture

Start with the smallest repro window you can create. Close unrelated tools, start the target service or application, and let it reach a steady state before pressing Mark A. If the leak is tied to a UI action, API call, test case, or scheduled task, make that operation repeatable so you can run it several times and look for matching growth. A five-run repro that grows one group by five handles is much easier to trust than a single noisy run.

Configure your symbol paths before you need the stack. Kernel frames resolve from the Microsoft symbol path, and application frames need the PDBs for the build you are testing. Missing symbols do not stop the capture, but they make the final stack less useful.

Read the Open Handles View

The Open Handles pane is the main evidence view. It keeps live accounting by group instead of forcing you to scan every event. The most useful columns are:

• Live: currently open handles in the group.
• Growth: change since Mark A or capture start.
• Delta Mark: live-at-Mark-B minus live-at-Mark-A.
• Created and Closed: churn counters that separate a leak from healthy high-volume open/close activity.
• Dup Sources: number of distinct processes that duplicated handles into the group.

Use the Process filter when the machine is busy. Filtering the group list by process name or PID keeps the view focused without throwing away the underlying capture. If the target receives handles from a broker, do not ignore other processes completely; the Dup Sources column is the clue that the apparent leak may be caused by someone else.

Resolve the Allocation Stack

Select a growing group and HandleLeakInvestigator resolves that group's representative allocation stack on demand. Kernel frames resolve from the Microsoft symbol path, and user-mode frames use the configured PDB search path. Lazy symbolization keeps the live capture fast because the event stream is not symbolized row by row.

Check DuplicateHandle Provenance

Some handle leaks are not opened by the process whose count is growing. A broker, parent process, service, or injector may be duplicating handles into it. Select a group and open Provenance to see source-process counts for cross-process DuplicateHandleactivity. Raw duplicate events also expose source PID, source TID, and source handle in the properties pane.

Confirm the Candidate

After you identify a growing group, reset the aggregation or restart the capture and run the same scenario again. The same process, object type, and stack should grow again. If Live rises during the operation and later returns to baseline, you are probably looking at delayed close behavior rather than a true leak. If Created climbs while Closed remains near zero for that group, the evidence is much stronger.

NT, GDI, and USER Handle Domains

NT Object Manager handles are enabled by default and cover files, events, mutexes, sections, registry keys, processes, threads, ALPC ports, tokens, and related object types. If the leak is in GDI or USER resources, enable the experimental Win32k GDI/USER handle source from the Handle Types menu. The capture restarts with the new selection and starts a fresh aggregation baseline.

For related diagnostics, see Windows kernel debugging services, DbgPrintViewer for debug output, and WppViewer Studio for WPP and ETW trace analysis.

HandleLeakInvestigator

• What our customers say about us?

  

  Read our customer testimonials to find out why our clients keep returning for their projects.

  View Testimonials