SonarScanner MsvcDriver crashes when analysing

SonarQube Version: 8.9.1 (build 44547)
SonarScanner Version:

Our build setup uses FastBuild together with the Visual Studio Build Tools to compile our codebase.

Since SonarQube 8.9 (LTS) does not support generation of the build wrapper based on a Compilation Database yet, I used the conversion script workaround mentioned on JIRA.

When running the sonarscanner on the converted build-wrapper-dump.json, I get a NullPointerException at com.sonar.cpp.analyzer.MsvcDriver.onCapture ( (see full crash log below) - after successfully generating the metadata.

What would cause such an exception?

I cannot share the entire logs due to the proprietary nature of the project. If you need specific information, please let me know and I’ll and share if possible.

These are all supported SonarQube plugins:

  - CSS Code Quality and Security (cssfamily)
  - PL/SQL Code Quality and Security (plsql)
  - Scala Code Quality and Security (sonarscala)
  - C# Code Quality and Security (csharp)
  - Vulnerability Analysis (security)
  - Java Code Quality and Security (java)
  - HTML Code Quality and Security (web)
  - Flex Code Quality and Security (flex)
  - XML Code Quality and Security (xml)
  - VB.NET Code Quality and Security (vbnet)
  - Swift Code Quality and Security (swift)
  - CFamily Code Quality and Security (cpp)
  - Python Code Quality and Security (python)
  - Go Code Quality and Security (go)
  - JaCoCo (jacoco)
  - Kotlin Code Quality and Security (kotlin)
  - RPG Code Quality (rpg)
  - PL/I Code Quality and Security (pli)
  - T-SQL Code Quality and Security (tsql)
  - VB6 Code Quality and Security (vb)
  - Apex Code Quality and Security (sonarapex)
  - JavaScript/TypeScript Code Quality and Security (javascript)
  - Ruby Code Quality and Security (ruby)
  - Vulnerability Rules for C# (securitycsharpfrontend)
  - Vulnerability Rules for Java (securityjavafrontend)
  - License for SonarLint (license)
  - Vulnerability Rules for JS (securityjsfrontend)
  - COBOL Code Quality (cobol)
  - Vulnerability Rules for Python (securitypythonfrontend)
  - PHP Code Quality and Security (php)
  - ABAP Code Quality and Security (abap)
  - Vulnerability Rules for PHP (securityphpfrontend)

Crash log:

09:40:11.597 DEBUG: stylelint-bridge server will shutdown
09:40:16.638 INFO: ------------------------------------------------------------------------
09:40:16.638 INFO: ------------------------------------------------------------------------
09:40:16.638 INFO: Total time: 37.152s
09:40:16.737 INFO: Final Memory: 38M/176M
09:40:16.737 INFO: ------------------------------------------------------------------------
09:40:16.738 ERROR: Error during SonarScanner execution
        at com.sonar.cpp.analyzer.MsvcDriver.onCapture(
        at com.sonar.cpp.plugin.CFamilySensor.process(
        at com.sonar.cpp.plugin.CFamilySensor.process(
        at com.sonar.cpp.plugin.CFamilySensor.execute(
        at org.sonar.scanner.sensor.AbstractSensorWrapper.analyse(
        at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(
        at org.sonar.scanner.sensor.ModuleSensorsExecutor.execute(
        at org.sonar.scanner.scan.ModuleScanContainer.doAfterStart(
        at org.sonar.core.platform.ComponentContainer.startComponents(
        at org.sonar.core.platform.ComponentContainer.execute(
        at org.sonar.scanner.scan.ProjectScanContainer.scan(
        at org.sonar.scanner.scan.ProjectScanContainer.scanRecursively(
        at org.sonar.scanner.scan.ProjectScanContainer.doAfterStart(
        at org.sonar.core.platform.ComponentContainer.startComponents(
        at org.sonar.core.platform.ComponentContainer.execute(
        at org.sonar.scanner.bootstrap.GlobalContainer.doAfterStart(
        at org.sonar.core.platform.ComponentContainer.startComponents(
        at org.sonar.core.platform.ComponentContainer.execute(
        at org.sonar.batch.bootstrapper.Batch.doExecute(
        at org.sonar.batch.bootstrapper.Batch.execute(
        at org.sonarsource.scanner.api.internal.batch.BatchIsolatedLauncher.execute(
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(Unknown Source)
        at java.base/java.lang.reflect.Method.invoke(Unknown Source)
        at org.sonarsource.scanner.api.internal.IsolatedLauncherProxy.invoke(
        at com.sun.proxy.$Proxy0.execute(Unknown Source)
        at org.sonarsource.scanner.api.EmbeddedScanner.doExecute(
        at org.sonarsource.scanner.api.EmbeddedScanner.execute(
        at org.sonarsource.scanner.cli.Main.execute(
        at org.sonarsource.scanner.cli.Main.execute(
        at org.sonarsource.scanner.cli.Main.main(

Hi @remcok ,

could you share the entire log and the build-wrapper output folder content if I send you a private message?

Hi @mpaladin,

Sadly I’d still not be able to share those unless I redacted pretty much everything in the file.

I was able to narrow down the cause on my end. If I swap out the path of the executable of all captures, SonarScanner does not throw an exception. It seems that - even though the executables exist for all captures - some permissions are set incorrectly.

If that sparks any ideas, please let me know.

Hi @remcok ,

unfortunately without the logs I cannot help you much, and it is not a good idea to change the build-wrapper-dump.json file as you may get an incorrect and unintended analysis.

That’s unfortunate.

Based on the call stack that I provided, would you at least be able to share what is a causing the null pointer exception? E.g. can the SonarScanner not find the executable, or does it not have permission to run it?

Hi @remcok ,

I can see what is causing the stack trace and I would need the debug log to give a better hint, instead of just starting to guess.

I was able to solve the issue by including a capture of the msvc-cl that ran with no command-line arguments and returns an stdout and stderr, like such:

It seems that SonarScanner is looking through the build-wrapper-dump.json's captures for an entry that has an stderr, which is then used to determine the Compiler Version. If it’s missing, it throws the NullPointerException that I was seeing.

Hi @remcok ,

I just want to state that it is not supported to modify build-wrapper-dump.json content, this is a workaround, you are not fixing the real issue which is still unknown.

As stated in the original question, we are manually generating the build-json-wrapper.json as a workaround

Since SonarQube 8.9 (LTS) does not support generation of the build wrapper based on a Compilation Database yet, I used the conversion script workaround mentioned on JIRA.

This is a workaround recommended by SonarQube devs, which only works - for us - with the amendments made to the script that I listed in the solution. As such, it does solve the real issue.

Hi @remcok ,

I indeed missed or forgot about this point, sorry about that. Then fine to add the probe manually as you did.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.