「GetThreadContext」以外の別のプロセス（WindowsのC++）でスレッドのEBPを取得する方法があるのだろうかと思っていました。私はこの方法には時間がかかりすぎると思います（私はそれをたくさん使います）、もし私がEBPだけで、CONTEXTのすべての値を得ることができないなら、それはより速くなります。
"ReadProcessMemory"を使用し、残りの呼び出しスタックでEBPを取得することを考えていましたが、スタックがどこにあるのか、どこから取得する必要がないのでしょうか。
誰かがもっと良い方法を知っているなら、私はそれについて聞いてうれしいです。
ありがとう:)別のプロセスでスレッドのEBPを取得する
スレッドが実行されている場合、別のスレッドのEBPの実行値は、もちろんEBPレジスタにあります。実行されていない場合は、カーネルのスケジューラによって救われます。 GetThreadContextは、カーネル内の内容を取得しています。それ以外はもっと速くなりません。
私がこれを書いたときに理解していたよりもパフォーマンスの状況が悪いです。スレッドが実行されている場合、カーネルはAPCメカニズムを使用して最新の値を取得します。これは高速ではありませんが、他の代替APIはありません。
いいえ、間違っています。 NtGetContextThreadは、APCを現在のスレッドでない場合、常にターゲットスレッドにキューイングします。その後、APCが完了するのを待ちます。それほど速くはありません。 – wj32
実際には、他のより高速な代替手段があれば、これについてはもっと悪いと感じるでしょう。 1つはありますか？ – bmargulies
いいえ、スレッドが実行されている場合、そのレジスタはレジスタ内にありますが、あまり役に立ちません。実行されていない場合、レジスタはそのKTHREADオブジェクトに保存されます。スレッドのレジスタが実際に読み取れるように保存されていることを確認する最善の方法は、APCをキューに入れてそのスレッドのプロセッサで割り込みを発生させることです。 – wj32
EBPがレジスタであるため、GetThreadContextは唯一の方法です。プロセッサはコンテキストスイッチを実行したときにそれを保存します。スレッドのレジスタを読み取る唯一の方法はGetThreadContextです。
もちろん、EBPに必要な値が保証されているわけではありません。フレームポインタ省略でコンパイルされた関数では、現在の呼び出しフレームのフレームポインタにEBPが確実に設定されません。
スタックトレース（EBPを開始する最も一般的な理由）を探しているだけの場合は、StackWalk64をお勧めしますか？
あなたは何を書いていますか、プロファイラですか？あなたの問題を説明すると、誰かがあなたにより速い方法を与えることができます。 –
はい、プロファイラ:) – Idov