Contexte

L'année dernière, j'ai compilé un système de blog / serveur Web portable que je peux exécuter à partir d'un lecteur flash. C'est génial et fonctionne à merveille, en particulier sur XP. Le problème est que lorsqu'il est exécuté dans Windows 7, chaque programme de console génère deux processus, le processus lui-même et une copie de conhost.exe.

Problème

Dans le cas du système de blog portable, chacun de ses composants serveur (MySQL mysqld.exe, les deux instances d' Apache, les deux instances de httpd.exeVisualSVN visualsvnserver.exeet les multiples instances de PHP php-cgi.exe) génère une instance de conhost.exe. En ce moment (sans copie d' php-cgi.exeactif, j'ai cinq instances en conhost.execours d' exécution, utilisant presque aucun cycle CPU, mais consommant 22 Mo de mémoire (en plus des 80 Mo que les processus réels utilisent actuellement).

Recherche

Depuis Windows 7 a été libéré (et je pense que peut - être depuis Vista), j'ai à plusieurs reprises essayé de comprendre exactement dans quel but les divers (nouveau) processus d'accueil (par exemple conhost.exe, dllhost.exeet taskhost.exe) faire et si elles sont réellement nécessaires. J'ai essayé de les tuer et j'ai constaté que les programmes de console continuent de fonctionner, à la fois pour les programmes qui utilisent une fenêtre de console et ceux qui ne le font pas (comme les serveurs).

Je connais déjà l'ensemble csrss.exe⇨ Windows Vista ⇨conhost.exe et j'ai vu cette même explication (presque mot pour mot) à plusieurs reprises. Le problème est que tout le monde copie simplement cette même explication, ce qui n'est pas utile. Tout ce qu'il dit, c'est que dans XP-, les applications de console où «hébergé par» ou «exécuté sous» csrss.exe, mais dans Windows 7, elles ont été déplacées vers conhost.exepour des raisons de sécurité. L'aspect sécurité est logique, mais il ne dit rien sur ce que signifie l'héberger ni pourquoi / quand c'est nécessaire (ou s'il est possible de l'éviter si ce n'est pas nécessaire). Même la discussion de Raymond Chen sur la question passe sous silence pourquoi les applications de console sont hébergées différemment.

La chose la plus proche que je peux trouver pour une explication technique détaillée est un article de blog Microsoft qui semble renforcer l'idée qu'il s'agit simplement de l'interface graphique et de la fenêtre de l'application console. Cela me laisse encore plus à me demander si cela conhost.exeest nécessaire pour des programmes sans fenêtre comme ces serveurs. S'il n'y a aucune fenêtre, alors pourquoi devrais-je gaspiller des ressources et encombrer l'espace de processus avec des processus inutiles? Pourquoi Windows ne peut-il pas détecter les éléments inutiles et les éviter? La réponse de SecurityMatt a également été légèrement utile en ce qui concerne une explication technique, mais encore une fois, pas assez d'informations que je recherche.

Je ne suis pas le seul à avoir essayé de trouver un moyen d'arrêter les cas inutiles de conhost. Cette personne a demandé de le désactiver et on lui a simplement répondu «ce n'est pas possible» sans autre effort ni réflexion. Hugh D et «Hardly a feature» ont souligné le problème avec de nombreuses instances redondantes de conhost(au moins avec csrss, il n'y avait qu'une seule copie en cours d'exécution), y compris l'utilisation des ressources et les instances persistantes après la fin de leurs processus enfants. J'ai demandé à Laufer si / quand c'était même nécessaire.

Observations et tentatives de solution

S'ils ne sont pas réellement nécessaires à tout moment (encore une fois, je n'ai vu aucun effet néfaste en les tuant), je suppose que je pourrais (très irritant) contourner le problème en remplaçant les serveurs par des fichiers de commandes qui exécutent les serveurs , attendez, puis supprimez la copie conhostqu'ils provoquent. Bien sûr, cela nécessite un moyen rapide et facile de déterminer lequel il s'agit. FallenGameR a demandé comment obtenir l'instance de conhost.exeassociée à un programme de console d'un PID donné mais n'a pas obtenu de réponse. Je pense que la simple récupération du PID du processus parent devrait faire l'affaire (non, ProcessExplorer n'est pas une option, un automatisé / scriptableest nécessaire), mais non seulement cela nécessiterait de créer une sorte de cadre pour obtenir le PID de l'enfant (au lieu de simplement l'exécuter et de terminer la tâche), mais cela signifierait également trouver un moyen de le rendre compatible avec XP également (par exemple, vérifier le nom de l'image du processus parent). Ce billet de blog donne un sens, mais il nécessite PowerShell et n'est pas idéal, sans parler qu'il ne dit rien sur les ramifications de l'exécution du script.

Des questions)

Peut-être que Microsoft pense que personne n'utilise plus d'invites de commande (* cough * Windows 8 * cough *) et a donc supposé que ce n'était pas un gros problème de les surcharger, mais il existe certainement des scénarios où plusieurs applications de console s'exécutent et ont chacune générer un processus supplémentaire, consommant de la mémoire et utilisant PID est horrible, et essayer de le contourner est, au mieux, horriblement gênant.

Quelqu'un a-t-il des informations définitives et faisant autorité sur la question? Encore une fois, j'ai déjà lu l'explication générique; Je me demande:

1. Pourquoi les applications de console doivent (encore) être gérées différemment
2. Dans quelles circonstances spécifiques ils doivent avoirconhost
3. Quelles sont les conséquences de tuerconhost
4. S'il existe un moyen de l'arrêter / de l'empêcher / de le désactiver / de le bloquer ou au moins un moyen facile de le traiter rapidement vers l'arrière?

1. Les applications de console doivent être traitées différemment car sous le noyau NT (qui sous-tend tous 2000, XP, Vista, Windows 7 et Windows 8), ce sont des citoyens de seconde classe. Dans l'architecture système Unix, chaque processus au moment de la création est associé aux flux d'entrée, de sortie et d'erreur standard; le terminal IO est implémenté en termes de ces flux (stdin provenant du clavier et stdout / stderr allant vers le terminal), et un effort supplémentaire est requis de la part d'un processus qui ne souhaite pas utiliser ces flux ou leurs descripteurs de fichiers s'ouvrent.

   Dans l'architecture Windows NT, qui bien que n'étant pas un descendant linéaire de VMS a été développé par plus ou moins la même équipe, l'inverse est vrai; un processus nouvellement engendré par défaut n'a aucun flux d'E / S connecté à lui, et il n'y a pas un tel concept comme un "terminal". Les programmes qui souhaitent se comporter de façon un peu plus Unixy peuvent demander (par déclaration au moment de la compilation) que le système crée pour eux une fenêtre de console et des flux d'entrée / sortie qui lui sont connectés; le système le fera, mais comme Windows, contrairement à Unix, ne vous offre pas de terminaux gratuitement, un effort considérable est nécessaire pour en créer un, donc autrefois csrss.exe, et maintenant conhost.exe.

   Quant à la différence entre les deux, votre lien "A peine une fonctionnalité" l'explique assez bien; en bref, il existe pour contourner une faille de sécurité dans l'itération précédente de l'API de console hautement recondite de Windows, qui permettait une escalade de privilèges dans les versions de NT plus anciennes que Windows 7. (Vista, FYI, n'en a pas conhost.exe, ce qui convient à son en tant que Windows Millennium de la famille NT.)

2. Tout programme qui veut l'équivalent d'Unix stdin / stdout / stderr a besoin d'une console, donc d'une instance de conhost.exe. Les immigrants de pays Unix, tels qu'Apache, PHP, et autres, vont vouloir ces flux, d'où l'instanciation automatique du système conhost.exepour eux, qu'ils affichent réellement une fenêtre ou non. En théorie, il serait possible de modifier la source pour Apache par exemple de telle sorte qu'il ne nécessite aucun terminal, et de le compiler comme une application Windows GUI au lieu d'une application console, de sorte que le système ne ressentira pas le besoin de le générer conhost.exe. En supposant que c'est également possible dans la pratique, personne ne semble s'en être suffisamment soucié. Vous serez peut-être le premier.

3. Tuer une donnée conhost.exedésactivera presque certainement les E / S de la console pour tout processus exécuté sous cette instance. Vous ne vous en souciez probablement pas, car vous avez affaire à des processus serveur qui ne font rien d'intéressant sur les flux d'E / S de la console de toute façon, il n'y a donc probablement aucune raison de ne pas tuer leurs conhost.exes. En cas de doute, tuez-les et voyez si cela casse quoi que ce soit.

4. Il n’existe aucun moyen d’empêcher Windows de s’instancier conhost.exelorsqu’un programme lancé qui demande des entrées / sorties de console; la seule façon de le faire serait de le recompiler afin que Windows ne le considère pas comme une application console. Cependant, en supposant que la suppression du parent d'un processus serveur donné conhost.exen'affecte pas ses fonctionnalités de quelque manière que ce soit, vous devriez être en mesure de les tuer tous en même temps en émettant taskkill /f /im conhost.exeune invite d'exécution ou une fenêtre de console - de préférence la première, car ce dernier mourra probablement, et cessera presque certainement de fonctionner, dès que son conhost.exeinstance mère sera tuée. Encore une fois, en cas de doute, tuez-les et voyez si cela casse quoi que ce soit.

Une application console démarrée avec l' DETACHED_PROCESSindicateur obtient une console ni un processus enfant conhost. Le problème est que l'indicateur ne s'applique pas aux petits-enfants, il ne fonctionnera donc qu'avec les processus que vous démarrez directement (si vous pouvez même trouver un utilitaire qui vous permet de spécifier cet indicateur).

L'autre option qui pourrait fonctionner est si le processus de la console appelle la FreeConsole()fonction. Certaines applications serveur prennent en charge un paramètre -d ou -detach mais cela est probablement plus courant sur les systèmes * nix ...

Solution rapide qui peut fonctionner pour vous. Lorsque vous liez votre application, ajoutez / SUBSYSTEM: WINDOWS aux options. Vous pouvez également utiliser editbin.exe pour modifier un exécutable existant.

Cela empêche Windows de générer un conhost.exe pour votre application.