У меня недавно была очень похожая ситуация, и я нашел пару методов, полезных для расследования.Ни одна из них не является серебряной пулей, но каждая из них проливает немного больше света на проблему.
1) vmmap.exe из SysInternals (http://technet.microsoft.com/en-us/sysinternals/dd535533) хорошо справляется с сопоставлением информации о собственной и управляемой памяти и представляет ее вхороший пользовательский интерфейс. Та же информация может быть собрана с использованием методов, описанных ниже, но это гораздо проще и хорошее место для начала. К сожалению, он не работает с файлами дампа, вам нужен живой процесс.
2) Вывод «! Address -summary» является сводом более подробного вывода «! Address».Я нашел полезным поместить подробный вывод в Excel и запустить несколько опорных точек.Используя эту технику, я обнаружил, что большое количество байтов, которые были перечислены как "", на самом деле были страницами MEM_IMAGE, вероятными копиями страниц данных, которые были загружены при загрузке библиотек DLL, но затем скопированы при изменении данных.Я также мог бы фильтровать в большие регионы и углубляться в конкретные адреса.Бродить по дампу памяти зубочисткой и множеством молитв - это больно, но может показаться показательным.
3) Наконец, я выполнил вышеописанную версию техники vmmap.exe для бедного человека.Я загрузил файл дампа, открыл журнал и запустил! Address,! Eeheap,! Heap и! Threads.Я также нацелился на блоки среды потока, перечисленные в ~ * k, с помощью! Teb.Я закрыл файл журнала и загрузил его в мой любимый редактор.Затем я мог бы найти несекретный блок и выполнить поиск, чтобы увидеть, появился ли он в выходных данных одной из более подробных команд.Вы можете довольно быстро сопоставить собственные и управляемые кучи, чтобы отсеять тех из ваших подозрительных несекретных областей.
Все они слишком ручные.Я хотел бы написать скрипт, который будет принимать вывод, аналогичный тому, который я генерировал в методике 3 выше, и выводить файл mmp, подходящий для просмотра vmmap.exe.Однажды.
Последнее замечание: я сделал корреляцию между выводом vmmap.exe и выводом! Address и отметил эти типы областей, которые vmmap пара идентифицирует из различных источников (аналогично тому, что используют! Heap и! Eeheap) но это! адрес не знал о.То есть это те вещи, которые vmmap.exe помечал, но адрес! Не указывал:
.data
.pdata
.rdata
.text
64-bit thread stack
Domain 1
Domain 1 High Frequency Heap
Domain 1 JIT Code Heap
Domain 1 Low Frequency Heap
Domain 1 Virtual Call Stub
Domain 1 Virtual Call Stub Lookup Heap
Domain 1 Virtual Call Stub Resolve Heap
GC
Large Object Heap
Native heaps
Thread Environment Blocks
Было еще много «закрытых» байтов, не учтенных, но я снова могу сузитьпроблема, если я смогу отсеять их.
Надеюсь, это даст вам некоторые идеи о том, как провести расследование.Я в одной лодке, поэтому я был бы признателен за то, что вы тоже нашли.Спасибо!