Memory Dump Analysis Best Practices

We continue with best practices, the previous was SCP (Volume 6, page 19). The second best practice is to check the system for additional patterns after the main pattern was found (similar to avoiding common mistake #8, Volume 5, page 24). For example, in the case of a bug check resulted from NULL pointer dereference or any other exception in some 3rd-party driver code don't stop but look at all CPUs, processes and threads to find any other patterns such as Spiking Threads (Volume 1, page 305), Busy System (Volume 1, page 449), and Contention (Volume 5, page 423). Inspection of associated thread stack traces might reveal the same module and/or give additional clues to system behavior prior to the fault.

Another best practice that is directly related to productivity is a parallel processing of the same memory dump especially in the case of complete memory dumps. Here an analysis might start with running time consuming scripts that dump all process and threads in the variety of formats such as x64 and x86 thread stack traces. However, if the nature of the problem is such that it is possible to start with some pattern and continue unfolding its analysis then we can do that in parallel. One of examples may be discovered Incomplete Session (page 150) with an ALPC Wait Chain (Volume 3, page 97). Here we can follow such a wait chain while another WinDbg instance dumps all threads for the later pattern search.