sfondo

L'anno scorso ho compilato un sistema portatile di blog / web server che posso eseguire da un'unità flash. È fantastico e funziona meravigliosamente, specialmente su XP. Il problema è che quando viene eseguito in Windows 7, ciascun programma della console genera due processi, il processo stesso e una copia di conhost.exe.

Problema

Nel caso del sistema di blog portatile, ognuno dei suoi componenti server (MySQL mysqld.exe, le due istanze di Apache, le due istanze di httpd.exeVisualSVN visualsvnserver.exee le istanze multiple di PHP php-cgi.exe) genera un'istanza di conhost.exe. In questo momento (senza copie php-cgi.exeattive, ho cinque istanze di conhost.exeesecuzione, che usano quasi i cicli della CPU, ma che consumano 22 MB di memoria (oltre agli 80 MB che i processi attuali stanno attualmente utilizzando).

Ricerca

Dal momento che Windows 7 è stato rilasciato (e penso che forse dal Vista), ho più volte cercato di capire esattamente quale scopo i vari processi (nuovo) di accoglienza (ad esempio, conhost.exe, dllhost.exee taskhost.exe) fanno e se sono effettivamente necessari. Ho provato a ucciderli e ho scoperto che i programmi della console continuano a funzionare, sia per i programmi che usano una finestra della console, sia per quelli che non lo fanno (come i server).

Ho già familiarità con l'intero csrss.exe⇨ Windows Vista ⇨conhost.exe e ho visto la stessa spiegazione (quasi alla lettera) più volte. Il problema è che tutti semplicemente copiano e incollano quella stessa spiegazione che non è utile. Tutto ciò che dice è che in XP, le applicazioni console dove "ospitato da" o "eseguito sotto" csrss.exe, ma in Windows 7, sono state spostate conhost.exeper motivi di sicurezza. L'aspetto della sicurezza ha un senso, ma non dice nulla su cosa significhi ospitarlo o perché / quando è necessario (o se è possibile evitarlo se non necessario). Anche la discussione di Raymond Chen sull'argomento spiega perché le app per console sono ospitate in modo diverso.

La cosa più vicina a una spiegazione tecnica e dettagliata è un post sul blog di Microsoft che sembra rafforzare l'idea che si tratti semplicemente della GUI e della finestra dell'app della console. Questo mi lascia ancora più difficile chiedermi se conhost.exesia necessario per programmi senza finestre come questi server. Se non c'è alcuna finestra, allora perché dovrei sprecare risorse e ingombrare lo spazio del processo con processi non necessari? Perché Windows non è in grado di rilevare quando non è necessario ed evitarlo? La risposta di SecurityMatt è stata anche leggermente utile per quanto riguarda una spiegazione tecnica, ma ancora una volta, non abbastanza delle informazioni che sto cercando.

Non sono l'unico che ha cercato di trovare un modo per fermare casi non necessari di conhost. Questa persona ha chiesto di disabilitarlo e gli è stato semplicemente detto "non è possibile" senza ulteriori sforzi o pensarci. Hugh D e "Quasi una caratteristica" hanno sottolineato il problema con numerose istanze ridondanti di conhost(almeno con csrss, era in esecuzione una sola copia), incluso l'uso delle risorse e le istanze persistenti dopo la fine dei loro processi figlio. Laufer mi ha chiesto se / quando fosse necessario.

Osservazioni e tentativi di soluzione

Se non sono realmente necessari in ogni momento (di nuovo, non ho visto alcun effetto negativo nel ucciderli), allora suppongo che potrei (molto irritante) aggirare il problema sostituendo i server con file batch che eseguono i server , attendere e quindi uccidere la copia di conhostciò che eseguono. Naturalmente questo richiede un modo semplice e veloce per determinare quale sia. FallenGameR ha chiesto come ottenere l'istanza conhost.exeassociata a un programma console di un determinato PID ma non ha ottenuto una risposta. Penserei che il semplice recupero del PID del processo genitore dovrebbe fare il trucco (no, ProcessExplorer non è un'opzione, un automatizzato / gestibile da scriptè necessaria una soluzione), ma non solo ciò richiederebbe la creazione di una sorta di framework per ottenere il PID del bambino (anziché semplicemente eseguirlo e completarlo con l'attività), ma significherebbe anche trovare un modo per renderlo compatibile anche con XP (ad es. controllo del nome dell'immagine del processo genitore). Questo post sul blog fornisce un modo, ma richiede PowerShell ed è quasi l'ideale, per non parlare del fatto che non dice nulla sulle ramificazioni dell'esecuzione dello script.

Domande)

Forse Microsoft immagina che nessuno usi più i prompt dei comandi (* tosse * Windows 8 * tosse *) e quindi ha ipotizzato che non sia un grosso problema caricarli, ma ci sono sicuramente scenari in cui sono in esecuzione più app per console e ognuna con ognuna generare un processo PID in più, che consuma memoria, è terribile e, nella migliore delle ipotesi, cercare di aggirare il problema è terribilmente scomodo.

