VBCSCompiler.exe의 수많은 인스턴스

VBCSCompiler.exe의 수많은 인스턴스

---

최근에 Visual Studio Professional 2015 (14.0.23107.0)를 다운로드하여 설치했습니다. 처음으로 솔루션 (28 개 프로젝트)을 열고 Build-> Rebuild Solution을 수행했을 때 개발 머신이 절대적으로 크롤링되었습니다. CPU가 100 %에 도달했고 빌드가 완료되지 않았습니다.

Windows 작업 관리자를 열고> 10 개의 VBCSCompiler.exe 작업이 실행 중임을 확인했습니다. 이러한 작업을 결합하면 CPU가 90 % 이상을 보냈습니다.

왜 이렇게 많은 작업이 실행되고 있는지 아십니까? 이런 일이 발생하는 것을 막을 방법이 있습니까?

이것은 동일한 문제를 경험하는 다른 사람에게 가장 가까운 것입니다 : https://github.com/dotnet/roslyn/issues/2790

업데이트 (8/7)

-Hans Passant, 대단한 생각. 관리자가이 릴리스 (14.0.23107.0)를 제공했습니다. 이것이 "공식 릴리스"에 대한 올바른 버전입니까 ?? Visual Studio 2015의 릴리스 별 버전을 고의로 설치하지 않았습니다. 베타 비트가 존재하지 않는다고 생각합니다.

-Kyle Trauberman, 저는 Visual Studio의 컨텍스트에서 환경 변수에 익숙하지 않습니다. 그러나 나는 순진하게 set DisableRosyln=trueVS (및 MSBuild) 명령 프롬프트 창에서 실행했습니다. 이것은 어떤 영향도 미치지 않는 것 같습니다. VBCSCompiler.exe는 VS2015를 다시 시작한 후에도 바로 백업되었습니다.

VS2015 설치를 복구하고 재부팅을 수행했습니다. 이것은 도움이되지 않았습니다.

업데이트 Part 2 (8/7) -Hans Passant, 매우 인상적인 글 쓰기 !! 이번에는 문제가 발생하지 않았지만 설명하신 내용을 살펴 보았습니다.

VBCSCompiler.exe로로드 된 모듈에 관한 한, 다음은 내가 가지고있는 것입니다.

.NET 핵심 어셈블리가 다른 버전에 있다는 것은 흥미 롭습니다. 당신은 4.06.79이고 나는 4.06.81입니다.

내 "클라이언트 측 dll"(C : \ Program Files (x86) \ MSBuild \ 14.0 \ Bin \ Microsoft.Build.Tasks.CodeAnalysis.dll에 있음)은 귀하와 동일한 버전 및 타임 스탬프에 있습니다.

이상하게도 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 인수에 대해 다시 알려 드리겠습니다. 다시 일어날 때까지 기다려야 할 것입니다.

---

흠, 명백한 재현 시나리오가 없으며 아무도 이것에 대해 불평하지 않습니다. 귀하의 솔루션은 전혀 드문 일이 아닙니다. CPU를 100 %로 페깅하고 VBCSCompiler 프로세스가 ~ 1.5GB를 삼키도록하는 것은 대규모 프로젝트에서 그리 어렵지 않지만 내 것을 보면 깨끗합니다.

몇 가지 제거 된 베타 비트가있는 첫 번째 가능한 실패 시나리오는 매우 일반적인 문제입니다. 디버거를 사용하여 살펴보십시오. 디버그> 프로세스에 연결을 사용하고 실행중인 인스턴스 중 하나를 선택합니다. 그런 다음 디버그> 모두 중단 및 디버그>보기> 모듈. 버전 번호와 타임 스탬프에주의를 기울이십시오. 다음과 같아야합니다.

읽을 수 있도록 일부 열을 의도적으로 숨겼습니다. 타임 스탬프는 CST 시간대입니다.

---

그것이 서버 측입니다. 버그가 발견 된 클라이언트 측은 C : \ Program Files (x86) \ MSBuild \ 14.0 \ Bin \ Microsoft.Build.Tasks.CodeAnalysis.dll에 있습니다. 속성을 살펴보면 내 파일은 85,192 바이트이며 June 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 이상 : 열 머리글을 마우스 오른쪽 단추로 클릭)을 사용하고 "명령 줄"옵션을 선택합니다.

Note the -pipename argument. If the File.Exists() call returns false then MSBuild will start VBCSCompiler.exe again. If you see all these instances running with the same -pipename argument then you have software running on your machine that is interfering with normal named pipe usage. First thing you'd consider then is to look for a less aggressive anti-malware solution. You can write a little test program that uses the System.IO.Pipes namespace to get a better exception message.

---

Any idea why there are so many of these tasks running?

Roslyn uses a shared compiler process that keeps your compiled code in memory for reuse in subsequent compiles. So the second compile will be quicker, but as you've seen there's a memory overhead.

Any way to stop this from happening?

Yes. From here there's a property of the compile task in msbuild that turns off the shared compiler, and it's set to true by default.

So in each project you'll have to add this property to the project file. Or in Visual Studio 2015 there's now shared projects, where you could add this property to the shared project and then include that shared project in all the other projects that need this setting.

<PropertyGroup>
  <UseSharedCompilation>false</UseSharedCompilation>
</PropertyGroup>

---

As of November 22, 2015 this issue was still happening to me in the Visual Studio 2015 community edition. My laptop was starting to double as a space heater with all of the instances of VBCSCompiler running full throttle.

The only fix that worked for me was to locate the file VBCSCompiler.exe in the /bin/roslyn directory of the web application and change security permissions on it.

You need to deny read & execute permission for the AppPool that your web app is running under.

---

According to Slaks, you can disable roslyn (which is what the VBCSCompiler.exe appears to be) by setting the DisableRoslyn environment variable to true.

See http://blog.slaks.net/2014-05-21/exploring-roslyn-part-2-inside-end-user-preview/ for more information.

Note, the link above is for the preview, but I can't imagine that it would have changed much between then and now.

---

VBCSCompiler의 "keep alive"옵션을 변경하여 실행 후 바로 닫을 수도 있습니다 ... "VBCSCompiler.exe.config"파일 ( "C : \ Program Files (x86) \ MSBuild \ 14.0 \ Bin \)을 수정해야합니다. VBCSCompiler.exe.config ") 필요한 값을 초 단위로 설정합니다 (기본적으로 600).

---

Visual Studio Enterprise 2015, 업데이트 1에서도이 문제가 발생했습니다.이 문제는 업데이트 2로 업그레이드하여 해결되었습니다.

---

응용 프로그램 풀 고급 설정에서 ID를 'NetworkService'로 변경하면 문제가 해결되었음을 알았습니다.

참고 URL : https://stackoverflow.com/questions/31708758/numerous-instances-of-vbcscompiler-exe