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

Question

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

После загрузки всех символов (мой и Microsoft) набирает !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 Это код, связанный с сбоем?

Answer 1

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

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

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

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

Answer 2

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

Активировать Pageheap с gflags.exe для ехе

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