Это могут быть прямые звонки на VirtualAlloc. Попробуйте изолировать тип памяти с помощью !address -summary. Еще лучше найти копию vadump.exe из старого комплекта ресурсов. Это дает более удобочитаемую разбивку.
Вы можете получить некоторые подсказки, сравнив выходные данные двух запусков команды WinDbg !vadump, а затем сбросив часть вновь выделенной оперативной памяти. Если у вас есть файлы символов и вы делаете дамп оперативной памяти с помощью команды dps, WinDbg будет отображать совпадения символов для каждого DWORD. Другими словами, если у значения есть имя в файле символов, вы его увидите. Хорошим примером этого является создание дампа объектов C++ с помощью VTables. VTable имеет символ, так что вы увидите, какой это тип.
И последнее, но не менее важное: вы можете установить точку останова на VirtualAlloc и выгружать стек для каждого вызова. Даже при отсутствии строгого сравнения между выделением и освобождением можно заметить интересный стек вызовов или размер выделения. Синтаксис точки останова для сброса стека и продолжения:
bp kernel32!virtualalloc "kb;g"
Кроме того, укажите точку останова на VirtualAllocEx. Насколько я знаю, большинство распределений VAD, инициированных процессом, должны достичь точки останова, за исключением тех, которые реализованы в ядре, таких как сопоставления файлов (CreateFileMapping/MapViewOfFile) и, возможно, LoadLibrary.
person
Gary Kratkin
schedule
22.04.2010
