Centinaia di istanze MSBuild e ConHost che si generano e riempiono la memoria quando si tenta di eseguire l'applicazione Web in Visual Studio 2015

Question

Per riportare alcuni retroscena, avevo anche questo problema su VS2012. Casualmente (non tutto il tempo), quando sono andato a gestire il mio progetto Web sulle aziende su IE tramite vs2012, si sarebbe bloccato per un po 'e alla fine non è riuscito a caricare. Ho notato che la mia macchina avrebbe essenzialmente difficoltà a fare qualsiasi cosa, e si è quasi fermata.

Il controllo del task manager rivelerebbe CENTO, se non MIGLIAIA di istanza MSBuild.exe e Conhost.exe generati, riempiendo ogni possibile byte di memoria che potevano (max 8 giga sulla macchina). Avevo solo una manciata di soluzioni che dovevano essere costruite.

Non ho mai scoperto la vera causa, ma un eventuale aggiornamento a VS2012 credo fermato quel problema per diversi mesi.

Avanti veloce ad oggi, ora sono su una macchina con 16 giga di RAM e ora eseguo VS2015 14.0.23107.

Ho notato di recente che il problema della generazione infinita di MSBuild e Conhost era tornato, questa volta riempiendo tutti i miei 16 GB di memoria.

Ho cercato internet più che posso, ma non ho trovato argomenti simili a quello che sto vivendo.

So che questa è una 'possibilità' di Microsoft, come riferito qui:

msbuild.exe staying open, locking files

e in altri luoghi.

Ma nessuno che ho visto ha un problema in cui tanti MSBuilds e Conhosts generano che ogni singolo byte di memoria viene consumato da loro, e sei costretto a riavviare la tua macchina o aspettare che muoiano tutti (cosa che non fa sembra accadere dopo un determinato periodo di tempo).

Le uniche variabili d'ambiente mi viene in mente di quando questo è accaduto di recente sono:

1. avevo almeno 2 istanze di VS2015 esecuzione
2. avevo appena fatto fare i cambiamenti e la costruzione di una soluzione
3. Sono andato a eseguire la nostra applicazione Web su una soluzione che dipende da quella precedente che avevo appena creato.

Qualcun altro ha questo problema, e hai mai trovato la causa?

operativa -Editazione-

Update: io non sono al 100%, se questo è stato risolto, ma non ho ottenuto da quando ho fatto questi cambiamenti.

In sostanza, abbiamo due diverse soluzioni qui al lavoro. Sono molto simili, l'unica differenza è che uno di essi ha meno altri progetti/dipendenze con esso.

Passaggio tra queste due soluzioni spesso e credo che la soluzione di configurazione per uno di loro avesse "Debug con diagnostica estesa" selezionata per almeno un progetto.

Inoltre, ho avuto le opzioni di compilazione impostate per eseguire fino a 8 build paralleli allo stesso tempo.

Il nostro manager di devops pensa che sia possibile che, una sorta di passaggio tra le soluzioni combinate con le build parallele abbia causato una sorta di corruzione/errore che ha generato migliaia di MSBuild.

Da allora abbiamo risolto il problema con "Debug con diagnostica estesa" e ho modificato le opzioni di compilazione in modo che fosse solo una build parallela e da allora non ho riscontrato il problema.

Answer 1

In modo abbastanza interessante, ho avuto il problema in cui un flusso di processi MSBuild e conhost ha iniziato a spuntare e ha ucciso tutta la mia memoria. Nel mio caso, è stato correlato al mio test con le caratteristiche del fuso orario. Ho cambiato il mio fuso orario del sistema operativo per test/controllo qualità di un'applicazione web e questo è stato il risultato per qualche motivo. A qualcosa con Visual Studio non piacciono le modifiche al fuso orario al volo.