Hintergrund

Letztes Jahr habe ich ein tragbares Blog / Web-Server-System kompiliert, das ich von einem Flash-Laufwerk ausführen kann. Es ist großartig und funktioniert wunderbar, besonders unter XP. Das Problem ist, dass unter Windows 7 jedes Konsolenprogramm zwei Prozesse erzeugt, den Prozess selbst und eine Kopie von conhost.exe.

Problem

Im Fall des tragbaren Blog - Systems, die jeweils einer seiner Server - Komponenten (MySQL mysqld.exe, Apache zwei Instanzen httpd.exe, VisualSVN die zwei Instanzen visualsvnserver.exe, und mehrere Instanzen von PHP php-cgi.exe) laicht eine Instanz conhost.exe. In diesem Moment (ohne Kopien von php-cgi.exeactive, habe ich fünf conhost.exelaufende Instanzen , die fast keine CPU-Zyklen belegen, aber 22 MB Arbeitsspeicher verbrauchen (zusätzlich zu den 80 MB, die die tatsächlichen Prozesse derzeit verwenden).

Forschung

Da Windows 7 veröffentlicht wurde (und ich denke , vielleicht seit Vista), habe ich mehrmals auf versuchte herauszufinden , genau , welchen Zweck die verschiedenen (neu) Host - Prozesse (zB conhost.exe, dllhost.exeund taskhost.exe) zu tun und ob sie tatsächlich notwendig sind. Ich habe versucht, sie zu töten und festgestellt, dass die Konsolenprogramme weiterhin funktionieren, sowohl für Programme, die ein Konsolenfenster verwenden, als auch für solche, die dies nicht tun (wie Server).

Ich kenne mich bereits mit csrss.exeWindows Vista ausconhost.exe und habe die gleiche (fast wörtliche) Erklärung mehrmals gesehen. Das Problem ist, dass jeder einfach die gleiche Erklärung kopiert, was nicht hilfreich ist. Es heißt nur, dass in XP-, Konsolenanwendungen, bei denen "Hosted by" oder "Run under" csrss.exewar, diese conhost.exeaus Sicherheitsgründen in Windows 7 verschoben wurden . Der Sicherheitsaspekt ist sinnvoll, sagt aber nichts darüber aus, was es bedeutet, ihn zu hosten oder warum / wann es notwendig ist (oder ob es möglich ist, ihn zu vermeiden, wenn es nicht notwendig ist). Sogar Raymond Chens Diskussion zu diesem Thema beschönigt, warum Konsolen-Apps überhaupt anders gehostet werden.

Das Nächste, was ich zu einer detaillierten, technischen Erklärung finden kann, ist ein Microsoft-Blogbeitrag, der die Idee zu untermauern scheint, dass es sich lediglich um die GUI und das Fenster der Konsolen-App handelt. Deshalb frage ich mich immer mehr, ob conhost.exedies für fensterlose Programme wie diese Server erforderlich ist. Wenn es überhaupt kein Fenster gibt, warum sollte ich dann Ressourcen verschwenden und den Prozessraum mit unnötigen Prozessen überladen müssen? Warum kann Windows nicht erkennen, wenn es unnötig ist, und es vermeiden? Die Antwort von SecurityMatt war auch in Bezug auf eine technische Erklärung ein wenig nützlich, aber auch hier reichte die gesuchte Information nicht aus.

Ich bin nicht der einzige, der versucht hat, unnötige Vorkommnisse zu stoppen conhost. Diese Person fragte nach der Deaktivierung und erhielt einfach den Hinweis, dass dies ohne weitere Anstrengungen oder Gedanken nicht möglich sei. Hugh D und „Kaum ein Feature“ wiesen auf das Problem mit zahlreichen redundanten Instanzen von conhost(zumindest mit csrssnur einer ausgeführten Kopie) hin, einschließlich der Ressourcennutzung und verweilender Instanzen nach dem Ende ihrer untergeordneten Prozesse. Ich habe Laufer gefragt, ob / wann es überhaupt nötig ist.

Beobachtungen und Lösungsansätze

Wenn sie nicht zu allen Zeiten tatsächlich erforderlich sind (wieder habe ich keine negativen Auswirkungen ihrer Beseitigung gesehen), könnte ich das Problem (sehr irritierend) umgehen, indem ich die Server durch Batchdateien ersetze, auf denen die Server ausgeführt werden Warten Sie, und töten Sie dann die Kopie conhost, die sie ausführen. Dies erfordert natürlich eine schnelle und einfache Methode, um festzustellen, um welche es sich handelt. FallenGameR hat gefragt, wie die conhost.exemit einem Konsolenprogramm einer bestimmten PID verknüpfte Instanz abgerufen werden soll , hat jedoch keine Antwort erhalten. Ich würde denken, dass das einfache Abrufen der PID des übergeordneten Prozesses den Trick tun sollte (nein, ProcessExplorer ist keine Option, eine automatisierte / skriptfähigeLösung ist erforderlich), aber dies würde nicht nur das Erstellen eines Frameworks zum Abrufen der PID des Kindes erfordern (anstatt es einfach auszuführen und mit der Aufgabe fertig zu sein), sondern auch das Herausfinden einer Möglichkeit, es kompatibel zu machen auch mit XP (z. B. Überprüfen des Abbildnamens des übergeordneten Prozesses). Dieser Blog- Beitrag gibt einen Weg vor, erfordert jedoch PowerShell und ist kaum ideal, ganz zu schweigen von den Auswirkungen der Ausführung des Skripts.

Fragen)

