TL;DR: Java Error 1603 usually happens due to missing files, leftover Java components, active Java processes, or using the online installer. Deploying the offline Java MSI with PDQ Deploy is the most reliable way to fix it, especially in legacy Windows environments.
Java Error 1603 is a Windows Installer fatal error that commonly occurs during Java deployments when required files, registry keys, or prior Java remnants interfere with installation. This guide explains the most common causes of Java Error 1603 and how to reliably fix it, especially when deploying Java via MSI in legacy Windows environments.
Note: This post references legacy Java versions and older Windows operating systems. While some examples and file paths are specific to those environments, the underlying causes and troubleshooting process for Java Error 1603 remain applicable to modern Java MSI deployments.
Additionally, PDQ Deploy does not work on Home editions of Windows.
What is Java Error 1603?
This is a Windows Installer (MSI) error that simply means “Fatal error during installation." This error usually means that something the installer expected wasn’t available or something exists that the installer didn’t expect.
There are a number of reasons why 1603 is thrown. Rather than try to go into all the different reasons why this could happen (the number of reasons are too voluminous for a simple blog), I will quickly mention a few and then show you a great way to overcome this problem when it comes to Java. So pour a Guinness and listen (read) up.
What causes Java Error 1603 during installation?
A required installation file is missing, such as the data1.cab file if you are installing using the extracted MSI in Java 7. (Java 8 no longer uses a separate .cab file as all the necessary files are embedded in the actual MSI.)
If you are deploying Java, then an AV solution may delete the included files, thus causing the installer to throw a 1603.
There are remnants of a previous Java installation.
When Java is installed (by default) it attempts to uninstall previous updates in the same family (e.g. Installing Java 7 Update 71 will uninstall Java 7 Update 67, but not Java 6 or Java 8).
Sometimes previous updates are not completely uninstalled. When this happens, a 1603 error can occur when the new version tries to install.
Sometimes the only remnant (that can still cause a failure) is a stray registry key!
Java is currently being used when the installation begins.
This is fairly common when you attempt to deploy the jre-7uxx-windowsxx.exe and the target computer is running Java in a browser.
You are attempting to deploy the online Java EXE.
If you are deploying the EXE (and not the extracted MSI), then it is imperative that you only install the offline version. A quick way to tell is if your install file contains the letters “iftw” in the name. (e.g. jre-8u11-windows-i586-iftw.exe). IFTW means “install from the web.” This file is very small (usually < 2 MB). NEVER deploy this file. First of all, the online version usually includes the Ask Toolbar, which we all know really, really sucks and is actually worse than any 1603 error you’ll ever run into. Just grab the offline file from Java, or better yet just use the Java packages from the PDQ Package Library.
How do you fix Java Error 1603 when deploying Java?
The most reliable way to fix Java Error 1603 is to deploy Java using a preconfigured offline MSI package via PDQ Deploy. Here is a screenshot of Java 8 packages in the PDQ Deploy Package Library.
In most cases, you can simply deploy the Java 8 Update 25 package.
You will need a PDQ license to access these packages.
Quick & easy patch management
Unlock automated patching that's simple, secure, and pretty damn quick.
Update
One of our awesome power users, Selfman, sent us some information regarding the installation of Java on non-English versions of Windows and how he beat his particular 1603 error. His message is included below:
The problem is within the installer which has some issues with Unicode / non-English characters.
During the installation, the installer creates a installcache folder which is by default located (in WinXP)
at C:\Documents and Settings\All Users\Application data\Oracle\Java\installcache\
This folder contains bspatch.exe, baseimagefam8, diff.
The bspatch is run and creates a “newimage” which is basically a ZIP file.
This is then located by the installer.exe during its run:
C:\Program Files\Java\jre1.8.0_60\installer.exe “C:\Program Files\Java\jre1.8.0_60\installer.exe” /s INSTALLDIR=”C:\Program Files\Java\jre1.8.0_60\\” REPAIRMODE=0 ProductCode={26A24AE4-039D-4CA4-87B4-2F83218060F0}
The problem is that the path is set to a wrong location, so for example in Czech edition of WindowsXP its
C:\Documents and Settings\All Users\Data aplikac\Oracle\Java\installcache\newimage
instead of
C:\Documents and Settings\All Users\Data aplikací\Oracle\Java\installcache\newimage
The ' í ' character is missing from the path.
This is the reason why the installation fails. The installer can’t find the newimage and ends with “PATH NOT FOUND” (Process monitor)
The workaround is to copy the whole Oracle folder to the referred location and rerun the jre-8u60-windows-i586.exe setup.
The problem does not seem to appear on English Windows or systems with MUI/LIP.
My installation package failed and so did the AA alternative package.


