Иногда при работе машины начинаются ситуации, когда GUI начинает глючить - не прорисовываются шрифты, окна и т.д. В общем стандартное поведение WinGDI когда таблица GDI объектов переполнена. При этом если посмотреть в TaskManager на кол-во созданых GDI объектов - то там явно меньше 16000. Вопрос - как определить кто кушает ресурсы? То же самое с памятью. смотришь - занято больше гигабайта. Если считать mem_commit у процессов - то около 500-600 мегабайт.
Прога - TaskInfo. Лично мне не раз помогала именно с безобразиями GDI&USER objects. hxxp://iarsn.com/download.html
Бери Process Explorer ( sysinternals.com ). Нужно будет кликнуть правой мышой на заголовке списка и выбрать доп. столбцы, т.к. по умолчанию они не отображаются.
[cutted] Внизу приведены totals ни User, ни Handle, ни GDI не превышают OS Limit А вот если посмотреть Commit chrge и working set - то разница в 200 метров. Куда они подевались?
По опыту помню - это либо Handles либо GDI объекты. Вопрос - может ли какая-то срань из драйверов жрать ресурсы?
rst Видимо утечка ресурсов, невесть в чем. Попытайся найти драйвер или что там еще может быть, последовательно их отключая (или устанавливая по одному на чистую систему).
Русинович нашел у себя руткит, через загрузку проца непонятную, почитай его блог может у тебя тоже такое животное обитает на компе.
Working set тебе не поможет. Этот параметр отражает подмножество физических страниц, используемых процессом. Туда попадают и страницы, на которых лежат разделяемые dll и т.п. Так что разница между Commit charge будет в любом случае. Тебе нужно смотреть Private Bytes и Peak Private Bytes. Это помять, которую процесс использует только для себя. Можно ещё отключить файл подкачки, чтобы легче было идентифицировать пожирателя.
А с GDI объектами? Можно ли аллоцированные в ведре посмотреть? Или в ведре GDI объекты аллоцировать нельзя?
Объем пожираемой памяти скорее всего не при чём тут. Это именно утечка GDI ресурсов. Припоминаю, что пару раз была у меня подобная ботва. Оба раза проблема была в забытии отдать назад захваченный контекст устройства. Типа GetDC без ReleaseDC. Через несколько захватов контекста, без отдачи назад, оно и начинается, причем общее кол-во открытых хендлов не имеет никакого значения. Глянь сюда: http://msdn.microsoft.com/msdnmag/issues/01/03/leaks/default.aspx http://msdn.microsoft.com/msdnmag/issues/03/01/GDILeaks/default.aspx http://www.geocities.com/the_real_sz/misc/bear_.htm ЗЫ: про "ведро" я не понял.
А у меня другой вопрос. Кто знает почему прога жрет много ресурсов(загрузка процессора)? Прога которая проигрывает видео последовательность.
Чтобы выглядеть не совсем идиотом Типа каждый жрет в зависимости от апетита - это я в курсе. Уточняю вопрос. Интересует: - две программы юзают одинаковый алгорим (дефлате злиб) - частота вызова функции сжатия одинаковая - объем данных примерно одинаков результат(ProcessExplorerNt) - моя жрет много, а другая ничего не жрет. Что за безобразие и как его ... Р.С. Не жлобитесь на слова, все равно найду причину, но тогда точно об этом никто не узнает
Самое простое, что можно сделать, раз ProcessExplorer уже есть, - это поставить частоту обновления в 0,5 сек и в свойствах процесса, на закладке Threads, отсортировать список по "CSwitch Delta" и посмотреть стек для потока, который чаще всего работает. Возможно нужно будет тыкнуть на кнопку Stack несколько раз, чтобы поймать момент. Возможно это даст тебе некоторое представление о том, какой поток жрет процессор и какой код он выполняет. Ну а вообще, тут, наверное, профилировщик нужно подключить.
Four-F - ведро==ядро. Раз TaskManager показывает, что в юзермоде все ок, то получается, что обжора в ядре живет.
Даже если он в ядре, то это процесс, а их всего два: Idle и System. Эти процессам GDI объекты вроде как ни к чему. Хотя Bear и GDIObj кажут, что они таки имеют эти объекты, но сомневаюсь, что это правда. Рисовать то им негде и не зачем. Вспомнил ещё одну тулзу: NTObjects ( http://www.smidgeonsoft.prohosting.com/software.html ), правда ей статистику очень неудобно смотреть, но кол-во GDI объектов и их типы на процесс она кажет. Обидно только, что все эти тулзы показывают разные значения и кому верить не понятно Я уже говорил, что у меня подобное было, когда несколько раз получал контекст устройства и не отдавал назад. При этом GDI объектов и прочих ресурсов было ну совсем мало использовано. Т.е. совершенно нормальный процесс, с абсолютно приемлемым потреблением ресурсов, но система из-за него страдала. Может тебе в этом направлении подумать? Понаблюдать в каком процессе постоянно растет кол-во GDI хендлов. Ещё можешь попробовать MemProof ( http://www.automatedqa.com/downloads/memproof/index.asp ) - он прямо с бинарниками работает. Натравливаешь его поочередно на подозрительные проги, после закрытия процесса текущее кол-во ресурса должно быть = 0. Может так что-то найдёшь...
По-моему, проблема в том, что 16384 - это теоретическое ограничение на количество GDI-хэндлов. А практическое зависит еще и от объема свободной физической памяти. http://msdn.microsoft.com/library/default.asp?url=/library/en-us/sysin fo/base/gdi_objects.asp Собственно, я сегодня в очередной раз наблюдал у себя такой же глюк. И даже заметил источник проблемы - одна софтина сожрала тысяч пять, не меньше. Но суммарное потребление до 16384 явно не дотягивало. Теперь я понимаю, почему в XP лимит увеличен до 65536, хотя и не понимаю, почему там реже такие проблемы с нехваткой памяти.
