6 replies to this topic

[VBScab]

The app in question is TradeWeb v7.04. The vendor assures us that it's 7.04 but the version property is '7.3'...which speaks volumes about quality control.

When deployed per-user (a site requirement) via GP, the install fails at the FeaturesInstalling CA which is one of the first CAs. I can install it fine if I RunAs a local admin. I have reset the IS driver (it requires - and checks for! - v7.7.02) COM+ stuff to be 'Launching User' rather than the default 'Interactive User'. The error logged is:

MSI (s) (98:F4) [12:30:26:813]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSI13E.tmp, Entrypoint: FeaturesInstalling
1: Invoke Function fails, Error = 0x8000ffff

Googling for the error just brings up a bunch of stuff about it occuring for re-installs but this is on a virgin VM which has never seen the app before. If I can't get to the bottom of this, I'm just going to re-package the damn thing.

[Zweitze]

Error 0x8000ffff occurs when a COM client calls a COM server, and this COM server raises an exception, but fails to handle it. The Windows layer between client and server intercepts the exception and sends 0x8000ffff to the client. In some environments (eg. Delphi) you'll get the error text 'Catastrophic error'.

In your case the COM client is the 'FeaturesInstalling' CA, ask the vendor which server it is calling.

[VBScab]

[Zweitze]

Check the type of the CA. If its a VBScript CA, you can open the source and check for a statement like:

CreateObject("MyPoorlyWrittenComServer.App")
or
GetObject("SomeComServerThatIsAlreadyRunning.App")

Basically anything calling CreateObject / GetObject. The CreatObject call itself does NOT fail, but some method on the returned object does.

If the CA is a DLL CA then it's sources call something like

CoCreateInstance(<CLSID>)
or one of its friends.

Again, that call actually succeeds, but the invocation of one of its methods fails.

In this case it's harder to figure out which object failed, unless you have access to the sources of the CA.
I believe (not sure) that some old Platform SDK has a utility similar to ApiMon: Where ApiMon lists all Win32 APIs called, that utility lists all instantiated objects, and their methods invoked.
Alternatively you can debug that CA, step through it, check which DLLs get loaded along the way etc.

I don't think it's the IS Driver, but you could check this using a fresh system with a correct driver version * and no newer versions *.
Based on your starting post about COM+ an educated guess would be WMI, maybe the author is using that technology to set the behavior of the COM+ app.

[VBScab]

[Zweitze]

For the record I'm curious how you figured out that the IS driver is the offending software - or did Tradeweb tell you that this was the only thing they were using inside InstallFeature?

I do know that the IS driver is not a COM+ application. Then again, the error tells you that a COM Server fails, not a COM+ application.

[VBScab]

OK, to finish this puppy up, I got the install to complete by:
- resetting the DCOM permissions for all 'InstallShield Driver' COM+ servers to 'Launching User', using a widely-available script in a CA placed very early on in the Deferred sequence
- set the OnFeaturesInstalling CA from 'System Context' to 'User Context' (for Orca fans, I edited the 'Type' value 3073 to 1025)

Edited by VBScab, 23 January 2008 - 12:15.