Pattern-Driven Memory Analysis (Part 2)

Before we explain stages of the analysis process shown in Part 1, let’s start with a brief overview of memory dumps, debuggers and logs. Recall that a memory dump is a snapshot of a process, system or physical memory state. This unifies post-mortem analysis and live debugging. Debuggers are tools that allow us to get and modify these memory snapshots. Other tools that allow us to get memory dump files are process dumpers like userdump.exe, Task Manager since Vista, WER, and system dumpers like LiveKd and Win32dd. We should not forget tools and methods that allow us to trigger Windows kernel ability to save consistent memory dump files: NMI button, keyboard method and various software bugcheck-triggers like Citrix SystemDump. Now coming back to debuggers. One of their essential features is to save a debugging session log, formatted textual output saved in a text file for further processing. One good example is !process 0 ff WinDbg command to output all processes and their thread stack traces (see Stack Trace Collection pattern for other variations). 

I’ve created a page to add all P-DMA parts as soon as I write them:

Pattern-Driven Memory Analysis

- Dmitry Vostokov @ -

One Response to “Pattern-Driven Memory Analysis (Part 2)”

  1. Crash Dump Analysis » Blog Archive » Pattern-Driven Memory Analysis (Part 3) Says:

    […] Part 2 briefly discussed debuggers and their commands. Certain debugger commands can be grouped together into scripts that can be run against memory dump files and their resulted textual output can be redirected to log files. […]

Leave a Reply

You must be logged in to post a comment.