Memory Explorer Views

One process up close, the whole machine at a glance, and the raw event stream.

Memory Explorerhas two main panes — Process and System — plus a raw Events list, switchable from the top-right of the window. The Process view answers "what is this one process doing with its memory?" The System view answers "is the machine under memory pressure, and from what?" This page walks through each surface.

Process View

The process view is the leak-hunting workspace. It is scoped to the process you pick in the Process combo, and every surface stays synchronized to the timeline playhead so you can rewind the whole view to any earlier instant.

• Address-space map— the process's regions, log-compressed and colored by kind: Image, Mapped, Private, Reserved, Heap. Hover to highlight; click to select a region and reveal its allocating stack.
• Outstanding allocations — live VirtualAlloc regions grouped by allocating stack and ranked culprit-first by trailing growth, then outstanding bytes. The top row auto-selects, so a leak surfaces without scrolling.
• Call stack— the selected group's allocating stack, symbolized on demand from your PDB search path. Lazy symbolization keeps the live capture fast.
• Timeline— committed bytes over time with per-event ticks. Drag the playhead (or Left / Right / Home / End) to scrub the map and grid back to "state as of T"; "Jump to now" returns to live.
• Working set — select a region and refresh to see resident versus nonresident-or-unknown committed pages. Regions up to 262,144 committed pages are covered exhaustively; larger regions are evenly sampled and labeled sampled.
• Fault sparkline — bounded 250 ms buckets reconstructed from transition, demand-zero, copy-on-write, guard, and hard page-fault events for the selected process.

The A/B diff lives here too: press Mark A to anchor the playhead, and regions born after A are outlined on the map while the header reports the region and byte counts gained and lost since A. See the leak workflow for how these fit together.

System View

The system view steps back to the whole machine. It is where you go when memory pressure is real but no single process obviously owns it — or when the leak is in kernel pool rather than a process's VirtualAlloc.

• Stat tiles — commit charge against its limit (with a meter), nonpaged pool, paged pool, and hard-fault rate, polled about once a second from documented APIs.
• Physical memory lists — Active, Standby, Modified, Compressed, and Free over the recent window when the OS query is available; otherwise a commit-charge trend.
• Pool tags — live per-tag kernel pool accounting from the capture session, ranked by outstanding bytes with growth sparklines and deltas: the poolmon workflow, with history. Pool events are aggregated at ingest rather than kept as raw rows, because system-wide pool runs on the order of 100,000 events per second.
• Per-process memory — processes ranked by private working set (or another metric) with a trend and a delta, so the heaviest and fastest-moving processes are obvious. Click a row to open that process in the Process view.

Events

The Events list is the raw stream behind the Process view: every VirtualAlloc, VirtualFree, map, and unmap as an individual row. Quick filter, compound filters, regex find, highlight rules, and export all apply, exactly as in DbgPrintViewer. The grp=token on a row matches that row's allocation-stack group, so you can pivot from an outstanding-allocation group straight to the events that built it. Pool events are intentionally not raw rows — they are aggregated into the System view's pool-tag accounting.

The events shown above are pool activity from live system processes; every event carries the allocating stack, resolved on demand in the lower pane.

ETL Replay

Every view works the same on a saved trace. File → Open ETLreplays a trace through the identical decode path: the Process combo lists the pids found in the trace, the timeline spans the trace's extent, and scrubbing behaves exactly as it does live. File → Start Capture to ETL… records the live session to a file you can reopen later or hand to a vendor.

A replay never queries the viewer machine, so a foreign-machine trace stays historical. The region panel labels live residency unavailable and instead shows the process working-set summaries and fault buckets that were captured in the ETL, so nothing you see is contaminated by the machine you happen to be reading the trace on.

A Note on Working-Set Interpretation

QueryWorkingSetExproves only whether each queried virtual page is currently valid in the target process's working set. For invalid pages, Windows does not publish a per-address standby / modified / compressed / pagefile classification. Reserved and uncommitted pages are excluded before the query, so the gray bar means committed but currently nonresident or otherwise unknown, not "paged out." Memory Explorer therefore reports resident versus nonresident/unknown rather than fabricating a breakdown the public APIs cannot support. Machine-wide Active, Standby, Modified, Free, and Compressed history lives in the System view, and those totals do not imply a decomposition of any one process region.

Ready to try it? Download Memory Explorer, or read how to find a memory leak.

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