Installshield – great for developers, sucks ass for victims (aka everyone else)

Holy crap, what a safari this is turning into.  I’m trying to uninstall a piece of software (the Intel Debugger v9.1.x) that was apparently packaged with Installshield.  However, every time I tell Windows to uninstall it, it returns to me the following error:

image

Idiot move #1: look for help from InstallShield Corp

So I Google for this error and come up with a half-dozen links to various “support” articles from InstallShield and related on how to resolve this error.  It tells me to download various versions of their runtimes and engine installers, none of which make any improvement in the situation.

I went away for a while, came back again today and tried a whole different attack:

Forget the vendor, just debug it yourself (using Process Monitor)

  • Launch Process Monitor, filtering out all running processes except msiexec.exe
  • Near the end we finally see some activity that’s related to the problem:

MsiExec.exe    RegQueryKey    HKCR\CLSID\{8B1670C8-DC4A-4ED4-974B-81737A23826B}\LocalServer32

MsiExec.exe    RegQueryValue    HKCR\CLSID\{8B1670C8-DC4A-4ED4-974B-81737A23826B}\LocalServer32\(Default)    Data: C:\PROGRA~1\COMMON~1\INSTAL~1\Driver\8\INTEL3~1\IDriver.exe

  • Then there are four attempts to launch the IDriver.exe, all of which immediately halt
  • Lastly, there’s an update to the MSI log file which says this:
1: The InstallScript engine on this machine is older than the version required to run this setup.  If available, please install the latest version of ISScript.msi, or contact your support personnel for further assistance.
=== Logging stopped: 09/06/2008  14:02:26 ===

At least I know which file is “older than the version required”.

However, the next problem is figuring out how to get the ‘right one’ executed in its place:

Where Your Hero* Learns Just How Screwed Up InstallShield’s Model Really Is

* aka “just some dick on the Internet”

From what I can tell, Installshield only cares about one person: the dork who blindly builds the Installer package for their one little application.  Apparently, if you need to call on the Installshield components, don’t ever even try to discover whether they’re already installed on the target.  Instead, assume that they must *not* be installed (presumably because every developer on the planet has the privilege of being the first to get software installed on each PC where it’s being used), and always install a copy of some Installshield dependency on the end-user’s PC.  And then for good measure, make sure that there’s a hard-coded dependency on the version of the InstallShield bits that went with the installer.

They sure as hell don’t seem to care about the lowly end-user or IT administrator, who might have to actually *deal* with the nightmare of conflicting/overwriting/installed-to-every-conceivable-corner-of-the-filesystem versions of these hard-coded InstallShield dependencies.

Just for s**ts and giggles, try this at home:

  • fire up REGEDIT.EXE
  • Press [Ctrl]-F to bring up the Search dialog
  • Type Installshield and [Enter]
  • Click the [F3] button a few dozen (or hundred) times

A bit more digging on my own system:

Current version of IDriver.exe in the logged directory = 8.0.0.123

One article in the InstallShield/Macrovision/Acresso library confirms the noted location is where the IDriver.exe version 7 or 8 should be found.

Once more, I downloaded and installed the latest InstallScript 8 package (which turns out to be the 8.0.0.123 I already had installed), so I then decided to try downloading all the later versions and install them one by one as well.  I was hoping that the Registry setting that resolves to this particular IDriver.exe would be overridden (at least in the “Version Independent ProgID” or something similar) by a later install.  Here’s one set of settings that I figured were related:

  • CLSID: {8B1670C8-DC4A-4ED4-974B-81737A23826B}
  • (Default) value: InstallShield InstallDriver
  • AppID: {1BB3D82F-9803-4d29-B232-1F2F14E52A2E}
  • LocalServer32: C:\PROGRA~1\COMMON~1\INSTAL~1\Driver\8\INTEL3~1\IDriver.exe
  • ProgID: ISInstallDriver.InstallDriver.1
  • VersionIndependentProgID: ISInstallDriver.InstallDriver

Yep, after installing IScript9.msi, the CLSID under the entry HKCR\ISInstallDriver.InstallDriver changed to {B3EDE298-AE75-4A1C-AB7E-1B9229B77BBE}.  However, the uninstall “Fatal error” continued to crop up.  Apparently the fatal application’s uninstaller doesn’t chase the ProgIDs but some other reference instead.

Then by some wild fortune, I happened to stumble on a very obscure directory in which the “later version” of the InstallScript MSI installer (isn’t there some irony embedded in that?) was actually still cached.  WHY this wasn’t available from the vendor’s own web site, I’ll never know.  However, installing this version of IScript.msi did overwrite the ProgID once again, and the version of IDriver.exe installed in the target location was 8.1.0.293.

