Проблема с анализом дампов - PullRequest
1 голос
/ 27 декабря 2010

Я пытался поймать трассировку стека адреса, но он всегда ничего мне не показывает,

моя проблема - проанализировать утечку памяти, поэтому я запросил всю статистику кучи, а затем запросил наибольшее количество выделенной памяти, он вернул мне много выделения,

и я попытался найти многие адреса адресов по «! Heap -p –a ####«, #### - это адрес. но он никогда не вернет мне стек вызовов,

но если я найду этот адрес / любые другие адреса в памяти, это покажет мне подобное распределение.

также, если я попытаюсь выполнить эту команду «dt ntdll! _DPH_HEAP_BLOCK StackTrace ####», она вернет мне NULL трассировку стека.

это из-за того, что куча страниц для приложения не включена ????

Ответы [ 2 ]

0 голосов
/ 01 марта 2012

Здесь есть несколько вещей, во-первых, вы не получите полную трассировку стека для символов, к которым у вас нет доступа, для этого вам понадобятся pdbs без удаленных частных символов.

Для символов Microsoft, введя '.symfix; .reload' в WinDbg, эта проблема должна быть решена.

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

Вы можете попросить клиента сгенерировать трассировку стека пользователей в gflags и воспроизвести ошибку или отправить вам pdbs с полной символьной информацией.

Также можно открыть файл дампа в Visual studio:

  1. Файл-> Открыть-> Проект / Решение перейдите к файлу дампа и нажмите «OK»
  2. В обозревателе решений щелкните правой кнопкой мыши проект-> Отладка-> Начать новый экземпляр

Вам может показаться, что этот подход более знаком, но у вас не будет доступа к инструментам WinDbg, но поскольку это посмертный анализ, вы можете открыть дамп в Visual Studio и WinDbg, поскольку вы все равно не выполняете инвазивную отладку.

0 голосов
/ 14 января 2011

При проблемах с собственной памятью вы не можете легко использовать дампы для определения основной причины.

У Microsoft есть инструмент DebugDiag для 32-битных процессов,

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=28bd5941-c458-46f1-b24d-f60151d875a3&displaylang=en

Вы можете использовать его для отслеживания утечек памяти в некоторых типичных сценариях,

http://support.microsoft.com/kb/919790

Кроме того, привлечение группы поддержки Microsoft может ускорить анализ основных причин,

http://support.microsoft.com

...