In doing a bit of spring cleaning on my home PC, which was upgraded from Windows 7 to 10 several months back, I came across one particular application whose installer was refusing to behave. The product name was Intel® SDK for OpenCL* Applications 2013, and I had installed it several years ago under Windows 7, for reasons that are both mysterious and unimportant.
Normally, removing an application is as simple as opening the Add/Remove Programs dialog and clicking Uninstall. But in the case of this particular tool, the (un)installer refused to function at all under Windows 10. Any attempt to invoke it produced the following unhelpful little popup:
Intel® SDK for OpenCL* Applications 2013 designed to work on Microsoft Windows Vista* x64, Windows* 7 x64, Windows* 8 x64, Windows Server* 2008 R2 x64 operating systems only. The installer detected that you're trying to install the SDK on a different version. Aborting installation
At this point I had a few options. Walking away and leaving it to sit on my hard drive forever was the obvious one, but a true nerd never turns down a challenge. Downgrading to Windows 7 was right out, so I decided it was time to earn my stripes for the day.
First things first, let’s see what we can learn about the application. Most traditional apps register their uninstallers in the registry, or we can query WMI from the command line. I chose the latter.
wmic wmic:root\cli> product where "name like '%opencl%'"
The output gives us an important piece of information: the location of the installer MSI in the package cache.
Installers are basically glorified zip files that include additional layers of features: instructions for where on the system to place the files, dialogs to present to the user, etc. An Uninstaller is basically just an installer in reverse; it tells the system where the files are that need to be removed. Now that we know where the (un)installer is stored, we can work on it.
MSI installers can be invoked from the command line, so we can try that option next.
msiexec /x C:\WINDOWS\Installer\1d2d2be.msi
No luck… same failure.
We could also enable debug logging with msiexec to gather more information, but at this point it’s pretty clear that the installer’s logic is broken. It’s fairly common to prevent people from installing on an unknown version of Windows, but it’s a bit less sensible to prevent an uninstall, and it seems like whoever wrote the installer routines just never planned for this scenario.
Fortunately for us, unlike some install systems, MSI files are fairly easy to edit. There are lots of tools you could use for this, but I chose one that is free, relatively light weight, and provided by none other than Microsoft (meaning it’s hopefully fairly safe too). The tool is called Orca and it’s part of the Windows SDK.
Note that you don’t need the SDK for your version of Windows; any version that contains Orca will do. You also don’t need everything in the SDK installer, which can be quite large. In the case of the Windows 7 SDK, Orca is part of the Win32 Development Tools.
Frustratingly, the SDK doesn’t actually install the Orca application, it installs the Orca installer. (We must go deeper!) So, once the SDK is installed, pull up the SDK installation directory and locate Orca.msi. Install that, and then you’re good.
Before launching Orca, make a copy of the installer MSI that you’re going to edit. Always have a backup! If anything goes wrong during the editing process, we’ll want a pristine copy to fallback on, or we may never get this app removed.
Now we launch Orca, and open up our edit copy of the problem MSI. We can now browse (and modify) the MSI tables right from this tool. In this case, I looked for the error message that I knew appeared when the installer failed.
And there it is…
The LaunchCondition table lists, as the name suggests, conditions the installer checks for before allowing the installation to proceed. Or in my case, the uninstallation. I select the offending condition in the menu, and Delete. Save the MSI, and exit Orca.
Now all that remains is to put the new MSI where Windows expects to find it: the location named in WMI, where we originally found the file. (For installed MSI products, Windows will use the installer from the cache, even if you launch a different installer with the same ID from somewhere else on the filesystem.)