tło

W zeszłym roku skompilowałem przenośny system blog / serwer WWW, który mogę uruchomić z dysku flash. Jest świetny i działa wspaniale, szczególnie na XP. Problem polega na tym, że gdy jest uruchamiany w systemie Windows 7, każdy program konsoli odradza dwa procesy, sam proces plus kopię conhost.exe.

Problem

W przypadku przenośnego systemu blogów, każdy z jego składników serwera (MySQL mysqld.exe, dwa wystąpienia Apache, dwa wystąpienia httpd.exeVisualSVN visualsvnserver.exei wiele wystąpień PHP php-cgi.exe) spawnuje wystąpienie conhost.exe. W tej chwili (bez kopii php-cgi.exeaktywnych, mam pięć instancji conhost.exeuruchomionych, zużywających prawie żadnych cykli procesora, ale zużywających 22 MB pamięci (oprócz 80 MB, których aktualnie używają rzeczywiste procesy).

Badania

Ponieważ system Windows 7 został wydany (i myślę, że być może od Vista), mam kilkakrotnie próbowali dowiedzieć się dokładnie, jaki cel różne procesy (nowy) hosta (na przykład conhost.exe, dllhost.exei taskhost.exe) robić i czy są one rzeczywiście niezbędne. Próbowałem je zabić i stwierdziłem, że programy konsoli nadal działają, zarówno dla programów korzystających z okna konsoli, jak i tych, które nie działają (jak serwery).

Znam już cały csrss.exe⇨ Windows Vista ⇨conhost.exe i wielokrotnie widziałem to samo (prawie dosłownie) wyjaśnienie . Problem polega na tym, że wszyscy po prostu kopiują i wklejają to samo wyjaśnienie, które nie jest pomocne. Wszystko, co mówi, to to, że w XP-, konsolowych aplikacjach, gdzie „hostowane przez” lub „uruchamiane pod” csrss.exe, ale w Windows 7 zostały przeniesione do conhost.exebezpieczeństwa. Aspekt bezpieczeństwa ma sens, ale nie mówi nic o tym, co to znaczy go hostować ani dlaczego / kiedy jest to konieczne (lub czy można tego uniknąć, jeśli nie jest to konieczne). Nawet dyskusja Raymonda Chena na ten temat ukazuje, dlaczego w ogóle aplikacje konsolowe są hostowane inaczej.

Najbliższe szczegółowe wyjaśnienie techniczne mogę znaleźć na blogu Microsoft, który wydaje się potwierdzać pogląd, że chodzi tylko o GUI i okno aplikacji konsolowej. To sprawia, że ​​zastanawiam się jeszcze bardziej, czy conhost.exejest to konieczne w przypadku programów bez okien, takich jak te serwery. Jeśli w ogóle nie ma okna, to dlaczego miałbym marnować zasoby i zaśmiecać przestrzeń procesową niepotrzebnymi procesami? Dlaczego system Windows nie może wykryć, gdy jest to niepotrzebne i go uniknąć? SecurityMatt za odpowiedź była również nieznacznie użyteczne w odniesieniu do technicznego wyjaśnienia, ale znowu nie na tyle informacji szukam.

Nie jestem jedynym, który próbował znaleźć sposób na powstrzymanie niepotrzebnych przypadków conhost. Ta osoba zapytała o wyłączenie i powiedziano jej po prostu „nie jest to możliwe”, bez dalszych wysiłków lub myśli o tym. Hugh D i „Hardly a feature” wskazali na problem z licznymi, nadmiarowymi instancjami conhost(przynajmniej z csrssuruchomioną tylko jedną kopią), w tym z wykorzystaniem zasobów i instancjami trwałymi po zakończeniu ich procesów potomnych. I Laufer zastanawiał się, czy / kiedy jest to konieczne.

Obserwacje i próby rozwiązania

Jeśli nie są one faktycznie konieczne przez cały czas (ponownie, nie widziałem żadnych złych skutków ich zabicia), to przypuszczam, że mógłbym (bardzo irytująco) obejść ten problem, zastępując serwery plikami wsadowymi, które uruchamiają serwery , poczekaj, a następnie zabij kopię conhost, którą powodują. Oczywiście wymaga to szybkiego i łatwego sposobu ustalenia, który to jest. FallenGameR zapytał, jak uzyskać instancję conhost.exeskojarzoną z programem konsolowym o danym PID, ale nie otrzymał odpowiedzi. Myślę, że po prostu pobranie PID procesu nadrzędnego powinno załatwić sprawę (nie, ProcessExplorer nie jest opcją, automatyczny / skryptowyrozwiązanie jest wymagane), ale nie tylko wymagałoby stworzenia jakiegoś frameworka, aby uzyskać PID dziecka (zamiast po prostu uruchomić go i wykonać zadanie), ale oznaczałoby to również wymyślenie sposobu, aby był kompatybilny także z XP (np. sprawdzenie nazwy obrazu procesu nadrzędnego). Ten post na blogu podaje jeden sposób, ale wymaga programu PowerShell i nie jest idealny, nie wspominając o tym, że nie mówi nic o konsekwencjach uruchomienia skryptu.

Pytania)

Być może Microsoft stwierdził, że nikt już nie używa wierszy poleceń (* kaszel * Windows 8 * kaszel *) i dlatego założył, że nie jest wielkim problemem, aby je obciążać, ale zdecydowanie są scenariusze, w których działa wiele aplikacji konsolowych i każdy z nich ma swoje spawnowanie dodatkowego, pochłaniającego pamięć procesu wykorzystującego PID jest okropne, a próba obejścia go jest w najlepszym wypadku okropnie niewygodna.