Möglicherweise geht Microsoft davon aus, dass niemand mehr Eingabeaufforderungen verwendet (* hust * Windows 8 * hust *) und vermutet, dass dies keine große Belastung darstellt, aber es gibt definitiv Szenarien, in denen mehrere Konsolen-Apps ausgeführt werden und jede einzelne haben Es ist schrecklich, einen zusätzlichen, speicherintensiven PID-Prozess zu erzeugen, und es ist bestenfalls schrecklich unpraktisch, ihn zu umgehen.

Hat jemand endgültige, maßgebliche Informationen zu diesem Thema? Wieder habe ich bereits die allgemeine Erklärung gelesen; Ich frage mich:

1. Warum Konsolenanwendungen (noch) anders behandelt werden müssen
2. Unter welchen besonderen Umständen müssen sie habenconhost
3. Welche Konsequenzen hat das Töten ?conhost
4. Gibt es eine Möglichkeit, es zu stoppen / zu verhindern / zu deaktivieren / zu blockieren oder zumindest eine einfache Möglichkeit, es später schnell zu lösen?

1. Konsolenanwendungen müssen unterschiedlich gehandhabt werden, da sie unter dem NT-Kernel (der allen 2000, XP, Vista, Windows 7 und Windows 8 zugrunde liegt) Bürger zweiter Klasse sind. In der Unix-Systemarchitektur sind jedem Prozess zum Zeitpunkt der Erstellung die Standardeingaben, -ausgaben und -fehlerströme zugeordnet. Terminal I / O wird in Bezug auf diese Streams implementiert (stdin kommt von der Tastatur und stdout / stderr geht zum Terminal), und zusätzlicher Aufwand ist seitens eines Prozesses erforderlich, der diese Streams nicht nutzen möchte oder muss ihre Dateideskriptoren öffnen sich.

   In der Windows NT-Architektur, die zwar kein direkter Nachfolger von VMS ist, aber von mehr oder weniger demselben Team entwickelt wurde, ist das Gegenteil der Fall. Standardmäßig sind mit einem neu erstellten Prozess überhaupt keine E / A-Streams verbunden, und es gibt kein solches Konzept wie ein "Terminal". Programme, die sich etwas unixiger verhalten möchten, können (durch Deklaration zur Kompilierungszeit) anfordern, dass das System für sie ein Konsolenfenster und damit verbundene Eingabe- / Ausgabestreams erstellt. Das System wird dies tun, aber da Windows Ihnen im Gegensatz zu Unix keine Terminals kostenlos zur Verfügung stellt, ist ein erheblicher zusätzlicher Aufwand erforderlich, um eines zu erstellen, also früher csrss.exeund jetzt conhost.exe.

   Der Unterschied zwischen den beiden Begriffen wird durch den Link "Kaum eine Funktion" angemessen erläutert. kurz gesagt, es an die Arbeit um eine Sicherheitslücke in der vorherigen Iteration von Windows hoch recondite Konsole API vorhanden ist , die für die Rechteausweitung in Versionen von NT älter als Windows 7. (Vista, FYI erlaubt, nicht über conhost.exe, die von geziemt seiner Status als Windows Millennium der NT-Familie.)

