2016-05-05 36 views
0

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

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

ответ

4

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

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

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

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

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

+0

Вы поразили мое любопытство. Прочитав больше об этом в Википедии, я обнаружил вторичный механизм, conhost.exe (порожденный CSRSS под текущей учетной записью пользователя) используется для отображения окна консоли. Похоже, что процесс, выполняющийся под учетной записью пользователя, будет честной игрой для Spy ++, но опять же, на рабочем столе также запрещается шпионаж. Это метод, в котором вызван CreateProcess, который не позволяет Spy ++ работать? –

+0

@BrianDavis: Окно рабочего стола не обрабатывается каким-либо особым образом, а Spy ++ может использоваться для мониторинга сообщений. Возможно, вы используете Spy ++ с неправильной битностью (например, 32-разрядный Spy ++ в 64-разрядной ОС)? – IInspectable

0

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

Так, согласно вопросу ор в:

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

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

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

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

Обращаясь к MS документации:.

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

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

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

Смежные вопросы