Tag Archives: Windows

MSI Hacking: Intel SDK for OpenCL Installed on Windows 10

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: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.)



Failure to set SearchScopes with sysprep in Internet Explorer

It’s supposed to be possible to set the default search engine in Windows Internet Explorer using a custom unattend.xml file with sysprep.  This technique uses the SearchScopes configuration under Microsoft-Windows-IE-InternetExplorer.

If you’re maintaining images of Windows 8 or Windows Server 2012R2, you may have come across problems where these SearchScopes fail to apply correctly.  Sysprep will run successfully, but on startup Bing will still be the default search engine in IE.   After some investigation, the issue appears to be related to having certain (now obsolete) Windows Updates applied to the base image.

To resolve, search for KB2976627 and KB2987107 in the installed Windows updates, and remove them if found.  Reboot after removal, followed by a full check for new updates.  Install any pending updates as normal, and re-run sysprep.  Assuming your SearchScopes are properly configured, they should work now.

This is an OEM record

We’ve been having an issue where our Dell servers will fill up their hardware event logs with the following, particularly during reboot:

Tue Jan 17 2012 09:02:00 This is an OEM record.
Tue Jan 17 2012 09:02:00 This is an OEM record.
Tue Jan 17 2012 09:02:00 This is an OEM record.

This is something of an issue since the event log fills up rather quickly, and you lose the ability to collect more meaningful logs (hardware failure!). But what does this mean, and why so many of the same message?

The short version is that Windows includes an IPMI driver which has the ability to also write to the machine system event log (SEL). Everywhere you see “This is an OEM record” is basically the DRAC’s way of saying “The OS wrote this, and I don’t know what it means.” The DRAC can only decode its own entries.

This handy article actually does a nice job of explaining how to use racadm to decode said logs: http://en.community.dell.com/techcenter/systems-management/w/wiki/bmc-sel-log.aspx. It also explains why Windows shutdowns tend to spam the logs with lots of entries, and how to stop it from doing so via a regedit.

Finally, here is the official Microsoft KB for disabling the IPMI logging: http://support.microsoft.com/kb/962920