ライブラリでキーボード フック プロシージャを使用するアプリがあります。1 つのメッセージのフックの wParam は 255 で、これは "(reserved / OEMClear)" と考えられます。アプリケーションがライブラリでクラッシュする原因となるため、このメッセージの原因を突き止めたいと思います。発生してはならないことを考えると、それを特定するのは良いことです。メッセージは、私たちが持っている 1 台の PC だけに繰り返し届きます。他のコンピューターにはメッセージがまったく表示されません。
では、ウィンドウに送信されたメッセージの送信元を追跡する方法、またはシステム上のすべてのメッセージを追跡する方法はありますか?
(私は当初、Spy++ または winspector を使用することを提案しましたが、それらはメッセージの送信にフックしません。それは意味がありません!ウィンドウはメッセージを受信しますが、送信しません。スレッドがそれを行います。デバッガーの使用に関する提案)。
デバッグが役立つ場合があります。Windows PDBファイルをダウンロードして、これらのメッセージのいずれかが発生した場合にのみヒットするブレークポイントを設定してみてください。その時点でコール スタックを見ると、多くの場合、何が起こっているのかが明らかになります。投稿されたメッセージと他のプロセスから送信されたメッセージは、このアプローチを無効にします。
1 回限りのデバッグ/トラブルシューティング セッション中に、スレッド/プロセス間で win32 ウィンドウ メッセージを送信しているユーザーを特定する手法を思い付きました。いくつかの仮定を立てる必要があるため、100% 信頼できるわけではありませんが、これまでのところ、うまくいかなかったケースは見つかっていません。
基本的な考え方は、メッセージが到着すると、通常、受信者のウィンドウ スレッドがメッセージ ループ (具体的には) で待機GetMessage()してブロックされるという事実を利用することです。メッセージが配信されると、送信スレッドは受信スレッドの準備を整え、待機状態から抜け出します。
Windows では、 Event Tracing for Windowsを使用して、どのスレッドが他のどのスレッドの準備を整えているかを正確に追跡する方法を提供していることがわかりました。この機能を使用すると、多くの場合、メッセージを送信したスレッドを特定できます。受信スレッドを準備したのはスレッドです。メッセージを送信した時点での送信スレッドのコール スタックを確認することも可能です。またwin32k、スタックのカーネル側 ( ) 部分も確認できます。
基本的な手順は次のようになります。
GetMessage。たとえば、次のスクリーンショットでは、TID 7640が WindowsTerminal.exe TID 1104 から発信されたシェル フック メッセージを受け取ります。
これで目的が達成されるかどうかはわかりませんが、sysinternals の Process Monitor を見てください。
http://technet.microsoft.com/en-us/sysinternals/bb896645.aspx
プロセスに発生するすべてを表示するので、メッセージもキャッチすると思います。執筆時点ではサイトがダウンしていたため、確認できませんでした。