Определение использования ресурсов GDI / User из аварийного дампа

Question

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

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

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

Answer 1

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

В WinDbg вы также можете попробовать !poolused запросите некоторую информацию.

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

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

Answer 2

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

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

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

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

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

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

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

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

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

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

Answer 3

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

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

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