Crash Dump Analysis Patterns (Part 4)

After looking at one dump today where all thread environment blocks were zeroed, import table corrupt and recalling some similar cases I encountered previously I came up with the next pattern: Lateral Damage.

When this problem happens you don’t have much choice and your first temptation is to apply Alien Component anti-pattern unless your module list is corrupt and you have manifestation of another common problem I will talk about next time: Corrupt Dump.

Anti-pattern is not always bad solution if complemented by subsequent verification and backed by experience. If you get damaged process and thread structures you can point to a suspicious component (supported by some evidence like raw stack analysis and educated guess) and request additional dumps in hope to get less damaged process space or see that component again. At the very end if removing it stabilizes the customer environment it proves you were right.

- Dmitry Vostokov @ DumpAnalysis.org -

9 Responses to “Crash Dump Analysis Patterns (Part 4)”

  1. !analyze -v : Crash Dump Analysis Patterns (Part 4) Says:

    […] 원문링크 […]

  2. Dmitry Vostokov Says:

    Sometimes you get some vital information missing for default or usual analysis techniques and you need to seek other ways to look at dump data - this is the essence of Lateral Damage pattern.

  3. Crash Dump Analysis » Blog Archive » Lateral damage, stack overflow and execution residue: pattern cooperation Says:

    […] I mentioned in comments to Lateral Damage pattern it lies in between the normal healthy dump files and corrupt dumps. For example, the […]

  4. Crash Dump Analysis » Blog Archive » Icons for Memory Dump Analysis Patterns (Part 6) Says:

    […] we introduce an icon for Lateral Damage […]

  5. Crash Dump Analysis » Blog Archive » Crash Dump Analysis Patterns (Part 104) Says:

    […] The same also applies to user dumps where thread times information is omitted so it is not possible to use !runaway WinDbg command or to a dump saved with various options of .dump command (including privacy-aware) instead of /ma or deprecated /f option. On the contrary, manually erased data in crash dumps looks more like an example of another pattern called Lateral Damage. […]

  6. Crash Dump Analysis » Blog Archive » Structural Memory Patterns (Part 1) Says:

    […] Lateral Damage […]

  7. Crash Dump Analysis » Blog Archive » Crash Dump Analysis Patterns (Part 114) Says:

    […] above. In some cases exception information might not be valid though, for example, in the case of laterally damaged or truncated memory dump […]

  8. Dmitry Vostokov Says:

    In case of process memory dumps where .ecxr doesn’t work we may try .exr -1 to display the last exception record which may show an exception address, code, and parameters (such as a write or read address)

  9. Dmitry Vostokov Says:

    0: ???> ~0s

    WARNING: Many commands will not work

    0:000> .ecxr
    Unable to get exception context, HRESULT 0×80004005

    0:000> .exr -1
    ExceptionAddress: …(ModuleA!func+offset)

Leave a Reply

You must be logged in to post a comment.