Memory Lifecycle Recorder

Watch a Windows process come to life, page by page.

Nothing on Windows shows the temporalstory of a process's address space. VMMap is a snapshot; Reference Set analysis needs system-wide working-set flushing and expert table-wrangling. The lifecycle recorder in Memory Explorer is built for that gap: launch your app under it and scrub through its first seconds frame by frame — watch the loader assemble the address space, watch heaps and stacks materialize, and see exactly which pages of each DLL were ever touched and which instruction touched them, cold or warm start.

Questions It Answers

• What is my app's real warm-up cost — how much comes from disk versus already-resident standby memory?
• How much of each DLL do we actually touch? (Typically under 10% — and nobody can normally see it.)
• Which call stack first touched this 40 MB of resident private memory?
• What does my startup look like cold versus warm?

Launch & Record or Arm & Wait

There are two ways to bind to a process from its very first instruction:

• Launch & Record — give an executable, arguments, and working directory. The recorder starts the process suspended, arms itself, and resumes it, so nothing is missed.
• Arm & Wait — give a process name and bind to the first matching start. This is how you catch a service child, a COM-activated server, or a browser child process you cannot launch yourself.

Exactly one instance is tracked: the recorder binds a PID at launch or first start and ignores later same-name starts. If a live capture is running, arming stops it first (a lifecycle recording is its own focused capture profile) and says so in the status line.

The Launch Atlas Map

The map is a Launch Atlas: every region, in address order, laid out as a log-sized block on one continuous ribbon that wraps across rows and fills the whole canvas — no scrolling, the entire address space is one picture. Slots are fixed for the whole recording, so during playback blocks never move; pages simply light up in place, and the picture reads like video. A region that does not exist yet at the cursor time shows as a faint dashed ghost; a freed region fades back to a ghost.

Inside each block, pages are colored by how they first arrived:

• Committed, untouched — cool blue.
• Demand-zero first touch — flashes white, settles green (freshly committed heap and stack).
• Soft page-in (transition) — settles teal (a page already resident on the standby list — the warm-start story).
• Hard fault — flashes and stays amber, persistently marking the pages that cost a real disk read.
• Copy-on-write — magenta.
• Reserved / freed — dim outline or dashed ghost.

A brief phosphor-style decay on each flash, plus per-frame activity rings around blocks with events in the current frame, let you see where the action is while playing or stepping without watching every pixel.

Scrub, Step, and Play

A timeline strip plots hard-fault rate, soft-fault rate, committed bytes, and touched bytes over the recording. The scrubber offers play/pause, a speed control from slow-motion up to full speed, single-frame stepping, and drag-anywhere seek — click a hard-fault spike in the plot and the map jumps there. Storage is keyframe-plus-delta, so seeking to any moment is a nearest- keyframe-plus-replay away. A dotted marker shows where the process exited; after exit the map stays and the scrubber still covers birth to exit.

Warm-Up Scorecard

A scorecard band reports as-of-cursor totals — committed, touched, and hard-faulted bytes — and a per-module mini-table showing each module's touched percentage of its image with the hard-faulted fraction called out. This is the number almost no tool exposes: how little of each DLL a process actually uses at startup, and how much of that came from disk. Because the scorecard tracks the scrubber, you can watch the touched percentage climb as startup proceeds.

First-Touch Attribution

The map and the main window's Events tab share one selection and one time cursor. Click a page and the Events tab scrolls to that page's first-touch fault event with its call stack expanded; the tooltip already names the innermost user-visible frame ("by module!symbol"). Double-click a region block to seed a compound filter for that region's full history — allocation, faults, and free. Selecting an event row highlights its page on the map and snaps the scrubber to its time. Fault stacks are captured for demand-zero and hard faults, which answer the two real questions: who touched this heap page, and who caused this disk read.

Requirements and Scope

• Windows 10 or later, run elevated (the page-fault providers run on a system logger).
• A UI-launched target inherits the viewer's elevation; the launch panel notes this rather than silently changing the child's token.
• Live recording only in this version — the lifecycle recorder observes a running launch rather than replaying a saved ETL trace, and it tracks a single process, not a process tree.
• The cold-launch standby purge is system-wide and approximate (in-use shared pages cannot be evicted); it is opt-in and clearly labeled.

See also the process snapshot for a VMMap-style point-in-time breakdown, the views guide, 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