Azure DevOps SonarQubeAnalyze@5 & SonarQube 9.9 LTS failing to download scanner jar

Upgraded from previous 8.9.x LTS Developer Edition to 9.9 LTS Developer Edition, currently running into issues with our Azure DevOps pipelines failing when trying to download the scanner-developer-9.9.0.x.jar

Caused by: java.lang.IllegalStateException: Fail to download scanner-developer- to C:\...

##[error]The process 'F:\agent-02\_work\_tasks\SonarQubePrepare_15b84ca1-b62f-4a2a-a403-89b77a063157\5.11.1\classic-sonar-scanner-msbuild\SonarScanner.MSBuild.exe' failed with exit code 1

Any ideas as to why this is suddenly happening & how to resolve? We’re running the latest Analyze step against the latest LTS. We didn’t have this issue with LTS 8.9 & SonarQubeAnalyze@4.

Edit: per this post I tried the supposed URL ( from which the step is trying to download the scanner and I end up with:

{"errors":[{"msg":"Plugin scanner-developer- not found"}]}

Edit 2: our C# projects reference SonarAnalyzer.CSharp currently, if that has any impact.

Edit 3: We’re currently checking to see if this is an AV issue on our end, and have verbose logging on. For anyone wondering, edit 1 here is incorrect, the URL hit is: /batch/file?name=scanner-developer-


Is this download URL something generated for you or one you crafted?

Could you provide your full analysis log?

The analysis / scanner log is what’s output from the analysis command. Hopefully, the log you provide - redacted as necessary - will include that command as well.

This guide will help you find them.


Generated per edit 3, retrieved from the verbose logs.

This appears to be some weirdness like others have experienced in the following threads:

Plugin download fails - SonarQube - Sonar Community (
Scanner always timeout during plugin download - SonarQube - Sonar Community (

We’re running SonarQube on AKS with an nginx reverse proxy, utilizing the official helm chart and with the built-in ingress from that chart. Trying to retrieve plugins even from a normal browser has the same behavior where the download “completed” (XXMB downloaded of XXMB) but the connection takes an extremely long time to actually close, and thus the browser to consider it to be actually completed.

We haven’t experienced this with any other AKS-nginx hosted services that deal with files, so this appears to be something peculiar to SonarQube itself. We managed to “solve” this by upping the variable to 180 seconds as well as slip-streaming any plugins failing to be downloaded into the destination cache location manually.


Thanks for verifying. I’ve flagged this for more expert attention.


Hello @crookc, thanks a lot for taking the time to participate in the community.

Based on your inputs, and the that you had to increase at the SonarQube level, could you run some other tests ?

Our hypothesis is that it is either the network that is too slow or “full”, or the SonarQube pod that is under heavy load.

In order to asses those, could you follow the tests outlined here.

The goal is to run the download very close to the SonarQube pod, to determine if its the network or the pod.

Please let us know if you need some more information, waiting to ear from you.