特定のプロセスの子ウィンドウを列挙して、ダイアログ ウィンドウをチェックしたいと考えています。ここでは説明しませんが、何か見つかった場合は、後でそのアプリケーションを強制終了したいと思います。
これを行うためにスタンドアロン アプリケーションを実行しても問題はありません。アプリケーションは (いくつかの P/Invoke 呼び出しを介して) プロセスのウィンドウにアクセスでき、後でそのアプリケーションを強制終了できます。
ただし、同じコードをサービスとして実行すると、期待どおりに動作しません。サービスを実行しているユーザーがデスクトップとやり取りできないようです (これは、LOCAL システム アカウントでのみ確認できる設定です)。
これに対する回避策を知っている人はいますか？Windows サービスからプロセスのウィンドウを列挙することは可能ですか?
参考までに-私が使用しているコード（少なくとも適応）はここから入手できます：https://stackoverflow.com/a/1405088/2115261
プロセスと同じターミナル サービス セッション (別名リモート デスクトップ セッション) でのみウィンドウを列挙できます。ただし、適切な権限があれば、別のターミナル サービス セッションでサブプロセスを起動して、代わりに作業を行うことができます。ただし、これを行う方法によっては潜在的なセキュリティの問題に注意する必要があります。
ターゲット プロセスへのハンドルを既に取得していると仮定すると、最も簡単な方法は、 を使用OpenProcessTokenしてターゲット セッションでトークンを取得し、DuplicateTokenExそれを複製してCreateProcessAsUser、サブプロセスを起動することです。必要なのは yes/no の答えだけなので、IPC メカニズムを必要とせずにプロセス終了コードを使用できます。
セキュリティへの影響: サブプロセスはユーザーのコンテキストで実行されているため、知識のあるユーザーはサブプロセスが適切に実行されないようにすることができます。また、IPC メカニズムを使用する場合は、サブプロセスからの入力を信頼できないものとして処理する必要があります (バッファー オーバーランなどをチェックします)。
別のアプローチは、サブプロセスを独自のコンテキストでターゲット セッションで起動することです。IIRCでは、独自のトークンをSetTokenInformation複製しTokenSessionId、サブプロセスをCreateProcessAsUser.
セキュリティへの影響: サブプロセス、およびそれを介したサービス プロセスとサービス アカウントは、破砕攻撃 (悪意のあるウィンドウ メッセージ) やその他のリスクにさらされる可能性がありますが、整合性レベルのメカニズムによってこれがある程度緩和される可能性があります。別のウィンドウ ステーションとデスクトップ (適切な ACL を使用) を作成することでこれらのリスクが排除されることは理解していますが、実行するコードへの影響についてはわかりません。別の緩和策としてCreateRestrictedToken、サブプロセスを起動する前にトークンからすべてのグループと権限を削除する方法があります。
ユーザーがダイアログ ウィンドウの存在を検出する機能を無効にできないことが絶対に不可欠でない限り、最初のアプローチを強くお勧めします。
サービスにログオン用のローカル システム アカウントを与えると、(サービス コントロール マネージャーから) サービスのプロパティで [デスクトップとの対話をサービスに許可する] チェックボックスをオンにすることができます。
サービスのプロパティ ページの [ログオン] タブを参照してください。
それはあなたのために働くかもしれません。しかし、残念ながら、おそらくそうではないでしょう。まだ試してみる価値はありますか？