web-dev-qa-db-ja.com

VBCSCompiler.exeの多数のインスタンス

最近、Visual Studio Professional 2015（14.0.23107.0）をダウンロードしてインストールしました。初めてソリューション（28プロジェクト）を開き、Build-> Rebuild Solutionを実行したときに、開発マシンが完全にクロールされました。 CPUは100％で最大になり、ビルドは10分以上経過しても完了しませんでした。

Windowsタスクマネージャーを開いて、次のことに気付きました：> 10個のVBCSCompiler.exeタスクが実行されています。これらのタスクを組み合わせると、CPUが90％を超えて送信されました。

これらのタスクの多くが実行されている理由は何ですか？これを防ぐ方法はありますか？

これは、同じ問題を経験している他の誰かに私が見つけることができる最も近いものです： https://github.com/dotnet/roslyn/issues/279

更新（8/7）

-ハンス・パッサン、素晴らしい考え。私のマネージャーはこのリリース（14.0.23107.0）を提供してくれました。これは「公式リリース」の正しいバージョンですか?? Visual Studio 2015のリリースごとのバージョンを故意にインストールしたことはありませんでした。ベータ版が存在するとは思いません。

-Kyle Trauberman、Visual Studioのコンテキストでの環境変数についてはそれほど詳しくありません。ただし、単純にset DisableRosyln=true VS（およびMSBuild）コマンドプロンプトウィンドウ。これは何の影響も与えなかったようです。 VBCSCompiler.exeは、VS2015を再起動した後でもすぐにバックアップを示しました。

VS2015インストールを修復し、再起動しました。これは役に立ちませんでした。

パート2を更新（8/7）今回はこの問題は発生しませんでしたが、あなたが説明したことを確認しました。

VBCSCompiler.exeでロードされたモジュールに関しては、次のとおりです。

enter image description here

.NETコアアセンブリのバージョンが異なるのは興味深いことです。あなたは4.06.79にいますが、私は4.06.81にいます。

私の「クライアント側dll」（C：\ Program Files（x86）\ MSBuild\14.0\Bin\Microsoft.Build.Tasks.CodeAnalysis.dllにあります）は、あなたと同じバージョンとタイムスタンプです： enter image description here

奇妙なことに、ILSpyのコードを見ると、わずかに異なるものが見えます-おそらく最適化でしょうか？

    private static NamedPipeClientStream TryAllProcesses(string pipeName, int timeoutMs, CancellationToken cancellationToken, out string newPipeName)
{
    string str = pipeName;
    int num = 1;
    while (File.Exists(string.Format("\\\\.\\pipe\\{0}", pipeName)))
    {
        NamedPipeClientStream result;
        if ((result = BuildClient.TryConnectToProcess(pipeName, timeoutMs, cancellationToken)) != null)
        {
            newPipeName = pipeName;
            return result;
        }
        pipeName = str + "." + num.ToString(CultureInfo.InvariantCulture);
        num++;
    }
    newPipeName = pipeName;
    return null;
}

** VBCSCompiler.exeのインスタンスに渡される特定のpipname引数についてご説明します。私はそれが再び起こるまで待たなければならないでしょう。

c#.netvisual-studio-2015roslyn
58
John Russell

うーん、明白な再現シナリオはなく、他の誰もこれについて文句を言いません。あなたの解決策はまったく珍しいことではありません。 CPUを100％にペグし、VBCSCompilerプロセスに約1.5 GBを飲み込ませることは、大規模プロジェクトではそれほど難しくありませんが、私のものを見るときしみがあります。

いくつかのアンインストールされたベータビットが存在する最初の可能性のある障害シナリオは、非常に一般的な問題です。デバッガーを使用して、外観を確認します。 [デバッグ]> [プロセスにアタッチ]を使用して、実行中のインスタンスの1つを選択します。次に、[デバッグ]> [すべて解除]および[デバッグ]> [表示]> [モジュール]。バージョン番号とタイムスタンプに注意してください。これらは次のようになります。

enter image description here

読みやすくするために、意図的にいくつかの列を非表示にしていることに注意してください。タイムスタンプはCSTタイムゾーンです。

