Sensor C# performance degradation on Microsoft Hosted agents

SonarQube Cloud
,
1
  • ALM used: Azure DevOps
  • CI system used: Azure DevOps
  • Languages of the repository: C#, (Detected in analysis: [cs, css, web, xml, json, js, vbnet, yaml])

We are using Microsoft Hosted agents to run analysis, since Monday last week (26.05.2025 ~around 2PM CEST) we are observing a significant increase in time spent on the scanner (50-70x in case of a large analysis)
Before it used to take around 10-15 minutes (we’ve been doing it like this for a while)
For smaller projects we have also observed an increase, but not as drastic.

Before:

INFO: Importing 1XXX Roslyn reports
Found 8XX MSBuild C# projects: 5XX MAIN projects. 1XX TEST projects. 1XX with no MAIN nor TEST files.
Sensor C# [csharpenterprise] (done) | time=88179ms

Currently:

INFO: Importing 1XXX Roslyn reports
Found 8XX MSBuild C# projects: 5XX MAIN projects. 1XX TEST projects. 1XX with no MAIN nor TEST files.
Sensor C# [csharpenterprise] (done) | time=6246000ms

The amount of projects is exactly the same in both cases.
All other tasks ran on the agent seem to have similar execution times - so it is probably not the fault of the Microsoft hosted agent, but we can’t rule it out entirely.
Most tasks in the sonar log except for the C#/VBNET scanner also seem too have similar performance.

All the versions in the log file seem to be exactly the same, runner-image version is the same, Java version etc.

SonarScanner for MSBuild 10.1.2
INFO: SonarScanner 5.0.1.3006

We cannot verify the exact version of Sonar language plugins since they are not printed without DEBUG

We tried passing the following settings:

sonar.ai.codefix.hidden=true
sonar.sca.enabled=false
sonar.scanner.scanAll = false
And messing the the scope analysis using inclusion/exclusions but achieved no results.

3

I believe we are seeing this specific issue as well. Our codebase is a mix of C# and VB.net, I see these two lines accounting for most of the time:

2025-06-06T11:23:02.7567215Z 11:23:02.740 INFO: Sensor C# [csharpenterprise] (done) time=2379152ms
2025-06-06T11:52:51.6284905Z 11:52:51.621 INFO: Sensor VB.NET [vbnetenterprise] (done) time=1465773ms

Within that there is an approx 50/50 split between steps like:

Importing results from 8 proto files in …
Not enough content in ‘[FilePath]’ to have CPD blocks

and the second half importing Roslyn reports:

Processing Roslyn report: C:\a\1.sonarqube\out\343\Issues.json
Adding external issue CA1825: ..
Adding normal issue S3236: …

With no standout issue accounting for most cases.

Our hardware is a Azure VM in a scaleset or Standard_F8s_v2 machines. The image for this hasn’t been changed.

SonarScanner for MSBuild 8.0.3
SonarScanner 5.0.1.3006

I can provide verbose log files etc privately.
We noticed this from 2025/06/02, prior to that the analysis of a similar sized PR was taking approx 15 mins total.

4

Hi all,

Thanks for the pings. We’re looking in to this.

@PLJAKRZ4, first welcome to the community! Second, can you confirm that “last Monday” is May 26 (English is so imprecise sometimes.)

 
Thx,
Ann

5

Hi again,

We believe we’ve identified the cause and - given that it’s already the weekend for most of our engineers - are planning to tackle it first thing Monday.

 
Thx,
Ann

1 Like
6

Hello, yes it was May 26th.

I guess internally on a Friday afternoon I like to believe that Monday after the weekend is further away than it really is.
Will edit the opening post for clarity

1 Like
7

Hi,

A fix was deployed that should fix the performance issue. We would be happy to hear a confirmation from you that it solved your issue.

Thanks!

3 Likes
9

We are seeing massive improvement in our Analyze step performance since you’ve rolled out the change. We’ve gone from (pre any problems) taking about 35 minutes for most runs of approx 400 projects to now taking around 5 minutes.

I was a little suspicious at first, but it does appear to be producing the issues and coverage reports we’d expect.

Thanks for the quick responses.

3 Likes
10

We’ve managed to run a build after the fix.
We got an execution time within our expectations (sub 10 minutes).

Thank you for the prompt support.

2 Likes
11

Thanks for the confirmation, that’s great to hear!

If I understand correctly you’re analysis is even faster then before the performance degradation. This is also great news and we already hoped that this is the case.

Do you know which kind of projects are faster now? With the deployed fix, the analysis of CSS / VBNet projects in Pull Requests should be faster then before.

Best