Crash Dump Analysis Patterns (Part 4)
2009 (0x7D9) - The Year of Debugging
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 -
_1125.png)
New Books:
DLL List Landscape: The Art from Computer Memory Space
Dumps, Bugs and Debugging Forensics: The Adventures of Dr. Debugalov
WinDbg: A Reference Poster and Learning Cards
Memory Dump Analysis Anthology, Volume 2
Also available:
Memory Dump Analysis Anthology, Volume 1
New Children's Book:
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 […]