Quick reality check

If SonarQube croaks with a jvm.dll missing or server JVM error you probably have a Java mismatch, or a PATH playing matchmaker with the wrong runtime. This guide walks through the usual suspects and how to stop SonarQube from trying to load a 32 bit jvm into a 64 bit process and other classic Windows and Linux pratfalls.

Symptoms to look for

• Startup log shows failure to load jvm.dll or a server JVM error
• java -version reports a different runtime than JAVA_HOME
• Windows machines use a stray JRE instead of the JDK

Step by step fixes

1. Install a matching 64 bit JDK

   SonarQube expects a 64 bit Java JDK for server mode. If you installed a 32 bit runtime that will trigger the missing jvm.dll error because the wrapper cannot load a 32 bit DLL into a 64 bit process. Grab a supported JDK from OpenJDK, Oracle, or a trusted build and install the 64 bit variant.

2. Set JAVA_HOME to the JDK root

   Point JAVA_HOME at the JDK root not a JRE. On Windows use the System Environment Variables dialog to create a system variable named JAVA_HOME and set it to the JDK folder. On Linux export JAVA_HOME before starting SonarQube for example

   export JAVA_HOME=/usr/lib/jvm/java-11-openjdk-amd64

   Then verify with

   echo %JAVA_HOME% for Windows or echo $JAVA_HOME for Linux

3. Point SonarQube to the right Java binary

   Edit the startup scripts so SonarQube uses the JDK you just declared. On Windows check bin/windows-x86-64/StartSonar.bat. On all platforms check conf/wrapper.conf for any hard coded Java paths and replace references to a bundled or system JRE with the JDK bin folder. The wrapper and scripts prefer JAVA_HOME so make sure that path is correct.

4. Fix PATH and remove stray JRE entries

   Make sure the JDK bin appears ahead of any older Java installations in PATH. Remove stray JRE entries that might supply a 32 bit jvm.dll. Helpful checks

   • where java on Windows
   • which java on Linux
   • java -version to confirm the binary that will run

5. Restart SonarQube and read the logs

   After making changes restart the SonarQube service or run the startup script from the SonarQube folder so new environment variables are picked up. Watch the logs for a successful JVM load message and any remaining path mismatches.

Troubleshooting tricks that actually help

• If the wrapper still fails check that JAVA_HOME points to a JDK root and not a JRE. The wrapper looks for the JDK in a very literal way.
• Make sure you did not accidentally install a 32 bit JDK or JRE on a 64 bit OS. That is the most common cause of jvm.dll issues.
• If you use a packaged OS JDK double check distribution support for SonarQube versions. Not every combo is happy together.
• If changes do not take effect run the startup script from the same shell that has the environment variables set. Services do not always pick up user level changes.

Parting advice

Think of SonarQube and Java as picky roommates. If you do not point them at the same places you will get a passive aggressive log file. Match the JDK architecture to SonarQube, set JAVA_HOME to the JDK root, fix PATH order, and edit startup scripts if they hard code a bad runtime. Do that and the jvm.dll drama should exit stage left.