Process Snapshot

A VMMap-style, point-in-time breakdown of a process address space.

The process snapshot is a separate window in Memory Explorerthat answers a different question from the live views: not "what is changing?" but "where is all the memory, right now?" It captures one process at one instant and lays out every region with a full VMMap-parity accounting — how much each range commits, how much is physically resident, how much of that is private versus shared, what kind of memory it is, and what backs it.

It is a synchronous, manual snapshot. Opening the window captures the state; pressing F5 captures again. There is no timer or live refresh here on purpose — this is the view you reach for when you want a stable, complete picture to read and export, not a moving stream.

Why a Static Snapshot

Windows memory tooling is fragmented. VMMap shows a superb address-space breakdown but only as isolated snapshots with no call stacks; Task Manager and Process Explorer show totals, not structure. Memory Explorer's live views cover the temporal, leak-hunting story — see finding a memory leak. The process snapshot covers the other half: a rigorous, VMMap-parity accounting of a single moment that you can sort, aggregate, and hand to someone else.

Per-Region Accounting

Each committed region shows both what it reserves in the address space and what it actually costs in physical memory:

• Commit — the committed span from VirtualQueryEx. On Windows 10 1607+ the allocation query adds a private-committed versus shareable-commit split, prefixed Alloc on image and mapped rows because the OS reports it for the whole allocation.
• Working set — resident bytes from one QueryWorkingSet pass, attributed back to each region, with private, shareable, and currently-shared subsets. Process-wide working set is shown beside the summed query with a signed reconciliation delta.
• Classification — a VMMap-style label: private data, heap, stack, TEB, PEB, image section, mapped file, shareable data, or a mapped range whose backing could not be proved. The original VirtualQuery state, type, allocation base, and protection are always preserved when a semantic label is absent or partial.
• Backing — image and mapped-file paths via GetMappedFileNameW; private, pagefile-backed, and physical mappings are distinguished. A pagefile-backed section whose object name is not retrievable says so rather than masquerading as private.

Sharing Semantics, Honestly

Sharing is where memory accounting usually lies. The snapshot uses the documented working-set block bits: Shared separates private from shareable pages, and ShareCount > 1 identifies the currently-shared subset. Copy-on-write is explicit — a resident page whose share bit cleared after a COW write counts in private working set even though its allocation is still MEM_IMAGE or MEM_MAPPED. Because the OS ShareCount is a saturating three-bit value, shared working set is shown as a subset of shareable, never summed as a separate fabricated physical cost.

Composition Card and Aggregation

Above the region table, a composition card totals the snapshot three ways — by memory type, by loader module, and by backing file or object— each with commit and working-set totals, so "how much is this DLL costing across all its sections?" and "how much of my private commit is heaps?" are a glance away. Filtering the region table narrows what you read without throwing away the capture.

Documented Platform Limits

The snapshot is deliberate about what Windows can and cannot prove:

• QueryWorkingSet returns only pages physically present at the call; it cannot classify a nonresident page as standby, modified, compressed, or paged out. Those categories are labeled unavailable, not guessed. Machine-wide Active / Standby / Modified / Free / Compressed history lives in the System view.
• A protected or inaccessible process keeps its virtual map but shows per-region working-set and sharing values as unavailable (the query needs PROCESS_QUERY_INFORMATION | PROCESS_VM_READ).
• Heap labeling uses one documented representative block per Toolhelp heap; the snapshot does not walk every heap block, because a remote heap walk is quadratic on large heaps. This is classification, not the deferred heap-allocation-tracing feature.
• The map walk, allocation query, working-set query, and process counters are sequential, not one atomic OS transaction, so a changing target can produce small signed reconciliation deltas or unattributed pages — which are surfaced rather than hidden.

See also the views guide, the memory lifecycle recorder for watching a process come to life, or download Memory Explorer.

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