Analyzing .dmp files

Question

Hello All,

I am trying to solve a c++ exe run time error issue that happens only in production. I am new to C++ and windbg but I am pasting the enalysis here. I would greatly appreciate if some one can point me to as to how and under what condition this error occurs and more importantly how do I figure out which line of code is causing it. I read lot of forums BUT If I open the dmp file in VS 2008, I have a pdb file locally and the exe locally BUT I can never get the Go To Source code menu option enabled. Quick reply as to how to analyze this .dmp file and how to understand it, would be highly appreciated.. Thanks!

---

• *
• Exception Analysis *
• *

  ---

GetPageUrlData failed, server returned HTTP status 404 URL requested: http://watson.microsoft.com/StageOne/MYServer_exe/0_0_0_0/MyServer_exe/0_0_0_0/000194ab.htm?Retriage=1

FAULTING_IP: Myserver+194ab 004194ab c6040100 mov byte ptr [ecx+eax],0

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 004194ab (Myserver+0x000194ab) ExceptionCode: c0000005 (Access violation) ExceptionFlags: 00000000 NumberParameters: 2 Parameter[0]: 00000001 Parameter[1]: 00000000 Attempt to write to address 00000000

DEFAULT_BUCKET_ID: NULL_POINTER_WRITE

PROCESS_NAME: Myserver.exe

ERROR_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_CODE: (NTSTATUS) 0xc0000005 - The instruction at 0x%08lx referenced memory at 0x%08lx. The memory could not be %s.

EXCEPTION_PARAMETER1: 00000001

EXCEPTION_PARAMETER2: 00000000

WRITE_ADDRESS: 00000000

FOLLOWUP_IP: MYServer+194ab 004194ab c6040100 mov byte ptr [ecx+eax],0

MOD_LIST:

NTGLOBALFLAG: 0

APPLICATION_VERIFIER_FLAGS: 0

FAULTING_THREAD: 000004e0

PRIMARY_PROBLEM_CLASS: NULL_POINTER_WRITE

BUGCHECK_STR: APPLICATION_FAULT_NULL_POINTER_WRITE

LAST_CONTROL_TRANSFER: from 00418a4e to 004194ab

STACK_TEXT: WARNING: Stack unwind information not available. Following frames may be wrong. 087ffa74 00418a4e 0a73b070 087ffc6c 087ffd8c Myserver+0x194ab 087ffb64 00410767 0a73b070 087ffd74 087ffd8c Myserver+0x18a4e 087ffc6c 0041089b 0a73b0f8 0a727a78 0a73b108 Myserver+0x10767 087ffd74 00433913 0a73b0f8 0a727a78 0a73b108 Myserver+0x1089b 087ffe58 0042fbf3 0a73b0f8 0a727a78 00000044 Myserver+0x33913 087fffb8 7d4dfe37 000006a0 00000000 00000000 Myserver+0x2fbf3 087fffec 00000000 0042fae0 000006a0 00000000 kernel32!BaseThreadStart+0x34

SYMBOL_STACK_INDEX: 0

SYMBOL_NAME: Myserver+194ab

FOLLOWUP_NAME: MachineOwner

MODULE_NAME: Myserver

IMAGE_NAME: Myserver.exe

DEBUG_FLR_IMAGE_TIMESTAMP: 4c2123df

STACK_COMMAND: ~86s; .ecxr ; kb

FAILURE_BUCKET_ID: NULL_POINTER_WRITE_c0000005_Myserver.exe!Unknown

BUCKET_ID: APPLICATION_FAULT_NULL_POINTER_WRITE_Myserver+194ab

Followup: MachineOwner

Answer 1

k will give you the stack trace of the current stopped in thread.
~*kb Will give you the stack trace of all threads

Symbols

You might like to set the symbol search path to include MS symbols, this will allow a better stack trace.

You can do this each time using .sympath srv*C:\Symbols*http://msdl.microsoft.com/download/symbols or more permanently set _NT_SYMBOL_PATH environment var (say as a system variable) to srv*C:\Symbols*http://msdl.microsoft.com/download/symbols

You may need to get the symbols to re load using the following.

.symfix+ c:\symbols
.reload /f

Crash line

EXCEPTION_RECORD: ffffffff -- (.exr 0xffffffffffffffff) ExceptionAddress: 004194ab FAULTING_IP: Myserver+194ab 004194ab c6040100 mov byte ptr [ecx+eax],0

If all you want is the line of the crash then there is an application 'CrashFinder' which will load your app and pdb and allow you to enter this 004194ab to report the line of the crash.

Answer 2

You can also set the symbol path, where you have your application PDBs, and the source path, where you have your sources, using the top menu (I think it says Set symbol path and Set source path).

For a crash dump, once you have set up symbol and source paths, and loaded the dump file, you'll find useful the command: !analyze -v

And from the report you pasted, check the line: STACK_COMMAND: ~86s; .ecxr ; kb This line tells you the thread that caused the fault (86). Just past that line into the command window to obtain the stack for that thread: ~86s; .ecxr ; kb

Answer 3

If you're more comfortable with VS, don't give up on it yet. You do see disassembly and stack, and lack only symbols? Do you click the stack frame that is your module and still see no code? Can you even see a stack frame that is within your module? Have you established access to the MS public symbols? (you probably should anyway, even with WinDbg). Does WinDbg report the stack symbols? (they're not listed in the snippet you pasted here). If not it's very likely to be a symbol issue. There are ways to diagnose these both on WinDbg and VS. Did you inspect the 'symbol load information' for the modules you wish to debug? (easiest way in VS is right click the module at the modules window).

There are advice to be given based on any combination of answers to these question. If you provide more detail it can help focus the advice.