Comment 7 for bug 357456

Revision history for this message
In , Focht (focht) wrote :

Hello,

well the custom action thread tries to use MSXML6 COM inproc server and fails because there is no apartment (COM not initialized).
There are basically two problems here.
One part (reuse of existing MTA) is covered by my bug 17902 though CoGetClassObject() is the culprit there.

As for the other part, I found the following blog containing useful information regarding custom actions and COM: http://blogs.msdn.com/astebner/archive/2005/02/07/368917.aspx

--- quote ---
...
This question rang a bell so I dug into some of the emails that have gone across our internal Windows Installer question-n-answer alias and here is the official answer from the Windows Installer team:

"One of the first things that a custom action server does when it is created is to call CoInitializeEx(0, COINIT_MULTITHREADED).

However, the thread on which a DLL custom action is run is different from the main thread (on which COM is initialized) and COM will not be initialized on it. It is up to the custom action to initialize COM to its liking."
--- quote ---

Because the custom action thread which executes "Adobe_ProcessPropertyFile" CA doesn't initialize COM explicitly (not creating apartment), the MTA from the main thread has to be used.

The problem is: there is no custom action server the blog talks about here which does this.
Msi will be called in the context of installer threads which might have or have not initialized COM in various ways.

One solution could be to have Wine's Msi create a dedicated thread serving as "fake" CA server main thread which creates an MTA if not already exist by calling CoInitializeEx(NULL, COINIT_MULTITHREADED).
All custom action threads that don't explicitly initialize COM would be then part of that MTA (which is guaranteed to be an MTA, not relying on installer STA threads).

Regards