Archive for August 8th, 2008

Who saved the dump file?

Friday, August 8th, 2008

Sometimes the question arises about which postmortem debugger saved a crash dump resulted from an unhandled exception. For example, for pre-Vista systems the customer may believe that they used NTSD and but we know that properly configured NTSD as a default debugger never saves mini-dumps. However the WinDbg shows this:

Loading Dump File [application.mdmp]
User Mini Dump File: Only registers, stack and portions of memory are available

In the post Who calls the postmortem debugger? I showed that the default unhandled exception filter launches a default postmortem debugger. Because CreateProcess call needs a path and it is taken from AeDebug registry key the value is stored on a stack. So it is easy to dump the stack data, find UNICODE pattern and dump the string, This can be done using raw stack data or from the full exception processing stack trace where unhandled exception filter is present:

STACK_TEXT: 
0dadc884 7c827cfb ntdll!KiFastSystemCallRet
0dadc888 77e76792 ntdll!NtWaitForMultipleObjects+0xc
0dadcb78 77e792a3 kernel32!UnhandledExceptionFilter+0×7c0
0dadcb80 77e61ac1 kernel32!BaseThreadStart+0×4a
0dadcba8 7c828752 kernel32!_except_handler3+0×61
0dadcbcc 7c828723 ntdll!ExecuteHandler2+0×26
0dadcc74 7c82855e ntdll!ExecuteHandler+0×24
0dadcc74 7c35042b ntdll!KiUserExceptionDispatcher+0xe
0dadcf70 0964a32a msvcr71!wcscpy+0xb
[…]

0:086> dds 0dadc884
0dadc884  7c828270 ntdll!_except_handler3
0dadc888  7c827cfb ntdll!NtWaitForMultipleObjects+0xc
0dadc88c  77e76792 kernel32!UnhandledExceptionFilter+0×7c0
0dadc890  00000002
0dadc894  0dadc9e8
0dadc898  00000001
0dadc89c  00000001
0dadc8a0  00000000
0dadc8a4  003a0043
0dadc8a8  0057005c
0dadc8ac  004e0049
0dadc8b0  004f0044
0dadc8b4  00530057
0dadc8b8  0073005c
0dadc8bc  00730079
0dadc8c0  00650074
0dadc8c4  0033006d
0dadc8c8  005c0032
0dadc8cc  00720064
0dadc8d0  00740077
0dadc8d4  006e0073
0dadc8d8  00320033
0dadc8dc  002d0020
0dadc8e0  00200070
0dadc8e4  00390032
0dadc8e8  00320035
0dadc8ec  002d0020
0dadc8f0  00200065
0dadc8f4  00300031
0dadc8f8  00380038
0dadc8fc  002d0020
0dadc900  00000067

0:086> du 0dadc8a4
0dadc8a4  "C:\WINDOWS\system32\drwtsn32 -p ”
0dadc8e4  “2952 -e 1088 -g”

- Dmitry Vostokov @ DumpAnalysis.org -

Posted in Crash Dump Analysis | No Comments »

Three main ideas of debugging

Friday, August 8th, 2008

I recently started reading a book written by Peter Watson “Ideas: A History of Thought and Invention, from Fire to Freud” where he points to common tripartite view of intellectual history. Reflecting on it, I also came up with my own view about the history of debugging. The main three ideas are:

- Forward debugging

Conventional debugging where an engineer starts with initial conditions and during debugging tries to reproduce the problem or see the anomalies on the way to it. Delta debugging also falls into this category.

- Memory dump analysis

Taking memory slices for remote or postmortem analysis. Helps in problem identification, effective and efficient troubleshooting and also in debugging hard to reproduce or non-reproducible bugs.

- Backward debugging

Also called time travel debugging. Although mostly in its early stages of development this debugging method is the future. In the most simple way, but technologically infeasible at the moment, it can be implemented as recording memory dumps in succession with every tick. Currently, to avoid saving redundant information and conserve storage the code is altered to save context dependent information for every processor instruction or high-level programming language statement. Another approach that comes with virtualization is coarse-grained backward debugging where memory and execution state is saved at certain important points or after specified time intervals.

- Dmitry Vostokov @ DumpAnalysis.org -

Posted in Books, Debugging, Science of Memory Dump Analysis | 1 Comment »