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 -
September 17th, 2008 at 9:53 am
[…] 원문링크 […]
November 5th, 2008 at 5:39 pm
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.
November 5th, 2008 at 6:35 pm
[…] I mentioned in comments to Lateral Damage pattern it lies in between the normal healthy dump files and corrupt dumps. For example, the […]
March 15th, 2010 at 3:15 pm
[…] we introduce an icon for Lateral Damage […]
August 4th, 2010 at 11:07 pm
[…] 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. […]
September 24th, 2010 at 10:52 am
[…] Lateral Damage […]
November 9th, 2010 at 12:03 pm
[…] above. In some cases exception information might not be valid though, for example, in the case of laterally damaged or truncated memory dump […]
March 26th, 2015 at 5:21 pm
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)
March 26th, 2015 at 5:41 pm
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)