Поиск GDI / использования ресурсов пользователя из аварийного дампа - PullRequest
6 голосов
/ 19 сентября 2008

У меня аварийный дамп приложения, которое предположительно пропускает GDI. Приложение работает на XP, и у меня нет проблем с загрузкой его в WinDbg, чтобы посмотреть на него. Ранее мы использовали расширение Gdikdx.dll для просмотра информации Gdi, но это расширение не поддерживается в XP или Vista.

Есть ли у кого-нибудь указатели для поиска использования объекта GDI в WinDbg.

В качестве альтернативы, у меня есть доступ к сбойной программе (и ее пакету стресс-тестирования), поэтому я могу воспроизвести на работающей системе, если вам известны какие-либо «живые» средства отладки для XP и Vista (или Windows 2000, хотя это не наша цель).

Ответы [ 3 ]

5 голосов
/ 17 октября 2008

Я провел последнюю неделю, работая над инструментом поиска утечек GDI. Мы также проводим регулярное стресс-тестирование, и оно никогда не длилось дольше, чем стоимость дня без остановки из-за чрезмерного потребления дескриптора объекта user / gdi.

Насколько я могу судить, мои попытки были довольно успешными. Конечно, я заранее потратил некоторое время на поиски альтернативного и более быстрого решения. Стоит отметить, что у меня был некоторый предыдущий полу-везучий опыт работы с инструментом GDILeaks из статьи msdn, упомянутой выше. Не говоря уже о том, что мне пришлось решить несколько проблем, прежде чем приступить к работе, и на этот раз мне просто не дали того, что и как я хотел. Недостатком их подхода является тяжелый интерфейс отладчика (он на несколько порядков замедляет исследуемую цель, что я считаю недопустимым). Другим недостатком является то, что он не работал все время - на некоторых прогонах я просто не мог заставить его сообщать / вычислять что-либо! Его сложность (судя по количеству кода) была еще одним фактором отпугивания. Я не большой поклонник графических интерфейсов, так как я считаю, что я более продуктивен без окон вообще; о). Мне также было трудно заставить его находить и использовать мои символы.

Еще один инструмент, который я использовал перед настройкой для написания своего собственного, был leakbrowser .

В любом случае, я наконец остановился на итеративном подходе для достижения следующих целей:

  • незначительные штрафы за исполнение
  • Простота реализации
  • неинвазивность (используется для нескольких продуктов)
  • полагается на максимально возможное количество

Я использовал обходные пути (некоммерческое использование) для основной функциональности (это инъекционная DLL). Включите использование Javascript для автоматической генерации кода (от 15K сценария до исходного кода 100K поколения - я никак не могу кодировать это вручную и без препроцессора C!), А также расширение windbg для анализа данных и поддержки снимков / различий.

Короче говоря, после того, как я закончил, мне потребовалось несколько часов для сбора информации во время другого стресс-теста и еще один час для анализа и устранения утечек.

Я буду более чем рад поделиться своими выводами.

P.S. Некоторое время я потратил на попытки улучшить предыдущую работу. Моим намерением было свести к минимуму ложные срабатывания (я видел слишком много таких при разработке), поэтому он также будет проверять согласованность распределения / выпуска, а также избегать учета распределений, которые никогда не просочились.

Редактировать: Найти инструмент здесь

4 голосов
/ 19 сентября 2008

Несколько лет назад была опубликована статья MSDN Magazine , в которой говорилось о утечках GDI. Это указывает на несколько разных мест с хорошей информацией.

В WinDbg вы также можете попробовать команду !poolused для получения дополнительной информации.

Поиск утечек ресурсов из аварийного дампа (посмертно) может быть затруднено - если это всегда было одно и то же место, используя одну и ту же переменную, которая пропускает память, и вам повезло, вы могли увидеть последнее место что это будет утечка и т. д. Вероятно, было бы намного проще с живой программой, запущенной под отладчиком.

Вы также можете попробовать Microsoft Detours , но лицензия не всегда работает. Он также немного более инвазивен и продвинут.

0 голосов
/ 27 июня 2016

Я для этого создал скрипт Windbg. Посмотрите на ответ

Команда для получения количества дескрипторов GDI из аварийного дампа

Для отслеживания стека выделения вы можете установить точку останова ba (Break on Access) после последнего выделенного объекта GDICell, чтобы разрывать ее как раз в тот момент, когда происходит другое выделение GDI. Это может быть немного сложно, потому что адрес меняется, но этого может быть достаточно, чтобы найти практически любую утечку.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...