Memory Explorer
See where a Windows process's memory goes — and what is leaking it.
Free download. Memory Explorer is currently in beta.
Memory Explorer is a Windows memory visualization and leak-tracking tool. It puts three things in one window: a per-process address-space map you can scrub back in time, a live list of outstanding allocations grouped by the call stack that made them, and a system-wide view of kernel pool tags and commit health. Instead of watching a single committed-bytes number climb and guessing, you can see which regions grew, when they grew, and the exact code path responsible.
It is built for the everyday memory problem: a service, application, or driver-adjacent process whose memory rises slowly over hours, or spikes under a particular workload. Attach to it, let it run, and the ranking surfaces the leaking allocation site. Everything works the same way on a live machine or on a saved ETL trace someone handed you.
What Memory Explorer Is For
- Track down a memory leak by allocation stack, the way a profiler ties CPU time to a function — but for outstanding committed memory.
- Understand a process's address space at a glance: how much is image, mapped, private, heap, or reserved, and how that layout changes over a run.
- Compare two moments in time with an A/B diff to see exactly which regions were born during a suspect operation.
- Diagnose system-wide memory pressure — commit charge against its limit, nonpaged and paged pool growth, and which kernel pool tag is climbing.
- Investigate a trace after the fact by replaying an ETL file captured on another machine, with the same timeline and drill-down.
The Views
Memory Explorer has two main panes plus a raw event list. For a detailed walkthrough of each surface, see the views guide.
- Process view — the address-space map, outstanding-allocation groups, call stack, committed-bytes timeline, per-region working set, and a page-fault sparkline for one selected process.
- System view — stat tiles for commit charge, nonpaged and paged pool, and hard-fault rate; physical memory lists (Active / Standby / Modified / Compressed / Free); and live pool-tag accounting ranked by outstanding bytes with growth trends.
- Events — every alloc, free, map, and unmap as a filterable, searchable row, so you can drill from an allocation group down to the raw stream behind it.
Two companion windows go deeper on a single process. The process snapshot is a VMMap-style, point-in-time breakdown — commit, working set, sharing, and classification per region. The memory lifecycle recorder tracks a process from its first instruction and plays its address space coming to life, page by page, colored by how each page was first touched.
How It Finds the Leak
Live VirtualAlloc regions are grouped by their allocating stack and ranked culprit-first: by growth over the trailing 30-second window, then by outstanding bytes. Allocations that already existed when you attached are seeded from a snapshot and never count as growth, so a fresh attach cannot rank the baseline above a real leak. The top row auto-selects; for a leaking process, that is the leak. Select a group and Memory Explorer resolves its allocating stack on demand from your configured PDB search path.
See how to find a Windows memory leak for the full step-by-step workflow, including the Mark A / B diff.
Watch a Process Come to Life
The live views tell you what a process's memory is doing now; the memory lifecycle recorder tells you how it got there. It tracks one process from its very first instruction and plays its address space materializing on a Launch Atlas map — every region in address order as a wrapped ribbon of blocks, with pages lighting up the first time they are touched.
Each page is colored by howit arrived: demand-zero for freshly committed heap and stack, soft page-in for a page already resident on the standby list, amber for a hard fault that cost a real disk read, and magenta for copy-on-write. Scrub the timeline frame by frame to watch the loader assemble the address space, read a warm-up scorecard that shows each module's touched percentage of its image (usually under 10%), and click any page to jump to the fault that first touched it, call stack attached.
Two ways to bind from the first instruction: Launch & Record starts the target suspended and resumes it under the recorder, and Arm & Wait catches a process by name — a service child, a COM server, or a browser child process. An opt-in cold- launch toggle purges the standby list first for a reproducible cold baseline. See the memory lifecycle recorder for the full tour.
Requirements
- Windows 10 or later.
- Administrator privileges for live kernel capture. Opening a saved ETL trace, and snapshot inspection of a process you can open, work without elevation.
- A configured PDB search path for symbolized allocation stacks.
Get Memory Explorer
Memory Explorer is free. Download it, start a capture, pick a process, and watch its address space and allocation stacks fill in.
Frequently Asked Questions
What is Memory Explorer?
Memory Explorer is a free Windows memory visualization and leak-tracking tool. It shows a per-process address-space map you can scrub back in time, ranks outstanding allocations by the call stack that made them, and provides a system-wide view of kernel pool tags and commit/memory health. It works live or from a saved ETL trace.
Does Memory Explorer require administrator privileges?
Live capture requires Administrator because the kernel memory providers run on a system logger. Without elevation the app degrades gracefully: the Memory pane still shows a snapshot of any process you can open, but there is no live event stream, timeline, or pool data. Opening a saved ETL trace does not require elevation.
How does Memory Explorer identify a memory leak?
It groups live VirtualAlloc regions by their allocating stack and ranks them culprit-first by growth over a trailing window, then by outstanding bytes. Pre-existing allocations captured at attach never count as growth, so a fresh attach cannot rank the baseline above a real leak. The top group is usually the leak, and selecting it resolves the responsible call stack.
Can Memory Explorer open ETL traces from another machine?
Yes. File → Open ETL replays a trace through the identical decode path, and scrubbing works exactly as it does live. Replay never queries the viewer machine, so a foreign-machine trace stays historical: the tool shows the process working-set summaries and fault buckets that were captured in the ETL.
Hunting a different resource? See HandleLeakInvestigator for handle leaks, DbgPrintViewer for debug output, and WppViewer Studio for WPP and ETW trace analysis. Doing kernel work? See our Windows driver development and Windows debugging services.
Memory Explorer
What our customers say about us?
Read our customer testimonials to find out why our clients keep returning for their projects.
View Testimonials