4

Problem

So, we ran into a very strange problem. Currently this is our situation. We have two builds servers attached to two TFS collections

  • Collection A has a build server with Windows Server 2012 R2 installed on it
  • Collection B has a build server with Windows Server 2008 R2 installed on it.

Both servers have the sonar-msbuild-runner installed. Everything works fine on Collection A but when executing the analysis on the build server on Collection B we get the following error.

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

We retrieved the latest version on Github and added additional logging to find out which line caused the error. This line is causing the problems.

Reproducing

I was able to reproduce this error on my local dev machine that runs Windows 7 with the following code. When setting a debug point on the first Assert and then trying to access the projectName property by hovering your mouse over it, it will cause my entire Visual Studio to crash.

[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);

    }
}

Resulting in the following error message:

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

Possible Solution

The error leads straight to this KB article. We were unable to apply this fix.

Additionally we removed the .NET framework 4 because version 4.5.2 was already installed and we thought it might conflict with each other. Now only 4.5.1 and 4.5.2 are still installed on the build server and we are unsure what a solution could be. As a final option, we are considering upgrading the build server on collection B to Windows Server 2012 R2 to see if this could be a solution.

Edit: Fixed

Due to an internal error, VS2013 was deinstalled. So we had to reinstall VS2013 and update 4. We also upgrade to version 1.0. This seems to have fixed the problem. Code Coverage is now available in our web portal.

Pascal Berger
  • 4,262
  • 2
  • 30
  • 54
Rik van den Berg
  • 2,840
  • 1
  • 18
  • 22
  • Are you using TFS 2013 ? The code that is crashing is retrieving the code coverage file from TFS and to do this it needs to connect to TFS using the TFS Object Model. It looks like there's a problem between the Object Model and the .net fwk on the machine... – Bogdan Gavril MSFT Jul 16 '15 at 15:37
  • @BogdanGavril-MSFT It is TFS2013 and in the unit test it is version assembly version v12.0 that is being referenced – Rik van den Berg Jul 16 '15 at 16:21

1 Answers1

3

This looks like a problem / bug in the .NET framework, as you also investigated. If you can upgrade to Windows Server 2012 R2 then this would be best way to go forward.

There is also a workaround on the part of sonar-msbuild-runner: you can disable the code coverage retrieval by setting an environment variable: SQ_SkipLegacyCodeCoverage. However if you do this SonarQube will not get code coverage data ...

Bogdan Gavril MSFT
  • 20,615
  • 10
  • 53
  • 74
  • Thanks for clarifying! Setting that environment variable does help for now while we wait for our system upgrade. I assume legacy means the build servers before TFS2013 as opposed to the VNext that is coming? – Rik van den Berg Jul 16 '15 at 18:23
  • 1
    Indeed, "legacy" refers to XAML builds and "VNext" refers to the new system which (I think) will be known as simply "TFS Build". There is an issue with XAML builds in that the code coverage file is uploaded to the TFS server and deleted locally so Sonar MSBuild Runner needs to re-download it to be able to send it to the SonarQube server. – Bogdan Gavril MSFT Jul 17 '15 at 09:50
  • This issue is resolved after we upgraded to version 1.0 of the MSBuild.SonarQube.Runner. We also had to reinstalled VS2013. We are unsure wether both or one of the two actions resolved the issue. – Rik van den Berg Jul 30 '15 at 09:55