0

I am new in windbg and memory analize in windows. I try analize memory dump (crash dump) it's x64 system.

After loading all symbols (my and microsoft) I type !analyze -v

This is a part of output:

......
FAULTING_SOURCE_CODE:  <some code here>

SYMBOL_STACK_INDEX:  6

SYMBOL_NAME:  rtplogic!CSRTPStack::Finalize+19d

FOLLOWUP_NAME:  MachineOwner

MODULE_NAME: RTPLogic

IMAGE_NAME:  RTPLogic.dll

DEBUG_FLR_IMAGE_TIMESTAMP:  58542837

STACK_COMMAND:  ~544s; .ecxr ; kb

FAILURE_BUCKET_ID:  WRONG_SYMBOLS_c0000374_RTPLogic.dll!CSRTPStack::Finalize

BUCKET_ID:  X64_APPLICATION_FAULT_WRONG_SYMBOLS_rtplogic!CSRTPStack::Finalize+19d
......

This WRONG_SYMBOLS worried me.

Can I be sure code in FAULTING_SOURCE_CODE it is the code that related to crash?

Stepan Loginov
  • 1,667
  • 4
  • 22
  • 49

2 Answers2

2

No, unfortunately you can't trust it. There's at least one point in the analysis of the call stack where the debugger wasn't 100% sure if he got the stack unwinding right.

When you type ~544s; .ecxr; k you'll see a call stack. That call stack will include a warning at that point where it becomes uncertain. You can trust everything before, which may already help, but you can't trust the stack frames below the warning.

You can compare the k output to dps @ebp (maybe add L fff if it's not enough) in order to see what else the debugger could have guessed.

Note that in the output of dps you may also see totally unrelated stuff if, by accident, one of your calculations on the stack resulted in a value that could be interpreted as a symbol.

Thomas Weller
  • 55,411
  • 20
  • 125
  • 222
2

c0000374 is a STATUS_HEAP_CORRUPTION. Looking at the normal dump only shows code after the corruption has occurred.

Activate Pageheap with gflags.exe for your exe

enter image description here

PageHeap enables Windows features that reserve memory at the boundary of each allocation to detect attempts to access memory beyond the allocation. This will crash the app sooner and here you can see the real cause of the crash. Open the dmp and run !analyze -v to see what gets corrupted.

magicandre1981
  • 27,895
  • 5
  • 86
  • 127
  • It is sounds intresting. As I understand `gflags` is tool that changes some settings of process that already runned. But in my case memory dump is not from my PC, and I haven't direct acces to remote PC with problem. Is it possible enable this feature in another way? LFor example like debug flag during compilation? – Stepan Loginov Jan 26 '17 at 18:07
  • you have to activate this setting on the PC where the app crashes. – magicandre1981 Jan 26 '17 at 18:07
  • @StepanLoginov: be aware that full page heap will allocate 8kB of memory (2 pages, 1 accessible page for the data and 1 inaccessible page to trigger the debugger) for every single `int` on the heap. Thus, this approach only finds leaks >4kB. I find that it hardly works for 32 bit programs, because they all suffer from out of memory before the actual problem happens. It may work well for your 64 bit program. – Thomas Weller Jan 26 '17 at 20:09