So SonarQube refused to start and Windows threw a dramatic message about jvm.dll being missing or a server JVM that vanished into the void. Relax, this is usually not the end of the world. It is a classic case of architecture mismatch or the service wrapper pointing at the wrong Java install. Follow these steps and your SonarQube will stop ghosting you.

Quick check to prove something broke

Open a Command Prompt and run the usual suspects to see what Java the system actually knows about.

java -version
where java

If java -version shows a 32 bit runtime while your SonarQube is the 64 bit build you will get the missing jvm.dll or missing server JVM error. The Windows service wrapper cannot load a 32 bit jvm into a 64 bit process. That is not a metaphor.

Install a matching 64 bit JDK or JRE

Download a vendor supported 64 bit JDK or JRE that matches SonarQube requirements. Pick the 64 bit installer. If you already have a Java install but it is 32 bit then uninstall or avoid it. SonarQube needs a 64 bit jvm.dll living inside a 64 bit Java install.

Set JAVA_HOME and update PATH so things stop guessing

Create or update the environment variable named JAVA_HOME to point at the Java install folder. Then make sure the Java bin is first on PATH so the service and startup scripts find the right java executable.

setx JAVA_HOME "Program Files\Java\jdk1.8.0_xxx"
setx PATH "%JAVA_HOME%\bin;%PATH%"

On Windows services the environment in use can be different from your interactive shell. If the SonarQube service is installed make sure the service account sees the same JAVA_HOME and PATH, or skip to the wrapper step below.

Force the SonarQube wrapper to use the right Java

If the service still picks the wrong java then stop trusting guesswork. Edit the file in the SonarQube conf folder named wrapper.conf and set the wrapper command to the full path of the 64 bit java.exe. That removes the mystery and prevents Windows from loading the wrong jvm.dll.

# look for a property like this in conf\wrapper.conf
wrapper.java.command=Program Files\Java\jdk1.8.0_xxx\bin\java.exe

Save the file and make sure you edited the copy that the installed service actually uses. Some installers copy config files around so double check which folder your service points at.

Run the right startup script or restart the service

If you run SonarQube by hand use the batch file in the proper platform bin folder. For a 64 bit Windows install that is the bin\windows-x86-64 folder. If you run SonarQube as a Windows service stop and start the service so the wrapper reloads the new settings.

net stop SonarQube
net start SonarQube
rem or run .\bin\windows-x86-64\StartSonar.bat

Extra debugging tips when jvm.dll still plays hide and seek

• Run where java to see every java.exe on PATH. Remove older entries that point at 32 bit installs.
• Check the Java release bitness in the java -version output. Look for 64 bit keywords or missing bits that betray a 32 bit build.
• Open the wrapper logs to see which path it tried to load. Logs will show the actual command line the wrapper used to start Java.
• If SonarQube uses a Windows service created by a wrapper exe confirm that the wrapper executable matches your SonarQube package architecture. The wrapper and SonarQube packaging usually match but it is worth a peek.

Short checklist to finish like a pro

• Confirm 64 bit Java is installed
• Set JAVA_HOME to the 64 bit install
• Put %JAVA_HOME%\bin early on PATH
• Edit conf\wrapper.conf to use the full Java path if needed
• Restart the SonarQube service or run the correct StartSonar.bat

If you followed these steps and SonarQube still complains about missing jvm.dll then post the wrapper log and java -version output. Most likely the problem is an unexpected Java somewhere on PATH or a wrapper pointing at an old config. Fix that and the server JVM will stop sulking.