Предположим, вы ищете данные PE-заголовка EXE / DLL, которые возвращают вызовы @ divo, например. Компания, продукт и т. Д. Эти кстати. получены из вызова Win32 API информации о версии - подробности о MSDN:
http://msdn.microsoft.com/en-us/library/ms646981.aspx
Следующая сложная задача, с которой вы столкнетесь, - это перечисление стека вызовов для определения контекста модуля вашего абонента. Я не пробовал - но если вы изучите свой собственный стек вызовов, я сомневаюсь, что вы увидите кадры неуправляемого вызывающего абонента там. Подозреваю, что он останавливается на переходном кадре, введенном перед переключением в CCW. Кроме того, так как это COM, возможно, вызывающий абонент может вызывать из вне процесса - ваш вызывающий будет представлять собой процесс прокси.
Если это не удастся - вам понадобятся API отладки для размотки внешнего стека - что вводит другие ограничения:
- повышенные разрешения безопасности, необходимые для обхода стека
- потенциальное влияние на производительность при раскручивании стека.
На основе вызовов по вызовам любой из них может сделать подход отладчика нецелесообразным.
Обновление
Некоторые исследования показывают, что существует множество ошибок и ошибок при чтении стека выше переходного кадра CCW даже в отладчике. например
http://support.microsoft.com/kb/317221
Смешанное Неуправляемое / Управляемое разрешение символов довольно уродливо - некоторые мысли здесь о том, как это сделать ... Блог DaveBr's об отладке также довольно удивителен.
http://bytes.com/groups/net-vc/280340-stackwalk-callstack-symbol-resolve-managed-unmanaged-code-dbghelp-etc
http://blogs.msdn.com/davbr/archive/2005/10/06/478006.aspx
На шагах, предпринимаемых для сортировки вызовов между неуправляемыми / управляемыми клиентами, имеется много фуража - например,
http://msdn.microsoft.com/en-us/library/ms973872.aspx