Czy ktoś ma ostateczne, wiarygodne informacje w tej sprawie? Znów przeczytałem już ogólne wyjaśnienie; Zastanawiam się:

1. Dlaczego aplikacje konsolowe muszą (nadal) być w ogóle obsługiwane inaczej?
2. W jakich konkretnych okolicznościach muszą miećconhost
3. Jakie są konsekwencje zabijaniaconhost
4. Czy jest jakiś sposób, aby go zatrzymać / zapobiec / wyłączyć / zablokować lub przynajmniej łatwy sposób, aby szybko sobie z tym poradzić?

1. Aplikacje konsolowe muszą być obsługiwane w różny sposób, ponieważ w jądrze NT (który leży u podstaw wszystkich wersji 2000, XP, Vista, Windows 7 i Windows 8) są obywatelami drugiej kategorii. W architekturze systemu Unix każdy proces w czasie tworzenia ma dołączone standardowe strumienie wejściowe, wyjściowe i błędów; terminal IO jest zaimplementowany pod względem tych strumieni (stdin wychodzący z klawiatury i stdout / stderr idący do terminala), a proces, który nie chce korzystać z tych strumieni lub nie wymaga ich deskryptory plików są otwarte.

   W architekturze Windows NT, która choć nie była liniowym potomkiem VMS, została opracowana przez mniej więcej ten sam zespół, prawda jest odwrotna; nowo odrodzony proces domyślnie nie ma z nim żadnych strumieni we / wy i nie ma takiej koncepcji jak „terminal”. Programy, które chcą zachowywać się w nieco bardziej uniksowy sposób, mogą zażądać (poprzez deklarację czasu kompilacji), aby system utworzył dla nich okno konsoli i podłączone do niego strumienie wejścia / wyjścia; system to zrobi, ale ponieważ system Windows, w przeciwieństwie do systemu Unix, nie udostępnia terminali za darmo, konieczne jest sporo wysiłku, aby utworzyć taki, dawniej csrss.exei teraz conhost.exe.

   Jeśli chodzi o różnicę między tymi dwoma, link „Prawie żadna funkcja” wyjaśnia to dość dokładnie; w skrócie, istnieje możliwość obejścia luki w zabezpieczeniach w poprzedniej iteracji wysoce zrekonstruowanego interfejsu API konsoli Windows, który pozwalał na eskalację uprawnień w wersjach NT starszych niż Windows 7. (Vista, FYI, nie ma conhost.exe, co jest zgodne z jego status Windows Millennium z rodziny NT).

2. Każdy program, który chce odpowiednika Uniksa stdin / stdout / stderr, potrzebuje konsoli, stąd instancja conhost.exe. Imigranci z Unix-landu, tacy jak Apache, PHP i inni, będą chcieli tych strumieni, stąd automatyczna instancja systemu conhost.exedla nich, niezależnie od tego, czy faktycznie wyświetlają okno, czy nie. Teoretycznie możliwe byłoby zmodyfikowanie źródła dla np. Apache, tak aby nie wymagało terminala, i skompilowanie go jako aplikacji Windows GUI zamiast aplikacji konsolowej, aby system nie odczuwał potrzeby odradzania go conhost.exe. Zakładając, że jest to również możliwe w praktyce, wydaje się, że nikt nie dbał o to wystarczająco. Być może będziesz pierwszy.

3. Zabicie danego conhost.exeprawie na pewno wyłączy IO konsoli dla dowolnego procesu uruchomionego w tej instancji. Prawdopodobnie nie przejmujesz się tym, ponieważ masz do czynienia z procesami serwera, które i tak nie robią nic interesującego w strumieniach IO konsoli, więc prawdopodobnie nie ma powodu, aby nie zabijać ich conhost.exe. W razie wątpliwości zabij ich i sprawdź, czy coś nie zepsuje.

4. Nie ma sposobu, aby uniemożliwić Windowsowi tworzenie instancji conhost.exepo uruchomieniu programu, który żąda konsoli IO; jedynym sposobem na to byłoby ponowne skompilowanie go, aby system Windows nie traktował go jako aplikacji konsoli. Zakładając jednak, że zabicie rodzica danego procesu serwera conhost.exenie wpływa w żaden sposób na jego funkcjonalność, powinieneś być w stanie zabić je wszystkie naraz, wydając taskkill /f /im conhost.exepolecenie Uruchom lub okno konsoli - najlepiej pierwsze, ponieważ ten drugi prawdopodobnie umrze i prawie na pewno przestanie działać, gdy tylko jego conhost.exeinstancja nadrzędna zostanie zabita. Ponownie, jeśli masz wątpliwości, zabij ich i sprawdź, czy coś nie zepsuje.

Aplikacja konsoli uruchomiona z DETACHED_PROCESSflagą nie otrzymuje konsoli ani procesu potomnego conhost. Problem polega na tym, że flaga nie ma zastosowania do wnuków, więc będzie działać tylko z procesami, które uruchamiasz bezpośrednio (jeśli nawet możesz znaleźć narzędzie, które pozwala określić tę flagę).

Inną opcją, która może działać, jest wywołanie FreeConsole()funkcji przez proces konsoli . Niektóre aplikacje serwerowe obsługują parametr -d lub -detach, ale prawdopodobnie jest to bardziej powszechne w systemach * nix ...

Szybkie rozwiązanie, które może Ci pomóc. Podczas łączenia aplikacji dodaj / SUBSYSTEM: WINDOWS do opcji. Możesz także użyć editbin.exe, aby zmodyfikować istniejący plik wykonywalny.

Zapobiega to spawnowaniu systemu Windows przez conhost.exe dla twojej aplikacji.