Как я могу обнаружить сообщения, появляющиеся в другом процессе?

Question

Я хотел бы выполнить некоторый код всякий раз, когда (любое!) Окно сообщения (как порождено функцией MessageBox ) отображается в другом процессе. Я не запустил процесс, за которым слежу.

Я могу придумать три подхода:

1. Установите глобальную CBT Hook процедуру, которая сообщает мне, когда создается окно на рабочем столе. Затем проверьте, принадлежит ли окно к процессу, который я наблюдаю, и является ли имя класса #32770 (которое является именем класса диалоговых окон согласно странице О классах окон в MSDN). Это, вероятно, сработает, но затянет DLL, которая содержит подключаемую процедуру, практически во все процессы на рабочем столе, и подключаемая процедура часто вызывается. Пахнет как потенциальная проблема с производительностью.
2. Попробуйте создать подкласс класса системного окна #32770 (возможно ли это вообще?) И найдите сообщения WM_CREATE в моей процедуре пользовательского окна.
3. Перехватить Функция MessageBox Вызов API (даже если удаленный процесс уже запущен!) И вызвать мой код из функции ловушки.

Пока я знаю только то, что первая идея осуществима, но она кажется действительно неэффективной. Кто-нибудь может придумать более простое решение, чем решение этой проблемы?

Answer 1

Я не могу придумать ни одного эффективного решения, которое не предполагает внедрения кода в другой процесс (это, кстати, то, что делают многие типы хуков между прочим). Но если вы хотите пойти по этому пути, вы можете перехватывать вызовы MessageBox.

Потратьте некоторое время, чтобы перейти к вызову MessageBox в отладчике в режиме ассемблера, и вы увидите, что это косвенный вызов через таблицу поиска (так работает экспорт). так что если вы можете вставить свой код в процесс, вы можете вместо этого исправить таблицу, чтобы перейти к вашему коду.

См. http://www.codeproject.com/KB/threads/completeinject.aspx для кода, показывающего, как внедрить dll в другой процесс.

Answer 2

Я бы пошел с первым вариантом. Вы можете обойтись без установки только ловушки для основного потока пользовательского интерфейса отслеживаемого приложения, но если это не сработает, даже глобальные ловушки CBT не слишком ресурсоемки в моем опыте. Конечно, вы хотите, чтобы ваша подключаемая DLL содержала как можно меньше, кроме самой логики подключений. Если вам нужно что-то громоздкое, связывайте его динамически только тогда, когда вы знаете, что находитесь в правильном процессе.

Answer 3

Я думаю: Подход 2 невозможен. Подходы 1-3 требуют dll, который загружается во все процессы, а подход 3 "более правильный". Я полагаю, что поиск по таймеру не подходит по некоторым причинам?