lbq1221119

When debug a memory dump, the dump may not in the right exception context when it is first loaded in the debugger. However, we can figure out the right context from the dump.

Let's load the dump.

c:\debuggers>cdb -z c:\temp\foo.dmp

Symbol search path is: *** Invalid ***
****************************************************************************
* Symbol loading may be unreliable without a symbol search path.           *
* Use .symfix to have the debugger choose a symbol path.                   *
* After setting your symbol path, use .reload to refresh symbol locations. *
****************************************************************************
Executable search path is:
Windows XP Version 2600 (Service Pack 2) MP (4 procs) Free x86 compatible
Product: WinNt, suite: SingleUserTS
Debug session time: Tue Feb 26 07:14:42.000 2008 (GMT-8)
System Uptime: not available
Process Uptime: 0 days 2:07:05.000
......................................
This dump file has an exception of interest stored in it.
The stored exception information can be accessed via .ecxr.
(8c4.3d8): Wake debugger - code 80000007 (first/second chance not available)
eax=00000000 ebx=7c884700 ecx=0006ee6c edx=7c90eb94 esi=00000000 edi=0006f40c
eip=7c90eb94 esp=0006ee78 ebp=0006f528 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
*** WARNING: Unable to verify timestamp for ntdll.dll
*** ERROR: Module load completed but symbols could not be loaded for ntdll.dll
ntdll+0xeb94:
7c90eb94 c3              ret

Let’s load symbols first.

0:000> .sympath SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
Symbol search path is: SRV*c:\websymbols*http://msdl.microsoft.com/download/symbols
0:000> .reload
......................................

Unfortunately .ecxr did not give us the right context.

0:000> .ecxr
eax=00000000 ebx=7c884700 ecx=0006ee6c edx=7c90eb94 esi=00000000 edi=0006f40c
eip=7c90eb94 esp=0006ee78 ebp=0006f528 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
ntdll!KiFastSystemCallRet:
7c90eb94 c3              ret
0:000> kb
ChildEBP RetAddr  Args to Child             
0006ee74 7c90e273 7c863487 d0000144 00000004 ntdll!KiFastSystemCallRet
0006ee78 7c863487 d0000144 00000004 00000000 ntdll!NtRaiseHardError+0xc
//這個(gè)Filter是dbghelp.dll里面的MiniDumpWriteDump()方法來處理的。
0006f528 77c32f0f 0006f578 00000000 00000000 kernel32!UnhandledExceptionFilter+0x653
0006f544 01006484 80000003 0006f578 01009818 msvcrt!_XcptFilter+0x161
WARNING: Stack unwind information not available. Following frames may be wrong.
0006ffc0 7c816fd7 00000016 03d7f12c 7ffd6000 foo+0x6484
0006fff0 00000000 0100660c 00000000 00000000 kernel32!BaseProcessStart+0x23

However, Kernel32!UnhandledExceptionFilter is on the stack. UnhandledExceptionFilter takes an EXCEPTION_POINTERS structure as its parameter, which contains the exception context.

0:000> dc 0006f578
0006f578  0006f69c 0006f6bc 01013ea4 00000001  .........>......
0006f588  fffffffe 0006f5b0 0006f5b0 01009c32  ............2...
0006f598  01015100 010066ff 0006f69c 0006ffb0  .Q...f..........
0006f5a8  0006f6bc 0006f670 0006f5d4 7c9037bf  ....p........7.|
0006f5b8  0006f69c 0006ffb0 0006f6bc 0006f670  ............p...
0006f5c8  0006fd4c 7c9037d8 0006ffb0 0006f684  L....7.|........
0006f5d8  7c90378b 0006f69c 0006ffb0 0006f6bc  .7.|............
0006f5e8  0006f670 01009c12 00000001 0006f69c  p...............

We can change to the exception context.

0:000> .cxr 0006f6bc
eax=0006a1fa ebx=6a803bd8 ecx=00353ee8 edx=00080608 esi=6a8043d8 edi=6a8045c0
eip=7c901230 esp=0006f988 ebp=0006fca4 iopl=0         nv up ei pl zr na pe nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000246
ntdll!DbgBreakPoint:
7c901230 cc              int     3

Now we have the correct exception context.

0:000> k
  *** Stack trace for last set context - .thread/.cxr resets it
ChildEBP RetAddr 
0006f984 6a870952 ntdll!DbgBreakPoint
WARNING: Stack unwind information not available. Following frames may be wrong.
0006fca4 6a8755f9 bar+0x70952
0006fcd4 6a8757ae bar+0x755f9
0006fcf0 6a86f49e bar+0x757ae
0006fcfc 6a86fc06 bar+0x6f49e
0006fd5c 7c9011a7 bar+0x6fc06
0006fd7c 7c923f31 ntdll!LdrpCallInitRoutine+0x14
0006fe00 7c81cd76 ntdll!LdrShutdownProcess+0x14f
0006fef4 7c81cdee kernel32!_ExitProcess+0x42
0006ff08 77c39d45 kernel32!ExitProcess+0x14
0006ff14 77c39e78 msvcrt!__crtExitProcess+0x32
0006ff24 77c39e90 msvcrt!_cinit+0xee
0006ff38 0100645e msvcrt!exit+0x12
0006ffc0 7c816fd7 foo+0x645e
0006fff0 00000000 kernel32!BaseProcessStart+0x23