Могу ли я использовать результат анализа windbg, если у меня есть предупреждения о некоторых символах?

Я новичок в Windbg и анализе памяти в Windows. Я пытаюсь проанализировать дамп памяти (аварийный дамп), это система x64.

После загрузки всех символов (мой и майкрософт) я набираю !analyze -v

Это часть вывода:

......
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
......

Это WRONG_SYMBOLS беспокоило меня.

Могу ли я быть уверен, что код в FAULTING_SOURCE_CODE связан с аварией?


person Stepan Loginov    schedule 26.01.2017    source источник


Ответы (2)


Нет, к сожалению, этому нельзя доверять. В анализе стека вызовов есть по крайней мере один момент, когда отладчик не был на 100% уверен, правильно ли он раскрутил стек.

Когда вы наберете ~544s; .ecxr; k, вы увидите стек вызовов. Этот стек вызовов будет включать предупреждение в тот момент, когда он становится неопределенным. Вы можете доверять всему ранее, что может уже помочь, но вы не можете доверять кадрам стека ниже предупреждения.

Вы можете сравнить вывод k с выводом dps @ebp (можно добавить L fff, если этого недостаточно), чтобы увидеть, что еще мог догадаться отладчик.

Обратите внимание, что в выводе dps вы также можете увидеть совершенно не связанные вещи, если случайно одно из ваших вычислений в стеке привело к значению, которое можно интерпретировать как символ.

person Thomas Weller    schedule 26.01.2017

c0000374 это STATUS_HEAP_CORRUPTION. Просмотр обычного дампа показывает код только после того, как произошло повреждение.

Активируйте Pageheap с помощью gflags.exe для вашего exe

введите здесь описание изображения

PageHeap включает Windows функции, которые резервируют память на границе каждого выделения для обнаружения попыток доступа к памяти за пределами выделения. Это приведет к падению приложения раньше, и здесь вы можете увидеть настоящую причину сбоя. Откройте dmp и запустите !analyze -v, чтобы увидеть, что повреждено.

person magicandre1981    schedule 26.01.2017
comment
Звучит интересно. Насколько я понимаю, gflags — это инструмент, который изменяет некоторые настройки уже запущенного процесса. Но в моем случае дамп памяти не с моего ПК, и у меня нет прямого доступа к удаленному ПК с проблемой. Можно ли включить эту функцию другим способом? Например, как флаг отладки во время компиляции? - person Stepan Loginov; 26.01.2017
comment
вы должны активировать этот параметр на ПК, где происходит сбой приложения. - person magicandre1981; 26.01.2017
comment
@StepanLoginov: имейте в виду, что полная куча страниц будет выделять 8 КБ памяти (2 страницы, 1 доступная страница для данных и 1 недоступная страница для запуска отладчика) для каждого отдельного int в куче. Таким образом, этот подход находит утечки только >4kB. Я считаю, что это вряд ли работает для 32-битных программ, потому что все они страдают от нехватки памяти до того, как возникает реальная проблема. Это может хорошо работать для вашей 64-битной программы. - person Thomas Weller; 26.01.2017