Somehow, finally, that did the trick.  Finally got that Installshield-driven crap off my system.  Trying to resist the impulse to wipe all traces of Installshield product off my system as well, and reminding myself that I could create this same hell for myself ten times over in so doing.

So, apparently all it takes is for some ancient application to overwrite the better version of an “Installation Engine”, and all hell breaks loose.  I’m beginning to see why the Installshield product line has been bought and sold more times than… well, I’m drawing a blank on a family-friendly comparison, so let’s just say this was not one of the more profitable software businesses out there.  And no freakin’ wonder.

Advertisements

7 thoughts on “Installshield – great for developers, sucks ass for victims (aka everyone else)

  1. It’s not InstallShield’s job to support you, it’s Intel’s job as they are the ISV that packaged that application.Eitherway, good profiling. You’d make a decent setup developer. 🙂As an aside, IS8 is 5 years old. 2 years ago IS12 came out with a completly redesigned scripting engine ( embedded inside the MSI, no pre-installed engine ) that solves these kinds of problems.Still, it’s interesting to note that because of InstallShields brand name, they take the heat, not Intel.

    Like

  2. I agree with Chris: the problem is with the installation package created by the application vendor and not with the tool that was used to create the package. You need to blame the developer who didn’t know what s\he was doing in the first place and not InstallShield.

    Like

  3. Hey this looks familiar to me. Dealing with a similar case uninstalling Microsofts Firewall client 3 on a few hunderd coputers.

    Like

  4. I totally disagree on the following statement “blame the ISV/Intel/install Engineer and don’t blame InstallShield” that is just nonsense!! No one should claim that InstallShield is pullet proof software. After all it is just software with many cool features (bounce up and down in quality level). The reason I’m saying this, three years a go I faced similar issue of what ParaniodMike listed, the different was the engine was installed on a network machine, my package installation will fail subsequently on this particular machines since the engine can not be accessed, also re-installing the engine didn’t solve the problem that much (it was discovering the problem and remove the engine from every machine and reinstall my software) that solved the problem. This was a big hit for us at that time and we used it as a good case to move to MSI (this also doesn’t mean moving to a safe heaven), but at lease staying away from the obvious headache. I like so much the recent InstallShield Custom Action feature however they are four years late after every one out there loved .NET and C++ Custom Actions.Good point though!

    Like

  5. I’m not here to defend the old InstallScript engine design, it sucked. But it has been replaced over two years ago. I know the problems you described can be mitigated because I did so several years ago. You tweak the DCOM AppID launching permissions in the MSI redist and then deploy. This keeps it from resetting itself on subsequent transactions. I’ve written about this ad nauseum over the years so the information is out there. InstallShield has always supported C++ custom actions and up until last month, I was one of the few vocal people showing love for .NET CA’s so I don’t see how you can claim InstallShield was 4 years late to the game. According to my estimation, the whole community ( lead by Microsoft bloggers ) were 4 years late to the game.

    Like

  6. InstallShield (before being acquired) has always taken a lot of pride in the fact that they were practically more recognised by end users than Microsoft. As such, they should have made things easier for end-users to deal with this concoction. That said, as an ex-staffer (google me if you want), I always thought that mixing the IScript engine with MSI was a bad idea. But it was there as a bridge between the ‘old way’ of InstallScript event-driven installers without MSI, and MSI itself, which took away a LOT of flexibility in the installer that InstallScript allowed. By allowing developers to write InstallScript actions, moving from a non-MSI to an MSI model became easier. Granted, InstallShield 8 is old by developer standards, but unfortunately for said developers, InstallShield 7 to 11.5 are STILL OUT THERE. InstallShield 12 has its own problems, amongst them being the fact that calling multiple InstallScript custom actions in sequence slows the system down (because each action requires the registration, invocation, and deregistration of the InstallShield scripting engine). And the only way around that is to lump custom actions together in one amorphous blob of code, the complete opposite of what MSI intends (discrete CA’s that do one and one thing only). We as developers have been overly spoilt by InstallShield at the cost of the consumer. The consumer gets the shaft here, not the developer. The developer can generally hide behind his organisation’s support team (if they have one), the consumer just faces a wall if the vendor washes his hands of the responsibility.So Mike, I am terribly sorry that you had to go through this. I know that in the old days we probably would’ve pulled out the stops to help you (I certainly would have, that’s why I joined the organisation at behest of the founder), but Chris and Colby are correct in saying that your vendor (Intel) should have taken your support call and pulled out the stops to help you resolve this (even if that meant that Intel had to open a call with InstallShield).

    Like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s