以下の編集を参照してください。特に #3 では、ETW が適しているようです。
int 2Eh理論的には、古いと新しいに独自のトラップ ハンドラをインストールできますsysenter。ただし、実際には、Patchguard (Vista 以降) と署名要件のために、これは以前ほど簡単ではなくなります。コンテキスト スイッチを検出するための他の一般的な手段を認識していません。つまり、独自にロールする必要があります。OS のすべてのコンテキスト スイッチはコール ゲート (前述のトラップ ハンドラー) を通過し、ReactOS を使用すると、デバッグ/逆アセンブルが苦手な場合に舞台裏を覗くことができます。
ただし、どちらの場合も、カーネル モード権限 (通常はリング 0 と呼ばれます) なしでこのようなものをインストールする一般的な方法はありません。それ以外は、Windows のセキュリティ上の欠陥になります。あなたが望むものを達成するためのWindows提供の方法も知りません。
「文書化されていない Windows NT」という本には、正確なトピックについての非常に優れた章があります (ただし、明らかに古いint 2Eh方法を対象としています)。
特定の関数のみをフックすることに耐えられる場合は、一部のフィルター ドライバーまたはユーザー モード API のフックを回避できる可能性があります。正確な要件によって異なります。
更新:更新された質問を読んで、内部、特にIRQLの概念(DOS時代のIRQと混同しないでください)とスケジューラについて読む必要があると思います。問題は、毎秒文字通り何百ものコンテキスト スイッチが発生する可能性があり、通常は発生することです。ただし、ウォッチャー プロセス (コンテキスト スイッチを監視するプロセス) は、他のユーザー モード プロセスと同様にプリエンプト可能です。これは、リアルタイム シグナリングまたはそれに近いものを実現する方法がないことを意味し、その方法に大きな疑問符が付けられます。
あなたが実際に達成したいことは何ですか？コンテキスト スイッチの数は、実際には何も与えません。SEH 例外が発生するたびに、コンテキスト スイッチが発生します。あなたが興味を持っていることは何ですか？おそらく、パフォーマンス カウンターの方がニーズに適しているのではないでしょうか?
更新 2: 1 つのスレッドであっても、1 秒以内に驚異的な数のコンテキスト スイッチが発生します。したがって、独自のトラップハンドラーをインストールすると仮定しても、システム上の他のすべてのスレッドに (逆に) 影響を与えることになります (結局、すべてのコンテキストスイッチをキャッチし、それが関心のあるプロセス/スレッドであるかどうかを確認し、次に、あなたのことをするか、それを渡します）。
すでに定義された手段ではなく、最終的に達成したいことを教えていただければ、代替案を提案できるかもしれません.
更新 3: 明らかに、ここで 1 つの点で間違っていました。Windows には、コンテキスト スイッチを通知する機能が搭載されています。そして、ETW を利用してそれらを利用することができます。指摘してくれたサイモンに感謝します。