Sonar-msbuild-runner завершает работу с ошибкой 255, модуль CLR неисправен

Проблема

Итак, мы столкнулись с очень странной проблемой. В настоящее время это наша ситуация. У нас есть два сервера сборки, подключенные к двум коллекциям TFS.

  • Коллекция A имеет сервер сборки с установленной на нем Windows Server 2012 R2.
  • Коллекция B имеет сервер сборки с установленной на нем Windows Server 2008 R2.

На обоих серверах установлен sonar-msbuild-runner. На Коллекции А все работает нормально, но при выполнении анализа на сервере сборки на Коллекции Б мы получаем следующую ошибку.

Faulting application name: SonarQube.MSBuild.PostProcessor.exe, version: .9.0.0, time stamp: 0x559d2baa
Faulting module name: clr.dll, version: 4.0.30319.34209, time stamp: 0x5348961e
Exception code: 0xc0000005
Fault offset: 0x00002d1f
Faulting process id: 0x11ec
Faulting application start time: 0x01d0bf9ffbb54cab
Faulting application path: D:\PathToSolutionFolderOnBuildServer\.sonarqube\bin\SonarQube.MSBuild.PostProcessor.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: 3cbfce4b-2b93-11e5-b84b-0050569a7ef0

Мы получили последнюю версию на Github и добавили дополнительное ведение журнала, чтобы выяснить, какая строка вызвала ошибку. Эта строка вызывает проблемы< /а>.

Воспроизведение

Мне удалось воспроизвести эту ошибку на моем локальном компьютере разработчика под управлением Windows 7 со следующим кодом. Когда я устанавливаю точку отладки в первом Assert, а затем пытаюсь получить доступ к свойству projectName, наведя на него указатель мыши, это приведет к сбою всей моей Visual Studio.

[TestMethod]
public void TestMethod1()
{
    using (TfsTeamProjectCollection collection = TfsTeamProjectCollectionFactory.GetTeamProjectCollection(new Uri("http://tfs-url:8080/tfs/collectionname/")))
    {
        IBuildServer buildServer = collection.GetService<IBuildServer>();
        string uri = "vstfs:///Build/Build/4238";
        var buildUri = new Uri(uri);
        IBuildDetail build = buildServer.GetMinimalBuildDetails(buildUri);
        string projectName = build.TeamProject;

        ITestManagementService tcm = collection.GetService<ITestManagementService>();
        ITestManagementTeamProject testProject = tcm.GetTeamProject(projectName);

        Assert.IsNotNull(testProject);
        IBuildCoverage[] coverage = testProject.CoverageAnalysisManager.QueryBuildCoverage(uri, CoverageQueryFlags.Modules);
        Assert.IsTrue(coverage.Length > 0);

    }
}

В результате появляется следующее сообщение об ошибке:

Faulting application name: devenv.exe, version: 12.0.31101.0, time stamp: 0x54548724
Faulting module name: clr.dll, version: 4.0.30319.34209, time stamp: 0x5348961e
Exception code: 0xc0000005
Fault offset: 0x004c2b43
Faulting process id: 0x10e4
Faulting application start time: 0x01d0bf9ec962fde0
Faulting application path: C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe
Faulting module path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
Report Id: 14f6496d-2b9b-11e5-a293-083e8ea0a055

Возможное решение

Ошибка ведет прямо к этой статье базы знаний. Нам не удалось применить это исправление.

Кроме того, мы удалили .NET framework 4, потому что версия 4.5.2 уже была установлена, и мы подумали, что они могут конфликтовать друг с другом. Теперь на сервере сборки все еще установлены только 4.5.1 и 4.5.2, и мы не уверены, какое решение может быть. В качестве последнего варианта мы рассматриваем возможность обновления сервера сборки в коллекции B до Windows Server 2012 R2, чтобы посмотреть, может ли это быть решением.

Изменить: исправлено

Из-за внутренней ошибки VS2013 был удален. Поэтому нам пришлось переустановить VS2013 и обновить 4. Мы также обновились до версии 1.0. Кажется, это решило проблему. Code Coverage теперь доступен на нашем веб-портале.


person Rik van den Berg    schedule 16.07.2015    source источник
comment
Вы используете TFS 2013? Код, который дает сбой, извлекает файл покрытия кода из TFS, и для этого ему необходимо подключиться к TFS с помощью объектной модели TFS. Похоже, есть проблема между объектной моделью и .net fwk на машине...   -  person Bogdan Gavril MSFT    schedule 16.07.2015
comment
@BogdanGavril-MSFT Это TFS2013, а в модульном тесте ссылка на версию сборки версии v12.0.   -  person Rik van den Berg    schedule 16.07.2015


Ответы (1)


Это похоже на проблему/ошибку в платформе .NET, как вы также исследовали. Если вы можете перейти на Windows Server 2012 R2, то это будет лучший способ двигаться вперед.

Существует также обходной путь со стороны sonar-msbuild-runner: вы можете отключить получение покрытия кода, установив переменную среды: SQ_SkipLegacyCodeCoverage. Однако, если вы сделаете это, SonarQube не получит данные о покрытии кода...

person Bogdan Gavril MSFT    schedule 16.07.2015
comment
Спасибо за разъяснения! Установка этой переменной среды помогает на данный момент, пока мы ждем обновления нашей системы. Я предполагаю, что наследие означает серверы сборки до TFS2013, а не грядущий VNext? - person Rik van den Berg; 16.07.2015
comment
Действительно, устаревшее относится к сборкам XAML, а VNext относится к новой системе, которая (я думаю) будет известна как просто сборка TFS. Существует проблема со сборками XAML, заключающаяся в том, что файл покрытия кода загружается на сервер TFS и удаляется локально, поэтому Sonar MSBuild Runner необходимо повторно загрузить его, чтобы иметь возможность отправить его на сервер SonarQube. - person Bogdan Gavril MSFT; 17.07.2015
comment
Эта проблема устранена после обновления MSBuild.SonarQube.Runner до версии 1.0. Нам также пришлось переустановить VS2013. Мы не уверены, решили ли проблему оба или одно из двух действий. - person Rik van den Berg; 30.07.2015