Qualcuno ha informazioni definitive e autorevoli sulla questione? Ancora una volta, ho già letto la spiegazione generica; Mi chiedo:

1. Perché le applicazioni console devono (ancora) essere gestite in modo diverso
2. In quali circostanze specifiche devono avereconhost
3. Quali sono le conseguenze dell'uccisioneconhost
4. Se c'è un modo per fermarlo / prevenirlo / disabilitarlo / bloccarlo o almeno un modo semplice per affrontarlo rapidamente dopo?

1. Le applicazioni della console devono essere gestite in modo diverso perché sotto il kernel NT (che è alla base di 2000, XP, Vista, Windows 7 e Windows 8) sono cittadini di seconda classe. Nell'architettura del sistema Unix, ad ogni processo al momento della creazione sono associati i flussi di input, output ed errore standard; il terminale IO è implementato in termini di questi flussi (stdin proveniente dalla tastiera e stdout / stderr che va al terminale), e un ulteriore sforzo è richiesto da parte di un processo che non desidera utilizzare quei flussi o avere i loro descrittori di file si aprono.

   Nell'architettura di Windows NT, che pur non essendo un discendente lineare di VMS, è stato sviluppato più o meno dallo stesso team, è vero il contrario; un processo appena generato per impostazione predefinita non ha alcun flusso I / O collegato ad esso e non esiste un concetto come "terminale". I programmi che desiderano comportarsi in modo leggermente più Unixy possono richiedere (mediante dichiarazione in fase di compilazione) che il sistema crei per loro una finestra della console e flussi di input / output ad esso collegati; il sistema lo farà, ma poiché Windows, a differenza di Unix, non offre terminali gratuiti, è necessario un notevole sforzo aggiuntivo per crearne uno, quindi precedentemente csrss.exee ora conhost.exe.

   Per quanto riguarda la differenza tra i due, il link "Difficilmente una funzionalità" lo spiega abbastanza adeguatamente; in breve, esiste per ovviare a un difetto di sicurezza nella precedente iterazione dell'API console altamente ricondizionata di Windows, che ha consentito l'escalation dei privilegi nelle versioni di NT precedenti a Windows 7. (Vista, FYI, non ha conhost.exe, che si adatta al suo stato come Windows Millennium della famiglia NT.)

2. Qualsiasi programma che desideri l'equivalente di Unix stdin / stdout / stderr necessita di una console, quindi un'istanza di conhost.exe. Gli immigrati dalla terra di Unix, come Apache, PHP, e altri, vorranno questi flussi, da cui l'istanza automatica del sistema conhost.exeper loro, indipendentemente dal fatto che visualizzino o meno una finestra. In teoria, sarebbe possibile modificare l'origine per es. Apache in modo tale che non richiedesse alcun terminale e compilarlo come un'applicazione GUI di Windows anziché come un'applicazione console, in modo che il sistema non sentisse la necessità di generarlo a conhost.exe. Supponendo che sia anche possibile in pratica, nessuno sembra essersi preoccupato abbastanza per farlo. Forse sarai il primo.

3. Uccidere un dato conhost.exequasi sicuramente disabiliterà l'IO della console per qualunque processo sia in esecuzione in quell'istanza. Probabilmente non ti interessa, perché hai a che fare con processi server che non stanno facendo nulla di interessante sui flussi IO della console, quindi probabilmente non c'è motivo di non uccidere i loro messaggi conhost.exe. In caso di dubbio, uccidili e vedi se si rompe qualcosa.

4. Non è possibile impedire a Windows di creare un'istanza conhost.exeall'avvio di un programma che richiede l'IO della console; l'unico modo per farlo sarebbe ricompilarlo in modo che Windows non lo consideri come un'applicazione console. Tuttavia, supponendo che l'uccisione del genitore di un determinato processo del server conhost.exenon ne comprometta la funzionalità nel modo che ti interessa, dovresti essere in grado di ucciderli tutti in una volta inviando taskkill /f /im conhost.exeun prompt Esegui o una finestra della console - preferibilmente il primo, poiché quest'ultimo probabilmente morirà, e quasi sicuramente cesserà di funzionare, non appena la sua conhost.exeistanza padre verrà uccisa. Ancora una volta, in caso di dubbio, uccidili e vedi se si rompe qualcosa.

Un'applicazione console avviata con il DETACHED_PROCESSflag non ottiene una console né un processo figlio conhost. Il problema è che il flag non si applica ai nipoti, quindi funzionerà solo con i processi che avvii direttamente (se riesci a trovare un'utilità che ti consente di specificare questo flag).

L'altra opzione che potrebbe funzionare è se il processo della console chiama la FreeConsole()funzione. Alcune applicazioni server supportano un parametro -d o -detach ma questo è probabilmente più comune sui sistemi * nix ...

Soluzione rapida che potrebbe funzionare per te. Quando si collega l'applicazione, aggiungere / SUBSYSTEM: WINDOWS alle opzioni. È inoltre possibile utilizzare editbin.exe per modificare un eseguibile esistente.

Questo impedisce a Windows di generare un conhost.exe per la tua applicazione.