So, we ran into a very strange problem. Currently this is our situation. We have two builds servers attached to two TFS collections
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.
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
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.
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.
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 ...