В следующем предполагается, что плагины созданы на C ++ или других «родных» языках, по крайней мере, на .NET.
Выделение памяти с помощью оператора new переходит к HeapAlloc(),Чтобы выяснить, кто выделил память, эту информацию также необходимо будет сохранить в куче.
Однако вы не можете предоставить эту информацию в операторе new, и даже если бы это было возможно,вам нужно будет переписать все операторы new в вашем коде.
Другим способом было бы то, что HeapAlloc() просматривает стек вызовов в тот момент, когда кому-то требуется память.При нормальной работе это слишком дорого (с точки зрения времени) и слишком много накладных расходов (с точки зрения памяти).Однако возможно включить так называемую базу данных трассировки стека в пользовательском режиме , иногда сокращенно называемую базой данных UST.Это можно сделать с помощью инструмента GFlags, поставляемого с WinDbg.
Инструментом для захвата снимков памяти является UMDH, также доступный с WinDbg.Он будет хранить результаты в виде текстовых файлов.Должна быть возможность извлекать статистические данные из этих UST, однако я не знаю инструмента, который бы делал это, а это значит, что вам нужно было бы написать его самостоятельно.
Третий подход - использование концепции"пометки кучи".Тем не менее, это довольно сложно и также требует изменений в вашем коде.Я никогда не реализовывал это, но вы можете посмотреть на вопрос Как извлечь выгоду из тегов кучи с помощью DLL?
Допустим, UST-подход выглядит наиболее выполнимым.Насколько большой должна быть база данных UST?
До сих пор мне было достаточно 50 МБ для выявления и устранения утечек памяти.Однако для этого варианта использования не важно получать информацию обо всей памяти.Просто нужно достаточно образцов, чтобы поддержать гипотезу.Эти 50 МБ ИМХО выделяются в памяти вашего приложения, поэтому это может повлиять на приложение.
В базе данных UST хранятся только адреса, а не текст стека вызовов.Поэтому в 32-битном приложении каждому кадру в стеке вызовов требуется только 32-битная память.
В вашем случае 50 МБ будет недостаточно.Принимая во внимание среднюю глубину 10 кадров и средний размер выделения 256 байтов (4 байта для целого, но также и более крупные объекты, такие как строки), вы получите
4 ГБ / 256 байтов = 16M выделения
16M выделений * 10 кадров * 4 байта / кадр = 640 МБ UST
Если данные предположения реалистичны (я не могу этого гарантировать), вам потребуется размер базы данных UST 640 МБ.Это сильно повлияет на ваше приложение, поскольку оно уменьшает объем памяти с 4 ГБ до 3,3 ГБ, поэтому OOM приходит раньше.
Информация UST также должна быть доступна в файле DMP, если она была настроена в то времяаварийный дамп был создан.Конечно, нет в вашем файле DMP, иначе вы бы сказали нам.Тем не менее, он недоступен для статистики.Использование текстовых файлов UMDH ИМХО - лучший подход.
Можно ли мне точно определить, сколько памяти использует каждая надстройка Outlook?
Нес файлом DMP, который у вас есть на данный момент.Все еще будет сложно с инструментами, доступными в WinDbg.
Осталось еще несколько вариантов:
Отключите все плагины и измерьте память самого Outlook.Затем включите один плагин за раз и измерьте объем памяти с помощью этого плагина.Вычислите разницу, чтобы узнать, какая дополнительная память нужна плагину.
Сбой сразу при запуске?Или позже, скажем, через 10 минут использования?Может ли это быть утечка памяти?Выявление утечки памяти может быть проще: просто включите один плагин за раз и следите за использованием памяти с течением времени.Используйте профилировщик памяти, а не WinDbg.Его будет намного проще использовать, и он может рисовать соответствующую графику, которая вам нужна.
Обратите внимание, что вам нужно определить четкий процесс для измерения памяти.Некоторая память будет выделяться только тогда, когда вы делаете что-то конкретное («отложенная инициализация»).Возможно, вы тоже хотите измерить эту память.