What causes DllNotFoundException?

Java Runtime Environment is not installed on the Self-Hosted IR host machine, so jvm.dll does not exist. JRE is installed but its bin\server (or bin\client) directory is not on the system PATH, preventing Windows from locating jvm.dll. Bitness mismatch: a 32-bit JRE is installed but the Self-Hosted IR is 64-bit (or vice versa), causing the correct jvm.dll to be unfindable. The JAVA_HOME environment variable is missing or incorrect, and the IR service was not restarted after JRE installation to inherit the updated PATH

How do I fix DllNotFoundException?

Step 1: Confirm whether JRE is installed on the IR host by running java -version in a command prompt; if it returns an error, install the 64-bit JRE matching your 64-bit Self-Hosted IR from https://www.java.com.. Step 2: After installation, verify that the PATH environment variable includes the JRE's bin and bin\server directories (e.g., C:\Program Files\Java\jre1.8.0_XXX\bin and ...\bin\server) where jvm.dll resides.. Step 3: Set or correct the JAVA_HOME system environment variable to point to the JRE root directory; apply the change at the system level (not user level) so the IR Windows service can inherit it.. Step 4: Restart the Self-Hosted Integration Runtime service — environment variable changes are not picked up by running services until a restart.. Step 5: Re-run the failing Copy activity; if jvm.dll is still not found, use Process Monitor (Sysinternals) on the IR host to trace the exact paths Windows searches for the DLL and ensure the correct path is included.

High severityconfigurationAzure Data Factory →

Power BI Refresh Error:
DllNotFoundException

What does this error mean?

The Self-Hosted IR failed to load a required native DLL — most commonly jvm.dll from the Java Runtime Environment — when processing Java-dependent file formats like ORC or Parquet, causing the Copy activity to fail.

Common causes

1Java Runtime Environment is not installed on the Self-Hosted IR host machine, so jvm.dll does not exist
2JRE is installed but its bin\server (or bin\client) directory is not on the system PATH, preventing Windows from locating jvm.dll
3Bitness mismatch: a 32-bit JRE is installed but the Self-Hosted IR is 64-bit (or vice versa), causing the correct jvm.dll to be unfindable
4The JAVA_HOME environment variable is missing or incorrect, and the IR service was not restarted after JRE installation to inherit the updated PATH

How to fix it

1Step 1: Confirm whether JRE is installed on the IR host by running java -version in a command prompt; if it returns an error, install the 64-bit JRE matching your 64-bit Self-Hosted IR from https://www.java.com.
2Step 2: After installation, verify that the PATH environment variable includes the JRE's bin and bin\server directories (e.g., C:\Program Files\Java\jre1.8.0_XXX\bin and ...\bin\server) where jvm.dll resides.
3Step 3: Set or correct the JAVA_HOME system environment variable to point to the JRE root directory; apply the change at the system level (not user level) so the IR Windows service can inherit it.
4Step 4: Restart the Self-Hosted Integration Runtime service — environment variable changes are not picked up by running services until a restart.
5Step 5: Re-run the failing Copy activity; if jvm.dll is still not found, use Process Monitor (Sysinternals) on the IR host to trace the exact paths Windows searches for the DLL and ensure the correct path is included.

Frequently asked questions

Why does jvm.dll fail to load even after I install JRE?

The most common reason is that the IR Windows service started before JRE was installed and has not been restarted, so it is running with the old PATH that does not include the JRE bin directories. Always restart the Self-Hosted IR service after installing or updating JRE.

Is there a way to avoid needing JRE on the IR node for Parquet files?

Yes — if you move the workload to an Azure Integration Runtime (cloud-hosted), JRE is managed by Microsoft and you do not need to install anything. The JRE requirement only applies to Self-Hosted IR nodes processing Java-dependent formats locally.