（いつ）CONHOST.EXEは実際に必要ですか？
バックグラウンド
昨年、フラッシュドライブから実行できるポータブルブログ/ Webサーバーシステムをコンパイルしました。それは素晴らしく、特にXPで素晴らしく機能します。問題は、Windows 7で実行すると、各コンソールプログラムが two プロセス、プロセス自体、およびconhost.exeのコピーを生成することです。
問題
ポータブルブログシステムの場合、そのサーバーコンポーネント（MySQLのmysqld.exe、Apacheのtwohttpd.exeのインスタンス、VisualSVNのvisualsvnserver.exeの2つのインスタンス） PHPのphp-cgi.exeの複数のインスタンス）は、conhost.exeのインスタンスを生成します。この時点で（php-cgi.exeのコピーがアクティブでない場合、conhost.exeのインスタンスが5つ実行されています。CPUサイクルはほとんど使用されていませんが、22 MBのメモリを消費しています（実際のプロセスでは80 MBに加えて）現在使用しています）。
研究
Windows 7がリリースされてから（そしておそらくVistaから）、私は何度かexactlyさまざまな（新しい）ホストプロセスの目的（たとえば、conhost.exe、dllhost.exe、およびtaskhost.exe）は、それらが実際に必要かどうかを示します。私はそれらを殺そうとしましたが、コンソールウィンドウを使用するプログラムと使用しないプログラム（サーバーなど）の両方で、コンソールプログラムが引き続き機能することがわかりました。
私はすでに全体に精通していますcsrss.exe⇨Windows Vista⇨conhost.exe同じ（ほぼそのまま） 説明 を何度も見ました。問題は、誰もが役に立たない同じ説明を単にコピーして貼り付けることです。 XP-では「ホストされる」または「実行される」コンソールアプリケーションcsrss.exeがWindows 7ではセキュリティのためにconhost.exeに移動されたというだけです。セキュリティの側面は理にかなっていますが、それをホストすることの意味や、なぜ/いつ必要なのか（または必要でない場合は回避できるかどうか）については何も述べられていません。 Raymond Chenの ディスカッション の問題でさえ、コンソールアプリがまったく異なる方法でホストされている理由が明らかにされています。
詳細で技術的な説明に最も近いものは Microsoftブログの投稿 であり、これはコンソールアプリのGUIとウィンドウに関するものでしかないという考えを強調しているようです。これにより、これらのサーバーのようなウィンドウのないプログラムにconhost.exeが必要かどうか、さらに疑問に思っています。ウィンドウがまったくない場合、なぜリソースを無駄にし、不要なプロセスでプロセス空間を散らかさなければならないのですか？ Windowsが不要なタイミングを検出して回避できないのはなぜですか？ SecurityMattの response も技術的な説明に関しては少し役に立ちましたが、ここでも、探している情報が不十分でした。
conhostの不要なインスタンスを停止する方法を見つけようとしたのは私だけではありません。 この人 それを無効にすることについて尋ねられ、それ以上の努力も考えもしないで単に「不可能」と言われました。 Hugh D および “ Hardly a feature” は、conhostの多数の冗長インスタンスの問題を指摘しました（少なくともcsrssでは、子プロセスが終了した後のリソース使用量と残存インスタンスを含む、単一のコピーのみが実行されていました）。 I Laufer は、それが必要かどうか、いつ必要かという質問をしました。
観察と解決策の試み
それらが常に実際に必要ではない場合（ここでも、それらを殺したことによる悪影響は見られません）、サーバーを実行するバッチファイルでサーバーを置き換えることにより、（非常に苛立たしく）問題を回避できると思います。 、待ってから、それらが実行するconhostのコピーを強制終了します。もちろん、これには、どちらかをすばやく簡単に判断する方法が必要です。 FallenGameR は、特定のPIDのコンソールプログラムに関連付けられているconhost.exeのインスタンスを取得する方法を尋ねましたが、応答がありませんでした。親プロセスのPIDを取得するだけでうまくいくと思います（いいえ、ProcessExplorerはオプションではなく、automated/scriptableソリューションが必要です）が、何らかのソートを作成する必要があるだけではありません子のPIDを取得するためのフレームワークの（ただし、単純に実行してタスクで完了するのではなく）だけでなく、XPと互換性を持たせる方法（たとえば、親プロセスのイメージ名）。 このブログ 投稿は1つの方法を提供しますが、PowerShellを必要とし、スクリプトの実行による影響については何も述べていないことは言うまでもなく、理想的とは言えません。
質問
おそらくMicrosoftは、誰もコマンドプロンプトを使用していないと考えており（* cough * Windows 8 * cough *）、それらに負担をかけることは大きな問題ではないと想定していますが、複数のコンソールアプリが実行されており、それぞれがすべてのシナリオを持っているシナリオは間違いありません余分な、メモリを消費する、PIDを使用するプロセスを生成するのはひどく、それを回避しようとすることは、せいぜいひどく不便です。
誰もが問題について決定的で信頼できる情報を持っていますか？繰り返しますが、私はすでに一般的な説明を読みました。不思議なんだけど：
- 理由コンソールアプリケーションは（まだ）まったく異なる方法で処理する必要がある
- 特定の状況下では必要
conhost - consequencesは何を殺すのか
conhost - それを停止/防止/無効化/ブロックする方法、または少なくとも後方で迅速に対処する簡単な方法がある場合は？
コンソールアプリケーションは、NTカーネル（2000、XP、Vista、Windows 7、およびWindows 8のすべての基盤となる）ではセカンドクラスの市民であるため、異なる方法で処理する必要があります。 Unixシステムアーキテクチャでは、作成時のすべてのプロセスに、標準の入力、出力、およびエラーストリームが付加されています。端末IOは、これらのストリーム（キーボードからのstdin、および端末へのstdout/stderr）に関して実装されており、プロセスの一部で追加の作業が必要です。それらのストリームを利用するか、ファイル記述子を開いておきたい。
Windows NTアーキテクチャでは、VMSの直系の子孫は多かれ少なかれ同じチームによって開発されましたが、その逆は真です。デフォルトで新しく生成されたプロセスには、それに接続されているI/Oストリームがまったくなく、「ターミナル」などの概念はありません。ややUnix的な方法で動作したいプログラムは、（コンパイル時の宣言によって）システムにコンソールウィンドウを作成し、それに接続された入出力ストリームを要求することができます。システムはそれを行いますが、WindowsはUnixとは異なり、端末を無料で提供しないため、端末を作成するためにかなりの追加の労力が必要です。以前は
csrss.exeでしたが、現在はconhost.exeです。2つの違いについては、「機能がほとんどない」リンクで十分に説明されています。つまり、Windows 7より前のバージョンのNTで特権の昇格を可能にした、Windowsの高度に調整されたコンソールAPIの以前のイテレーションのセキュリティ欠陥を回避するために存在します（Vista、FYI、
conhost.exe、これは、NTファミリのWindows Millenniumとしてのステータスにふさわしいものです。）Unix stdin/stdout/stderrと同等の機能を必要とするプログラムには、コンソール、つまり
conhost.exeのインスタンスが必要です。 Apache、PHPなどのUnix圏からの移民は、これらのストリームを必要とするため、実際にウィンドウを表示するかどうかに関係なく、システムはconhost.exeを自動的にインスタンス化します。理論的には、ソースを変更することが可能です。端末を必要とせず、コンソールアプリケーションではなくWindows GUIアプリケーションとしてコンパイルするようにApacheを使用しているため、システムはconhost.exeを生成する必要を感じません。それが実際に可能であると仮定すると、誰もそうするのに十分気にかけていないようです。おそらくあなたが最初になるでしょう。特定の
conhost.exeを強制終了すると、ほぼ確実にコンソールIOがそのインスタンスで実行されているすべてのプロセスに対して無効になります。サーバープロセスを処理しているので、おそらく気にしないでください。とにかくコンソールで何か面白いことをしていないIOストリームなので、おそらくconhost.exesを強制終了しない理由はありません。疑わしい場合は、強制終了して何かが壊れていないか確認してください。コンソールIOを要求するプログラムが起動されたときにWindowsが
conhost.exeをインスタンス化しないようにする方法はありません。これを行う唯一の方法は、Windowsがコンソールアプリケーションと見なさないように再コンパイルすることです。ただし、特定のサーバープロセスの親conhost.exeを強制終了しても、気になる方法でその機能が損なわれない場合、実行プロンプトでtaskkill /f /im conhost.exeを発行することにより、それらを一度に強制終了できるはずです。コンソールウィンドウ-できれば前者。後者はおそらく死に、その親conhost.exeインスタンスが強制終了されるとすぐに機能しなくなります。繰り返しますが、疑わしい場合は、彼らを殺し、何かが壊れるかどうかを確認してください。
_DETACHED_PROCESS_ フラグで開始されたコンソールアプリケーションは、コンソールもconhost子プロセスも取得しません。問題は、フラグが孫に適用されないため、直接開始するプロセスでのみ機能することです（このフラグを指定できるユーティリティが見つかった場合でも）。
機能する可能性のあるもう1つのオプションは、コンソールプロセスが FreeConsole() 関数を呼び出す場合です。一部のサーバーアプリケーションは-dまたは-detachパラメーターをサポートしますが、これはおそらく* nixシステムでより一般的です...
あなたのために働くかもしれない迅速な解決策。アプリケーションをリンクするときに、オプションに/ SUBSYSTEM：WINDOWSを追加します。 editbin.exeを使用して、既存の実行可能ファイルを変更することもできます。
これにより、ウィンドウがアプリケーションのためにconhost.exeを生成するのを防ぎます。