2. Jedes Programm, das das Äquivalent von Unix stdin / stdout / stderr haben möchte, benötigt eine Konsole, daher eine Instanz von conhost.exe. Einwanderer aus dem Unix-Land wie Apache, PHP und andere wollen diese Streams, daher die automatische Instanziierung des Systems conhost.exefür sie, unabhängig davon, ob sie tatsächlich ein Fenster anzeigen oder nicht. Theoretisch wäre es möglich, die Quelle für z. B. Apache so zu ändern, dass kein Terminal erforderlich ist, und sie als Windows-GUI-Anwendung anstelle einer Konsolenanwendung zu kompilieren, sodass das System nicht das Bedürfnis hat, sie zu erzeugen conhost.exe. Vorausgesetzt, es ist auch in der Praxis möglich, scheint sich niemand genug darum gekümmert zu haben. Vielleicht bist du der Erste.

3. Einen Gegebenen töten conhost.exe Instanz beenden, wird die Konsolen-E / ziemlicher Sicherheit für jeden Prozess deaktiviert, der unter dieser Instanz ausgeführt wird. Das interessiert Sie wahrscheinlich nicht, da Sie es mit Serverprozessen zu tun haben, die auf den Konsolen-E / A-Streams sowieso nichts Interessantes bewirken. Es gibt also wahrscheinlich keinen Grund, ihre E / A-Prozesse nicht zu beenden conhost.exe. Wenn Sie Zweifel haben, töten Sie sie und prüfen Sie, ob etwas kaputt geht.

4. Es gibt keine Möglichkeit zu verhindern, dass Windows beim Starten conhost.exeeines Programms, das die Konsolen-E / A anfordert, eine Instanz erstellt. Der einzige Weg, dies zu tun, wäre, es neu zu kompilieren, so dass Windows es nicht als Konsolenanwendung ansieht. Wenn Sie jedoch davon ausgehen, dass das Beenden eines übergeordneten Serverprozesses conhost.exedie Funktionalität in keiner Weise beeinträchtigt, die Sie interessieren, können Sie alle Prozesse gleichzeitig beenden, indem Sie taskkill /f /im conhost.exeeine Aufforderung zum Ausführen oder ein Konsolenfenster aufrufen - vorzugsweise das erstere, da Letzterer wird wahrscheinlich sterben und mit ziemlicher Sicherheit aufhören zu arbeiten, sobald seine übergeordnete conhost.exeInstanz getötet wird. Wenn Sie Zweifel haben, töten Sie sie erneut und prüfen Sie, ob etwas kaputt geht.

Eine Konsolenanwendung startete mit dem DETACHED_PROCESS Flag erhält weder einen Konsolen- noch einen untergeordneten Conhost-Prozess. Das Problem ist, dass das Flag nicht für Enkelkinder gilt, sodass es nur mit den Prozessen funktioniert, die Sie direkt starten (wenn Sie überhaupt ein Dienstprogramm finden, mit dem Sie dieses Flag angeben können).

Die andere Option, die möglicherweise funktioniert, ist, wenn der Konsolenprozess die FreeConsole()Funktion aufruft . Einige Serveranwendungen unterstützen den Parameter -d oder -detach, dies ist jedoch auf * nix-Systemen wahrscheinlich häufiger der Fall.

Schnelle Lösung, die für Sie arbeiten kann. Fügen Sie beim Verknüpfen Ihrer Anwendung / SUBSYSTEM: WINDOWS zu den Optionen hinzu. Sie können auch editbin.exe verwenden, um eine vorhandene ausführbare Datei zu ändern.

Dies verhindert, dass Windows eine conhost.exe für Ihre Anwendung erzeugt.