それがサーバー側です。バグを発見したクライアント側は、C：\ Program Files（x86）\ MSBuild\14.0\Bin\Microsoft.Build.Tasks.CodeAnalysis.dllにあります。そのプロパティを見てください。私のサイズは85,192バイトで、日曜日に作成されます。6月21、2015、7:06:54 PM、ファイルバージョン番号1.0.0.50618。 ReflectorやILSpyなどの逆コンパイラでファイルを確認し、BuildClient.TryAllProcesses（）に移動します。バグ修正に関連する行は次のとおりです。

for (int i = 1; File.Exists(string.Format(@"\\.\pipe\{0}", pipeName)); i++)

バグのあるバージョンには\\.\pipe\がありませんでした。

上記のスニペットでエラーチェックが非常に不適切であることに注意してください。File.Exists（）は多くの理由でfalseを返します。また、バグが以前に発見されなかった基本的な理由。これにより、プログラマーが自主的にインストールする典型的なシュリンクラップマルウェアにマシンが感染した場合に有効になる、いくつかの障害モードが可能になります。サーバーとクライアントのコードは、特別な名前の名前付きパイプを介して相互に接続します。タスクマネージャーの[プロセス]タブに表示されるもの。 [表示]> [列の選択]（Win8以降：列ヘッダーを右クリック）を使用して、[コマンドライン]オプションをオンにします： enter image description here

-pipename引数に注意してください。 File.Exists（）呼び出しがfalseを返す場合、MSBuildはVBCSCompiler.exeを再び起動します。これらのすべてのインスタンスが同じ-pipename引数で実行されている場合、通常の名前付きパイプの使用を妨げるソフトウェアがマシン上で実行されています。次に検討する最初のことは、攻撃性の低いマルウェア対策ソリューションを探すことです。 System.IO.Pipes名前空間を使用して、より優れた例外メッセージを取得する小さなテストプログラムを作成できます。

21
Hans Passant

これらのタスクの多くが実行されている理由は何ですか？

Roslynは、コンパイルされたコードをメモリに保持して、後続のコンパイルで再利用できる共有コンパイラプロセスを使用します。そのため、2回目のコンパイルは高速になりますが、ご覧のとおり、メモリのオーバーヘッドがあります。

これを防ぐ方法はありますか？

はい。 here からmsbuildには、共有コンパイラをオフにするコンパイルタスクのプロパティがあり、 default によってtrueに設定されます。

そのため、各プロジェクトでは、このプロパティをプロジェクトファイルに追加する必要があります。または、Visual Studio 2015には共有プロジェクトがあり、このプロパティを共有プロジェクトに追加して、この設定を必要とする他のすべてのプロジェクトにその共有プロジェクトを含めることができます。

<PropertyGroup>
  <UseSharedCompilation>false</UseSharedCompilation>
</PropertyGroup>
20
Cameron MacFarland

2015年11月22日の時点で、この問題はVisual Studio 2015コミュニティエディションでも発生していました。私のラップトップは、VBCSCompilerのすべてのインスタンスがフルスロットルで実行され、スペースヒーターを兼ね始めていました。

私のために働いた唯一の修正は、Webアプリケーションの/ bin/roslynディレクトリでVBCSCompiler.exeファイルを見つけて、セキュリティ許可を変更することでした 。

denyWebアプリが実行されているAppPoolの読み取りと実行の許可が必要です。

enter image description here

7
Aaron Hudon

Slaksによれば、DisableRoslyn環境変数をtrueに設定することで、roslyn（VBCSCompiler.exeのように見える）を無効にできます。

詳細については、 http://blog.slaks.net/2014-05-21/exploring-roslyn-part-2-inside-end-user-preview/ を参照してください。

上記のリンクはプレビュー用であることに注意してください。ただし、当時から現在までに大幅に変更されたとは想像できません。

2
Kyle Trauberman

VBCSCompilerの「キープアライブ」オプションを変更して、実行直後に閉じることもできます...「VBCSCompiler.exe.config」ファイル（「C：\ Program Files（x86）\ MSBuild\14.0\Bin \」を変更する必要があります） VBCSCompiler.exe.config "）および必要な値を秒単位で設定します（デフォルトでは600です）。

1
Kosmich

アプリケーションプールの詳細設定でIDを「NetworkService」に変更すると、問題が解決されることがわかりました。

0
Shazoo

Visual Studio Enterprise 2015 Update 1でもこの問題が発生しました。この問題は、Update 2にアップグレードすることで解決しました。

0
Bogdan