Почему Spy++ не работает с окнами консоли

Я пытался убедиться, что сообщения отправляются в мое окно с помощью Spy++ (под управлением Windows 7), но по ошибке попытался шпионить за окном консоли, которое моя программа использовала для вывода отладки. Spy++ сразу уведомил меня, что «за указанным окном нельзя следить. Windows не разрешает доступ к потоку сообщений для этого окна».

Хотя Spy++ правильно собирает другую информацию об окне (например, имя, стиль, имя класса), он не может обрабатывать очередь сообщений. Почему это? И, из нездорового любопытства, есть ли способ запретить Spy++ доступ к очереди сообщений моего собственного пользовательского окна с помощью Windows API?


person Brian Davis    schedule 05.05.2016    source источник


Ответы (2)


Хотя Spy++ правильно собирает другую информацию об окне (например, имя, стиль, имя класса), он не может обрабатывать очередь сообщений. Почему это?

Окно консоли принадлежит процессу CSRSS, а не процессу CMD.EXE. CSRSS — это критически важная системная служба, которая защищена и не может быть перехвачена без специальных привилегий отладки.

"Когда процесс пользовательского режима вызывает функцию, включающую консольные окна, создание процесса/потока или параллельную поддержку, вместо выполнения системного вызова библиотеки Win32 (kernel32.dll, user32.dll, gdi32.dll) отправить межпроцессный вызов процессу CSRSS, который выполняет большую часть фактической работы без ущерба для ядра."

И, из нездорового любопытства, есть ли способ запретить Spy++ доступ к очереди сообщений моего собственного пользовательского окна с помощью Windows API?

Как правило, нет. Если только вам не удастся запустить свое окно в защищенном системном процессе.

person Remy Lebeau    schedule 05.05.2016
comment
Вы возбудили мое любопытство. Прочитав больше об этом в Википедии, я обнаружил вторичный механизм, conhost.exe (порожденный CSRSS под текущей учетной записью пользователя), который используется для отображения окна консоли. Похоже, что процесс, работающий под учетной записью пользователя, был бы справедливой игрой для Spy++, но опять же, окно рабочего стола также отклоняется от слежки. Является ли метод, в котором вызывается CreateProcess, мешает работе Spy++? - person Brian Davis; 05.05.2016
comment
@BrianDavis: Окно рабочего стола не обрабатывается каким-либо особым образом, и Spy++ можно использовать для отслеживания сообщений. Возможно, вы используете Spy++ с неправильной разрядностью (например, 32-разрядный Spy++ в 64-разрядной ОС)? - person IInspectable; 06.05.2016

Итак, я недавно обнаружил это сам, я создал консольное приложение .NET, которое запускает процесс с помощью CMD.EXE, и столкнулся с проблемой взаимодействия Win32 с клавиатурой. Поэтому я запустил ранее проверенную утилиту Spy++, чтобы посмотреть, что происходит, и обнаружил, что я совершенно не могу контролировать очередь сообщений для своего приложения из нее.

Итак, согласно вопросу оператора:

"Есть ли способ запретить Spy++ доступ к очереди сообщений моего собственного пользовательского окна с помощью Windows API?"

Существует список ограниченных классов окон, встроенных в Spy++:

  • SpyxxHk (предположительно, это собственный класс перехвата),
  • #32768 (Контекстное меню),
  • #32769 (Рабочий стол),
  • ,
  • ConsoleWindowClass (Командная строка)

Таким образом, если вы каким-либо образом привяжете свое приложение к этим классам, Spy++ будет отображать это сообщение о блокировке при попытке просмотра их сообщений, конечно, это может оказаться бесполезным, поскольку ограничивает только эти классы.

Ссылаясь на документацию MS:

https://msdn.microsoft.com/en-us/library/windows/desktop/dd373640(v=vs.85).aspx

«Для событий вне контекста событие доставляется в том же потоке, который вызывал SetWinEventHook. В некоторых ситуациях, даже если вы запрашиваете события WINEVENT_INCONTEXT, события все равно будут доставляться вне контекста. Эти сценарии включают события из окон консоли и события из процессов с разной разрядностью (64 бита против 32 бит)"

Предполагает, что можно получить события окна консоли.

person KVKConsultancy    schedule 02.01.2018