（別のプロセスのウィンドウの）WndProcのアドレスを見つけるにはどうすればよいですか。DLLを挿入し、GetClassInfoEx（）、GetWindowLong（）、またはGetWindowLongPtr（）のいずれかを使用してDLLを見つけようとしても、常に0xffff08edのような値を取得します。これは、実行可能アドレスではありません。これはMSDNによると、「...ウィンドウプロシージャのアドレス、またはウィンドウプロシージャのアドレスを表すハンドル」です。
残念ながら、それでは十分ではありません。実際のアドレスが必要です。Spy ++はほとんどの場合正しく機能します（ただし、それでも失敗することがあります）。だからそれは可能であるはずです。ありがとう。
[編集：]私の小さな問題に超高速で正しい解決策を提供してくれたChris Beckeに感謝します！
おそらく、windowprocの間違ったバージョンを要求しているために、窮地に立たされています。
Window Procsは、アプリケーションと同様に、ansiとunicodeの2つのフレーバーで発生します。Windowsは、ansiウィンドウへの生のポインタをUnicodeアプリケーションに返すことはできません。また、その逆も同様です。これは、間違った文字列型で呼び出そうとするためです。
したがって、GetWindowLongPtr関数はありません。そのマクロは、WindowsAPIが提供する2つの「実際の」関数GetWindowLongPtrAとGetWindowLongPtrWに解決されます。ウィンドウがUnicodeウィンドウであり、GetWindowLongPtrAが呼び出された場合、windowsはrawポインターの代わりにハンドルを返すため、（CallWindowProcを介して行われた）呼び出しをインターセプトし、文字列をansiからunicodeにマーシャリングできます。逆の変換は逆になります。
正しい関数を呼び出したとしても、ハンドルが返される可能性があります。ansiコードがUnicodeウィンドウをサブクラス化した可能性は完全にあります。そのため、windowprocはcallWindowProcハンドルの1つに完全に置き換えられました。
その場合、運が悪かったと思います。
クリスベッケの答えを拡張するには（私の問題を解決しました、ありがとう！）：
したがって、GetWindowLongPtr関数はありません。そのマクロは、WindowsAPIが提供する2つの「実際の」関数GetWindowLongPtrAとGetWindowLongPtrWに解決されます。ウィンドウがUnicodeウィンドウであり、GetWindowLongPtrAが呼び出された場合、windowsはrawポインターの代わりにハンドルを返すため、（CallWindowProcを介して行われた）呼び出しをインターセプトし、文字列をansiからunicodeにマーシャリングできます。逆の変換は逆になります。
関数を呼び出すことにより、問題のウィンドウがユニコードウィンドウであるかANSIウィンドウであるかを確認できIsWindowUnicodeます。この情報を使用してGetWindowLongPtr、（実行時に）呼び出す必要のある関数を決定できます。